Post
 |
| Luddites failed to achieve their goals |
Being a huge leap from any other init system it naturally appears as a large and complex software to any guy who only tinkered with a few sysvinit scripts in the last 20 years.
Yes, I definitely do not agree with systemd luddites: below, I comment their Rundown...
1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid.The first objection by Luddites and Boycotters arbitrarily assumes that an init system should be "small" and doing "one thing" only: starting a bunch of processes. This means that a normal Linux boot requiring its typical large forest of daemons, clean-ups, initializations, libraries, privileges, config files, sockets, special directories, etc, will need every single process to handle, validate, update, protect its particular environment, check if already started, output a reasonable log, sparingly use root privileges, etc, while we expect them to use only the least needed privileges and resources and only start when actually needed. Would it be wise to have a single, secure, solid path for common operations? Since this bunch of processes is at least 90% the same on any Linux system, one wonders why systemd has been the first project of its kind.
Their first objection also incorrectly assumes that Linux software should absolutely enforce the "Unix philosophy" everywhere (do gcc, X11, Firefox and Linux kernel actually enforce it?), escalating a byzantine philosophical debate to a technical issue. Initializing a Linux system is a non-trivial task in which the "divide and conquer" strategy historically never led to any "kept simple" solution - even in the case of sysvinit, even in the simple embedded environments. Note also that an init system of any Linux distribution, once tested and debugged does not require frequent modifications: in any scenario, common users should not tinker with a sysvinit-style installation, and the most required from a system administrator is all about adding/removing services.
2. systemd's journal files (handled by journald) are stored in a complicated binary format, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID-compliant transactions. You typically don't want that to happen to your syslogs. The advice of the systemd developers? Ignore it. No, seriously. Oh, and there's embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.This objection appears to confuse syslogs with database transactions. A corrupted journal file - text or binary or even a "complicated binary" format - is just a corrupted journal file, and any actual file is a "potentially corruptible" file whenever someone/something is able to write on it. No Unix machine out there has true ACID-compliant transactions for dmesg and syslogs (except -maybe- baroque and paranoid things like Solaris BSM auditing). The advice of systemd developers simply makes sense.
By the way, are you talking about an init system or the components it starts as well? Almost any embedded and desktop Linux machine starts small webservers here and there (example: the CUPS configuration tool), and almost any Linux machine requires some network-time-protocol sync as soon as it gets internet connectivity. Is there any technical reason to require an init system being designed to only spawn some processes?
3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.The third objection mistakes the position of the "compatibility Wallace line": which parts of a Linux system should be absolutely "Unix compatible"? And which kind of software should rely on specific Linux kernel features? Why a Linux init system should ignore Linux-specific features like cgroups, SCM_CREDENTIALS, signalfd? Why a Linux init system should contain a granulated mix of Unix-philosophy tasks and Linux-specific processes?
The thing about "different kernel versions" reminds me some vintage Microsoft propaganda against Linux switching from ipfwadm to ipchains and then to iptables. Can you name any other Linux kernel update of last years that actually broke compatibility to some init system at any degree?
Tight integration between the kernel and the init system implies that under the hood nothing is wasted. Are you really afraid of clean and non-redundant things? You first complain about systemd being too Linux-specific, and then complain about systemd binding Linux
4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago. The integration of the device node manager that was once part of the Linux kernel is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency.Again, a "political" view tries to deny a technical advantage, while adding some extra confusion. Are you talking about a generic Linux distro builders or its users? Do users need to know what dbus and device node manager is underneath their packages? Do distro builders have the right to choose what init system they need? Is there any technical reason against systemd? What exactly is a "standard API" for an init system?
Knowing that the sources of systemd are open, what do you mean by decreased transparency?
5. By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using coredumpctl. Besides going against all reason, it also creates complications in multi-user environments (good luck running gdb on your program's core dump if it's dumped to the journal and you don't have root access), since systemd requires root to control. It assumes that users and admins are dumb, but more critically, the fundamentally corruptible nature of journal logs makes this a severe impediment.Oh, yes, the fundamentally corruptible nature of files, yeah, only applies to systemd journal log files, yadda, yadda, wonderful. Will you be a bit more specific about those unnamed complications against reason of needing a coredumpctl invocation instead of wandering in a forest of log directories? Are you really assuming that the coredumpctl+gdb thing is the Unfixable Bug of the XXI Century?
6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 2010. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.Linux kernel size makes it a single point of failure. As of this writing, Linux kernel has had more than 100 CVE reports in 2014 and more than 1200 in the last 15 years. But we still fail to find any "juicy target for crackers", even if the kernel is installed on an overwhelmingly large number of machines ranging from wristwatches to supercomputers.
It's not that wise to estimate software reliability and maintainability from CVE reports. Except if you hate a specific software and need to spread some FUD (fear, uncertainty, doubt).
7. systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps. This means GNOME versions >= 3.8 are incompatible with non-Linux systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion.Actually "viral" means that a number of Linux distro gurus think that systemd is better that any other init system (RHEL 7, SLES12, Sailfish, Ångström, Arch, Mageia to name a few extra ones joining that "rapid rise" club). Those who believe in the myth that systemd "adds complexity" should first inspect their init shell scripts and dependency management, based on bizarre and articulated constructs - the "case start stop" ones, the "some config stuff" ones, the "include this and maybe that" ones, the 00* to 99* ones, and so on... - while a readable, clean and simple .service textfile delegates all "complexity" to the underlying well-tested unified-style systemd engine. And yes, you can even use it to start your classic scripts as well.
It's somewhat funny seeing Boycotters against systemd because GNOME guys made a "hard dependency" on it: why 3.8 and later releases cannot work also on a standard init system like previous versions? GNOME is the culprit... but Luddites blame systemd.
(Side note: GNOME guys are asking for some new features in the Linux kernel... Why?)
8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur. This happens to be another example of SPOF.Again with the FUD festival. We can kexec a kernel, in a while we will even hotfix a running kernel, yet you say we won't ever be able to upgrade systemd on the fly? Boycotters fail again to provide at least a decent example where "system goes down": they deliberately want to confuse different scenarios and concepts - namely experimental code, security patches, write access to the /sbin/init executable, existence and solidity of an educated community of contributors, and so on.
9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc.This statement only makes sense for Linux environments that may not use glibc: that is, very small embedded ones. Desktops and servers do use glibc, and user applications generally require "bug-for-bug compatibility" with glibc.
And again: you cannot blame systemd for somebody else's weakness.
10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly. One also needs to worry about a much higher multitude of code paths and behaviors in a system-critical program, including the possibility of systemd not synchronizing with the message bus queue on boot, and thus freezing. This is as opposed to a conventional init, which is deterministic and predictable in nature, mostly just execing scripts.A number of Linux distributions (see above) already sports systemd: their developers apparently do not see any "complicated nature", or at least see that it has more benefits than drawbacks.
The "much higher multitude of code paths" actually applies more to init systems featuring shellscripts than to systemd (systemd has a single code-path for all configuration files, all service start/stop mechanisms, and so on). If you ever tinkered with some init scripts trying to trace back where something is started and what are the contents of shell variables in that moment and where is anything logged, you surely noticed (and blamed) their bloated code and repeating patterns.
11. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.No one is forced to use systemd: systemd is not the mafia. If you think that systemd is "desktop oriented", you should ask Red Hat and SUSE why RHEL7 and SLES12 chose it as a core component.
I'm also wondering why you are willing to look for alternatives.
12. systemd doesn't even know what the fuck it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. It engulfs functionality that variously belonged to util-linux, wireless tools, syslog and other projects. It has no clear direction, other than the whims of the developers themselves. Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.This is gross - and clearly confirms that Boycotters are criticizing what they don't understand.
And yes - feel free to explore alternatives, promote reimplementations, start forks, migrate to "something similar", but if you start spreading FUD and badmouthing systemd authors and code, you just show yourself as naive and ingenuous luddites.
Nessun commento:
Posta un commento