Earlier quoted context omitted.
Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.
I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".
Why I dislike systemd
181–190 of 254 posts
Re: Why I dislike systemd
#182Earlier quoted context omitted.
The shell has always been awful. It is underpowered and overfeatured with a deeply crappy API. It is more like Windows 3.1 than any sane development environment.
The good news is that you don't have to implement initscripts as shell scripts. I recall at least one GNU/Linux distro that used Python for all its initscripts, for example. Really, as long as the "script" is executable, a SysVInit-based or BSD-rc-based system doesn't really care (unless it's doing something strange like calling a specific interpreter on each script - i.e. calling `sh /etc/rc.d/rc.*` or somesuch).
Actually, a FreeBSD or NetBSD rc system does indeed care, for that very reason. rc.d scripts are sourced by a /bin/sh shell, using the . command. See run_rc_script on the rc.subr(8) manual page for details. Ironically, it's daemontools and daemontools-like systems where what you say holds the most widely. Tools such as execline can be and are in practice used in "run" programs.
Re: Why I dislike systemd
#183Earlier quoted context omitted.
The key is the expense vs reward ratio. I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and t…
I don't think it's really fair to compare writing unit files to being able to program in shell. True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented. And for sure, these options are immensely more reusable when writing a new unit file than mixing and matc…
knowing the systemd unit options is not a reusable skill
That is, to an extent, not true. There is at least one system that can import systemd unit files, subject to some fairly obvious limits on Linux idiosyncrasies. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Re: Why I dislike systemd
#184Earlier quoted context omitted.
The good news is that you don't have to implement initscripts as shell scripts. I recall at least one GNU/Linux distro that used Python for all its initscripts, for example. Really, as long as the "script" is executable, a SysVInit-based or BSD-rc-based system doesn't really care (unless it's doing something strange like calling a specific interpreter on each script - i.e. calling `sh /etc/rc.d/rc.*` or somesuch).
Actually, a FreeBSD or NetBSD rc system does indeed care, for that very reason. rc.d scripts are sourced by a /bin/sh shell, using the . command. See run_rc_script on the rc.subr(8) manual page for details. Ironically, it's daemontools and daemontools-like systems where what you say holds the most widely. Tools such as execline can be and are in practice used in "run" programs.
I learn something new every day; thanks!
It doesn't look like OpenBSD has such a requirement (the start_daemon() routine in /etc/rc just calls each configured daemon's initscript as-is from /etc/rc.d without specifying sh or ksh to execute with); I had (incorrectly) assumed that this was a general BSDism rather than an OpenBSDism.
Re: Why I dislike systemd
#185Earlier quoted context omitted.
I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".
http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01537.html
That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag, which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature, so go whine to the kernel folks about the thing of theirs that we broke and don't feel like fixing", as if the systemd folks have become one with the Microsoft).
Whether or not there are other underlying issues stemming from such misbehavior is irrelevant to the fact that the misbehavior exists. It's like sticking your hand in a fire, then blaming your hand instead of your own stupidity for your third-degree burns.
Re: Why I dislike systemd
#186Earlier quoted context omitted.
Except that there's no reason for systemd's model to "get traction" outside of desktop-focussed Linux distributions, since a "better user experience" is it's current raison d'etre. So no, I shouldn't need to have to "learn to trust the operating system / systemd" on my servers -- it has no reason to be there!
The model where services do not daemonize and write a pid to a file is actually hugely better for servers. Most of the rest of it is not useful.
The model where services do not daemonize and write a pid to a file is ...
... the one that people who moved away from System 5 rc scripts years ago have been pushing for with some degree of success, for years. systemd is not its source at all. systemd has merely been reaping the benefit of all of the programs over the past 18 years that have gained a --no-fork or a --foreground or a -D or a -F or whatever option in response to those who wanted to run services properly without bodging things under daemontools, or runit, or s6, or perp, or freedt, or daemontools-encore ...
Re: Why I dislike systemd
#187With System V and Debian, one added some new apache or bind configuration and then called invoke-rc.d daemon reload to inform the daemon to reread the configuration files. With systemd, you do the exact same thing and then call systemctl reload daemon . Is the author making an argument here based some other distributions way of handling System V?
No. The author is not getting reloading the daemon's configuration mixed up with reloading systemd's configuration. You, however, are. The systemctl manual page warns about this mistake. See what it says under daemon-reload.
Re: Why I dislike systemd
#188It seems that the author completely disregards the modern tendency to treat boxes as commodities. While pondering a "what's going to start on this particular machine" question is interesting in the "old world", it is hardly a question anyone asks when your fleet starts to be measured in tens of thousands of cloud instances.
Re: Why I dislike systemd
#189Earlier quoted context omitted.
This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifyi…
It's perfectly possible to run scripts with systemd unit files, so there's no real "flexibility" lost anywhere. The primary improvement is that systemd handles by default most of what used to be boiler-plate in every script, on top of calculating dependencies automatically. Then you get integrated process supervisor capabilities so that the init system actually knows whether services are running or not. Speed was cer…
Possible sure, but it the systemd compatiblity with sysv scripts are listed as 99%. Meaning that complex scripts are liable to break, and it is exactly those that you want the compatibility for.
Re: Why I dislike systemd
#190I'm one of the people who jumped ship to OpenBSD in the last year or so. I think I first touched a Linux machine in 1997 or 1998. systemd has been part of the reasons I did that for precisely the same reason. There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE. It's more efervescent than it's ever been. Fifteen years ago…
> There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE.
Yeah, i've been thinking the same recently.
The current development above the kernel seems to either be from the desktop down, or from the point of view of managing 1000s of headless instances in a "container" farm.
This with a side-order of Windows-isms demanded from corporate/government clients looking for a way to get away from MS while retaining their centrally controlled fine grained access control.