Re: systemd waisted 5 hours of my work time today
On Sun, Jul 27, 2014 at 7:47 PM, Tom H <tomh0665@gmail.com> wrote:
> On Thu, Jul 24, 2014 at 9:00 AM, Slavko <linux@slavino.sk> wrote:
>> Dňa Thu, 24 Jul 2014 13:00:24 +0100 Tom Furie <tom@furie.org.uk>
>> napísal:
>>>
>>> You are, of course, aware that testing and unstable are test platforms
>>> where breakage is to be expected? They shouldn't be used for anything
>>> "mission critical", that's what stable is for.
>>
>> No, i will not comply with this.
>>
>> The testing must be in state, where it must to boot (except some boot
>> options tweaks) by default. I think, that nobody here will complain if
>> some of software/services on testing doesn't work, but computer must to
>> boot!
>
> Can you point to a document where such a commitment has been made or
> such a criterion has been decided?
You've just touched my hotpoint, Tom --
The post that got me kicked off the Fedora developer list was the one
a bit more than two years ago where I questioned Poettering's
engineering qualifications specifically because he lead the putsch.
(I'm apparently no longer on the auto-mod list over there, but I don't
really care any more.)
Engineering by putsch is simply not what qualified engineers do to
users who have not agreed, up front and beforehand, to be fodder for
the putsch.
Yeah, when we agree to use Sid or Rawhide, we agree to a certain
amount of being guinea pigs, but this is a level or two beyond that,
even.
Being a little less metaphorical, the shift from sysv-init to anything
as comprehensive as systemd necessarily breaks APIs en-masse. The
parts that are in the specs may be manageable, but it is known that in
systems as complex as OSses, there are more implicit linkages than any
single person or any committee can plan for.
Implicit linkages are where the API providers' understandings and the
API users' understandings have some common base that is not recognized
as needed to be written down.
But when you expand the reach of the API or the user domain, you
discover that the common understanding is not there after all, and
then programmers start engineering by rumor and superstition. Both the
API and the user domain were not just drastically expanded, but also
shifted in this case. Uhm, by shift, I mean that the focus has changed
significantly.
Systemd is not a replacement for sysv-init. It is a set of brand-new
functionality that sysv-init was never intended to implement. And it
kind-of-sort-of adds the sysv-init functionality as the spoonful of
sugar that is supposed to make the medicine go down. Woops, that's
more metaphor.
One of the symptoms of this kind of implicit linkage is where the end
users end up saying, well, the docs say ordering shouldn't matter, but
in this particular case it does. (See several recent threads for
recent examples.)
The sort of changes being brought in by systemd are so sweeping that
we cannot expect them all to be shaken out in the distro's
experimental release, even if the agreement to be test users were to
agree something to that extreme. So the stable users are going to
experience downtime. Period. (I'm not going to bet one way or another
as to whether Redhat, as a company, survives this. I will be surprised
if it does not slow their profit margins down enough that the board
members will be looking for scapegoats.) The real damage, we haven't
really seen yet.
Good engineers would have set up their own distro to implement systemd
in, to knock the bugs out, to prove the utility, and to isolate the
fallout. Refer to the way SELinux et. al. have been handled. Any less
careful approach is beyond hubris. That's why the systemd group, et.
al. are often accused of arrogance.
I know you're no fan of systemd yourself, Tom, but you (and rest of
the community) have to start seeing where you (and we) have been
wangled.
In this case, yeah, experimental is experimental, but there are
limits. And that was not the way to have done it.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: