On 11/24/2014 at 02:56 AM, Scott Ferguson wrote: > On 24/11/14 13:20, Jerry Stuckle wrote: > >> On 11/23/2014 8:42 PM, Ric Moore wrote: >>> Like what?? I first installed systemd back when it was announced. >>> I have yet to have a single problem with it. >> >> What about all of those people with custom software running which >> relies on sysv init for starting? > > They should continue using sysv, don't you think? > > It's illogical to upgrade and not expect change - even when electing > (as Debian allows) to retain the same init system. It's illogical to upgrade and not expect *improvement*, but "improvement" is much more narrow than "change". An upgrade can bring "it runs faster", "it doesn't crash in situations where it would have crashed before", "it can now do things which it could not previously do" (AKA new features) - and all of those things are unambiguously improvements. Many projects - bash, grep, less, X, nano, just to name a few - consistently provide only improvements on upgrade; to do anything else would be considered a regression. However, not all upgrades are limited to providing improvements. Some of them also provide things which are not unambiguously improvements, but which either are only arguably improvements, or are simple changes. systemd seems to fall within that latter category. Debian itself has not historically managed to achieve "provide only improvements on upgrade" AFAIK - even for upgrades between stable releases, much less upgrades within one - and it's not necessarily reasonable to expect that it should, given the scope of the project and the limited manpower available. However, it has come reasonably close in some ways, and I think that the goal (for all software projects) should be to be as close to achieving that as possible. The transition to systemd, in its current form, seems to me to take Debian farther away from that goal - if only because of the cases in which systemd behaves differently from sysvinit in ways which are not unambiguously better. Maybe that's inevitable, but if so it should at least be recognized and acknowledged regretfully as such. Sneering at people whose preferred / expected upgrade model is "improvements only" as being illogical does not do that. >> Sure, people who only run software in .deb packages won't be hit >> as hard. > > At all. That depends on what you (or they) count as a "hit". They will certainly be hit with the change in boot-messages behavior, unless they have previously removed Debian's default "quiet" from their kernel command line, or they take extra action (beyond just "only run software in .deb packages") to explicitly retain the existing behavior. They may very well be hit with the change in expectations about the contents of /etc/fstab (in terms of when noauto or nofail is required). Et cetera. You may not count such things as a "hit", but other people might, and it might not be unreasonable for them to do so. > And then only if *they* don't elect to stay with sysv. > > But that is definitely not the entire Debian user base. > > Those that deploy customisations in the "Debian Way" should file bug > reports if those customisations are not supported *if* they change > init systems. Upgrades have *always* supported customisations done > the "Debian Way" - and I have every confidence they will continue to > do so Is this impacted in any way by the discussion recently on (I think) debian-devel about things under /etc which are now symlinks to configuration files (some of them I think systemd-related) under /lib or /usr/lib, which latter will be overwritten on upgrade even if local modifications have been made? At a glance, it certainly looks to me as if "the Debian Way" of customizing things may now have changed at least somewhat, based on differences in the way systemd expects / requires things to be done. Previously, if you edit a config file under /etc, your edits will not be automatically overwritten on upgrade; at the moment, those edits may be transparently passed through to a config file in some other location, and then automatically overwritten there on upgrade. There have been suggestions made to mitigate that by setting these symlinked-to config files as a-w, and modifying any editors that don't already do so to warn (with requirement for override) on an attempt to write to a read-only file, even if running as a user which could actually do so (i.e., as root). Though it seems unlikely that that would catch all possible editors that someone might reasonably use or want to use for such a purpose, and it could not catch cases where a file is replaced by mv or cp or the like... -- 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