Re: systemd waisted 5 hours of my work time today
On Sun, Jul 27, 2014 at 9:18 PM, Joel Rees <joel.rees@gmail.com> wrote:
> 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
Sorry! :)
> 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.)
Kicked off or moderated? (It would mean the same to me because I'd
unsubscribe...). I remember some threads where you were arguing about
some Fedora software policies (one about grubby?).
> 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.
I run rawhide on my laptop and the only systemd breakage that I've
experienced since Fedora 15 has been nfs. X and Gnome have broken more
often over the years...
I'm trying to remember systemd breakages in Debian but it's late and
I'm tired and the only one that comes to mind is the fact that systemd
doesn't respect sysvinit tmpfs settings in "/etc/default/". I suppose
that if Fedora used a similar environment file in its equivalent,
"/etc/sysconfig/", there might have been an upstream solution. As it
is, Debian users will have to use a drop-in to over-ride the systemd
.mount that they want to change, unless they write a unit to use the
Debian environment file.
> 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.
Yes, systemd replaces sysvinit's functionality (booting up) plus extra
functionality.
> 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.)
I think that you're referring to the network and network-online
business. As I pointed out in that thread, the man page(s) showed that
the OP's expectation/understanding was incorrect of the necessity of
using "Requires". Quite frankly, I found the reasoning obscure
(systemd's not his) but the necessity of "Requires" as well as "After"
or "Before" (I've forgotten which one the OP was using) was
documented.
> 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.
I suppose that there'll be more problems in upgrades to jessie than
for previous upgrades but that clean installs will be fine - as they
seem to be for RHEL 7 (I haven't yet had a chance to use it on our
test instances at work or on my own CentOS/SL VM but the scuttlebutt
at work is that it's fine).
> 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.
I'm not a fan but I'm not an anti. We have it here and elsewhere and
I've been using it in Fedora since F15 so I'm used to it. On servers
where I run Debian, I'm hoping to use sysvinit for jessie in protest
at certain things but I'm not expecting that to be possible for
jessie+1.
> In this case, yeah, experimental is experimental, but there are
> limits. And that was not the way to have done it.
I'm not sure what you're referring to. The introduction of systemd in
Debian or the recent removal of the systemd-shim dependency in testing
and unstable?
Reply to: