[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I'm not a huge fan of systemd



Brian wrote:
On Sat 12 Jul 2014 at 11:26:23 -0400, Miles Fidelman wrote:

[Sorry to snip a lot of reasonable comment, but I'd rather concentrate
on your final points for now].
Now, I would hope that by the time Jessie gets released as stable,
bugs and impacts have been minimized, and that the release notes and
installation instructions are comprehensive when it comes to systemd
impacts - but we're from there.
We all hope the same as you with regard to bugs. "Impacts" are a different
matter; I rather think the beneficial impacts of systemd are not what you have
in mind! The vast majority of users will press a button and the machine will
boot properly; they will not care less. Those who have responsibility for more
complex systems will read the documentation, whether it be Debian's or
upstream's; duty is a hard taskmaster.

Yes, duty is a hard taskmaster, but when I select platform technologies I kind of expect them to be stable across updates. Same again when I'm involved in specifying, developing, and/or deploying updates to stable products.

I'm not as sanguine as you seem to be that things will just work, particularly after reading a recent presentation on the state of systemd in Wheezy and Jessie - a little dated (FOSDEM, Feb 2013) - but the most recent status update referenced on the debian wiki's systemd site) - which includes goodies like "NFS mounting via /etc/fstab is currently broken"


The discussions on this list are precisely what will lead to such
documentation by:
You are very optimistic. debian-user doesn't replace the BTS.

No. But it sure is a good way for developers to pick up on problems with newly released code. The BTS is a lot better at clear bugs in systemd, than in identifying impacts that it might have on other software, or on administrative scripts people have written, and so forth.

a. alert many of us to issues and impacts before we migrate
(particularly impacts on things that won't be caught by package
maintainers)
Let's be specific here. If you are in charge of a cups installation with
1,000 printers you are surely going to read its Debian documentation?
Why should the Release Notes mention socket activation as an "impact"
and point you there?

Well if someone is going to make a kernel change, or a change to a core service (like systemd) - and it was going to break another major utility, like cups - I would sure hope that that was mentioned in the release notes.
b. provide input to package maintainers, and maybe upstream
developers, on things that might need some work as a result of
systemd
The BTS exists for this purpose.

As noted - more for bugs in systemd, then downstream impacts.

c. provide raw material for the release notes and installation
instructions for Jessie
debian-doc is the place for this.


Not really. Raw material comes from the place where impacts are identified and discussed.

The example I keep coming back to is the perl4->perl5 transition, and the perl5-> perl6 transition; or, for that matter ongoing revisions to HTML. It's one thing when developers openly acknowledge "things will break, we're trying to minimize that, but we're also including compatibility modes and building translators, and such." I get a very different vibe from systemd - more like "we don't care if we break things, that's your problem." Note I get a much more positive vibe from the folks who are incorporating systemd into Debian - after reading things like "sysvinit will most likely remain the default for most installations" (mind you that was from FOSDEM 2013 things might have changed).

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra


Reply to: