You're right: I think the category of "budget computers" will pretty much disappear. But is it going to be such a loss? Our phones are already more powerful than most budget computers. Once OS convergence happens (Ubuntu Phone, please), for many of us there won't be any reason to carry around a laptop.
You're right: desktops will become workstations (if they're not that already). They will continue to be very powerful devices suited for very particular work, that either requries a lot of computational power or is ergonomically sutied for a desk-and-chair.
Until quite recently, desktops were multipurpose devices: they did all that but also browsed the web, did word processing, and other lighter tasks. They'll still be able to do that, for sure, it's just that unless people need the workstation stuff, there are simply better devices than desktops.
The desktop isn't dying, it's just narrowing its mission.
I agree with your idea, but you got it a bit wrong: Xubuntu it still Ubuntu. I think many people hate Unity (I don't; I just treat it as an "early beta" of an idea that one day might work), but don't realize that things like Xubuntu and Kubuntu are very much still Ubuntu.
The desktop interface is a *very tiny* part of the OS, really. But it's the first thing most users see, and is crucial for PR.
I love Xubuntu. Hence, I also love Ubuntu (if not the Unity package) and the great work done by everyone involved.
Ubuntu should follow the openSUSE way: when you install it, it asks you which desktop you want. There's no realy need for separate distros, IMO.
openSUSE's brilliance is that it allows to choose the desktop you want during installation. This is vastly preferable to Ubuntu's requirement of downloading different flavors (Kubuntu, Xubuntu, Lubuntu, GNOME Remix). I also imagine that it's easier for devs, because it involves less packaging and distribution work.
I'm sticking with Xubuntu myself, because I much prefer the Debian way of doing things. Still, it's heartwarming to see that some things *can* be done better.
Gabe constantly says that his business model thrives on free competition, and that he doesn't believe that a walled garden would be good for Valve. And technically, too, Valve made open choices for SteamOS and Steam Machines, where they didn't have to.
Consider that Apple took a free OS as its base and have closed it: Valve makes it clear that it has no intention in restricting you from sideloading applications on SteamOS or installing whatever you want on your Steam Machine.
Valve might change in the future, but for now they are absolutely pushing an open platform.
Yes, good point. But at least but they still render web sites properly, not something I can say about mobile Chrome. I would add a caveat, though, that browsing with touch is often a pain even with Android and iOS. So when I say "perfectly fine" I really mean "comparable," I'm looking forward to Metro support for Firefox coming soon, hopefully it won't be too dumbed down. I *need* AdBlock plus! Even mobile Firefox has a nice AdBlock add-on.
I'll repeat my title: this is what the Surface RT should have been. I would be happy to trade in my netbook + Nexus 10 tablet for one of these. And the price is very right, especially as it includes basic MS Office capability.
The Windows 8 interface is perfectly fine for a tablet. Worse in some ways than Android, better than others. The real advantage over Android is that you have a full web browser, none of those dumbed-down mobile versions that can't handle standard web sites. If you're really wedded to the Android app-world it's probably not so good for you, but remember that there's so much free Windows software that would do the job just fine. Android has been wanting full VLC and smoothly working Flash for years...
And as a netbook, it's the real deal. You can install *any* Windows software on it, unlike the Surface RT. And Bay Trail makes it that much more capable that the netbooks of old, that cost about the same, couldn't turn into tablets, etc.
People complaining about this being "slashvertisement" need to chill. This is news for nerds: a new category of consumer device that could really shake things up.
Summary: Java always supported multiple inheritance via interfaces, but it never supported multiple inheritance of state, and this situation continues with the current default methods feature. This is simply a new aspect of multiple inheritence in Java. This new feature does, however, does present the "diamond problem" for the first time in Java, but this is solved by simply disallowing ambiguous situations at the compiler level. Seems perfectly fine to me.
Writing (and maintaining) good documentation can easily take as much time as writing and testing the code, if not longer. But it's worth doing. Please, please document. Many more people will flock to your product, in turn giving you more influence and fame. It's worth it!
Think of a cheap, tiny MP3 player that can store lots and lots of music. Sure, it's not quite as robust as an SSD device, but many people treat MP3s as disposable, anyway.
This is a great development and will enable a nice niche class of devices.
There's nothing "conventional" about desktop OSes. If anything, Linux is used much more in embedded and now mobile applications. It's desktop Linux OSes that are the outliers.
Uhm, but Android truly is Linux. For many kinds of development work targetting Android, that fact is very important.
It matters very much that Android and, say, Ubuntu, have the same Linux kernel. It allows for an amazing span of shared effort. And of course it matters very much that Android and Ubuntu are very different OSes.
So, yes, RMS is exactly right.
I'll furthermore add that Debian, and OS that many people like you would like to simply call "Linux", is also available in a totally entirely absolutely non-Linux version called Debian GNU/kFreeBSD.
Names are important and the situation has not taken care of itself.
I want to remind everyone that the support Canonical provided was a *single part-time programmer*, and that it's this that is now funded by Blue Systems. Definitely very nice support, and appreciated, but it's not the kind of support that makes-or-breaks a project.
I think you're jumping on the Node.js bandwagon without understanding why.
Node.js is a good asynchronous server, like Tornado (written in Python). However, it sounds like you are writing a backend for a RESTful (mobile) web application. Web is rarely asynchronous and has no special benefits from using an asynchronous server. You will not be more scalable just because you choose Node.js as your platform.
However, if you're excited about JavaScript on the server -- wonderful, because you get to use the same language throughout your project -- then consider the following products that are based on the JVM:
Prudence (cool because it has a framework for MongoDB, which is also JavaScript-based, and also because it uses Restlet, a truly awesome JVM library)
This is a fairly balanced statement (I especially like the "if you don't hate C++"). But it's also obviously a subjective experience, and YMMV.
I found Vala/Genie to be an amazing development experience: C#/Python-like linguistics, but with the true C ABI, with automatic wrapping for dynamic languages. GObject is ingenious! But it is also true that Vala is still in beta: some bindings might be broken, and Genie has some serious linguistic failings, but it's not a big deal to fall back to C when nothing else works. So, one approach is that you can use Vala, report bugs, help make it better ASAP. Still, I can sympathize with projects such as LXDE not having this patience.
Other tidbits:
1. The "breakage" of GTK+3 compared to GTK+2 is overblown. The API changes are rather small, and there are good guides for doing it. Most projects shouldn't take more than a day or two to upgrade. The basic components are all the same, and GLib is essentially unchanged. There are big changes for theme developers, but I wouldn't count that as a dev challenge, more of a user challenge.
2. Qt requires that you not just love C++, but also deal with the Qt C++ preprocessor... it's not a very pure C++ environment. It's mature and works, but not everybody's cup of tea. I know I would rather not have to program with it given good alternatives.
3. I'm very happy with the competition between GTK+ and Qt. It is making both toolkits better. And for a long time it hasn't been a problem using both toolkits together on the same DE.
I'm with you in this sentiment generally, though I'm also away of Linus' "fu** you, NVIDIA" moment. Apparently, NVIDIA are annoying collaborators with devs, and not only for video drivers.. so let's not cut them too much slack.
My pet peeve: people complain constantly that NVIDIA "refuses" to open source their drivers. But these people don't understand that it's not a matter of merely deciding to do so: the NVIDIA drivers contain a whole bunch of 3rd-party code that NVIDIA cannot legally open source. It would require either 1) a lot of legal agreements (and likely lots of royalty and lawyer fees) to make 3rd-party agreements, or 2) rewriting the 3rd-party code from scratch, without referring to the original code. Both of these tasks are monumental and very expensive (for task #2, they would have to hire new programmers that have not been "tainted" by having seen the original code).
Specs can't be "just" released for similar reasons: like the code, they are encumbered by patents and copyrights.
NVIDIA have expressed a general will to open source the driver, but it may take years to take it to the next step.
But think of something like FreeDesktop.org: it's possible for project to work together on standards in order to guarantee that other layers in the stack would indeed treat the layer next to them as interchangable.
So it's really less about technical difference than about a vibrant will and culture of cooperation. It's very unfortunate that there are sour grapes on various fronts: Canonical has gone about Mir quite poorly, and it's unclear at this state if there is a will for compatability on Wayland and Mir teams, although this may change in the future if both become popular and users demand it.
Note that this refers not only to layers "above" but also layers "below". For example, it's not just enough that Wayland and Mir share a compatible API for servers like XMir/XWayland to run on top, but also that they allow for using the same video drivers. In this particular case, the layer below (drivers) is so problematic that it's the important one to focus on.
The difference is that.dsc is integrated into Debian standard repositories. In fact, a repository is also a continuous build machine. (LaunchPad does this best.) The whole toolset iis oriented around handling upstream sources and patches together to create a dsc with a clearly traceable past. The RPM toolset is almost like a toy in comparison!
I just want to point out an often overlooked difference between Debian and other free OSes: Debian is actually a very comprehensive build system for complete OSes, it's not just a set of packages. A.deb file may seem equivalent to an.rpm, but actually the toolset behind the two formats is as different as night and day.
To the point, a Debian-based OS is not a "binary" distribution as opposed to "source" distributions like Gentoo. In a Debian, every package is actually available as both source (.dsc files) and possibly binaries for various architectures (.deb files). The final vendor can opt to create an installation CD for a particular architecture, but there's nothing stopping anyone from created a source-based CD, too. Debian is a build system designed specifically for free software operating systems, and despite the clunkiness of its toolsset, it does its job very well.
So, it's unsurprising that the author found a strong equivalence in Debian. Indeed, the.deb files we get are procuded by.dsc files using the equivalent build process he used, but on the vendor's build farm.
Unsurprising, but still worthwhile that he checked this to make sure. So much of computer security is based on trust, and what looks obvious may not be. So, we now have some evidence about Debian's reliability in this particular matter.
This shows a lot of maturity on the part of the GNOME devs (for creating a usable classic mode), and on the part of RedHat for defaulting on it.
Radical change may be exciting for developers and vendors, who are too aware of the usability issues with the "old" desktop paradigm, but it's not trivial to change a culture overnight. We're not all Steve Jobs clones who understand what people want better than they seem to know. iPhones were greeted with love, but the new experimental desktops coming out of the free software world seem to cause more angst than adoration. It takes maturity to recognize that maybe you are going too far all at once.
Slow but steady is the smart way to go: allow for radical experimentations while not breaking usability patterns built over years of using computers.
Slashdot Mirror
You're right: I think the category of "budget computers" will pretty much disappear. But is it going to be such a loss? Our phones are already more powerful than most budget computers. Once OS convergence happens (Ubuntu Phone, please), for many of us there won't be any reason to carry around a laptop.
You're right: desktops will become workstations (if they're not that already). They will continue to be very powerful devices suited for very particular work, that either requries a lot of computational power or is ergonomically sutied for a desk-and-chair.
Until quite recently, desktops were multipurpose devices: they did all that but also browsed the web, did word processing, and other lighter tasks. They'll still be able to do that, for sure, it's just that unless people need the workstation stuff, there are simply better devices than desktops.
The desktop isn't dying, it's just narrowing its mission.
Right: but no plaintext versions.
Thanks! But these are for the drafts, no? How come the final version doesn't have a plaintext file?
Does anyone know where to find plaintext versions of the 4.0 licenses?
I agree with your idea, but you got it a bit wrong: Xubuntu it still Ubuntu. I think many people hate Unity (I don't; I just treat it as an "early beta" of an idea that one day might work), but don't realize that things like Xubuntu and Kubuntu are very much still Ubuntu.
The desktop interface is a *very tiny* part of the OS, really. But it's the first thing most users see, and is crucial for PR.
I love Xubuntu. Hence, I also love Ubuntu (if not the Unity package) and the great work done by everyone involved.
Ubuntu should follow the openSUSE way: when you install it, it asks you which desktop you want. There's no realy need for separate distros, IMO.
openSUSE's brilliance is that it allows to choose the desktop you want during installation. This is vastly preferable to Ubuntu's requirement of downloading different flavors (Kubuntu, Xubuntu, Lubuntu, GNOME Remix). I also imagine that it's easier for devs, because it involves less packaging and distribution work.
I'm sticking with Xubuntu myself, because I much prefer the Debian way of doing things. Still, it's heartwarming to see that some things *can* be done better.
You're plain wrong.
Gabe constantly says that his business model thrives on free competition, and that he doesn't believe that a walled garden would be good for Valve. And technically, too, Valve made open choices for SteamOS and Steam Machines, where they didn't have to.
Consider that Apple took a free OS as its base and have closed it: Valve makes it clear that it has no intention in restricting you from sideloading applications on SteamOS or installing whatever you want on your Steam Machine.
Valve might change in the future, but for now they are absolutely pushing an open platform.
Yes, good point. But at least but they still render web sites properly, not something I can say about mobile Chrome. I would add a caveat, though, that browsing with touch is often a pain even with Android and iOS. So when I say "perfectly fine" I really mean "comparable," I'm looking forward to Metro support for Firefox coming soon, hopefully it won't be too dumbed down. I *need* AdBlock plus! Even mobile Firefox has a nice AdBlock add-on.
I'll repeat my title: this is what the Surface RT should have been. I would be happy to trade in my netbook + Nexus 10 tablet for one of these. And the price is very right, especially as it includes basic MS Office capability.
The Windows 8 interface is perfectly fine for a tablet. Worse in some ways than Android, better than others. The real advantage over Android is that you have a full web browser, none of those dumbed-down mobile versions that can't handle standard web sites. If you're really wedded to the Android app-world it's probably not so good for you, but remember that there's so much free Windows software that would do the job just fine. Android has been wanting full VLC and smoothly working Flash for years...
And as a netbook, it's the real deal. You can install *any* Windows software on it, unlike the Surface RT. And Bay Trail makes it that much more capable that the netbooks of old, that cost about the same, couldn't turn into tablets, etc.
People complaining about this being "slashvertisement" need to chill. This is news for nerds: a new category of consumer device that could really shake things up.
It's all discussed in the FAQ.
Summary: Java always supported multiple inheritance via interfaces, but it never supported multiple inheritance of state, and this situation continues with the current default methods feature. This is simply a new aspect of multiple inheritence in Java. This new feature does, however, does present the "diamond problem" for the first time in Java, but this is solved by simply disallowing ambiguous situations at the compiler level. Seems perfectly fine to me.
Writing (and maintaining) good documentation can easily take as much time as writing and testing the code, if not longer. But it's worth doing. Please, please document. Many more people will flock to your product, in turn giving you more influence and fame. It's worth it!
You lack imagination!
Think of a cheap, tiny MP3 player that can store lots and lots of music. Sure, it's not quite as robust as an SSD device, but many people treat MP3s as disposable, anyway.
This is a great development and will enable a nice niche class of devices.
There's nothing "conventional" about desktop OSes. If anything, Linux is used much more in embedded and now mobile applications. It's desktop Linux OSes that are the outliers.
Uhm, but Android truly is Linux. For many kinds of development work targetting Android, that fact is very important.
It matters very much that Android and, say, Ubuntu, have the same Linux kernel. It allows for an amazing span of shared effort. And of course it matters very much that Android and Ubuntu are very different OSes.
So, yes, RMS is exactly right.
I'll furthermore add that Debian, and OS that many people like you would like to simply call "Linux", is also available in a totally entirely absolutely non-Linux version called Debian GNU/kFreeBSD.
Names are important and the situation has not taken care of itself.
I want to remind everyone that the support Canonical provided was a *single part-time programmer*, and that it's this that is now funded by Blue Systems. Definitely very nice support, and appreciated, but it's not the kind of support that makes-or-breaks a project.
We must find the Soul Cube and give it to our greatest hero!
Well, CynagonMod specifically has the ability to introduce new CM-specific APIs to allow this functionality.
I know I would feel much better allowing an app to do something specific rather than give it blanket authority via root.
PolicyKit for Android, perhaps?
I think you're jumping on the Node.js bandwagon without understanding why.
Node.js is a good asynchronous server, like Tornado (written in Python). However, it sounds like you are writing a backend for a RESTful (mobile) web application. Web is rarely asynchronous and has no special benefits from using an asynchronous server. You will not be more scalable just because you choose Node.js as your platform.
However, if you're excited about JavaScript on the server -- wonderful, because you get to use the same language throughout your project -- then consider the following products that are based on the JVM:
Prudence (cool because it has a framework for MongoDB, which is also JavaScript-based, and also because it uses Restlet, a truly awesome JVM library)
Helma (very mature and proved its worth)
JSSP
Myna
Phobos
This is a fairly balanced statement (I especially like the "if you don't hate C++"). But it's also obviously a subjective experience, and YMMV.
I found Vala/Genie to be an amazing development experience: C#/Python-like linguistics, but with the true C ABI, with automatic wrapping for dynamic languages. GObject is ingenious! But it is also true that Vala is still in beta: some bindings might be broken, and Genie has some serious linguistic failings, but it's not a big deal to fall back to C when nothing else works. So, one approach is that you can use Vala, report bugs, help make it better ASAP. Still, I can sympathize with projects such as LXDE not having this patience.
Other tidbits:
1. The "breakage" of GTK+3 compared to GTK+2 is overblown. The API changes are rather small, and there are good guides for doing it. Most projects shouldn't take more than a day or two to upgrade. The basic components are all the same, and GLib is essentially unchanged. There are big changes for theme developers, but I wouldn't count that as a dev challenge, more of a user challenge.
2. Qt requires that you not just love C++, but also deal with the Qt C++ preprocessor... it's not a very pure C++ environment. It's mature and works, but not everybody's cup of tea. I know I would rather not have to program with it given good alternatives.
3. I'm very happy with the competition between GTK+ and Qt. It is making both toolkits better. And for a long time it hasn't been a problem using both toolkits together on the same DE.
I'm with you in this sentiment generally, though I'm also away of Linus' "fu** you, NVIDIA" moment. Apparently, NVIDIA are annoying collaborators with devs, and not only for video drivers.. so let's not cut them too much slack.
My pet peeve: people complain constantly that NVIDIA "refuses" to open source their drivers. But these people don't understand that it's not a matter of merely deciding to do so: the NVIDIA drivers contain a whole bunch of 3rd-party code that NVIDIA cannot legally open source. It would require either 1) a lot of legal agreements (and likely lots of royalty and lawyer fees) to make 3rd-party agreements, or 2) rewriting the 3rd-party code from scratch, without referring to the original code. Both of these tasks are monumental and very expensive (for task #2, they would have to hire new programmers that have not been "tainted" by having seen the original code).
Specs can't be "just" released for similar reasons: like the code, they are encumbered by patents and copyrights.
NVIDIA have expressed a general will to open source the driver, but it may take years to take it to the next step.
But think of something like FreeDesktop.org: it's possible for project to work together on standards in order to guarantee that other layers in the stack would indeed treat the layer next to them as interchangable.
So it's really less about technical difference than about a vibrant will and culture of cooperation. It's very unfortunate that there are sour grapes on various fronts: Canonical has gone about Mir quite poorly, and it's unclear at this state if there is a will for compatability on Wayland and Mir teams, although this may change in the future if both become popular and users demand it.
Note that this refers not only to layers "above" but also layers "below". For example, it's not just enough that Wayland and Mir share a compatible API for servers like XMir/XWayland to run on top, but also that they allow for using the same video drivers. In this particular case, the layer below (drivers) is so problematic that it's the important one to focus on.
The difference is that .dsc is integrated into Debian standard repositories. In fact, a repository is also a continuous build machine. (LaunchPad does this best.) The whole toolset iis oriented around handling upstream sources and patches together to create a dsc with a clearly traceable past. The RPM toolset is almost like a toy in comparison!
I just want to point out an often overlooked difference between Debian and other free OSes: Debian is actually a very comprehensive build system for complete OSes, it's not just a set of packages. A .deb file may seem equivalent to an .rpm, but actually the toolset behind the two formats is as different as night and day.
To the point, a Debian-based OS is not a "binary" distribution as opposed to "source" distributions like Gentoo. In a Debian, every package is actually available as both source (.dsc files) and possibly binaries for various architectures (.deb files). The final vendor can opt to create an installation CD for a particular architecture, but there's nothing stopping anyone from created a source-based CD, too. Debian is a build system designed specifically for free software operating systems, and despite the clunkiness of its toolsset, it does its job very well.
So, it's unsurprising that the author found a strong equivalence in Debian. Indeed, the .deb files we get are procuded by .dsc files using the equivalent build process he used, but on the vendor's build farm.
Unsurprising, but still worthwhile that he checked this to make sure. So much of computer security is based on trust, and what looks obvious may not be. So, we now have some evidence about Debian's reliability in this particular matter.
This shows a lot of maturity on the part of the GNOME devs (for creating a usable classic mode), and on the part of RedHat for defaulting on it.
Radical change may be exciting for developers and vendors, who are too aware of the usability issues with the "old" desktop paradigm, but it's not trivial to change a culture overnight. We're not all Steve Jobs clones who understand what people want better than they seem to know. iPhones were greeted with love, but the new experimental desktops coming out of the free software world seem to cause more angst than adoration. It takes maturity to recognize that maybe you are going too far all at once.
Slow but steady is the smart way to go: allow for radical experimentations while not breaking usability patterns built over years of using computers.
Good show, everyone involved.