On 2015-08-31 at 00:39, T.J. Duchene wrote: > On Sun, Aug 30, 2015 at 10:49 PM, Doug <dmcgarrett@optonline.net> > wrote: >> What we would like is stability, and until Poettering started >> messing with Linux, we pretty much had it--at least in any given >> distro. > > That's where we part in agreement. You can't blame Poettering for > messing with Linux. We can blame him for his design decisions WRT systemd, the philosophy behind it, and the attitude with which he pushes it. systemd's actual functionality, for the most part (various more-or-less superficial things aside), isn't that bad; a lot of it is actually (at least potentially) good. It's the compromises in principle that are the biggest problems, and Lennart simply does not seem to share the principles which are being compromised. > The distributor makers looked at systemd and realized that it would > make things easier for them. Systemd fills a distributor's need. You > don't have to like it, but only Debian is responsible for Debian. > Poettering had no input in that decision, so you should not blame him > for it. Debian could not have chosen systemd if Lennart had not written it, and Debian could not have chosen systemd-in-its-current-form if Lennart had not designed it in that form, so some layer of the blame does fall on him. > Frankly, at no point have I seen Linux become more "unstable" > because of systemd. In my experience, Linux as an operating system > is not horribly stable when you use the bleeding edge releases. It's > much better than Windows most of the time, but I would not use even a > stable Linux in a nuclear reactor. Linux is not designed for > extreme stability. It depends on what kind of stability you're talking about. The init-time experience with sysvinit and sysvrc has been fairly stable for years, if not decades; systemd breaks with that stability, in an attempt to introduce a new paradigm which its developers think is better. There are plenty of reports of systems which worked just fine with a given configuration which do not work with that configuration after being transitioned to systemd; for one easy non-cosmetic example (there are apparently others), consider the "a failed mount which is not explicitly marked for failures to be ignored will result in a failed boot" behavior, which did not occur without systemd but does happen with systemd. Yes, you can change your system's configuration to make it work, but in a stable system you shouldn't have to. (And I'm not talking about "stable" in the sense of the Debian repository codenames; I'm talking about 'stable" in the larger sense.) On a more cosmetic level, without systemd, if you use a "quiet" option on the kernel command line you will silence kernel output during boot but not silence service-startup (etc.) option during the later stages of the bootstrap process - but with systemd, using that option silences both kernel output _and_ service-startup (etc.) output.. Yes, you can add half-a-dozen-ish systemd-specific options on the kernel command line to get systemd to display the same combination of output types as would have happened by default without systemd - but if you have to change your system configuration in order to get the same behavior, that system is not behaving in a stable fashion. Also on a mostly-cosmetic level, if you log in at a text console without systemd, you will get a certain set of messages, coming mostly from login and from your shell - but with systemd, logging in at a text console also produces a mess of extra messages coming from logind, which are largely irrelevant to whoever just logged in and which step all over either the original set of messages or the actual shell prompt. As far as I've been able to determine, there is no way to get logind to not produce these messages, without also preventing it from producing messages later - or in background logging - which you might actually want. And, if I'm interpreting the situation correctly, you will probably see these messages in your console every time _anyone_ gets a new "session" on that computer, even if it's not you. This is the final-straw behavior which led me to reject systemd for my own systems. (And, no, logind is not systemd-the-PID1-binary - but is part of systemd-the-collection-of-other-binaries-which-orbit-that-binary, and is developed by systemd-the-project-which-develops-all-those-binaries. This is part of the name ambiguity which I was wanting to fix.) The systemd developers acknowledge the need for some degree of backwards compatibility, in that they have "support" on some level for /etc/init.d/ init scripts. However, without _full_ backwards compatibility on _every_ level - including the cosmetic - being at least _available for those who want to choose it_ (and preferably being the default behavior), the behavior seen before a transition to systemd will be similar enough to the behavior seen after such a transition for the whole to deserve the description "stable". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature