If Linux Is About Choice, Why Then ...

classic Classic list List threaded Threaded
96 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

If Linux Is About Choice, Why Then ...

David Niklas
On  Mon, 13 Mar 2017 12:30:11 -0700
Patrick Bartek <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

David Niklas
On Fri, 7 Apr 2017 14:27:40 -0400
David Niklas <[hidden email]> wrote:

> On  Mon, 13 Mar 2017 12:30:11 -0700
> Patrick Bartek <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Patrick Bartek-2
In reply to this post by David Niklas
On Fri, 7 Apr 2017 14:27:40 -0400 David Niklas <[hidden email]> wrote:

> On  Mon, 13 Mar 2017 12:30:11 -0700
> Patrick Bartek <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Richard Owlett-3
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" ;/




Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

tomas@tuxteam.de
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Nicolas George-4
Le nonidi 19 germinal, an CCXXV, [hidden email] 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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Martin Read-2
In reply to this post by tomas@tuxteam.de
On 08/04/17 08:15, [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Nicolas George-4
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Mart van de Wege
In reply to this post by tomas@tuxteam.de
<[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

tomas@tuxteam.de
In reply to this post by Nicolas George-4
-----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, [hidden email] 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-----

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

tomas@tuxteam.de
In reply to this post by Nicolas George-4
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Joel Rees-3
In reply to this post by tomas@tuxteam.de
On Sat, Apr 8, 2017 at 4:15 PM,  <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Joe Rowan
On Sun, 9 Apr 2017 08:20:16 +0900
Joel Rees <[hidden email]> wrote:

> On Sat, Apr 8, 2017 at 4:15 PM,  <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

tomas@tuxteam.de
In reply to this post by Joel Rees-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 09, 2017 at 08:20:16AM +0900, Joel Rees wrote:

[...]

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

To be fair, there *is* a plus: with a restricted language, you can be
sure that some properties of the whole system are maintained. It then
becomes easier to reason about the whole behaviour. I think it becomes
a tradeoff.

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

iEYEARECAAYFAljqCuEACgkQBcgs9XrR2kbADQCcDpqg5P8RMFFFyk4YDUslK22w
nFAAnAm1/LMIznTSv84Lffg1/AI7319D
=fNYy
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Michael Fothergill-3
In reply to this post by David Niklas


On 7 April 2017 at 19:27, David Niklas <[hidden email]> wrote:
On  Mon, 13 Mar 2017 12:30:11 -0700
Patrick Bartek <[hidden email]> 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


​I have been reading through some of this stuff and I think that the debian users who are fans of the sysinit boot up scripts should switch to running Gentoo.

I use Gentoo with the openrc option. 

Those who are OK with systemd should stick with Debian.

Regards

MF




Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Joel Rees-3
In reply to this post by tomas@tuxteam.de
On Sun, Apr 9, 2017 at 7:20 PM,  <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, Apr 09, 2017 at 08:20:16AM +0900, Joel Rees wrote:
>
> [...]
>
>> 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.
>
> To be fair, there *is* a plus: with a restricted language, you can be
> sure that some properties of the whole system are maintained. It then
> becomes easier to reason about the whole behaviour. I think it becomes
> a tradeoff.

I think that was what I was trying to say, that the plus is also a
minus and you have to weigh it as a tradeoff.

But you do have to understand, in the weighing, that the restrictions
are not a perfect wall.

Also, I was trying to refer to the restricted dependency declaration
language becoming infrastructure that allows management software to
reliably analyze the dependencies. That was what was not happening
when the shell itself was being used to declare (or search out) the
dependencies.

Assuming that the declaration language is sufficient, the plus side is
that once the declarations are made, the management tools can work on
the dependencies more or less directly.

The minus side includes the problems of new language and the question
of whether it is sufficient, and, as someone else said elsewhere, the
baggage that systemd brings along with the new language.

The language itself could be made independent of systemd, if the
systemd project would cooperate with that.

> regards
> - -- tomás
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAljqCuEACgkQBcgs9XrR2kbADQCcDpqg5P8RMFFFyk4YDUslK22w
> nFAAnAm1/LMIznTSv84Lffg1/AI7319D
> =fNYy
> -----END PGP SIGNATURE-----
>



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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Patrick Bartek-2
In reply to this post by Michael Fothergill-3
On Sun, 9 Apr 2017 16:25:57 +0100 Michael Fothergill
<[hidden email]> wrote:

> On 7 April 2017 at 19:27, David Niklas <[hidden email]> wrote:
>
> > On  Mon, 13 Mar 2017 12:30:11 -0700
> > Patrick Bartek <[hidden email]> 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
> >
> >
> ​I have been reading through some of this stuff and I think that the
> debian users who are fans of the sysinit boot up scripts should
> switch to running Gentoo.
>
> I use Gentoo with the openrc option.

Gentoo is a rolling release.  I prefer the "stable" philosophy of Debian
-- basically only bug and security fixes. I've been running Wheezy
now for 5 years, and it's, for all practical purposes, the "same" as
when I installed it.  After such a time, a rolling release would be a
completely different animal versionwise.

I've tried rolling releases before.  They are usually cutting edge and
more problematical (Unless they've gotten a lot better).  I want
something that works for years and doesn't break. That's one of the
reasons I chose Debian five years ago. Now, because of the systemd
thing, I'm looking at alternatives.

> Those who are OK with systemd should stick with Debian.

After much reading, I consider systemd more suited to large, busy
servers than a desktop box or notebook with just one user.  It's
like being forced to use a huge tractor-trailer rig with lots of chrome
and lights and 24 gears when a simple mini-van will do. ;-)

B

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Miles Fidelman-3
On 4/9/17 4:15 PM, Patrick Bartek wrote:

> After much reading, I consider systemd more suited to large, busy
> servers than a desktop box or notebook with just one user.  It's
> like being forced to use a huge tractor-trailer rig with lots of chrome
> and lights and 24 gears when a simple mini-van will do. ;-)
>
>
Funny thing.  As far as I can tell, those of us who run production
servers are the ones who are most disturbed by the ways that systemd
wends its way into all aspects of a system.

Miles Fidelman


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

Reply | Threaded
Open this post in threaded view
|

Re: If Linux Is About Choice, Why Then ...

Lisi Reisz
On Sunday 09 April 2017 22:39:50 Miles Fidelman wrote:
> On 4/9/17 4:15 PM, Patrick Bartek wrote:
> > After much reading, I consider systemd more suited to large, busy
> > servers than a desktop box or notebook with just one user.  It's
> > like being forced to use a huge tractor-trailer rig with lots of chrome
> > and lights and 24 gears when a simple mini-van will do. ;-)
>
> Funny thing.  As far as I can tell, those of us who run production
> servers are the ones who are most disturbed by the ways that systemd
> wends its way into all aspects of a system.

Yes, ISTR being told during the flame wars that systemd was great for desktops
because it speeded up the boot process, but, just possibly, not so good for
servers.

My own experience is sadly the exact opposite.  I find it very slow, including
some very awkward hangs.

Still, I shall just have to add the vagaries of systemd to the many things I
need to learn urgently!

Lisi

12345