What killed Linux Desktop (version of Miguel de Icaza)

The true story.

The hard drive that stored the / home partition on my Linux machine is covered and I had to replace it with a new one. Since the system unit is under the table, I had to disconnect all the cables, get it, change the hard drives in places and insert it all back.

Pretty standard action. Connect the power supply, connect the keyboard, connect the mouse, but when I got to the audio cable, I just missed it.

Why so annoying audio connection?
')
It will probably break again and it will force me to go hunting to find out more than I ever wanted to know about the new audio system and driver technology that we use.

A few days ago, I spoke to Klint Finley of Wired, who wrote an article entitled "OSX killed Linux . " The main focus of the inquiries was about my opinion in comparing the Gnome 3 shell, Ubuntu Unity, and Xfce as competing shells.

Personally, I am very happy with Gnome Shell, I believe that the team that put it all together did a great job, and I like how it gave Gnome designers the opportunity - who have historically been involved only in design, almost hack - to actually expand the shell, improve UI and prototypes of "other stuff" without having to beg the hackers to implement "other stuff" for them. Certainly, they would not be prevented by some corrections and improvements, but I am sure that they will certainly direct efforts to this.

What went wrong with Linux on Desktop

In my opinion, the problem with Linux on Desktop lies in the developer atmosphere that was created around it.

Linus, despite being a low-level kernel developer, set the tone for our community for years to come when he abandoned the binary compatibility of device drivers. The kernel developers probably had good reasons for this, and could possibly force the industry to play by their own rules, but Desktop developers did not have the power that kernel developers had. But still we were able to maintain our point of view.

Our community’s point of view was one of the projected benefits: we don’t want unsupported code in our source trees, we don’t want to support the surrounding design, we want a clean and beautiful design, and we want to destroy all traces of bad or poorly implemented ideas from our trees source code.

And we did it.

We banned some APIs because there was a better way. We removed the functionality because “this approach does not work” for the degrees of “not being able to” from “this is a security vulnerability” to “this does not correspond to the new style that we use”.

We have replaced the main subsystems in the operating system, with poor transition paths. We introduced layers of compatibility, for the fact that there was neither really compatible, nor was supported. When confronted with "it does not work," the community response was one - "you do it wrong."

As long as you had an operating system that was 100% free, and you could fix and update every component of your operating system to keep up with the update system, you were fine and it was just an inconvenience that lasted several months until excesses were not settled.

The second aspect of the problem is that there are no two distributions that have agreed on the main (basic) components of the system to be used. Either they do not agree with the transition schedule, which was not synchronized, or they competed in the implementation of the same functionality.

Attempts to standardize the core and set of basic libraries were undermined by the “distribution kit of the day”, which held to the position of strength. If you are the main dog (leader), you don’t want to make any concessions that would help other distros catch up with you. Being incompatible has become by gaining market share. A strategy that continues to be used by the 800 pound gorillas of the Linux world.

Let's sum up:
a) First aspect: it changes too quickly, destroying both open source and closed source programs;
b) incompatibility among Linux distributions

This killed the ecosystem for third-party developers trying to focus on Linux on the desktop. You can try once to make all your efforts to support the most common distribution, or if you feel generous - the top three most popular distributions, only to find that your software is no longer working after 6 months.

Linux support has become a burden for independent developers.

But even at this time, some of us in the Linux world still believed that we could build everything as open source software. The software development industry as a whole had several hits in the target, and we were convinced that we could do the same for ourselves: spreadsheets, word processors, design programs. With all this, we did a good job.

Linux marked the beginning of centralized package management and most successful software update systems. We have done a good job, considering our goals and our culture.

But we missed the big picture. In the process, we were alienated from each third-party developer. The ecosystem that came to life in the Apple OSX AppStore cannot be achieved with Linux today.

Climbing osx

When OSX was just running, it was by no means an advanced Unix system. It had an old kernel with an old user environment, was poorly compatible with modern Unix, had primitive development tools and a very attractive UI.

Over time, Apple drew attention to most of the problems associated with the Unix stack: they improved compatibility, improved their core, started working more open source software and pieces working right out of the box.

The most pragmatic contributors to the Linux kernel and open source software have gradually changed their goals from “the whole world works on open source software” to an “open web”. Others found that fussing with their sound card every 6 months to listen to music and the difficulties of watching videos on Linux are not worth it. People started switching to OSX.

Many hackers switched to OSX. It was a good looking Unix with working audio, PDF viewers, working video drivers, codecs for watching movies and, ultimately, a very enjoyable system to use. Many have changed the absolute customizability of their system to a stable system.

As for me, I just fell in love with the iPhone, so using a Mac every day was a must. Being part of the Linux Desktop effort, I felt deeply guilty about OSX sympathies and carrying most of the work under it.

What did we do wrong

Backward compatibility and compatibility between Linux distributions is not the most attractive issue. It is not even remotely an interesting problem to solve. Nobody wants to do this job, everyone wants to innovate and be responsible for the next big feature of Linux.

Thus, Linux was left with idealists who wanted to develop the best system without worrying about boring details like support and backward compatibility.

At the same time, you can still run Photoshop 2001, which came along with XP, on Windows 8. And you can still run your old OSX applications on Mountain Lion.

Back in February, I visited FOSDEM and two of my dear friends giggled at the anticipation of plans to deploy a new system that would force many applications to change, only so that they could continue working. They have an excellent vision for solving a problem that I never knew was there, and no end user is likely to be worried about this, but at the same time every desktop Linux user will pay for it.

That day I stopped feeling guilty about my new love for OSX.

upd: Slightly corrected the translation. Unfortunately, my English is far from perfect, and someone else has not translated this entry to me. Therefore, I ask you to write possible corrections in lichku, or at least in the comments to indicate more appropriate constructions. Thank.