QML is just for GUI stuff, but you can add logic to the interface in JavaScript. Some people are claiming that Qt is losing its C++ roots, but, IMHO, they are wrong. QML will replace the UI files that Qt Designer created, but with lots of advantages. First, QML can be written by hand, and also with a very smart QML Designer that only modifies the lines that you change. That means that designers and coders can easily work together, and that changes to the UI are readable in the history of the project.
The other important benefit of QML, is that is really fun to use, and you can create compelling user interfaces with a fraction of the time. Then you can plug your C++ very easily to do the heavy lifting. The thing that makes Qt Quick excel, is that you can mix QML and C++ very easily throught the Qt property system and signals and slots.
Qt is binary compatible across minor releases, not just bugfix releases (that is the Y in X.Y.Z, not just Z). Right now we have 4.7.3, but you can replace it with 4.8.0 (is in beta, IIRC) without recompiling any application. If this doesn't work, is a bug, and should be fixed. I am pretty sure of this for several reasons:
First, because I use Debian unstable, and each time a new Qt minor version is uploaded, the whole bunch of packages that depend on it are not recompiled.
Second, because this would not be acceptable for proprietary applications that can not recompile third party stuff.
Third, because Symbian^3 devices, like my Nokia C7 (won in a Qt contest, BTW), had 4.6 by default, but now you can upgrade to 4.7, and no application requires a recompile (in general, you can't recompile apps from the Ovi Store, of course).
If you look closely at that bugreport, you will see that is clearly stated: "Fix Version/s: 5.0.0 (Next Major Release)", at the same time that mentions that can't be done due to binary compatibility. If the ABI could be broken in minor releases, that could be fixed in 4.7 or 4.8. Not necessary to wait till 5.0.
(...) if their names were actually attached and the comments could follow them home.
You mean your case? Because in mine, I sign my comments with my nickname, which in 1 minute can lead you to my real name and some of my websites, where I clearly state my name, and whose domains are owned by me. Heck, I even link to my site here. You don't need the Googling.
Qt 5 will be binary incompatible with Qt 4 because they will reorder libraries and modularize them. KDE will do the same with their Frameworks. However...
Qt 4 will require very few changes in the source code. Yes, they will drop the Qt3 support, but very few KDE apps use the Qt3 classes support (of the apps that I use, only JuK to my knowledge).
KDE 5 and Qt 5 will be mostly a major version bump because of the binary incompatibily that can't happen without a change in the major number. Some applications might not need any source code changes, or very few.
By far the most common complaint I see about X is "OMG IT'S SLOW BECAUSE IT ALWAYS RUNS OVER THE NETWORK!!!!!!!!". (...)
As far as I can tell, anyone who's backing Wayland has no actual concrete complaints about X, they just feel the need to rewrite everything from scratch
Have you bothered to read the article about Wayland's architecture? The problem with X11 is not the network transparency or the fact that it is not invented by the author. The problem, AIUI, is that the X server has to interchange lots of information with the compositor because each handle pieces of the information that should not be split. If a click happens, the server handles it, but the compositor can modify the aspect of a window, so the server requires information from the compositor too. Wayland fixes this merging the server and the compositor. This has nothing to do with the network transparency.
.NET abstracts away dealing with low-level pointers, everything is "managed" by the framework so it is freed when no longer used (it is still possible to leak memory by keeping references to things you don't use anymore, but the framework can only do so much for you), and various attempts to attack your program with buffer overflows etc to run shellcode wouldn't work because your high-level program doesn't deal with pointers, and.NET internals will stop buffers from overflowing (etc)
Then welcome to the world of interpreted languages. Replace.NET with Perl, Python, Java, Ruby or a ton of other languages that existed prior to C#, and this sentence makes the same sense.
Plus you have a ton of useful libraries already included. Want to pull a file from the web? No problem, create an object to represent your request, a callback to handle the response object, then send it out. Want to parse XML? One function call and you're left with a tree of XMLNode objects to walk. Maybe you can find amazing libraries for C++ but you're starting from scratch (well you had to at one point, at least) and have to check licenses on them all, etc. With.NET you start off with a good base of libraries you can use in your apps for free.
So what? Do you really think that there aren't awesome libraries with permissive licenses that can be used in any language or framework? I don't have much experience with Python, Perl, Ruby or Java, but a quick search on the list of Debian packages with "aptitude search language | wc -l" reveals more than 900 names with Ruby, 2800 with Python, 2700 with Perl and 1200 with Java (of course, not every library is packaged, and many results are bogus). This list of course includes XML and networking (and other importang things), but also more esoteric use cases, like an IRC bot or colorizing logs. All of this in a more cross platform way than.NET.
I'm not saying that.NET is bad. Probably for some specific use cases is the best. But overall, I doubt it's better than others, and I'm pretty sure it isn't worth the effort of creating it, unless you are Microsoft and have tons of cash to spare in an endevour to lock-in applications to your OS.
In general, I agree with you. The fact that Debian compiled all their packages on different architectures made software better, because it allowed to catch lots of endianess bugs, or 32bit-isms, even if nobody was using that software on that arch. Nobody was using KDE 3 on ARM, but now there are packages of some KDE 4 applications and technologies on ARM.
The problem is that making some compromise is necessary, or nobody will do vertical integration. For example, there are applications that could make use of file system metadata, but since the application developers strive for portability, they can't rely on it for important uses. Okular stores a configuration file for each file that opens, saving the page you were reading when you closed. If you store that information on the file system you can rename the file or remove it and everything is consistent. If you rename the file you lose that feature, and if you delete it you have a useless file lying there on your configuration. In this case is not a big deal, and I would not advocate to make this feature only available to systems with file system meta data. But there are situations were the compromise can at least be questioned and discussed, and dropping support for some platforms if there is an added gain that is more valuable, sometimes makes sense.
Have you bothered to read the interview? Lennart was talking about free software developers that cold be held back by the differences between Linux and BSDs. Those differences add complexity to support another OS that has small market share in the desktop OS in comparison with Linux (and this point is assumed, I don't know if it's proved somewhere).
That's sad but true, and happens everywhere. Sometimes you see how in the XDG list developers of one system (e.g. GNOME) are held back because KDE or XFCE don't invest the same amount of resources to one topic, while the opposite happens too (KDE moves forward in one topic that GNOME lags).
Want more examples? Debian wants to be an universal OS, so they have to support a wide variety of architectures, and now even different kernels. That's good, for sure (I'm a happy Debian user), but you have to admit that is a price that not everyone agrees if it's worth to pay.
The nVidia packaging was broken in Sid for one day or two because they added the multiarch support IIRC. I rolled back to the version of the previous day using the way back machine (or your package from/var/cache/apt/archives). That's the usual bread and butter for someone who wants to use Sid (is called Debian unstable for a reason).
And nVidia is working perfectly right now. I've been playing Open Arena as always just minutes ago. And the nVidia packaging is pretty damn good. The nvidia-dkms works like a charm, even if you upgrade the kernel. Of course I would still prefer open source drivers, since that would mean even less pain, and everything would be integrated. I'm pretty sure that my next graphics card will have open source drivers.
(...)the Spanish domain name, formerly a hub of illegal sports content (...)
Is a Spanish-focused site, and in Spain, file sharing is not proved in court to be illegal (some argue that it is, some that don't, but certainly no judge has pronounced the word "guilty" to a file sharer). But the summary is even more wrong. Quoting Roja Directa's blog:
Not only does Rojadirecta not transmit the aforementioned content, but it does not directly transmit any other type of audio or video content. Rojadirecta is simply an index of sporting events available on the Internet and not a provider of audio and video content.
Don't know about the US, but this is certainly not illegal in Spain. That's why the government has introduced Sinde's bill. Sinde's bill allows a civil commission (yes, bypassing courts!) to seize websites that link to content. I wonder if they will try to shut down Google or Bing.
The very first sentence to me sums up why Linux is not successful on the desktop relative to Windows for OSx.
Sorry, but I find this a ridiculous point. I expect from Slashdot some degree of technical level. If Slashdot summaries had to explain everything understandable to "normal desktop users", I would had to find another place to read. Xen is not music player, and requires some knowledge. To me is a product addressed to technical people.
Exactly, just a quick look at the dev blog shows the following updates with respect to new features (some stable releases, some tech preview):
QML Scene Graph in master branch
Qt Webkit minor releas
Qt 4.8 tech preview
Updates on Qt Creator, and its integration on the SDK
Updates on the open governance
Qt Quick 3D
Qt Mobility 1.2
First plans for Qt 5
This is only during May. If anything, I see Qt more alive than ever.
There is also the misconception that only the Qt developers do interesting research and add features. That's very wrong. Lots of KDE ideas were implemented in Qt at one point or another. Also note that companies like Digia or ICS (and several others) are now way more involved in Qt than ever, and will be more once the open governance transition finishes.
If anything, Nokia is exactly the one to blame for doing that. They broke compatibility across Maemo releases (IIRC).
In Maemo 5, when TrollTech and Qt was already in the company, they release the whole OS based on GTK+, but they say that the future is Qt (agreed), and release Qt 4.6 updates for the N900 with some specially crafted widgets for Maemo 5 integration. However, they are at the same time developing Qt Quick, which only appears in Qt 4.7, and yes, it's way better, but is yet another change for developers.
The change to Wayland is transparent for developers. They are expected to write stuff in Qt, so they should not worry about that.
Oh,and BTW, the next device from Nokia, is not MeeGo, is Harmattan (more or less Maemo 6). It's compatible WRT the API (uses Qt), but is still based on DEB, not RPM, so is not really MeeGo, and not binary compatible.
You can think of MeeGo as "just" a Linux distribution. However, it's optimized and focused in bringing the usual Linux stack to all sorts of devices (TVs, cars, phones, tablets...).
It's a true open source project, or at least, it aims to be (is just beginning), and provides some sort of tools, and middleware. It's also a specification that you have to comply if you want to be MeeGo certified, so you can grant that software runs on all MeeGo devices.
Has some Fedora user tried LLVMpipe with some desktop apps that require OpenGL (like Gnome Shell)?
LLVMpipe is supposed to bring CPU-based rendering to apps that otherwise would require a working graphics card with OpenGL support. Seems backwards at first, but it would be a more coherent experience: if you don't have working graphics drivers, you have the same experience (slower), instead of a fallback mode, or a different implementation (like Unity 2D instead of the "normal" Unity).
It could also pave the way for Qt 5 apps, because Qt 5 is going to require OpenGL too. If LLVMpipe works decently it would be an improvement for developers. They could use OpenGL features to make their lives easier, without worrying too much about if the user has proper drivers.
As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?
There is a rumor about this. Some people thought that it would be possible to add S40 support in Qt. I thought that S40 phones are too small and cheap to run powerful apps, and the demand for applications for this platform is quite small, but... Stephen Elop and Mary McDowell visited Qt headquarters. McDowell is the head of "mobile phones", which is the feature phone (or "dumb phone") division in Nokia. Given that Windows Phone is only targeted at high end, some of the market space that Symbian covered has to be swallowed by S40 too.
Given that Nokia is also very serious about the emerging markets (India, China, etc.), where they still have a strong position, this makes some sense. I'm not specially excited about this and is just a rumor, but makes sense. There is also MeeGo. I think they would be very stupid to drop it completely, specially if they have to pour money to release one device and maintain it first.
"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"
Very wrong. Look at the list of maturity and status of Qt modules. Nokia still is ready to maintain a huge percentage of Qt. They simply deprecated stuff because they think that other alternatives are better (eg. ditch Phonon because there is QtMultimedia). The only piece that Nokia is not interested in maintaining and that the comunity is worried about, is QtSVG, because the alternative, the SVG support in Webkit, is considered too big/slow, or unsuitable for being LGPL only.
This is Qt development frameworks (aka "old Trolltech") being honest in what they are interested about.
Oh, and being even more open in how they develop (they already have public BTS and reports).
When they release Ice Cream Sandwich, the Honeycomb source will be in the patch history. What they may not bother to do is to tag the specific commit of Honeycomb.
This is not true if Honeycomb is developed in its own branch, and Icecream is developed from master, i.e., based on Gingerbread, not on Honeycomb. This is very likely. Cyanogen stated that 2.3 and 3.0 were developed in parallel.
What I fail to see is what exactly from the MS world is Mono useful for in the Linux/BSD/free software world. We more or less see how new versions of Gnash are more or less ready to play YouTube, or something like that (some goal that is useful for average Joe). But what is Mono useful for? Yes, there are some GNOME applications, and still many GNOME users try to avoid them. What non-GNOME applications from Windows is Mono capable of running? And how useful are them? Is really worth the effort? I don't have the answer, but I must see something significant before I can answer yes, and I fail to see it (and sorry if it's my fault).
I fail to see the link where you point to the research that proves that names in the open source world are worse than in the proprietary world.
Look, naming is hard, and of course some names suck and could be replaced by something better. But you are nuts if you think that the naming that (for example) Apple does makes any sense to a non-English speaker. Even with the huge popularity of iTunes I've heard this name said in a lot of different ways (how is read in Spanish, and how is read in English, but with very different levels of success).
And with other products it's the same. I had a really hard time spelling Google or Youtube when they were not widely known. Does the Windows name give you any hint that is an operating system? And iOS is easy to write or to pronounce or understand? Why Photoshop is not for buying things? How the hell QuickTime makes you thinkg about video? And so on.
And after you've asked that prepubescent child how many centimeters are in a kilometer, ask him whether knowing that will ever matter.
I can think of many practical situations where someone might need to do calculations like that. For example, how do you think that one measures the amount of people are in a demonstration? You know how many squared centimeters a person fills, and how many squared meters of a street are full of people. Or how many cars are trapped in a congestion? You know the average length of a car (in meters), and you use your helicopter images to know how many kilometers of the highway are full of cars.
I'd could go on and on. How many cans/books/whatever will fill your shelf? How many boxes will fill your truck?
KDE runs awesome in my 2.2GHz processor with a passively refrigerated graphics card (with all the graphics effects), and with about 512MB of memory used if only KDE4 apps are used (which is 95% of my time). And if you read the blogs, you have the explanation about why it runs really good on small devices if the drivers are properly set up.
I would test it the same way I would test JavaScript code. With JavaScript, you don't have the certainty that the V8 engine behaves the same and has the same bugs on x86 and ARM, but in general it does (for the majority of cases). With other interpreted code, or with NaCl the situation is the same.
Native Client requires an implementation for each architecture, true, exactly the same thing that happens with native compilers. Since the project is still young, they started with x86 and it might be the more mature implementation, but there are versions for x86-64 and ARM. You only need a recompile to target different architectures. The API is cross-platform.
For the purpose of NaCl, all the abstraction layers of hardware are the problem, not the solution. Sometimes you just need the extra performance (or the possibility of using C/C++ code for a web tool).
Slashdot Mirror
QML is just for GUI stuff, but you can add logic to the interface in JavaScript. Some people are claiming that Qt is losing its C++ roots, but, IMHO, they are wrong. QML will replace the UI files that Qt Designer created, but with lots of advantages. First, QML can be written by hand, and also with a very smart QML Designer that only modifies the lines that you change. That means that designers and coders can easily work together, and that changes to the UI are readable in the history of the project.
The other important benefit of QML, is that is really fun to use, and you can create compelling user interfaces with a fraction of the time. Then you can plug your C++ very easily to do the heavy lifting. The thing that makes Qt Quick excel, is that you can mix QML and C++ very easily throught the Qt property system and signals and slots.
Ales & stouts for life! The harder it is to see through, the better it is!
You never enjoyed a Pale Ale, do you? Is an ale, and... well, is as pale as the average lager.
Qt is binary compatible across minor releases, not just bugfix releases (that is the Y in X.Y.Z, not just Z). Right now we have 4.7.3, but you can replace it with 4.8.0 (is in beta, IIRC) without recompiling any application. If this doesn't work, is a bug, and should be fixed. I am pretty sure of this for several reasons:
If you look closely at that bugreport, you will see that is clearly stated: "Fix Version/s: 5.0.0 (Next Major Release)", at the same time that mentions that can't be done due to binary compatibility. If the ABI could be broken in minor releases, that could be fixed in 4.7 or 4.8. Not necessary to wait till 5.0.
(...) if their names were actually attached and the comments could follow them home.
You mean your case? Because in mine, I sign my comments with my nickname, which in 1 minute can lead you to my real name and some of my websites, where I clearly state my name, and whose domains are owned by me. Heck, I even link to my site here. You don't need the Googling.
Qt 5 will be binary incompatible with Qt 4 because they will reorder libraries and modularize them. KDE will do the same with their Frameworks. However...
Qt 4 will require very few changes in the source code. Yes, they will drop the Qt3 support, but very few KDE apps use the Qt3 classes support (of the apps that I use, only JuK to my knowledge).
KDE 5 and Qt 5 will be mostly a major version bump because of the binary incompatibily that can't happen without a change in the major number. Some applications might not need any source code changes, or very few.
By far the most common complaint I see about X is "OMG IT'S SLOW BECAUSE IT ALWAYS RUNS OVER THE NETWORK!!!!!!!!". (...) As far as I can tell, anyone who's backing Wayland has no actual concrete complaints about X, they just feel the need to rewrite everything from scratch
Have you bothered to read the article about Wayland's architecture? The problem with X11 is not the network transparency or the fact that it is not invented by the author. The problem, AIUI, is that the X server has to interchange lots of information with the compositor because each handle pieces of the information that should not be split. If a click happens, the server handles it, but the compositor can modify the aspect of a window, so the server requires information from the compositor too. Wayland fixes this merging the server and the compositor. This has nothing to do with the network transparency.
Then welcome to the world of interpreted languages. Replace .NET with Perl, Python, Java, Ruby or a ton of other languages that existed prior to C#, and this sentence makes the same sense.
Plus you have a ton of useful libraries already included. Want to pull a file from the web? No problem, create an object to represent your request, a callback to handle the response object, then send it out. Want to parse XML? One function call and you're left with a tree of XMLNode objects to walk. Maybe you can find amazing libraries for C++ but you're starting from scratch (well you had to at one point, at least) and have to check licenses on them all, etc. With .NET you start off with a good base of libraries you can use in your apps for free.
So what? Do you really think that there aren't awesome libraries with permissive licenses that can be used in any language or framework? I don't have much experience with Python, Perl, Ruby or Java, but a quick search on the list of Debian packages with "aptitude search language | wc -l" reveals more than 900 names with Ruby, 2800 with Python, 2700 with Perl and 1200 with Java (of course, not every library is packaged, and many results are bogus). This list of course includes XML and networking (and other importang things), but also more esoteric use cases, like an IRC bot or colorizing logs. All of this in a more cross platform way than .NET.
I'm not saying that .NET is bad. Probably for some specific use cases is the best. But overall, I doubt it's better than others, and I'm pretty sure it isn't worth the effort of creating it, unless you are Microsoft and have tons of cash to spare in an endevour to lock-in applications to your OS.
In general, I agree with you. The fact that Debian compiled all their packages on different architectures made software better, because it allowed to catch lots of endianess bugs, or 32bit-isms, even if nobody was using that software on that arch. Nobody was using KDE 3 on ARM, but now there are packages of some KDE 4 applications and technologies on ARM.
The problem is that making some compromise is necessary, or nobody will do vertical integration. For example, there are applications that could make use of file system metadata, but since the application developers strive for portability, they can't rely on it for important uses. Okular stores a configuration file for each file that opens, saving the page you were reading when you closed. If you store that information on the file system you can rename the file or remove it and everything is consistent. If you rename the file you lose that feature, and if you delete it you have a useless file lying there on your configuration. In this case is not a big deal, and I would not advocate to make this feature only available to systems with file system meta data. But there are situations were the compromise can at least be questioned and discussed, and dropping support for some platforms if there is an added gain that is more valuable, sometimes makes sense.
Have you bothered to read the interview? Lennart was talking about free software developers that cold be held back by the differences between Linux and BSDs. Those differences add complexity to support another OS that has small market share in the desktop OS in comparison with Linux (and this point is assumed, I don't know if it's proved somewhere).
That's sad but true, and happens everywhere. Sometimes you see how in the XDG list developers of one system (e.g. GNOME) are held back because KDE or XFCE don't invest the same amount of resources to one topic, while the opposite happens too (KDE moves forward in one topic that GNOME lags).
Want more examples? Debian wants to be an universal OS, so they have to support a wide variety of architectures, and now even different kernels. That's good, for sure (I'm a happy Debian user), but you have to admit that is a price that not everyone agrees if it's worth to pay.
The nVidia packaging was broken in Sid for one day or two because they added the multiarch support IIRC. I rolled back to the version of the previous day using the way back machine (or your package from /var/cache/apt/archives). That's the usual bread and butter for someone who wants to use Sid (is called Debian unstable for a reason).
And nVidia is working perfectly right now. I've been playing Open Arena as always just minutes ago. And the nVidia packaging is pretty damn good. The nvidia-dkms works like a charm, even if you upgrade the kernel. Of course I would still prefer open source drivers, since that would mean even less pain, and everything would be integrated. I'm pretty sure that my next graphics card will have open source drivers.
(...)the Spanish domain name, formerly a hub of illegal sports content (...)
Is a Spanish-focused site, and in Spain, file sharing is not proved in court to be illegal (some argue that it is, some that don't, but certainly no judge has pronounced the word "guilty" to a file sharer). But the summary is even more wrong. Quoting Roja Directa's blog:
Not only does Rojadirecta not transmit the aforementioned content, but it does not directly transmit any other type of audio or video content. Rojadirecta is simply an index of sporting events available on the Internet and not a provider of audio and video content.
Don't know about the US, but this is certainly not illegal in Spain. That's why the government has introduced Sinde's bill. Sinde's bill allows a civil commission (yes, bypassing courts!) to seize websites that link to content. I wonder if they will try to shut down Google or Bing.
The very first sentence to me sums up why Linux is not successful on the desktop relative to Windows for OSx.
Sorry, but I find this a ridiculous point. I expect from Slashdot some degree of technical level. If Slashdot summaries had to explain everything understandable to "normal desktop users", I would had to find another place to read. Xen is not music player, and requires some knowledge. To me is a product addressed to technical people.
Exactly, just a quick look at the dev blog shows the following updates with respect to new features (some stable releases, some tech preview):
This is only during May. If anything, I see Qt more alive than ever.
There is also the misconception that only the Qt developers do interesting research and add features. That's very wrong. Lots of KDE ideas were implemented in Qt at one point or another. Also note that companies like Digia or ICS (and several others) are now way more involved in Qt than ever, and will be more once the open governance transition finishes.
If anything, Nokia is exactly the one to blame for doing that. They broke compatibility across Maemo releases (IIRC).
In Maemo 5, when TrollTech and Qt was already in the company, they release the whole OS based on GTK+, but they say that the future is Qt (agreed), and release Qt 4.6 updates for the N900 with some specially crafted widgets for Maemo 5 integration. However, they are at the same time developing Qt Quick, which only appears in Qt 4.7, and yes, it's way better, but is yet another change for developers.
The change to Wayland is transparent for developers. They are expected to write stuff in Qt, so they should not worry about that.
Oh,and BTW, the next device from Nokia, is not MeeGo, is Harmattan (more or less Maemo 6). It's compatible WRT the API (uses Qt), but is still based on DEB, not RPM, so is not really MeeGo, and not binary compatible.
You can think of MeeGo as "just" a Linux distribution. However, it's optimized and focused in bringing the usual Linux stack to all sorts of devices (TVs, cars, phones, tablets...).
It's a true open source project, or at least, it aims to be (is just beginning), and provides some sort of tools, and middleware. It's also a specification that you have to comply if you want to be MeeGo certified, so you can grant that software runs on all MeeGo devices.
Has some Fedora user tried LLVMpipe with some desktop apps that require OpenGL (like Gnome Shell)?
LLVMpipe is supposed to bring CPU-based rendering to apps that otherwise would require a working graphics card with OpenGL support. Seems backwards at first, but it would be a more coherent experience: if you don't have working graphics drivers, you have the same experience (slower), instead of a fallback mode, or a different implementation (like Unity 2D instead of the "normal" Unity).
It could also pave the way for Qt 5 apps, because Qt 5 is going to require OpenGL too. If LLVMpipe works decently it would be an improvement for developers. They could use OpenGL features to make their lives easier, without worrying too much about if the user has proper drivers.
As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?
There is a rumor about this. Some people thought that it would be possible to add S40 support in Qt. I thought that S40 phones are too small and cheap to run powerful apps, and the demand for applications for this platform is quite small, but... Stephen Elop and Mary McDowell visited Qt headquarters. McDowell is the head of "mobile phones", which is the feature phone (or "dumb phone") division in Nokia. Given that Windows Phone is only targeted at high end, some of the market space that Symbian covered has to be swallowed by S40 too.
Given that Nokia is also very serious about the emerging markets (India, China, etc.), where they still have a strong position, this makes some sense. I'm not specially excited about this and is just a rumor, but makes sense. There is also MeeGo. I think they would be very stupid to drop it completely, specially if they have to pour money to release one device and maintain it first.
"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"
Very wrong. Look at the list of maturity and status of Qt modules. Nokia still is ready to maintain a huge percentage of Qt. They simply deprecated stuff because they think that other alternatives are better (eg. ditch Phonon because there is QtMultimedia). The only piece that Nokia is not interested in maintaining and that the comunity is worried about, is QtSVG, because the alternative, the SVG support in Webkit, is considered too big/slow, or unsuitable for being LGPL only.
This is Qt development frameworks (aka "old Trolltech") being honest in what they are interested about.
Oh, and being even more open in how they develop (they already have public BTS and reports).
When they release Ice Cream Sandwich, the Honeycomb source will be in the patch history. What they may not bother to do is to tag the specific commit of Honeycomb.
This is not true if Honeycomb is developed in its own branch, and Icecream is developed from master, i.e., based on Gingerbread, not on Honeycomb. This is very likely. Cyanogen stated that 2.3 and 3.0 were developed in parallel.
What I fail to see is what exactly from the MS world is Mono useful for in the Linux/BSD/free software world. We more or less see how new versions of Gnash are more or less ready to play YouTube, or something like that (some goal that is useful for average Joe). But what is Mono useful for? Yes, there are some GNOME applications, and still many GNOME users try to avoid them. What non-GNOME applications from Windows is Mono capable of running? And how useful are them? Is really worth the effort? I don't have the answer, but I must see something significant before I can answer yes, and I fail to see it (and sorry if it's my fault).
I fail to see the link where you point to the research that proves that names in the open source world are worse than in the proprietary world.
Look, naming is hard, and of course some names suck and could be replaced by something better. But you are nuts if you think that the naming that (for example) Apple does makes any sense to a non-English speaker. Even with the huge popularity of iTunes I've heard this name said in a lot of different ways (how is read in Spanish, and how is read in English, but with very different levels of success).
And with other products it's the same. I had a really hard time spelling Google or Youtube when they were not widely known. Does the Windows name give you any hint that is an operating system? And iOS is easy to write or to pronounce or understand? Why Photoshop is not for buying things? How the hell QuickTime makes you thinkg about video? And so on.
And after you've asked that prepubescent child how many centimeters are in a kilometer, ask him whether knowing that will ever matter.
I can think of many practical situations where someone might need to do calculations like that. For example, how do you think that one measures the amount of people are in a demonstration? You know how many squared centimeters a person fills, and how many squared meters of a street are full of people. Or how many cars are trapped in a congestion? You know the average length of a car (in meters), and you use your helicopter images to know how many kilometers of the highway are full of cars.
I'd could go on and on. How many cans/books/whatever will fill your shelf? How many boxes will fill your truck?
KDE runs awesome in my 2.2GHz processor with a passively refrigerated graphics card (with all the graphics effects), and with about 512MB of memory used if only KDE4 apps are used (which is 95% of my time). And if you read the blogs, you have the explanation about why it runs really good on small devices if the drivers are properly set up.
I would test it the same way I would test JavaScript code. With JavaScript, you don't have the certainty that the V8 engine behaves the same and has the same bugs on x86 and ARM, but in general it does (for the majority of cases). With other interpreted code, or with NaCl the situation is the same.
Native Client requires an implementation for each architecture, true, exactly the same thing that happens with native compilers. Since the project is still young, they started with x86 and it might be the more mature implementation, but there are versions for x86-64 and ARM. You only need a recompile to target different architectures. The API is cross-platform.
For the purpose of NaCl, all the abstraction layers of hardware are the problem, not the solution. Sometimes you just need the extra performance (or the possibility of using C/C++ code for a web tool).