It might not be the end of the world, but the design of system and the attitudes of its developers.
Now that Red Hat has released RHEL 7 with system in place of the
erstwhile SysVinit, it appears that the end of the world is indeed
approaching. A schism and war of egos is unfolding within the Linux community right now, and it is drawing blood on both sides. Ultimately, no matter who "wins," Linux looks to lose this one.
The idea behind systems was to replace the aged Init
functionality and provide a sleek, common system initialization
framework that could be standardized across multiple Linux
distributions. systems promised to speed up system boot times, better
handle race conditions, and in general, improve upon an item that wasn't
exactly broken, but wasn't as efficient as it could be.
As an example, you might be able to produce software that could compile and run on numerous Linux distributions, but if it had to start at boot time, you could be required to write several different Init-style boot scripts, one for each supported distribution. Clearly this is inelegant and could use improvement.
Also, there was the problem that traditional Init is slow and bulky, based on shell scripts and somewhat random text configuration files. This is a problem on systems that need to boot as fast as possible, like embedded Linux systems, but is much less of a problem on big iron that takes longer to count RAM in POST than it does to boot to a log-in prompt. However, it's hard to argue that providing accelerated boot times for Linux across the board is not a good thing.
These are all laudable goals, and systemd wasn't the first project aimed at achieving them. It is, however, the first such project to gain mainstream acceptance. This is in no small part due to the fact that the main developers of systemd are employed by Red Hat, which is still the juggernaut of Linux distributions.
Red Hat exerted its considerable force on the Linux world. Thus, we saw system take over Fedora, essentially become a requirement to run the GNOME desktop, then become an inextricable part of a significant number of other distributions (notably not the "old guard" distributions such as Gentoo). Now you'd be hard-pressed to find a distribution that doesn't have systemd in the latest release (Debian doesn't really use systemd, but still requires systemd-shim and CGManager).
While system has succeeded in its original goals, it's not stopping there. system is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, system is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. system wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.
No matter which side of the argument you're on, this monolithic approach is in violation of the rules of Unix, specifically the rule stating it's best to have small tools that do one job perfectly rather than one large tool that is mediocre at performing many jobs. Prior to this, all the functions subsumed by systemd were accomplished by assembling small tools in such a way that they performed the desired function. These same tools could be used within a variety of other scripts to perform myriad tasks -- there was no singular way to do anything, which allowed for extreme freedom to address and fix problems. It also allowed for poor implementations of some functions, simply because they were poorly assembled. You can't have both, after all.
That's not the end of the story. There's more happening with system than many might realize. First, system is rather inelegantly designed. While there are many defensible aspects of system, other aspects boggle the mind. Not the least of these was that, as of a few months ago, trying to debug the kernel from the boot line would cause the system to crash. This was because of system's voracious logging and the fact that system responds to the "debug" flag on the kernel boot line -- a flag meant for the kernel, not anything else. That, straight up, is a bug.
However, the system developers didn't see it that way and actively fought with those experiencing the problem. Add the fact that one of the system developers was banned by Linus Torvalds for poor attitude and bad design and another was responsible for causing significant issues with Linux audio support, but blamed the problem on everything else but his software, and you have a bad situation on your hands.
There's no shortage of egos in the open source development world. There's no shortage of new ideas and veteran developers and administrators pooh-poohing something new simply because it's new. But there are also 45 years of history behind Unix and extremely good reasons it's still flourishing. Tools designed like system do not fit the Linux mold, to their own detriment. System's design has more in common with Windows than with Unix -- down to the binary logging.
My take is that system is a good idea poorly implemented, developed by people with enormous egos who firmly believe they can do no wrong. As it stands now, both system and the developers responsible for it need to change. In the open source world, change is a constant and sometimes violent process, and upheavals around issues such as system aren't necessarily bad. That said, these battles cannot be drawn out forever without causing irreparable harm -- and any element as integral to the stability and functionality of Linux as system has even less time than most.
As an example, you might be able to produce software that could compile and run on numerous Linux distributions, but if it had to start at boot time, you could be required to write several different Init-style boot scripts, one for each supported distribution. Clearly this is inelegant and could use improvement.
Also, there was the problem that traditional Init is slow and bulky, based on shell scripts and somewhat random text configuration files. This is a problem on systems that need to boot as fast as possible, like embedded Linux systems, but is much less of a problem on big iron that takes longer to count RAM in POST than it does to boot to a log-in prompt. However, it's hard to argue that providing accelerated boot times for Linux across the board is not a good thing.
These are all laudable goals, and systemd wasn't the first project aimed at achieving them. It is, however, the first such project to gain mainstream acceptance. This is in no small part due to the fact that the main developers of systemd are employed by Red Hat, which is still the juggernaut of Linux distributions.
Red Hat exerted its considerable force on the Linux world. Thus, we saw system take over Fedora, essentially become a requirement to run the GNOME desktop, then become an inextricable part of a significant number of other distributions (notably not the "old guard" distributions such as Gentoo). Now you'd be hard-pressed to find a distribution that doesn't have systemd in the latest release (Debian doesn't really use systemd, but still requires systemd-shim and CGManager).
While system has succeeded in its original goals, it's not stopping there. system is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, system is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. system wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.
No matter which side of the argument you're on, this monolithic approach is in violation of the rules of Unix, specifically the rule stating it's best to have small tools that do one job perfectly rather than one large tool that is mediocre at performing many jobs. Prior to this, all the functions subsumed by systemd were accomplished by assembling small tools in such a way that they performed the desired function. These same tools could be used within a variety of other scripts to perform myriad tasks -- there was no singular way to do anything, which allowed for extreme freedom to address and fix problems. It also allowed for poor implementations of some functions, simply because they were poorly assembled. You can't have both, after all.
That's not the end of the story. There's more happening with system than many might realize. First, system is rather inelegantly designed. While there are many defensible aspects of system, other aspects boggle the mind. Not the least of these was that, as of a few months ago, trying to debug the kernel from the boot line would cause the system to crash. This was because of system's voracious logging and the fact that system responds to the "debug" flag on the kernel boot line -- a flag meant for the kernel, not anything else. That, straight up, is a bug.
However, the system developers didn't see it that way and actively fought with those experiencing the problem. Add the fact that one of the system developers was banned by Linus Torvalds for poor attitude and bad design and another was responsible for causing significant issues with Linux audio support, but blamed the problem on everything else but his software, and you have a bad situation on your hands.
There's no shortage of egos in the open source development world. There's no shortage of new ideas and veteran developers and administrators pooh-poohing something new simply because it's new. But there are also 45 years of history behind Unix and extremely good reasons it's still flourishing. Tools designed like system do not fit the Linux mold, to their own detriment. System's design has more in common with Windows than with Unix -- down to the binary logging.
My take is that system is a good idea poorly implemented, developed by people with enormous egos who firmly believe they can do no wrong. As it stands now, both system and the developers responsible for it need to change. In the open source world, change is a constant and sometimes violent process, and upheavals around issues such as system aren't necessarily bad. That said, these battles cannot be drawn out forever without causing irreparable harm -- and any element as integral to the stability and functionality of Linux as system has even less time than most.
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment