Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #179886 > unrolled thread

If Linux Is About Choice, Why Then ...

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  If Linux Is About Choice, Why Then ... David Niklas <doark@mail.com> - 2017-04-07 20:50 +0200
    Re: If Linux Is About Choice, Why Then ... David Niklas <doark@mail.com> - 2017-04-07 22:10 +0200
    Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-08 03:30 +0200
      Re: If Linux Is About Choice, Why Then ... Richard Owlett <rowlett@cloud85.net> - 2017-04-08 07:10 +0200
        Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-08 09:20 +0200
          Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-08 11:10 +0200
            Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-08 22:30 +0200
          Re: If Linux Is About Choice, Why Then ... Martin Read <zen75502@zen.co.uk> - 2017-04-08 11:50 +0200
            Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-08 12:00 +0200
              Re: If Linux Is About Choice, Why Then ... The Wanderer <wanderer@fastmail.fm> - 2017-04-08 13:00 +0200
              Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-08 22:40 +0200
          Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-08 15:20 +0200
          Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-09 01:30 +0200
            Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-09 09:50 +0200
              Re: If Linux Is About Choice, Why Then ... Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-10 15:40 +0200
                Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-10 16:10 +0200
                  Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-10 16:20 +0200
                    Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-10 16:30 +0200
                      Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-10 16:40 +0200
                        Re: If Linux Is About Choice, Why Then ... tomas@tuxteam.de - 2017-04-10 21:10 +0200
                        Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 02:20 +0200
                      Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-10 23:30 +0200
                        Re: If Linux Is About Choice, Why Then ... deloptes <deloptes@gmail.com> - 2017-04-10 23:40 +0200
                        Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-11 16:40 +0200
                          Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 17:40 +0200
                        Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 17:30 +0200
                          Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-12 18:50 +0200
                            Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 21:50 +0200
                              Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-13 00:00 +0200
                            Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-12 22:50 +0200
                              Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 00:50 +0200
                                Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-13 02:20 +0200
                                Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-13 08:50 +0200
                                Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-13 11:00 +0200
                            Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-12 22:50 +0200
                              Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-12 23:20 +0200
                            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-12 23:20 +0200
                              Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 01:20 +0200
                                Re: If Linux Is About Choice, Why Then ... Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-04-13 02:00 +0200
                          Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-12 22:50 +0200
                            Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-13 01:00 +0200
                    Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 02:20 +0200
                Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 02:10 +0200
                  Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 05:40 +0200
                Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-11 03:40 +0200
                  Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-04-11 05:10 +0200
            Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-09 12:30 +0200
              Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-09 20:10 +0200
        Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-11 03:10 +0200
          Re: If Linux Is About Choice, Why Then ... Richard Owlett <rowlett@cloud85.net> - 2017-04-11 15:00 +0200
            Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-11 15:20 +0200
              Re: If Linux Is About Choice, Why Then ... Richard Owlett <rowlett@cloud85.net> - 2017-04-11 17:10 +0200
    Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-09 17:50 +0200
      Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-09 22:20 +0200
        Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-04-09 23:50 +0200
          Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-10 00:20 +0200
          Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-10 08:10 +0200
            Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-10 09:40 +0200
            Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-04-10 16:30 +0200
            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-12 11:40 +0200
              Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-12 18:20 +0200
                Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-12 23:10 +0200
                  Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-13 17:50 +0200
                    Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-13 19:40 +0200
                      Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-14 14:00 +0200
                        Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-17 23:40 +0200
                          Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-18 16:40 +0200
                            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-18 17:10 +0200
                              Re: If Linux Is About Choice, Why Then ... Gene Heskett <gheskett@shentel.net> - 2017-04-18 17:50 +0200
                                Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-20 02:20 +0200
                                  Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-21 16:40 +0200
                              Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-18 18:50 +0200
                                Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-20 12:00 +0200
                                Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-20 12:00 +0200
                                  Debian contributor Register of Interests (was Re: If Linux Is About  Choice, Why Then ...) Jonathan Dowland <jmtd@debian.org> - 2017-05-09 17:00 +0200
                                    Re: Debian contributor Register of Interests (was Re: If Linux Is  About Choice, Why Then ...) <tomas@tuxteam.de> - 2017-05-09 21:10 +0200
                            Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-18 17:40 +0200
                            Re: If Linux Is About Choice, Why Then ... Ben Caradoc-Davies <ben@transient.nz> - 2017-04-18 23:30 +0200
        Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-11 18:10 +0200
    Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 03:10 +0200
      Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-13 03:40 +0200
        Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 11:00 +0200
      Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-13 04:20 +0200
        Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-13 09:20 +0200
      Re: If Linux Is About Choice, Why Then ... Catherine Gramze <rhiamom@mac.com> - 2017-04-13 04:20 +0200
        Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 11:30 +0200
          Re: If Linux Is About Choice, Why Then ... Catherine Gramze <rhiamom@mac.com> - 2017-04-13 17:20 +0200

Page 1 of 5  [1] 2 3 4 5  Next page →

#179886 — If Linux Is About Choice, Why Then ...

On  Mon, 13 Mar 2017 12:30:11 -0700
Patrick Bartek <nemommxiv@gmail.com> wrote:
> The Linux mantra has always been "choice," plethoras of choices. So why
> at install time, is there no choice for the init system?  You get what
> the developers decide. Yes, you can install a new one -- I've done it
> and it works -- but only after the install.  It'd be a lot easier, if
> there were a choice to begin with just like whether you want a GUI and
> which one.
> 
> Now, I know with LFS, you get to choose everything, etc.  But is a
> choice of init at install time so outrageous that no one ever
> considered it or is it technically unfeasible or something else.
> 
> Just curious.
> 

Because this reply is so late I'm CC'ing you off list.

I sympathize, I run Gentoo Linux and us OpenRC. I plan on running Devuan,
a Debain derivative that supports lots of different init systems.
Why no one looks at their project and sees the people involved when
making a statistic up for the amount of dissatisfied systemd users I don't
know.

Sincerely,
David

[toc] | [next] | [standalone]

#179888

On Fri, 7 Apr 2017 14:27:40 -0400
David Niklas <doark@mail.com> wrote:

> On  Mon, 13 Mar 2017 12:30:11 -0700
> Patrick Bartek <nemommxiv@gmail.com> wrote:
> > The Linux mantra has always been "choice," plethoras of choices. So
> > why at install time, is there no choice for the init system?  You get
> > what the developers decide. Yes, you can install a new one -- I've
> > done it and it works -- but only after the install.  It'd be a lot
> > easier, if there were a choice to begin with just like whether you
> > want a GUI and which one.
> > 
> > Now, I know with LFS, you get to choose everything, etc.  But is a
> > choice of init at install time so outrageous that no one ever
> > considered it or is it technically unfeasible or something else.
> > 
> > Just curious.
> >   
> 
> Because this reply is so late I'm CC'ing you off list.
> 
> I sympathize, I run Gentoo Linux and us OpenRC. I plan on running
> Devuan, a Debain derivative that supports lots of different init
> systems. Why no one looks at their project and sees the people involved
> when making a statistic up for the amount of dissatisfied systemd users
> I don't know.
> 
> Sincerely,
> David

Oops,
The topic may be old but it does appear to be alive and well.
Also I sent to the list instead of CC'ing.

Sincerely,
David

[toc] | [prev] | [next] | [standalone]

#179889

On Fri, 7 Apr 2017 14:27:40 -0400 David Niklas <doark@mail.com> wrote:

> On  Mon, 13 Mar 2017 12:30:11 -0700
> Patrick Bartek <nemommxiv@gmail.com> wrote:
> > The Linux mantra has always been "choice," plethoras of choices. So
> > why at install time, is there no choice for the init system?  You
> > get what the developers decide. Yes, you can install a new one --
> > I've done it and it works -- but only after the install.  It'd be a
> > lot easier, if there were a choice to begin with just like whether
> > you want a GUI and which one.
> > 
> > Now, I know with LFS, you get to choose everything, etc.  But is a
> > choice of init at install time so outrageous that no one ever
> > considered it or is it technically unfeasible or something else.
> > 
> > Just curious.
> > 
> 
> Because this reply is so late I'm CC'ing you off list.
> 
> I sympathize, I run Gentoo Linux and us OpenRC. I plan on running
> Devuan, a Debain derivative that supports lots of different init

I considered Devuan initially, but it's based off Jessie; is still in
Beta, and in a few months Jessie will be oldstable.  Not the criteria
I'm looking for to replace my aging Wheezy system or install on a new
notebook I plan to get soon.

I've looked at other systemd-less Debian-based distros like AntiX and
mx16, but extraordinary measures must be taken to keep them free of
systemd components like using third party repos.  And I fear that will
ultimately affect whether they are truly Stable in the Debian
sense.  I have no interest in rolling releases.  Been there; done that.

Currently, I'm looking into a hybrid-Stretch with the init and
supervisor system I want -- easy enough to do -- disemboweling systemd
and relegating it to an innocous eunuch to satisfy dependencies. That
way I don't need any special repos and update/upgrade will work as it
should. Shows promise right now. More reading needed.  I have Plans B
and C just in case.

> systems. Why no one looks at their project and sees the people
> involved when making a statistic up for the amount of dissatisfied
> systemd users I don't know.

That's an argument for another day.

Thanks for your response.

B

[toc] | [prev] | [next] | [standalone]

#179890

On 04/07/2017 08:19 PM, Patrick Bartek wrote:
> [snip]
>> Why no one looks at their project and sees the people
>> involved when making a statistic up for the amount of dissatisfied
>> systemd users I don't know.
>
> That's an argument for another day.

Back when the systemd FLAME WAR was prominent, I followed a link to a 
justification link written by someone on the systemd development team.

My take-away was that systemd was aimed at *AND* had advantages for 
multi-user system.

I never saw anything addressing potential advantages for a specific 
organic user owning a discrete laptop.

Systemd *MAY* have technical advantages.
I am *NOT* qualified to say.
HOWEVER, in one sense, it is a marketing disaster.
'They' never told us, owners of single user laptops, why we should chose it.
YMMV ;/

OWL once more "ducks fer cover" ;/

[toc] | [prev] | [next] | [standalone]

#179892

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 08, 2017 at 12:06:19AM -0500, Richard Owlett wrote:
> On 04/07/2017 08:19 PM, Patrick Bartek wrote:
> >[snip]
> >>Why no one looks at their project and sees the people
> >>involved when making a statistic up for the amount of dissatisfied
> >>systemd users I don't know.
> >
> >That's an argument for another day.
> 
> Back when the systemd FLAME WAR was prominent, I followed a link to
> a justification link written by someone on the systemd development
> team.

It's much, much more complicated than that.

Note that UNIX systems have been decidedly multi-user, even long
before the SysV init (considerer "old" these days) even existed.

So we always had multi-user: the trend is rather the other way:
since everyone has his/her own gadget, complex things like desktop
environments tend to do silly things spoiling the multi-user roots
of UNIX.

There was another widespread init (BSD), which still has its places,
and which (ironically) brought things to the table which were given
up by SysV (namely process monitoring). What SysV brought was some
kind of modularity: you had one file per "package" instead of having
one huge file you had to edit each time you changed a package.

But it paid a price for that, and it could have been done much
better.

Personally I find SysV ugly, but in ways which could be made better.

What systemd brings (mainly[1]) to the table is the decoupling of
different "parts" of init: just imagine you have one service (let's
say a web server) which depends on some other thing (say a file
system being present via ummm... NFS, but it could be a RAID or a
memory stick, you get the idea). With a SysV init you can't express
that: you would have to script it explicitly. With systemd you
can express that the web server is only to be started once that
file system appears.

So I'd rather say systemd is an adaptation to a much more volatile
hardware landscape (which previously was only known in big iron)
comming to the masses these days (just think USB). It corresponds
to a more "dynamic" configuration.

There are, of course alternative ways to skin the cat.

Note that I'm a decided systemd opponent, and that might shine
through the above. Feel free to correct any misrepresentation.

regards

[1] Yeah: a "declarative" configuration, which may be considered
  as a plus (less obscure side effects) or as a minus (stronger
  separation between "priests" and "mortals").

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljojh8ACgkQBcgs9XrR2kbEXwCfXyu9yeq6p9N1jrPJXqB+si+M
RTEAn2cNEzBfh5h2V57FqZj4tOaap+Ix
=7wUU
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#179895

[Multipart message — attachments visible in raw view] — view raw

Le nonidi 19 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> So we always had multi-user: the trend is rather the other way:
> since everyone has his/her own gadget, complex things like desktop
> environments tend to do silly things spoiling the multi-user roots
> of UNIX.

We agree on that.

> Note that I'm a decided systemd opponent, and that might shine
> through the above. Feel free to correct any misrepresentation.

I would not have guessed. But you forgot a very important information:
what are you a PROponent of? A lot of people are only opponents, and
very vocal ones, and discussing with them is usually useless; I have
seen the symptoms on this very list. Being an opponent is easy,
everything has flaws that can be attacked; being a proponent is harder.

Now, back to the discussion at hand, namely a comparison between systemd
and the SysV init system:

> Personally I find SysV ugly, but in ways which could be made better.
> 
> What systemd brings (mainly[1]) to the table is the decoupling of
> different "parts" of init: just imagine you have one service (let's
> say a web server) which depends on some other thing (say a file
> system being present via ummm... NFS, but it could be a RAID or a
> memory stick, you get the idea). With a SysV init you can't express
> that: you would have to script it explicitly. With systemd you
> can express that the web server is only to be started once that
> file system appears.
> 
> So I'd rather say systemd is an adaptation to a much more volatile
> hardware landscape (which previously was only known in big iron)
> comming to the masses these days (just think USB). It corresponds
> to a more "dynamic" configuration.

This is true, and IMHO a balanced way of expressing things. But you
forgot a very important side to the question, that IMHO makes SysV init
unsalvageable: the init program, the one running as PID 1, itself.

With the SysV init system, the init program is stupid: it starts the
master script that spawns all the individual init scripts, it reaps its
children dutifully, but it does not keep track of anything beyond a
single 3-bits piece information called "runlevel".

Well, that is not entirely true: the init program can keep track of a
few specific children, defined in /etc/inittab with the "respawn"
keyword. But this feature is so limited and fragile that I have only
seen used to respawn gettys.

So, imagine you have an init script that starts, say, Apache httpd:
httpd double-forks and is adopted by PID 1. At some points later, the
httpd process exits; PID 1 reaps it, and that is all. Did it crash? Was
it stopped by the sysadmin? Is it completely stopped, or is there still
a mad subprocess running and monopolizing port 80? Nobody knows.

On the other hand, systemd keeps track. When httpd is started, systemd
knows "this is the httpd main process". Even better, it keeps track of
all the subprocesses started by it. If the main process exits, systemd
detects the return code, detects whether it is a crash or an explicit
shutdown, and logs it accordingly.

This makes a huge difference.

Of course, a lot of other init systems came along to try and address
that particular issue: daemontools, upstart, runit, etc. I have not
examined all of them very closely, but I am quite sure that any of them
is hugely better than SysV init.

But the arguments to compare them with systemd are not all the same.
That is why knowing what you are a proponent of is so important.

As far as I know, systemd is the one that makes the most use of the new
mutant powers of the Linux kernel: cgroups, namespaces... That makes the
whole thing more complicated, but that is what makes it possible to
implement certain features. For example, I have mentioned keeping track
of all the subprocess started by a daemon: I do not know if that would
have been possible without cgroups.

And of course, there are non-technical considerations. If there is a
technically awesome program but nobody uses it, maybe it is more
efficient to choose a slightly-less-awesome program for which
integration is already done and help is easier to find. That may not be
fully satisfactory, but not all battles are worth fighting. This
consideration makes a significant malus for init systems maintained by a
single developer with some help of her or his mailing-list friends. And
a significant bonus for init systems backed by a big corporation, even
if that gives it the awful taste of a corporate program.

On the non-technical side, having a non-obnoxious person as project
leader can definitely be counted as a plus. That is definitely not a
plus in the systemd (nor daemontools) column; I do not know for the
others.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179906

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 08, 2017 at 11:07:32AM +0200, Nicolas George wrote:
> Le nonidi 19 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> > So we always had multi-user: the trend is rather the other way:
> > since everyone has his/her own gadget, complex things like desktop
> > environments tend to do silly things spoiling the multi-user roots
> > of UNIX.
> 
> We agree on that.

Yes, this was more an answer to Richard.

> > Note that I'm a decided systemd opponent, and that might shine
> > through the above. Feel free to correct any misrepresentation.
> 
> I would not have guessed. But you forgot a very important information:
> what are you a PROponent of?

A more evolutionary approach. A de-boilerplating of SysV and perhaps
an outsourcing of process shepherding to something along the lines
of runit.

Definitely not a tightly coupled process set hooking into everything
from DBus to cgroups.

> With the SysV init system, the init program is stupid: it starts the
> master script that spawns all the individual init scripts, it reaps its
> children dutifully, but it does not keep track of anything beyond a
> single 3-bits piece information called "runlevel".

[...]

All the well-known arguments in favour of systemd. I know them by
heart, and this discussion has gone back and forth enough for all
of us. You know the counter-arguments as well as I know the pro
arguments, so I think it's no use in turning another round.

Perhaps we must accept that there are different philosophies here,
without hating each other :-)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljpRpkACgkQBcgs9XrR2kZpaACeNNLuitVVMbhY27fOik+KLBxe
764AnRJUKA+lPUgf/y5ASx6caCyd+3IA
=nhSQ
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#179896

On 08/04/17 08:15, tomas@tuxteam.de wrote:
> [1] Yeah: a "declarative" configuration, which may be considered
>   as a plus (less obscure side effects) or as a minus (stronger
>   separation between "priests" and "mortals").

If a systemd unit for a particular service needs the attention of an 
expert in order to be robust, the SysV-style RC script for the same 
service probably also needs the attention of an expert in order to be 
robust.

As such, I find your suggestion that declarative configuration causes 
'stronger separation between "priests" and "mortals"' more than a little 
bit questionable.

[toc] | [prev] | [next] | [standalone]

#179897

[Multipart message — attachments visible in raw view] — view raw

Le nonidi 19 germinal, an CCXXV, Martin Read a écrit :
> If a systemd unit for a particular service needs the attention of an expert
> in order to be robust, the SysV-style RC script for the same service
> probably also needs the attention of an expert in order to be robust.
> 
> As such, I find your suggestion that declarative configuration causes
> 'stronger separation between "priests" and "mortals"' more than a little bit
> questionable.

I think Tomás is perfectly aware of that, and quoted that argument from
systemd opponents without making it his own.

But you raise an interesting point. The people who invoke that argument
do not realize that they are already experts, "priests", of the shell
scripting language.

I think that explains some of the most vocal systemd opposition: systemd
aims to get rid of the scoriae of the past, but since it is IMHO
somewhat over-engineered, it has a learning curve that is rather steep
at the beginning. People who painstakingly learned the specifics of
shell scripts and init scripts are afraid that their skill will lose
value or become obsolete and they will need to start again.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179898

[Multipart message — attachments visible in raw view] — view raw

On 2017-04-08 at 05:56, Nicolas George wrote:

> Le nonidi 19 germinal, an CCXXV, Martin Read a écrit :
> 
>> If a systemd unit for a particular service needs the attention of
>> an expert in order to be robust, the SysV-style RC script for the
>> same service probably also needs the attention of an expert in
>> order to be robust.
>> 
>> As such, I find your suggestion that declarative configuration
>> causes 'stronger separation between "priests" and "mortals"' more
>> than a little bit questionable.
> 
> I think Tomás is perfectly aware of that, and quoted that argument
> from systemd opponents without making it his own.
> 
> But you raise an interesting point. The people who invoke that
> argument do not realize that they are already experts, "priests", of
> the shell scripting language.
> 
> I think that explains some of the most vocal systemd opposition:
> systemd aims to get rid of the scoriae of the past, but since it is
> IMHO somewhat over-engineered, it has a learning curve that is rather
> steep at the beginning. People who painstakingly learned the
> specifics of shell scripts and init scripts are afraid that their
> skill will lose value or become obsolete and they will need to start
> again.

With the additional factor that expertise in shell is useful in multiple
contexts, but (AFAIK, though I'm not an authority here) expertise in
systemd unit files et al. is useful *only* in the context of systemd -
with the result that the former is both more rewarding to learn, and
more likely to be already known by someone who is new to what might be
called 'sysadmin work'.

(Though there's something to be said for a new-to-the-problem-domain
person starting from zero rather than having to unlearn things that may
be useful in other problem domains but aren't advisable in this one.)

-- 
   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

[toc] | [prev] | [next] | [standalone]

#179907

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 08, 2017 at 11:56:10AM +0200, Nicolas George wrote:
> Le nonidi 19 germinal, an CCXXV, Martin Read a écrit :
> > If a systemd unit for a particular service needs the attention of an expert
> > in order to be robust, the SysV-style RC script for the same service
> > probably also needs the attention of an expert in order to be robust.
> > 
> > As such, I find your suggestion that declarative configuration causes
> > 'stronger separation between "priests" and "mortals"' more than a little bit
> > questionable.
> 
> I think Tomás is perfectly aware of that, and quoted that argument from
> systemd opponents without making it his own.

I'm aware of that, but still make this argument (in part) my own. There
is a whole spectrum between a script that "works in my environment" and
a robust script, as Martin envisions, the kind you would package as part
of a distribution, having to cope with very different environments.

The beauty of that spectrum is that a "mere mortal" can walk this thing
gradually, improving in the process.

I think it's perfectly legitimate to disagree with me on that, but there
you are.

> But you raise an interesting point. The people who invoke that argument
> do not realize that they are already experts, "priests", of the shell
> scripting language.
> 
> I think that explains some of the most vocal systemd opposition: systemd
> aims to get rid of the scoriae of the past, but since it is IMHO
> somewhat over-engineered, it has a learning curve that is rather steep
> at the beginning. People who painstakingly learned the specifics of
> shell scripts and init scripts are afraid that their skill will lose
> value or become obsolete and they will need to start again.

It's more: there's a huge gap between "doing what systemd allows", in its
declarative language, and changing the way it works, which involves
grokking the C sources.

This kind of layering is what we software "engineers" do all the time, but
in this case, the layer gap is far too wide for my taste.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljpSRoACgkQBcgs9XrR2kYaJwCfabVz/zbvHY+l9MPTGa7KhVzg
iFkAn2U0f7CLJDOroBxVs2zY+IcjfQTk
=ipzA
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#179901

<tomas@tuxteam.de> writes:

>
> What systemd brings (mainly[1]) to the table is the decoupling of
> different "parts" of init: just imagine you have one service (let's
> say a web server) which depends on some other thing (say a file
> system being present via ummm... NFS, but it could be a RAID or a
> memory stick, you get the idea). With a SysV init you can't express
> that: you would have to script it explicitly. With systemd you
> can express that the web server is only to be started once that
> file system appears.
>
> So I'd rather say systemd is an adaptation to a much more volatile
> hardware landscape (which previously was only known in big iron)
> comming to the masses these days (just think USB). It corresponds
> to a more "dynamic" configuration.
>
> There are, of course alternative ways to skin the cat.
>
> Note that I'm a decided systemd opponent, and that might shine
> through the above. Feel free to correct any misrepresentation.
>
You've been perfectly fair. Would that all opponents did so.

As Nicolas said, systemd's main advantage is that it keeps better track
of what exactly it launches. Not only can it keep track of subprocesses
launched by the main process, it can also use that knowledge to manage
their resources, giving the sysadmin the power to constrain a service so
that it never eats up all system resources.

Or, by putting it in a separate scope, it can separate processes from
the user session that started them, making clear the difference between a
rogue process that should have died on logout, and a user service that
should persist across sessions.

The bad news on that last one is that it triggered another flamewar, as
the default chosen (kill all processes on user session end) was rather
unfriendly to programs like tmux and screen.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

[toc] | [prev] | [next] | [standalone]

#179912

On Sat, Apr 8, 2017 at 4:15 PM,  <tomas@tuxteam.de> wrote:
> [...]
> What systemd brings (mainly[1]) to the table is the decoupling of
> different "parts" of init: just imagine you have one service (let's
> say a web server) which depends on some other thing (say a file
> system being present via ummm... NFS, but it could be a RAID or a
> memory stick, you get the idea). With a SysV init you can't express
> that: you would have to script it explicitly. With systemd you
> can express that the web server is only to be started once that
> file system appears.

Well, sure you could express such relationships in the sysv scripts,
and people did.

But sysv scripts used the shell as the declaration language, and the
shell is very flexible, and everyone seems to have done their own
thing in expressing such relationships. That made it hard to get an
overall analysis.

What could have been done here was to build a simple database of
relationships and a daemon to maintain the database. Sysv could start
that daemon early, and other inits could simply register through that
daemon as they came on-line.

But there were several different approaches to that, and territory
wars, and it wasn't ready for prime-time on the schedule of Fedora's
management team.

> [...]
> [1] Yeah: a "declarative" configuration, which may be considered
>   as a plus (less obscure side effects) or as a minus (stronger
>   separation between "priests" and "mortals").

There is no plus to a restricted declaration syntax except the walls
between the controlling service and the controlled services. In other
words, the minus of separation is the plus of separation.

And, of course, all the relationship database daemons used their own
subset of the shell's syntax for the declaration syntax. Systemd uses
a completely separate declaration syntax to strengthen the walls.

Noting that the walls are an illusion will invite flames, but that's
true of all the walls in software systems. They can all be got around.
If we couldn't get around the walls, no work could be done. The issue
is not the walls, it is whether processes can maintain reasonable
behavior in getting around the walls and still get their jobs done,
without too much policing and hand-holding from whatever
daemon/service is in charge of the wall.

And it was not that it could not be achieved in sysv, it was only that
it had not been uniformly achieved to meet Fedora management's
timetables.

This was and is the core of the arguments, I believe, but, if I expand
that thought too much I think it will still cause flames.

(And I don't understand why. Politics is an essential part of
management, and no one reasonable claims that open source means no
management at all. We ultimately will have to deal with the political
issues, whether we think we want to or not.)

(No, wait, I guess I do understand why. We do not have a uniform
language of politics. We can't say words like "democratic" or
"committee" and be sure that the person we are talking to understands
them they way we intend them. I should have been more careful about
that then, and I will try to be more careful now, if we can do this
conversation this time.)

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

[toc] | [prev] | [next] | [standalone]

#179913

On Sun, 9 Apr 2017 08:20:16 +0900
Joel Rees <joel.rees@gmail.com> wrote:

> On Sat, Apr 8, 2017 at 4:15 PM,  <tomas@tuxteam.de> wrote:
> > [...]
> > What systemd brings (mainly[1]) to the table is the decoupling of
> > different "parts" of init: just imagine you have one service (let's
> > say a web server) which depends on some other thing (say a file
> > system being present via ummm... NFS, but it could be a RAID or a
> > memory stick, you get the idea). With a SysV init you can't express
> > that: you would have to script it explicitly. With systemd you
> > can express that the web server is only to be started once that
> > file system appears.  
> 
> Well, sure you could express such relationships in the sysv scripts,
> and people did.
> 
> But sysv scripts used the shell as the declaration language, and the
> shell is very flexible, and everyone seems to have done their own
> thing in expressing such relationships. That made it hard to get an
> overall analysis.
> 
> What could have been done here was to build a simple database of
> relationships and a daemon to maintain the database. Sysv could start
> that daemon early, and other inits could simply register through that
> daemon as they came on-line.
> 

Someone correct me if I'm wrong, but I run sid and see things come and
go. Didn't we have this:

https://wiki.debian.org/LSBInitScripts

   long before systemd? And I have a memory of needing to add this
information to a firewall script I made from a template from a very
early version of LFS, on some version of stable. The date on the script
is July 2011.

Besides, I think the main points of contention about systemd are not
its init, but all the rest of the baggage that comes with it,
particularly the non-text log files. There does not seem to be a
compelling non-political reason for moving away from text files.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#179952

On Sun, Apr 09, 2017 at 08:41:28AM +0100, Joe wrote:
> Someone correct me if I'm wrong, but I run sid and see things come and
> go. Didn't we have this:
> 
> https://wiki.debian.org/LSBInitScripts
> 
>    long before systemd?

This and start-stop-daemon and probably a few other things are all
hacks that were layered on top of sysvinit, in an attempt to work around
its limitations and produce some kind of management system.

Ultimately, all of these hacks are fragile and doomed to failure.
The basic design concept of sysvinit is that you launch a daemon in
the background and record its PID in a file on disk.  Later, if you want
to stop it, or see if it's still running, you open up this PID file,
read the PID from it, and ask the kernel about the process with that ID.

Sounds OK, right?  At least, if don't have much experience with system
administration.

The problem is, PIDs get recycled.  If the daemon died 17 days ago, and
something else came along and used that PID, the sysvinit approach of
checking that the PID is still running will give the wrong result.

Add to that the very real problem of the legacy behavior of daemons that
originated in the 1980s: they double-fork themselves into the background,
on purpose.  This severs their tie to the parent process.  That means
you can't even *get* the PID of the actual daemon from the outside.
The daemon itself has to discover its *own* PID and write that to a PID
file.  And your init structure has to rely on that somehow?  That's what
the start-stop-daemon hack was introduced to try to work around, by
the way.

Hacks on top of hacks to work around hacks.  That's sysvinit.  It is not
salvageable.

Does that mean systemd is the ideal replacement?  No.  Systemd has these
overreaching tendrils in places it's got no business sticking tendrils.
Why does it have its own ntp daemon?  Why does it implement file system
automount behavior?  These things already exist as userspace processes.
Mature, trusted userspace processes, sometimes with multiple competing
alternatives already.

But then on the other hand, what else would you use instead of systemd?
Nobody has proposed a superior alternative yet, that I've seen.

So, IMHO, the best thing to do is to use systemd, but don't use any of
its optional intrusive tendrils.  Other people have other opinions, and
that's awesome.  A healthy, vigorous competitive environment benefits
all of us.

My wheezy servers use wheezy's sysvinit + daemontools.  My locally
installed services are managed by daemontools.  Debian's services are
managed by sysvinit.

On my jessie machines, I have systemd (with its syvinit compat layer)
plus daemontools, started as a systemd service.  I'm slowly transitioning
my local stuff from daemontools to systemd services, but I am in no hurry
to do so.

[toc] | [prev] | [next] | [standalone]

#179953

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 10, 2017 at 09:37:00AM -0400, Greg Wooledge wrote:
> On Sun, Apr 09, 2017 at 08:41:28AM +0100, Joe wrote:
> > Someone correct me if I'm wrong, but I run sid and see things come and
> > go. Didn't we have this:
> > 
> > https://wiki.debian.org/LSBInitScripts
> > 
> >    long before systemd?
> 
> This and start-stop-daemon and probably a few other things are all
> hacks that were layered on top of sysvinit [...]

Yawn.

Instead of actually answering, you distribute the leaflet.

SysV init is broken because it has no process monitoring? No.
Process monitoring isn't in its scope. Because it has no socket
activation? No.

Process monitoring: if you are serious about it, there's runit,
and daemontools. Socket activation? Try perhaps xinetd (before
this branches off to another sub-thread: I *know* it's not
*exactly* the same).

Some of us even like SysV's narrower scope, go figure.

Systemd doesn't "do" sound: is it broken for that?

C'm on. You can do better to contribute to a productive discussion
than that.

Sorry for sounding ranty, but yours was exactly the kind of post I
always see heating up the flamewars, with opinions and underhanded
contempt for the other side disguised as "facts" (no, I don't assume
it is intentional, mind you).

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljrkWoACgkQBcgs9XrR2kat2ACfVKHT+uleY6aPlR9uuTlKQ9+D
OvoAn2VfiXHU5NAVC2YI7oql5CrnTefs
=xesg
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#179954

[Multipart message — attachments visible in raw view] — view raw

Le primidi 21 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> SysV init is broken because it has no process monitoring? No.
> Process monitoring isn't in its scope.

Your other arguments make sense, but sorry, this one does not. The
process with PID one is the only immortal process on the system, and
adopts all orphan processes. For that reason, any kind of process
monitoring, if it needs reliability, must be rooted in PID 1. And in
turn, that makes process monitoring in scope for any project that aims
to implement a program for PID 1.

And that is what makes SysV init unsalvageable.

Socket activation, automounting, etc., are entirely optional and
peripheral. Process monitoring is not.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179955

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 10, 2017 at 04:13:48PM +0200, Nicolas George wrote:
> Le primidi 21 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> > SysV init is broken because it has no process monitoring? No.
> > Process monitoring isn't in its scope.
> 
> Your other arguments make sense, but sorry, this one does not. The
> process with PID one is the only immortal process on the system, and
> adopts all orphan processes. For that reason, any kind of process
> monitoring, if it needs reliability, must be rooted in PID 1. And in
> turn, that makes process monitoring in scope for any project that aims
> to implement a program for PID 1.

Runit works. Think about how :-)

(And yes, double-forking trickery fools it. Don't do that then. Most
daemons have a command line option for that, and those that dont...
after all, you have to "fix" daemons to let them participate in systemd's
socket activation party too, don't you?

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljrlsQACgkQBcgs9XrR2kZfZgCfT5XdzT/fzBWBo550RAKEyyKB
ucQAn1rdZZVk72FmNMWAs6UC8CV7cER/
=+CMt
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#179958

[Multipart message — attachments visible in raw view] — view raw

Le primidi 21 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> > Your other arguments make sense, but sorry, this one does not. The
> > process with PID one is the only immortal process on the system, and
> > adopts all orphan processes. For that reason, any kind of process
> > monitoring, if it needs reliability, must be rooted in PID 1. And in
> > turn, that makes process monitoring in scope for any project that aims
> > to implement a program for PID 1.
> 
> Runit works. Think about how :-)

No need to think how: runit takes PID 1. You prove my point.

(runit can also be integrated with the rudimentary monitoring of SysV
init: hacks upon hacks)

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179961

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 10, 2017 at 04:32:51PM +0200, Nicolas George wrote:
> Le primidi 21 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> > > Your other arguments make sense, but sorry, this one does not. The
> > > process with PID one is the only immortal process on the system, and
> > > adopts all orphan processes. For that reason, any kind of process
> > > monitoring, if it needs reliability, must be rooted in PID 1. And in
> > > turn, that makes process monitoring in scope for any project that aims
> > > to implement a program for PID 1.
> > 
> > Runit works. Think about how :-)
> 
> No need to think how: runit takes PID 1. You prove my point.

Just one of the possible usage patterns.

> (runit can also be integrated with the rudimentary monitoring of SysV
> init: hacks upon hacks)

As do PostgreSQL, where the postmaster manages all its children, or
Apache, or sshd. All hacks upon hacks. C'm on.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljr1xMACgkQBcgs9XrR2kZJ/wCfSDElfroVJGIsqEFsMh0zB0mU
05kAn2aqv5AP1Bq5+401TWqghNrY5+qY
=qa8g
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | linux.debian.user

csiph-web