Forging a new Linux path
At 21, Linux may be moving past its POSIX roots
There are a lot of debates going on about the pros and cons of the systemd service management system versus the legacy System V init system. Many of these debates center around the technical efficacy of systemd, but perhaps the most powerful question to be asked is: is Linux finally ready to walk away from its Unix legacy once and for all?
Here's a quick primer on systemd to set the stage for this discussion.
When a Linux system using init boots, it essentially is constructing the userspace part of the operating system: providing all of the services and device access that applications (and users) need to have an efficient experience on Linux. It does this by kicking off individual daemons, one at a time, in a very specific order. So the networking daemon gets started before the network services daemon, and so on.
One of the problems with this approach is that whole one-at-a-time thing. Boot times can be sped up with faster processors, but at the end of the day, everything has to wait for this sequential process to finish--and $Deity help you if one of the processes hangs.
systemd, which was started in 2010, gets around this issue by launching services in parallel. It also keeps in contact with what's going on in userspace. Unlike init daemons, which pretty much turn themselves off after services are launched, systemd keeps actively managing services, adding new ones as an application/user needs them.
That's not all, either: Red hat developers Lennart Poettering and Kay Sievers, the creators and maintainers of systemd, also takes away a lot of responsibilities that were once previously managed by the shell in userspace. This is one of the aspects that has led to many of the contentious debates. By connecting to or merging with the functionality of the udev device manager, ConsoleKit user manager, and polkit application privileges tool, systemd had many detractors are crying foul with calls of "bloat"--and lots of animosity for ConsoleKit and polkit.
Overall, the predominant theme in all of the arguments for or against systemd seem to hinge on its monolithic state. init, udev, and all the other tools and daemons that would kick off within the Linux boot process are all separate little modular programs that fit quite well within the modular nature of Linux and its Unix predecessors. That's what makes Linux so great: the capability to trim modules down or build them up as needed. systemd, the detractors argue, is well and truly against modularity, and its single unified nature is something that bothers them, a lot.
Hidden in all of the debate about how anti-Linux systemd may be, is one tiny but very important feature of systemd: the service manager will be able to run services that are not POSIX compatible. The oft-cited example is cgroups, which enhances the legacy process ID (PID) method of assigning processes to PIDs to user groups.
cgroups is something that has been in Linux for quite a while, but init won't turn it on because it is not POSIX-compatible. And it's only one of many Linux features that systemd works with and init doesn't. This has led some to criticize systemd for being too "Linux specific."
That many initially be confusing: aren't we talking about Linux after all? Don't we want to a system that will better implement all of the goodies that Linux has that Unix doesn't?
Well, it's complicated. The Debian Project, for instance, is furtively debating the adoption of systemd because it has Debian FreeBSD and Debian Hurd offerings as well as Debian GNU/Linux. The BSD and Hurd systems will work well with POSIX-compliant init, but not something like systemd.
Poettering's response to this argument is brusque and to the point: "There's a reason why systemd is more powerful than other init systems: we don't limit ourselves to POSIX, we actually want to give the user/administrator the power that Linux can offer you."
systemd represents a lot of things to a lot of people. To many, it's a threat to the Linux way of doing things, and an unnecessary departure from Linux's Unix roots. To others, it's yet another example of Red Hat asserting its own commercial goals on the rest of the Linux distributions.
From my perspective, it represents an opportunity to push Linux away from its Unix legacy and be able to stand on its own feet with unique features of its own. It's no accident that this debate is getting more prominent in the community just as Linux is about to turn 21.
Linux is all grown up now, so why can't developers be free to try new ways of putting it together? It may be a mistake, like the (oh so many) indiscretions of our youth, but without making a new path, how will Linux innovate to become greater than the sum of its parts?
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.