Maemo 6 "Harmattan" was fully Qt based. And while it said "MeeGo 1.2" on the device, it really was just Maemo 6 with some compatibility stuff to make it act similar to the MeeGo specifications. One difference was for example that MeeGo was going to use RPM packages, whereas Harmattan used dpkg, just like Maemo 5 had. There were also differences in things like the phone stack, the contacts management, sync framework, etc.

Otoh, while it was Qt based, the UI stack was slightly schizophrenic. Nokia developed a set of libraries called "Maemo Touch Framework" internally initially for the platform, but that turned out to be horrible to work with. Meanwhile the Qt guys developed QML/QtQuick. Then, when the N9 was released, Nokia pushed QtQuick as the platform to build applications on - while all the on-device applications and a lot of the tooling was done for MTF.

Maybe a physics postdoc? Estimate the amount of electrons, neutrons and protons in a cup and in five pennies, then figure out what the resulting object is. My guess is you end up with a donut.

And only if you're a spherical cow in a vacuum.

Anyone know how many clones of WebKit and related projects are on GitHub? Because I can imagine that pretty much skewing the statistics for C++ due to this: https://trac.webkit.org/browser/trunk/Source/WTF.

Except, of course, for the simple fact that the Nexus 4 is the fourth Nexus phone. Though I guess we will have to wait for the new Nexus phone to see if they continue with different names.

Did he at least get triple word score?

There are several problems with XML in this context though. For starters, writing anything based on XML by hand sucks. Not that TeX is perfect, but it is quite a bit more pleasant to write than XML.

Furthermore, XML based things like DocBook only solve a few - if any - of the issues outlined in the article, since they are only a way to describe content and structure. It is still up to whatever engine you use to convert things to PDF or another "reading" format. And this is also where these solutions fall short, since most of these engines are nowhere near as advanced as the TeX engines when it comes to generating actual documents. In fact, they are usually converted to HTML. I have yet to see an HTML engine that handles hyphenation, ligatures, justicfication and similar typesetting related topics anywhere close to what TeX engines do.

Something else mentioned in the article is programming within the document. This is an area where TeX really is not all that great, but at the same time it is yet another item where XML is worse. If you have ever done anything like XSLT you will know that simple if/then/else constructs can get very large very quickly. The solution in general seems to be to embed another language within your document - JavaScript being the obvious option there. However, as LuaTeX proves, that solution is really not exclusive to XML.

Except that quantum mechanics states no such thing. The term "to observe" in this context means "to interact with" and refers to the collapse of a wavefunction when two particles interact. There is no need for an external observer in this process. In addition, recent interpretations of quantum mechanics completely drop the concept of wavefunction collapse and state that everything can be in a superposition. Schrödinger's cat is actually a thought experiment that criticises wavefunction collapse and suggests superpositions can carry on to macroscopic scale.

Wayland support is still ongoing, but has been put at a lower priority since Wayland itself is hardly stable yet. As for Qt5, it's supposed to be released somewhere at the end of summer. KDE will likely only start switching with Qt 5.1. Presumably it should take relatively little time to port to Qt 5, at least not nearly as much as Qt 3 to Qt 4. Of course, for KDE there is also the KDE Frameworks 5 work to consider. In the end, I am not sure what the impact will be. We will just have to wait and see when it is released.

Right click the title bar, go to "Advanced -> Special Application Settings" or "More Actions -> Special Application Settings" and then under Size & Position check "Desktop" and use "Force". In 4.9 you can do the same with Activities, by the way. In addition, this can also be configured through "Window Rules" under "Window Behaviour" in System Settings. In fact, the above method is just a shortcut for this.

It is not just a matter of not having that mutation, it is also a matter of having a completely different metabolism. All mammals are warm-blooded, which means we need energy to keep ourselves warm. The larger you are, the more energy you need to keep yourself warm. Needing more energy means needing to eat more and needing a larger area to sustain you. At some point, you will hit a limit where if you grow bigger, you can no longer sustain yourself. For our current environment, this seems to be around the size of an elephant for land animals.

Obviously that it will now become Cb (C-flat)...

QML is as close to JSON as it can be while still supporting all the features that are needed for the concept to work. I'm not sure in what way you would like for it to be closer to JSON? I suppose the most major difference is that where JSON is weak typed QML is stronger typed. Properties are pretty strong typed, whereas the included JavaScript in signal handlers and other places is (obviously) completely weak-typed. But even the stronger-typed properties are not as strongly typed as they would be in C++.

For example, objects use introspection to resolve functions, meaning that I can call any exposed method on that object. The same goes for properties on objects. Where the strong typing appears is when you want to assign something to that property - an object property will throw an error when you try to assign an int and vice versa. While I personally appreciate it, I believe this was mainly done to ease the integration between QML and C++, since it becomes easier to optimise method calls if you do not need to parse the type at every call.

Agreed. We're currently about two years into a GURPS story. Personally I think the best part about it is the fact that it lacks any hard-defined setting. Yes, that means your GM needs to do more work up front, but then again, it also allows the GM to completely determine the setting. Our story is set in a Stargate-ish modern setting with Sci-fi elements, something that you won't quickly find in any of the "pre-defined" settings.

On the other hand, looking at it from the side of kernel development, why should kernel development be slowed to support the broken business model of existing companies?

In addition, there are also solutions to this problem, see things like DKMS and the NVidia drivers. Most of the time, switching kernel just requires a recompilation of the kernel module, which is exactly what DKMS handles. Heck, even the Catalyst driver usually deals fine with newer kernels, it is the X server that is the issue there. So this issue is mostly solved.

Android uses the Linux kernel. So you are saying that they do not target Linux yet they do?