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.

Qt on the other hand is available in LGPL, GPL or proprietary licensed form. You are free to pick whatever works best for your project. I really fail to see how GTK can be better than that on the licensing front.

Sorry, but that is just not true: moc does add meta data on objects (their methods, properties, etc.) that is _not_ available in ANSI C++. Not even with C++11.

I would argue exactly the other way around: Qt is stand-alone and GTK is not. If you want to write any app you need more than the UI. You actually want the application to *do* something but render a couple of widgets.

With GTK you end up hunting down a host of glib/gnome based libraries, all with slightly different peculiarities and all of them coming with little useful documentation. How is that stand-alone? With Qt you get everything in one convenient package (and are still free to leave out the parts you do not need in your binary packages).

Qt is a C++ library: Any C++ compiler can compile it on a wide range of platforms. How would that be possible if Qt was written in a weird dialect?

Of course the object model leaks into the language bindings. How could it not be? The same is true for "object-oriented" libraries written in C.

Yes, even with Qt you can not get perfect cross-platform applications. You will need to some platform-specific code in any non-trivial application. That is perfectly possible in Qt... and it still gets you at least 90% of the way! That was the other reason for switching that Dirk gave in his presentation: That GTK does *not* run properly on windows nor on Mac. He claimed that some core GTK people are actually opposing the toolkit working on those platforms and that independent teams are trying to maintain the cross-platform parts as good as they can against a hostile core team.

Subsurface was cross-platform with GTK and it looked like shit on *all* platforms incl. Linux. The Qt port looks way better -- they could finally get the UI they wanted but could not manage to implement in GTK -- and works equally well on all three target platforms. Check the demo right in the middle of the video: Dirk shows of the new UI and contrasts it with the old one in pretty gory details. So, yes, Qt is not perfect, but it is pretty good nontheless:-)