That kill apache, not the crap it started and that forked itself away.

Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.

That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your first sysv-init based Linux ever either;-)

I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.

At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?

With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.

A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.

Read a couple of man-pages and see for yourself.

You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.

You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache

Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.

I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.

Check out http://www.freedesktop.org/sof... , especially all the options starting with "Private" there.

Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.

Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.

Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.

The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.

If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.

You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.

That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.

Read the code, it is actually pretty ok.

No, but it can start a service for you that can.

If you think sysv init is not broken, then you must not have been using unix systems in earnest.

It is only simple till you want to have a reliable boot without races... BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?

You are aware that udev is part of that tree you are proposing to delete? With eSATA harddrives coming and going, projectors that get attached at random times, all kinds of gadgets with USB connectors? No thanks, I want something that I do not need to change a the boot script and then reboot when I plug in a mouse.

Let me keep systemd and go straight for a beer instead of bombing my system back into the 60s.

That way I can also update all the software I care about (much of it already depends on systemd or will do so soon), I get
* the journal instead of a set of randomly formatted text-dumps all over /var/log,
* a convenient way to kill apache with all the crap that it started,
* a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
* a more secure system by being able to isolate daemons from one another and the rest of the system.
* a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them

Sheesh:-)

I once got asked a question which I found hurtful and offensive, and felt tempted to 'blow up' the interview at that point. Fortunately, I resisted the temptation. As it turns out, the question was his way of introducing the next thing, which was telling me that he was offering me the job.

I do not see what you are going at: UTF-8, UTF-16 and UTF-32 are all different encodings of the same unicode characters. All of them can hold all defined unicode characters. I fail to see how Latin1 comes into the discussion... that is a subset of unicode that is available (just as all other unicode characters) in all unicode encodings. For a programmer it makes very little difference API-wise whether a string uses UTF-8, UTF-16 and UTF-32 internally.

UTF-16 does use a more RAM to hold a ASCII string than does UTF-8 (in fact twice as much). OTOH it uses less space than UTF-8 for most non-ASCII languages. So what is better depends mostly on which nationality you code for.

That is non-sense. Trolltech was very much not Nokia!

And even if: Both Trolltech and Nokia are no longer in the game. Nokia sold the Qt trademark (along with most of the Qt devs) to Digia about two years ago. Qt was long gone when Microsoft bought Nokia.

I am still pretty sure Digia will not come after you to shake you down for all your profits. Digia is a small company (compared to Nokia at least). Heck, Digia does not even own patents AFAICT.

First I am almost 100% sure that there will be some idiots employed by Intel somewhere. Every big company has some of those around. So "works for company X or Y" is not a qualification in my book.

Second Dirk is making it very clear that he is speaking as a private person about a hobbyist project of his, not as an employee of some company. So there is no reason to bring the company into the discussion. People will misread the headline to mean that this is something that Intel is doing. Just check this thread: One misguided individual is asking: "How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing?".a couple of comments down. It is not Intel speaking, it is not even "their developers". It is just one single guy speaking about something that is not related in any way to what Intel does. These misunderstandings were needlessly created by the headline.

Seriously: This is slashdot. How many people here on slashdot bother reading more than the headline? :-)

You are aware that you this is a project founded by Linus himself and that Dirk is involved with open source development since 1988, often working at the kernel and other core infrastructure you are likely to use if you run Linux?

I somehow doubt that these two are not aware of how open source works. I am further convinced that they are bright enough to figure things out on their own by reading the code and/or using the internet.

Sorry, but that is non-sense. C++ support has always been and will always be a focus of Qt development.

During Nokia times the QWidgets were considered to be "done" in the sense that there were no new exciting features expected to happen. But then widgets are pretty well used for years, pretty complete (all the standard stuff is there and you will need to write the rest anyway) and the APIs were hammered down ages ago. Bugs were going to be fixed as they are reported, so the code was and is fully supported. I think you are referring to this... it was awfully badly communicated back then and did raise quite a ruckus.

That was the state when Nokia was still at the helm: Digia is putting way more resources into "classic desktop parts" than Nokia did and with that widgets do see more love again.

Canonical did not ditch gnome3: They used all the bits and pieces and just replaced desktop itself. Unity was written in GTK, just like gnome, so there was no productivity win there. And the problem was IIRC more that way the switch was communicated (or better: not communicated) than the switch itself.

It is Dirk speaking here, not Intel. He makes that very clear during his presentation. Dirk just happens to work for Intel -- which somehow makes this newsworthy. This is definitely not Intel that made the announcement to not like GTK anymore.

No, GTK does not do what moc does in C.

Gobject introspection does something similar to what moc does. Gobject introspection is a code generator that reads XML files and produces code from that. Moc takes similar information right out of the header. Both use that information to generate code.

Signals/Slots in Qt just make use of that information that moc generated. Note that Qt 5 does allow you to use signals/slots without that information as well. But you still need the information moc generates for other purposes (language bindings, introspection, some debugging tools use it, etc.).

Yeap. But Boost does not allow to inspect which signals/slots and properties are available on any given object.
That is the information moc generates. Signals and slots in Qt just use that information, just as a host of other things including the language bindings, some runtime debugging tools and lots of other things.

So Linus and Dirk are not compatible with 'old'-style linux users? That is hilarious.