LWN.net Logo

The article is correct

The article is correct

Posted Mar 30, 2012 23:21 UTC (Fri) by jspaleta (subscriber, #50639)
In reply to: The article is correct by khim
Parent article: Free is too expensive (Economist)

It should also be pointed out the iOS and Android completely sidestep the issue of hardware drivers entirely. There's no expectation with the mobility operating system that'd you are ever meant to interact with any hardware not baked into the device. Both Google and Apple's solution for printing for the tablet age is basically turning printing into a weird web service of some sort..and encouraging you to buy specially capable printers to support their competing concepts of what that looks like.

The reality is... hardware drivers are hard for everyone. Mobility OSes just bake-in their hardware support and significantly reduce the complexity of the hardware they can interact with directly.

And operating system upgrades are...hard for everyone. Android upgrades fail. iOS upgrades fail. OS-X upgrades fail. MS Windows upgrades fail. There is no silver bullet. Vendors who take the time to certify OS upgrade path for previously purchased equipment is really the safest path for everyone. It's not perfect. There are enough iOS device owners out there who have gotten burned by an upgrade to make it clear that upgrades are inherently problematic for every vendor.


(Log in to post comments)

The article is correct

Posted Mar 31, 2012 7:21 UTC (Sat) by danieldk (guest, #27876) [Link]

> And operating system upgrades are...hard for everyone. Android upgrades fail. iOS upgrades fail. OS-X upgrades fail. MS Windows upgrades fail.

Your comparison is way off. I have many non-computer-savvy friends that have an iOS device or a Mac with OS X. Yet, I still have to see the first upgrade fail. Sure, some third-party software didn't immediately work (especially after OS X upgrades) sometimes. Sure, failed upgrades probably happen, but that is a rare event.

Compare that with Linux distributions. In the ~2005-2010 timeframe Linux was quite popular among fellow programmers, mainly due to the rise of Ubuntu. Most have abandoned Linux by now, mostly because of regressions (both in software and drivers) between major versions or sometimes even when running stable versions (e.g. kernel upgrades botching suspend/hibernate on laptops).

Linux was an acceptable UNIX system for many developers and computer scientists, especially given its price and the lack of competition in the low-end. But for people who do not give much about free software ideology, OS X has become a far more stable alternative, for which a large variety of third-party software that people need is available.

Going to conferences made me realize how profound this shift has been. A majority is using MacBooks these days, the rest is split between mostly Windows and a bit of Linux.

Linux lost the desktop wars.

The article is correct

Posted Mar 31, 2012 7:29 UTC (Sat) by ThinkRob (subscriber, #64513) [Link]

> Linux lost the desktop wars.

That assumes that "winning" (by the marketshare metric) was a goal.

The article is correct

Posted Mar 31, 2012 8:49 UTC (Sat) by khim (subscriber, #9252) [Link]

To win in any sense you need decent market share. About 10% or perhaps even 20% in some market. Otherwise you lose third-party support and, most importantly, you lose hardware vendors support.

Once you do that it's back to square one where only enthusiasts will play with your platform. And with diversity of components much higher then it was twenty years ago and proportion of enthusiasts much lower than it was twenty years ago your very survival is not guaranteed.

The article is correct

Posted Mar 31, 2012 7:31 UTC (Sat) by boudewijn (subscriber, #14185) [Link]

"Yet, I still have to see the first upgrade fail."

I have seen that happen with OSX. Quite badly, in fact, and more than once.

The article is correct

Posted Mar 31, 2012 7:55 UTC (Sat) by danieldk (guest, #27876) [Link]

And this is exactly the mindset why Linux on the desktop will not grow in marketshare. It's never, "ok, indeed, we have too many regressions, let's fix that", but always "system Windows/OS X is at least as bad". If that were true, OS X wasn't so popular among developers and even non-developers. The common mantra you hear from techie OS X users is "it's a stable system with third-party software, but I can still open a terminal". I realize that the comparison is not totally fair, since Apple has a very small variety of hardware to target, but there is plenty to learn even software-wise.

(PS. no personal attack intended)

The article is correct

Posted Mar 31, 2012 7:56 UTC (Sat) by danieldk (guest, #27876) [Link]

s/"system/"/

The article is correct

Posted Mar 31, 2012 9:30 UTC (Sat) by boudewijn (subscriber, #14185) [Link]

I don't understand how you can go from a factual correction -- i.e., you're anecdotal evidence was wrong so I corrected you -- to "It's never, "ok, indeed, we have too many regressions, let's fix that", but always "system Windows/OS X is at least as bad"

There's no hint in what I said of that: there's no hint of me excusing bugs in Linux, no hint of "they are broken, so it doesn't matter we are broken as well". Of course we have to fix issues and make Linux the best user environment there is.

Sure, Windows 7 is a ghastly mess and Windows 8 will be worse, and OS X is broken in many ways -- but while that's a fact, it's a fact that is completely irrelevant for whether the Linux desktop is perfect. It ain't, but lots of people are working really hard in many ways to get there.

The mindset that _I_ object too, strongly, is the parrot-talk about how linux will never succeed. We succeed, we are succeeding, and it will only get better. As long as people work on it, instead of sitting down and claiming it's a lost cause, let's give up.

I detest defeatism.

The article is correct

Posted Apr 1, 2012 9:54 UTC (Sun) by danieldk (guest, #27876) [Link]

> The mindset that _I_ object too, strongly, is the parrot-talk about how linux will never succeed.

Linux has already succeeded to a large extend in servers, routers, DVRs, and phones. Linux could also succeed on the desktop with some adjustment. Some things that are required:

- No crazy desktop changes in stable versions. I do like GNOME 3 and Unity, but the changes should've been more evolutionary.
- A stable ABI that is shared between all Linux distributions.
- An easy way to install third-party software. As easy as drag and drop. I know that this is technically possible today, but it requires the previous point plus maybe something like fat binaries. Also, the process of creating an application bundle should be easy.
- The core of the system and third-party applications should be decoupled more. It should be easy to continue running, say Debian Stable or Ubuntu LTS, while being able to upgrade your applications without upgrading the base system, X11, toolkits, or the desktop environment.

I certainly believe that Ubuntu's PPAs (and SUSE's build system) have made live a bit easier for everyone: as a developer I can simply put a source package in the archive, and packages are built for i386 and amd64, and it is relatively easy to maintain packages for multiple Ubuntu versions. But it is still not trivial for a non-expert user to add PPAs, let alone mix them (since multiple PPAs may provide different versions of the same dependencies).

As a developer, I also have too many moving targets. E.g. one piece of software that we wrote and provide requires Berkeley DB XML. DB XML is not available in most Linux distributions, and requires db(++), xqilla, and Xerces. Some distributions provide the versions of db, xqilla, and xerces that DB XML requires, there we "only" need to roll our own packages for DB XML in addition to our own software. On older distributions the dependencies are too old and newer distributions provide incompatible versions of xqilla. There we have cascading dependencies that we need to roll our own packages for. So, on modern distributions, we have to (at least) roll packages for our own software, DB XML, and xqilla. Not only is this a big hassle, package maintenance becomes as much work as software maintenance, there is a growing risk of conflicts with packages from other people's repositories. In addition to that, our users have Ubuntu, Debian, and CentOS in many different versions (Ubuntu being particularly ugly with their half-year releases) and platforms.

In contrast to that: on MacOS I just build one version on OS X 10.6 and it works for every OS X user. On Windows, I compile on any version with Visual Studio, and it works on all versions since Windows 2000. The result is that we pretty much ignore Linux, except for Ubuntu, and tell users to compile the software and some dependencies themselves on other distributions.

Given enough time, I'll probably roll a Linux version that includes all library dependencies and provide a wrapper script that sets LD_LIBRARY_PATH. But it would help tremendously if there was something standardized along the lines of an application bundle *and* a standardized ABI, so that we do not have to copy every library that the application depends on into that bundle (which in the case of the application discussed above would amount to including 50 libraries, or 76MB). Another possibility would be to statically link the application, but that has its own problems (e.g. no dlopen()).

The article is correct

Posted Apr 1, 2012 10:14 UTC (Sun) by khim (subscriber, #9252) [Link]

Another possibility would be to statically link the application, but that has its own problems (e.g. no dlopen()).

You can link some libraries statically and the rest dynamically. GlibC, in particular, is remarkably stable and it's easy to support older distributions with older versions of GlibC via LSB.

Something like -Wl,-Bstatic -lunstablelib1 -lunstablelib2 -Wl,-Bdynamic should do the trick.

Of course dlopen creates complications: if you want to use some library both from plugin and from main application (or just from two plugins) then you'll end up with two copies of library in memory! This, too, is solvable (for example you can add appropriate library to the main executable and use --export-dynamic to make it available for plugins), but yes, it's a PITA.

Yet you solve this somehow for MacOS and Windows (last time I've checked Windows had no DB XML support) thus it should be solvable for Linux, too.

The biggest problem with Linux is Q&A: if you limit yourself to LSB then you can not do a lot of things which are expected from modern program and if you use libraries outside of LSB then you immediately lose then cross-distribution compatibility and need to test your application with different versions of different distributions.

The article is correct

Posted Apr 1, 2012 11:50 UTC (Sun) by danieldk (guest, #27876) [Link]

> You can link some libraries statically and the rest dynamically. GlibC, in particular, is remarkably stable and it's easy to support older distributions with older versions of GlibC via LSB.

Good point, thanks!

> Yet you solve this somehow for MacOS

By providing an application bundle, which is a standardized procedure and something users expect. Also, (ABI-stable) system libraries are not copied to the application bundle. So, the bundle only contains a fraction of the used libraries (Qt and DBXML).

> and Windows

Again, here we use standard libraries (VS2008 redistributable), and drop Qt/DBXML DLLs in the same directory as the executable and it works perfectly on Windows XP and up (probably also Windows 2000, but we didn't check), although the software is compiled on Windows 7.

> (last time I've checked Windows had no DB XML support)

There's Windows support for DB XML. Oracle offers pre-built DLLs, or a source archive with Visual Studio project files. We use the latter, and building the DLLs with Visual Studio 2008 is just one click.

http://www.oracle.com/technetwork/products/berkeleydb/dow...

The article is correct

Posted Apr 2, 2012 8:48 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

The only thing your post proves is that Berkeley DB XML is not a reliable foundation to build on. You can hide it under Windows or OSX, but I'm quite sure it will fail there someday too.

Writing clever code is not everything, you need to think about what you build it on too.

The article is correct

Posted Mar 31, 2012 14:08 UTC (Sat) by Pawlerson (guest, #74136) [Link]

What I know OS X is just popular amongst Apple developers and those who are using applications like Photoshop which aren't present on Linux. OS X doesn't exists in serious enterprise business, so following your logic it can't be true it's better than Linux.

The article is correct

Posted Mar 31, 2012 17:09 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

It certainly exists in enterprise. And more and more iPads pop in very 'enterprisy' roles.

For example, one of our suppliers uses iPads for inventory management. Its camera is more than enough to scan barcodes and large input surface allows workers to view all the shipment details at once.

They've used Win6.5-based devices before that, btw.

The article is correct

Posted Mar 31, 2012 20:07 UTC (Sat) by Pawlerson (guest, #74136) [Link]

I meant enterprise computing. ;)

The article is correct

Posted Mar 31, 2012 21:02 UTC (Sat) by bats999 (guest, #70285) [Link]

True, iPads can be used to fill a company niche, but so could any number of tablets running free software. For any larger usage iPads still need support just as any other system. One does not simply purchase a crate of iPads and distribute them to a hospital staff, for example.

It's a bit off topic because the article is about desktop Linux (whatever that is), but why do those companies choose to use iPads?

The article is correct

Posted Apr 2, 2012 16:00 UTC (Mon) by jedidiah (guest, #20319) [Link]

People may find that "legacy application support" is the key thing here. I saw someone who had been contemplating an iPad3 get very excited about a Win7 tablet over the weekend. This person has no love for Microsoft products and even tried defecting to Linux and then a Mac. Has also been disapointed by PhoneOS versions of desktop Windows apps.

It's not the platform. It's the killer apps. People will put up with a platform they detest over that.

The article is correct

Posted Mar 31, 2012 7:38 UTC (Sat) by Pawlerson (guest, #74136) [Link]

There are many problems with Macs after upgrades. It's not hard to find. I will be no surprised if you are safer with (K)Ubuntu.
Linux lost the desktop wars.
Nope, it didn't. It already won, because it's one of the three the most important desktops. Did you just missed the newest Phoronix article about STEAM coming to Linux? :) Games are very important part of the desktops and with STEAM Linux will become stronger than ever.

The article is correct

Posted Mar 31, 2012 8:05 UTC (Sat) by Cato (subscriber, #7643) [Link]

Maybe you are kidding, but Steam on Linux is a recurring rumour with no basis in fact that I can see. Even if it does come to Linux, it would only matter if the games that it manages are also ported. I used to play some commercial 3D games on Linux under WINE but it was quite painful so I gave up and just dual-boot into Windows now.

The article is correct

Posted Mar 31, 2012 11:38 UTC (Sat) by TRS-80 (subscriber, #1804) [Link]

I've used Wine and Crossover for gaming with pretty good results, the main problem is losing at least half the raw performance of my video card. Fortunately they're so overpowered these days games are still playable. As for Linux support, why else would Gabe want to hire someone with Linux driver experience to improve performance.

The article is correct

Posted Mar 31, 2012 12:20 UTC (Sat) by Cato (subscriber, #7643) [Link]

Interesting - would be good if Valve's games are ported, or even better if their Source engine is ported, but it won't have a huge effect on the overall market.

Perhaps they will do a cloud gaming service, similar to http://onlive.com - using Linux for Source engine game servers would let them reduce their costs somewhat, but many games wouldn't run on Linux as their engines are tied to Windows, so it's not clear that's a winning strategy.

Another Linux gaming option is the Gaikai cloud gaming service, which has a Java applet client and does work fine on my Linux box. Some pros and cons compared to OnLive, but it is one option to play a wide range of Windows games with almost no setup hassles.

I used to use Crossover Games as well, but it was quite a faff.

The article is correct

Posted Mar 31, 2012 12:26 UTC (Sat) by Cato (subscriber, #7643) [Link]

In fact, OnLive Desktop is also interesting as a low cost way of running Windows apps in the cloud from a Linux desktop, tablet, etc. Or at least the concept is - they don't support Linux currently, but being able to easily run Windows desktop apps in the cloud would be great for consumers who just have one or two Windows apps they need, and can easily push them into the cloud without setting up their own Citrix type server.

The article is correct

Posted Mar 31, 2012 14:03 UTC (Sat) by Pawlerson (guest, #74136) [Link]

Interesting - would be good if Valve's games are ported, or even better if their Source engine is ported, but it won't have a huge effect on the overall market.
It will have a huge effect on the market share, because every game that runs on OS X will run on Linux as well. OS X will become non relevant and Linux will become much more valuable player and this will bring new software and increase its popularity further. Imagine free, rock solid and robust platform with dozens of great Open Source applications (and Steam) that is supported for five years (KUbuntu). This sounds exciting.

The article is correct

Posted Mar 31, 2012 13:01 UTC (Sat) by Pawlerson (guest, #74136) [Link]

If someone's kidding here it's Gabe from Valve:

http://www.phoronix.com/scan.php?page=news_item&px=MT...

I'm also doing a dual boot for now, because I want full performance.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds