Re: Four people decided the fate of debian with systemd. Bad faith likely
On Saturday, March 01, 2014 04:30:00 PM Andrew Merenbach wrote:
> On 03/01/2014 15:43, yaro@marupa.net wrote:
> > On Sunday, March 02, 2014 12:00:41 AM Volker Birk wrote:
> >> That makes some hope for the BSD world again. The good thing about Free
> >> Software is the alternatives.
> >
> > Indeed. Though I think you vastly overestimate how many people even think
> > this is a bad change. A highly vocal minority at worst.
> >
> > Have fun using BSD, which continues to have a dwindling user base, for
> > purely political reasons because you actually buy into conspiracy
> > theories about what Lennart Poettering does in his free time.
>
> Hi Conrad,
>
> I started using Debian six months ago and FreeBSD two months ago. I
> appreciate what I see as positive traits of both, including the
> welcoming communities, and when I read an assertion like this I feel as
> though some supporting documentation might be helpful. Without it it
> sounds to me like exactly the sort of F.U.D. that respondents in this
> thread are trying to dispel.
>
> With regard to conspiracy accusations, I think one concern involves the
> deviation here from someone's take on the UNIX philosophy. Precepts 4
> ("Choose portability over efficiency") and 7 ("Use shell scripts to
> increase leverage and portability") in particular sound to me like
> exactly the sort of assertions upon which reasonable people might
> disagree with regard to systemd:
>
> http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosop
> hy
>
> Pick other precepts that [[ your most loved/hated software of choice ]]
> [[ gets right/wrong ]] and that [[ this or that alternative system with
> more/less traction ]] [[ gets wrong/right ]].
>
> Of course some will argue as to how applicable the "UNIX philosophy" is
> to Linux and I could understand that.
>
> I don't have feelings for or against systemd because I don't know enough
> to say and in absence of that I'd rather avoid succumbing to F.U.D. ;-)
>
> Cheers,
> Andrew
I definitely respect your position here. I'll be respectful in turn.
The UNIX Philosophy is a great collection of ideas of what a UNIX/UNIX-like
system should be like. On paper. In practice it makes large assumptions that
sadly do not hold up to how *nix works today.
Probably its biggest flaw is the assumption they are all created equal and that
shell scripts are easy to write, test, and debug and that they will always
work. Sadly, this is far from the reality and this is why initscripts are
largely deprecated in the UNIX world today, if not outright superceded.
For example, initscripts are so VERY not portable. I am sorry to say this, but
it is true. In theory they should be, as you state, according the UNIX
Philosophy they should be. But here comes the problem of that philosophy
assuming every UNIX/UNIX-like works the same and has the same tools.
In a VM, you should try copying a Debian initscript into another SysV-using
Linux distribution. It doesn't work. Portable initscripts just don't happen.
Would be nice, but they don't.
There's another big part of the UNIX Philosophy that initscripts don't really
meet the standard for, and it is that of simplicity. Simplcity is probably the
most important focus of the UNIX Philosophy.
Open an initscript. Now open a typical systemd init file. See the difference?
This is a Very Good Thing. For one, it's straightforward. Instead of a lot of
imperative knowledge on how we should go about starting a daemon/service, we
have declarative knowledge of what the service is, what it needs, and what
type of service it is. Systemd takes that configuration and does only what it
needs for that service. Concurrently. Faster, more reliable startup occurs.
Another reason this is good is notice how much time you'd have to take to
figure out what, exactly, the initscript is doing. Is it starting the daemon
yet? Or is it still laying the framework? Why is it doing things that way?
While in unit files you may wonder what one option is, it's a quick man page
away, but initscripts willr equire good documented code and a reasonable skill
at reading the language.
Let's go over the fact it's a nightmare to debug initscripts and they still
frequently hit failures such as losing control of their associated daemon.
That's bad.
Systemd basically fixes some problems and also adds a few features I think
Linux has been in desperate need for: Concurrent dependency launch, reliable
process control, the journal, the udev merge makes sure that things services
need are available when they need them. It also provides ways to track the
states of all your units and even look into why they failed. Sadly,
initscripts usually chuck all errors into /dev/null, which isn't helpful.
Oh, as for portability, the way systemd works means unit files are pretty much
guaranteed to work no matter where they run provided of course their
associated software exists. Can't expect Apache to launch if Apache's not
installed. The only exceptions are probably in cases where a unit might call a
script or something that presumes a specific configuration.
Long-winded explanations aside: Systemd provides a unified userspace
foundation. Makes for easier daemon startup, device management, maintenence,
and configuration that all works together. It's a very effective system manager.
Conrad
Reply to: