However, they're also demanding better performance for desktop-centric workloads, specifically in the graphics department and in singular application processing workloads with limited disk and network I/O, rather than the high-I/O, highly threaded workloads you find with servers. If Linux on the desktop has any real chance of gaining more than this limited share, those demands will need to be met and exceeded on a consistent basis.
Add to that the need for all kinds of hardware support, peripheral support, power management, and other mostly desktop considerations, and the desktop and server distros drift even further apart. Also, I'd wager that there are an order of magnitude or more Linux server systems running on virtual machines than on desktops. That is a completely different scenario that should be accounted for when tailoring a distribution.
Can Linux do all of these things? Sure. Can we stop trying to make every Linux distribution capable of supporting all of these use cases out of the box? That's a very real possibility. There are already desktop-centric distributions like Mint, as well as more server-centric distributions like Gentoo and Debian to some degree (at least before systemd). They aren't full-on in either direction, but they definitely lean one way or the other. I'd be hard-pressed to consider RHEL 7 a truly server-centric distribution, given the use of systemd and the inclusion of desktop packages, but it's not really a desktop system either. It's middle-of-the-road in many regards.
There is enough pushback to systemd to warrant a fork of a major distribution that excises systemd and the GNOME dependencies, while providing a more traditional and stable server platform that has no hint of desktop support. No time need be wasted managing the hundreds upon hundreds of desktop packages present in the distro tree, no need to include massive numbers of desktop peripheral and graphical drivers (RHEL 6.3 ships with 57 xorg drivers, for instance).
There's also the matter of security. The security concerns for a desktop are vastly different than those for a server -- and server security concerns are vastly different among servers, depending on what each server is doing. However, it's safe to say that protecting against malware delivered by clicking through a malicious Web page is not high on the list of possible threats for a Memcached server.
I can clearly see the desire to improve the desktop Linux experience in terms of peripheral hardware support, graphics performance, sound, boot times, and ease of maintenance and management. Those are desktop concerns in a desktop distribution, and if ripping and replacing the plumbing helps to achieve the goals, then there may be some merit. However, there's no reason those same concerns should result in a rip and replace of the plumbing on server-class systems. It's shortsighted and dangerous.
Dedicated and tuned server distributions are a good idea anyway, systemd or not, but if that's the catalyst for the creation of a major, mainstream server-only Linux distribution that remains based on the Unix philosophies that have served us amazingly well over the past 45 years, then maybe all of this heated debate about systemd is not wasted after all.
This story, "It's time to split Linux in two," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
