On 2015-08-31 at 13:25, David Wright wrote: > Quoting The Wanderer (wanderer@fastmail.fm): > >> 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. > > That's a very interesting argument. Can we apply it to Presidents' > parents? A person's parents do not design or define that person. They have input, which is not to be entirely discounted - but even on the assumption that "nature vs. nurture" gets resolved entirely in favor of nurture, there are many other sources for "nurture" than just the parents. Plus, of course, a person has a mind of his/her/etc. own, which a program or set of programs does not. (Barring AI or obscure arguable corner cases, anyway.) All that aside, blaming parents does happen in the real world - things like "you didn't raise that boy right" appear often enough in certain parts of the culture. >> 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.) > > I can't see what's wrong with adding new features or with changing > defaults. Your example was documented in the release notes. I was speaking to the claim that systemd represented a lack of stability, vs. the claim that no instability had been seen because of systemd. (Paraphrasing in both cases.) Adding new features, while remaining 100% backwards compatible, is not ordinarily a problem - except inasmuch as doing so has side effects like increasing footprint or increasing attack surface, which is a separate discussion. Changing defaults isn't inherently a problem either (although I have an entire other discussion there), but it's difficult to claim that such a change is stable behavior. >> 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. > > All I've added to /etc/default/grub is systemd.show_status=true > which gives me about the same level of output from booting as before. > (A bit more, it's true: eg it says both starting and started for each > service, and the granularity is finer.) Hmm. Maybe I'm remembering wrong; I thought that when people complained about this before, the documentation to which they were pointed listed various individual options to re-enable various different types of boot messages separately. I did not see one to enable the messages en-masse which would not also enable the messages which the original 'quiet' option would have silenced. If such an option does exist and function, that blunts this example pretty solidly. >> 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. (For clarification, the reason this was the final straw was that it meant I could not simply ignore the presence of systemd entirely for normal use, since this would push it into my attention on every console login.) > I've tried to work out what you're talking about here. Here's a > comparison of my (admittedly rather noisy) VC login on two systems: > > west!david 12:22:14 ~ $ diff -U0 VC-login-*[ey] > --- VC-login-jessie 2015-08-31 11:34:23.476573261 -0500 > +++ VC-login-wheezy 2015-08-31 11:38:11.000000000 -0500 How did you get these files? I haven't been able to come up with a way to get a dump of the exact text that is on a console, short of manually typing it into an editor (probably on another computer, for convenience's sake). Parts of it are logged, but not as far as I can tell into a single file, and I would actively expect that the text I'm objecting to would get logged separately (if at all) in any case. I haven't done a full detailed analysis of exactly what happens yet, but the first time I log in on my laptop after boot, I get the following (retyped, timestamps and other unique numbers mangled, one line of context included): ======== No mail. [ 123.123456] systemd-logind[1234]: New seat seat0. [ 123.234567] systemd-logind[1234]: Watching system buttons on /dev/input/event4 (Power Button) [ 123.123678] systemd-logind[1234]: Watching system buttons on /dev/input/event5 (Video Bus) [ 123.123789] systemd-logind[1234]: Watching system buttons on /dev/input/event1 (Power Button) [ 123.124012] systemd-logind[1234]: Watching system buttons on /dev/input/event3 (Lid Switch) [ 123.124123] systemd-logind[1234]: Watching system buttons on /dev/input/event2 (Sleep Button) [ 123.134567] systemd-logind[1234]: Failed to start user service: Unknown unit: user@1000.service [ 123.138901] systemd-logind[1234]: New session 1 of user foobar. This line was printed by the fortune program, called by ~/.bashrc. ======== On later logins as the same user without rebooting, I get only the "New session X of user foobar" message, which is still bad enough but doesn't deserve the description "a mess of messages". Similarly, on logging out of that session, I get the following at the login prompt: foobar login: [1234567.123456] systemd-logind[1234]: Removed session 1. and the cursor for the login prompt appears on the next line, rather than appearing immediately after the 'hostname login: ' text. (The message from logind does not appear instantly after logout; if I start typing a username quickly enough, this will get printed in the middle of the username, thus completely confusing display of what has and has not already been typed.) This is potentially useful information to see in log files, and if the single "new session X of user foobar" line does get printed to all active consoles every time _anyone_ starts a new session (I still haven't tested that), there are circumstances where it might even be useful to have the immediate heads-up alert that "hey, someone else just logged in to your system!" - but it should not be being printed when the user logs in or out, especially not if it's going to step on the login prompt. Note that this is on a system with only some parts of "the systemd suite" present, and with systemd _not_ running as PID1. (I apologize for not mentioning that earlier; it's been long enough since I was changing any related part of this laptop's config that I didn't remember the exact details of how I'd left it.) Specifically: $ dpkg -l "*systemd*" | grep ii ii libpam-systemd:amd64 224-1 amd64 system and servi ii libsystemd0:amd64 224-1 amd64 systemd utility ii libsystemd0:i386 224-1 i386 systemd utility ii systemd 224-1 amd64 system and servi ii systemd-shim 9-1 amd64 shim for systemd -- 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