A Linux Conspiracy Theory
IgnorantGuru, Linux blogger and developer of the innovative SpaceFM file manager, bemoans a corporate threat to Linux.
Components that break
Seeing these changes, it made me take a second look at breakage I had seen in other Linux components such as udisks and gvfs. Used particularly by file manager developers, these components act as an abstraction layer between the kernel and applications, giving them convenient access to device management and file system functionality. Used in many distributions not involving GNOME at all, development of these components is also controlled by Red Hat developers and, like GTK and GNOME, they have been breaking wildly, creating instability and development dilemmas in many circles. With the introduction of udisks2, its command line was completely changed, simply breaking compatibility with all existing software and scripts which relied upon it. Red Hat developer David Zeuthen further added this bizarre note to the documentation: “This program is not intended to be used by scripts or other programs – options/commands may change in incompatible ways in the future even in maintenance releases.” Further, udisks2 arbitrarily changes the location of critical system files, breaking much software. Replying to my commentary on these problems, Hon Jen Yee, developer of the popular PCManFM file manager comments, “Udisks brings a lot of headache[s] for us as well. Why people [sic] keep breaking existing things that working [sic] very well? I hate polkit, consolekit and other *kit stuff very much. They never work reliably and the complicated layers just make me want to return to windows. We’re very far from KISS [Keep it simple, stupid] philosophy now. So sad.” [Fig 6]
Likewise, many developers of lightweight applications for LXDE and Xfce, such as the PCManFM and Thunar, were fooled into using gvfs’s API for required functionality, only to have it prove to be wildly unstable and ill-maintained, leading their software to be perceived as bug-ridden of late. Yet use of an API involves a great investment of time and effort – these developers have become trapped in the use of libraries which are developed by Red Hat with only GNOME in mind.
Linus Torvalds, creator of Linux and current maintainer of the kernel, has become extremely frustrated with Red Hat developers concerning their development practices in the kernel and core components like udev (which replaced HAL for device services). Writing to Red Hat employee Kay Sievers, Linus says, “I also call bullshit on your ‘it will surely be fixed when we know what’s the right fix’ excuses… You’re refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around *your* bugs.” Elsewhere, Linus famously gets right to the point in his reply to Mauro Carvalho Chehab: “Stop this crazy. FIX UDEV ALREADY, DAMMIT. Who maintains udev these days?… The fact is, udev made new – and insane – rules that are simply *invalid*. Modern udev is broken, and needs to be fixed… What kind of insane udev maintainership do we have?”
Another component introduced recently by Red Hat is systemd, a startup component along the lines of sysvinit. Systemd introduces questionable technologies such as dbus to start up and simply breaks existing init scripts, but even more concerning, it is being pushed aggressively on users and admins who don’t want it. By absorbing udev into the systemd source tree and promising to only support a core component like udev when it is installed with systemd, Red Hat is creating a monolithic stack of system tools which is hard to escape from. This announcement created a veritable explosion on Gentoo’s forums, a distribution devoted to giving users many choices. Unhappy with systemd developer and Red Hat employee Lennart Poettering, who jokes about breaking everyone’s systems with his bug-ridden PulseAudio daemon, Gentoo user SteveL writes, “…it’s because everything he comes out with wants to take over our machines, with a mess of so-called ‘integration’ requiring changes across the board. Till he finally realises what everyone was on about, and drops the project for his next shiny adventure, leaving everyone else to pick up the pieces.” Tech-savvy Arch Linux users, also accustomed to flexibility, were appalled at being forced to use systemd. Long-time Arch Linux user Daniel writes, “As I predicted, the switch to systemd has effectively been forced. Take a good look at the list of packages that require systemd thanks to the project’s takeover of udev and dbus.” [Fig 7] Sentiment was so strong against the ill maintenance of udev, and its inclusion in systemd, that a udev fork has begun.
Much of Red Hat’s approach reminds me of chess pieces being strategically placed, limiting movement of the other pieces on the board. Beyond Red Hat, KDE and Canonical’s Unity desktops have also shown these same anti-user, corporate product trends which increasingly cater to closed-source operating systems. The introduction of KDE 4 alienated many long-time KDE users, and Unity has been embroiled in controversy over Canonical adding surveillance tech to its search tools, such that even searches for local files are broadcast to Amazon and other corporate advertisers, as detailed in the Electronic Frontier Foundation’s exposé: ‘Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks’. [Fig 8]
Linux, which is itself a community-developed project involving thousands of developers globally, has a long tradition of building onto existing work. Such a large development community cannot function without co- operation – honouring others work by not creating breakage, allowing a variety of solutions to coexist (users’ choice) and being careful not to tread on others’ work and efforts. Linux is a global experiment in collaboration, extremely popular with its users. Even small businesses are a part of this community, benefiting from Linux’s infrastructure and giving back to it. Yet when involvement reaches the scale of extremely large and powerful corporations such as Red Hat (now a billion-dollar company), Google and Microsoft, the dynamic tends to change to one of pure exploitation.
Are large corporations, historically never a friend to Linux, using malicious development practices against Linux, deliberately sabotaging it and making it irrelevant, and/or turning it into a traditional, fixed corporate ‘product’? When it comes to large corporations, except for the few stockholders at the top of the pyramid, almost everyone loses – the drive is purely profit. Yet Linux is a great equaliser, providing valuable software free of charge internationally and encouraging the open sharing of technologies. Are large corporations, with their teams of hired guns, now threatening Linux from within?
The spirit of freedom
By contrast, non-commercial, community- developed or independent projects (including the Linux kernel and many core components) tend to be the reverse in these areas. They tend to provide a robust array of power options, and users strongly influence the software rather than merely being influenced by it. They follow a UNIX-like philosophy of working and playing well together. Their use and access is intended to be as free and broad as possible. Active non- commercial projects tend to be much better maintained, with old-world craftsmanship and pride rather than mass-produced junk. When these projects do make changes, they tend to be incremental. Since the roots are better preserved, changes tend to involve real growth and evolution, rather than shallow, mostly broken bells and whistles.
From the corporation’s perspective, how do you control and compete with an open technology like Linux, which includes freedom- to-use-and-change-based licences, worldwide collaboration of thousands of devoted fans, free distribution and no manufacturing requirements? Having failed to stop Linux in other ways, are corporations now attempting to keep Linux fragmented and make it very difficult for individuals and small, diverse groups to easily create and maintain valuable software? Are they creating a field where stable development is almost impossible due to changing interfaces, and where participation in projects is limited to and controlled by corporate insiders?
One of the more disturbing bits of news is that Red Hat is merging with (effectively being purchased by) Duke Energy, a huge energy conglomerate and a maker of nuclear power plants. This is raising flags because the oil and energy sector is one of the most corrupt, and has a very long and dark history of killing socially transformative technologies. These are not firms that are fans of open technologies and free access for all, so why are they now conducting surgeries on some of the most sensitive and critical parts of the Linux infrastructure? I believe Red Hat’s continuing control of key parts of Linux deserves deep suspicion, especially in light of its recent radical behaviour.
Consider how long Linux struggled to ‘take off’ and ‘make it on the desktop’. For years, many of us have discussed this – Linux users develop a tremendous passion for their OS, as well as the community which has grown around it, and saw the potential for it to revolutionise and set free consumer computing environments. Yet large corporations have always pushed Linux away with Payola-style scandals and more, essentially restricting hardware to Windows-only as much as possible. Yet Linux kept creeping forward nonetheless, its global fan base and spirit of collaboration unstoppable. Now, just as this emergence of Linux in consumer products is finally happening, with many Linux-powered devices introducing new users to its charms, radically damaging development practices are being introduced to widespread areas of the Linux ecosystem. It seems powerful influences are pushing Linux development into a Microsoft-like model from the inside. Their approach may serve their purposes well – Microsoft made gobs of money with it, for example. But did its users benefit from this as well, or merely suffer for it? Many Linux users are in fact refugees from such practices, and they’re finding their arrival in Linux rude indeed.