If Not Systemd, then What?

[Patrick Bartek]

After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.

Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.

So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

Just wondering.


B

[Scott Ferguson]

Good question Patrick - top posted as I'm referring to the Subject.

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between a
desktop and a server - just degrees.

Post by Patrick Bartek
Just wondering.
B

I suspect, despite my interest in the subject, this would be better on
the off-topic list.
If that sounds hypocritical, perhaps it is - but I see it as acceptance
that I've been wrong before.


Kind regards

[Miles Fidelman]

Post by Scott Ferguson
Good question Patrick - top posted as I'm referring to the Subject.

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between a
desktop and a server - just degrees.

Um, yes, there is. Typically different hardware (headless for
starters), storage area networks, clusters, high availability, as well
as different role, and so forth.

Miles

[Andrei POPESCU]

Um, yes, there is. Typically different hardware (headless for starters),
storage area networks, clusters, high availability, as well as different
role, and so forth.

I have a Raspberry Pi serving my domain (DNS + WWW). As far as I'm
concerned that's *my* server.

Kind regards,
Andrei

[Scott Ferguson]

Post by Miles Fidelman

Post by Scott Ferguson
Good question Patrick - top posted as I'm referring to the Subject.

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between a
desktop and a server - just degrees.

Um, yes, there is. Typically different hardware (headless for
starters), storage area networks, clusters, high availability, as well
as different role, and so forth.
Miles

With respect, you're just repeating your claim that there is a clear
distinction between server and desktop - not proving it, which doesn't
advance the discussion.

Samba is a server, as is NFS, and apache. If you run them on a desktop
is it still *just* a desktop?

Can you not run a desktop on server hardware?

Can you not run a server on desktop hardware?

I don't "believe" you've thought this through... :)

I'll leave pulseaudio out, just to make things simpler (and acknowledge
that "simple" is a synonym for "dumb").


Kind regards

P.S. I have been told that one major distro does (or is attempting to
do) just that - separate into a 'server' and a 'desktop' distribution.

[Joe]

On Wed, 22 Oct 2014 13:04:26 +1100

Post by Scott Ferguson
P.S. I have been told that one major distro does (or is attempting to
do) just that - separate into a 'server' and a 'desktop' distribution.

What, like Windows? I think that really is the point that is being
made, that Windows has always made the distinction, with the server OS
being very expensive and requiring access licences for machines or
people making use of it. Microsoft server software, such as DNS and
the full web server is only available on the server OS, with a few
cut-down versions on workstations.

With Linux, it is (so far) only usage which determines the category,
e.g. with few exceptions, servers are continuously powered, don't
have monitors, many don't have X, etc. There is no software which is
*only* installable on a server, though there is some which isn't
really practical on an intermittently-powered machine.

[Scott Ferguson]

Post by Joe
On Wed, 22 Oct 2014 13:04:26 +1100

Post by Scott Ferguson
P.S. I have been told that one major distro does (or is attempting to
do) just that - separate into a 'server' and a 'desktop' distribution.

What, like Windows?

No.
A Linux distro. SUSE.

Post by Joe
I think that really is the point that is being
made, that Windows has always made the distinction, with the server OS
being very expensive and requiring access licences for machines or
people making use of it. Microsoft server software, such as DNS and
the full web server is only available on the server OS, with a few
cut-down versions on workstations.
With Linux, it is (so far) only usage which determines the category,
e.g. with few exceptions, servers are continuously powered, don't
have monitors, many don't have X, etc. There is no software which is
*only* installable on a server, though there is some which isn't
really practical on an intermittently-powered machine.

Kind regards.

[Miles Fidelman]

Post by Scott Ferguson

Post by Miles Fidelman

Post by Scott Ferguson
Good question Patrick - top posted as I'm referring to the Subject.

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between a
desktop and a server - just degrees.

Um, yes, there is. Typically different hardware (headless for
starters), storage area networks, clusters, high availability, as well
as different role, and so forth.
Miles

With respect, you're just repeating your claim that there is a clear
distinction between server and desktop - not proving it, which doesn't
advance the discussion.

Ok, let's start with:
- it's the rare desktop that has a fiber channel interface
- it's the rare desktop that has an interface for dual-ported disk drives
- it's the rare desktop configuration that splits processing and storage
(e.g., blade servers + storage servers)
- in servers, large RAID arrays are common, desktops might have a pair
of mirrored disks, never seen anybody set up a desktop for RAID5,6,10
- these days, servers are generally run in clusters, with cluster file
systems, and environments like openstack on top of them
- when it comes to performance, desktops generally emphasize graphics
performance (e.g., for gaming, video editing, and such); servers are
designed more for how many virtual machines they can run
- high-availability clustering is a big data center concern, not a
desktop concern (anybody run DRBD, or Corosync on a dekstop?)
- when it comes to virtualization, on desktops its mostly for running
programs in other environments; for servers its mostly about supporting
lots of independent users and services
- when's the last time you saw a desktop or laptop with an IPMI BMC (or
for that matter, had a BMC infected by a virus - not pretty) (note: if
you don't know what BMC stands for, then go away and learn something
about serious data centers, before weighing in on the distinctions
between desktops and servers)
- scalability, optimization for transaction processing, high-volume mail
processing, etc., etc., etc. - not issues that one worries about on the
desktop

Post by Scott Ferguson
Samba is a server, as is NFS, and apache. If you run them on a desktop
is it still *just* a desktop?
Can you not run a desktop on server hardware?

Generally not - except remotely - given that most servers are headless
and don't have graphics boards. Yeah, one can X- into a server, if you
install the software. Many (most?) don't - CLI and various management
tools is plenty good for server admin (along with lots of bash scripts -
one of the reasons that a lot of sysadmins don't like systemd).

Post by Scott Ferguson
Can you not run a server on desktop hardware?

Not if you're supporting a serious load - unless you're clustering lots
of machines (but once you cluster a few hundred motherboards, you're
talking a desktop machine, you're talking a cluster).

Post by Scott Ferguson
I'll leave pulseaudio out, just to make things simpler (and acknowledge
that "simple" is a synonym for "dumb").

I don't believe you have any knowledge whatsoever about data centers or
real servers - and are talking through your hat. That you even mention
audio in the same conversation as
servers says you're in a different universe.

Post by Scott Ferguson
Kind regards
P.S. I have been told that one major distro does (or is attempting to
do) just that - separate into a 'server' and a 'desktop' distribution.

Let's see:
- IBM doesn't do desktops
- Windows has very separate desktop and server-side editions
- MacOS comes in separate flavors
- BSDs are primarily server oriented
- Until recently, most Linux distros were server oriented - particularly
Debian, I might add -- Linux on the desktop is a new phenomenon
- Solaris is mostly a server side o/s (workstations are small servers,
not large desktops)
- In the Linux world Ubuntu comes in desktop, server, and cloud varieties
- RHEL is almost entirely server oriented (can you say "Enterprise",
Gluster, JBoss, ....?)
- SUSE has desktop, server, and cloud varieties

Again - if you didn't know that, then you're talking out of ignorance.

Miles Fidelman

[Reco]

Hi.

Post by Miles Fidelman
- when's the last time you saw a desktop or laptop with an IPMI BMC
(or for that matter, had a BMC infected by a virus - not pretty)
(note: if you don't know what BMC stands for, then go away and learn
something about serious data centers, before weighing in on the
distinctions between desktops and servers)

A minor nitpick - there's Intel AMT which specifically targets desktops
to provide capabilities similar to BMC.

Reco

[Scott Ferguson]

Post by Reco
Hi.

Post by Miles Fidelman
- when's the last time you saw a desktop or laptop with an IPMI BMC
(or for that matter, had a BMC infected by a virus - not pretty)
(note: if you don't know what BMC stands for, then go away and learn
something about serious data centers, before weighing in on the
distinctions between desktops and servers)

A minor nitpick - there's Intel AMT which specifically targets desktops
to provide capabilities similar to BMC.
Reco

And (the old) HP Kayak range also, both "Desktops" and "Servers".

I'm now struggling to see how this directly relates to Debian.

Kind regards

[Rusi Mody]

Post by Miles Fidelman

Post by Scott Ferguson

Post by Miles Fidelman

Post by Scott Ferguson
Good question Patrick - top posted as I'm referring to the Subject.

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between a
desktop and a server - just degrees.

Um, yes, there is. Typically different hardware (headless for
starters), storage area networks, clusters, high availability, as well
as different role, and so forth.
Miles

With respect, you're just repeating your claim that there is a clear
distinction between server and desktop - not proving it, which doesn't
advance the discussion.

- it's the rare desktop that has a fiber channel interface
- it's the rare desktop that has an interface for dual-ported disk drives
- it's the rare desktop configuration that splits processing and storage
(e.g., blade servers + storage servers)
- in servers, large RAID arrays are common, desktops might have a pair
of mirrored disks, never seen anybody set up a desktop for RAID5,6,10
- these days, servers are generally run in clusters, with cluster file
systems, and environments like openstack on top of them
- when it comes to performance, desktops generally emphasize graphics
performance (e.g., for gaming, video editing, and such); servers are
designed more for how many virtual machines they can run
- high-availability clustering is a big data center concern, not a
desktop concern (anybody run DRBD, or Corosync on a dekstop?)
- when it comes to virtualization, on desktops its mostly for running
programs in other environments; for servers its mostly about supporting
lots of independent users and services
- when's the last time you saw a desktop or laptop with an IPMI BMC (or
for that matter, had a BMC infected by a virus - not pretty) (note: if
you don't know what BMC stands for, then go away and learn something
about serious data centers, before weighing in on the distinctions
between desktops and servers)
- scalability, optimization for transaction processing, high-volume mail
processing, etc., etc., etc. - not issues that one worries about on the
desktop

Post by Scott Ferguson
Samba is a server, as is NFS, and apache. If you run them on a desktop
is it still *just* a desktop?
Can you not run a desktop on server hardware?

Generally not - except remotely - given that most servers are headless
and don't have graphics boards. Yeah, one can X- into a server, if you
install the software. Many (most?) don't - CLI and various management
tools is plenty good for server admin (along with lots of bash scripts -
one of the reasons that a lot of sysadmins don't like systemd).

Post by Scott Ferguson
Can you not run a server on desktop hardware?

Not if you're supporting a serious load - unless you're clustering lots
of machines (but once you cluster a few hundred motherboards, you're
talking a desktop machine, you're talking a cluster).

Post by Scott Ferguson
I'll leave pulseaudio out, just to make things simpler (and acknowledge
that "simple" is a synonym for "dumb").

I don't believe you have any knowledge whatsoever about data centers or
real servers - and are talking through your hat. That you even mention
audio in the same conversation as
servers says you're in a different universe.

Are you guys just having fun talking past each other?
Or seriously dont know the two meanings of 'server'?

First two here: http://whatis.techtarget.com/definition/server

[Scott Ferguson]

<snipped>

Post by Rusi Mody
Are you guys just having fun talking past each other?

I can only speak for myself - no. I doubt Miles is having fun either.
And as it's apparent not a discussion I don't intend to pursue it.

I'm sure Miles does have some good points - and is a knowledgeable guy,
but he doesn't appear to be deploying a logic schema upon which to base
a technical discussion instead of continual goal shifting in an attempt
to substantiate an opinion based mostly on emotion (fear).

I 'can' understand: why he feels so emotional about it ; how that
emotion can affect thinking/writing.

Post by Rusi Mody
Or seriously dont know the two meanings of 'server'?

No. I was aware of both.

Three actually - to 'some' people, who have an annoying habit of
differentiating between "server" and "desktop" on the basis of case
style or location.

Post by Rusi Mody
First two here: http://whatis.techtarget.com/definition/server

Kind regards

[Scott Ferguson]

Post by Miles Fidelman

Post by Scott Ferguson

Post by Miles Fidelman

Post by Scott Ferguson
Good question Patrick - top posted as I'm referring to the Subject.

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between a
desktop and a server - just degrees.

Um, yes, there is. Typically different hardware (headless for
starters), storage area networks, clusters, high availability, as well
as different role, and so forth.
Miles

With respect, you're just repeating your claim that there is a clear
distinction between server and desktop - not proving it, which doesn't
advance the discussion.

- it's the rare desktop that has a fiber channel interface
- it's the rare desktop that has an interface for dual-ported disk drives
- it's the rare desktop configuration that splits processing and storage
(e.g., blade servers + storage servers)
- in servers, large RAID arrays are common, desktops might have a pair
of mirrored disks, never seen anybody set up a desktop for RAID5,6,10
- these days, servers are generally run in clusters, with cluster file
systems, and environments like openstack on top of them
- when it comes to performance, desktops generally emphasize graphics
performance (e.g., for gaming, video editing, and such); servers are
designed more for how many virtual machines they can run
- high-availability clustering is a big data center concern, not a
desktop concern (anybody run DRBD, or Corosync on a dekstop?)
- when it comes to virtualization, on desktops its mostly for running
programs in other environments; for servers its mostly about supporting
lots of independent users and services
- when's the last time you saw a desktop or laptop with an IPMI BMC (or
for that matter, had a BMC infected by a virus - not pretty) (note: if
you don't know what BMC stands for, then go away and learn something
about serious data centers, before weighing in on the distinctions
between desktops and servers)
- scalability, optimization for transaction processing, high-volume mail
processing, etc., etc., etc. - not issues that one worries about on the
desktop

I don't disagree with any of the above.

Respectfully, I repeat:-
; there is no *clear* distinction between server and desktop.
; you have not advanced the discussion (expand and/or tangent != advance)

Post by Miles Fidelman

Post by Scott Ferguson
Samba is a server, as is NFS, and apache. If you run them on a desktop
is it still *just* a desktop?
Can you not run a desktop on server hardware?

Generally not - except remotely - given that most servers are headless
and don't have graphics boards.

Please, you're a smart guy and have no need to stoop to advancing
selective cases as evidence of *clear* distinctions.

Post by Miles Fidelman
Yeah, one can X- into a server, if you
install the software. Many (most?) don't - CLI and various management
tools is plenty good for server admin

Agreed.

<snipped>

Post by Miles Fidelman
one of the reasons that a lot of sysadmins don't like systemd).

Opinions vary - not that "a lot" is *not* case, but that "a lot"
constitutes a "significant" percentage - or a "majority".

Of the sysadmin I've spoken to - the majority (a slight majority) hold
an opinion similar to mine:- we don't have one[*1], we are *very* wary
of "popular opinion" (lowest common denominator?), we are primarily
technicians and engineers not writers and have a strong preference for
demonstrated facts ("in the course of extensive testing").

[*1] as a result of "considering" two opposing opinions

Post by Miles Fidelman

Post by Scott Ferguson
Can you not run a server on desktop hardware?

Not if you're supporting a serious load - unless you're clustering lots
of machines (but once you cluster a few hundred motherboards, you're
talking a desktop machine, you're talking a cluster).

Again, selective instances. *Not* "clear cut distinctions".

Post by Miles Fidelman

Post by Scott Ferguson
I'll leave pulseaudio out, just to make things simpler (and acknowledge
that "simple" is a synonym for "dumb").

I don't believe you have any knowledge whatsoever about data centers or
real servers - and are talking through your hat.

That's the problem with "beliefs" - they can be the core of
"confirmation bias" - as to the insults, I'd normally associate that
with a lack of argument. Neither of which I expect of you.

Post by Miles Fidelman
That you even mention
audio in the same conversation as
servers says you're in a different universe.

Pulseaudio is a *server*.
I excluded it from the conversation. Your "argument" (in that paragraph)
is misguided.

Post by Miles Fidelman

Post by Scott Ferguson
Kind regards
P.S. I have been told that one major distro does (or is attempting to
do) just that - separate into a 'server' and a 'desktop' distribution.

- IBM doesn't do desktops
- Windows has very separate desktop and server-side editions
- MacOS comes in separate flavors
- BSDs are primarily server oriented
- Until recently, most Linux distros were server oriented - particularly
Debian, I might add -- Linux on the desktop is a new phenomenon
- Solaris is mostly a server side o/s (workstations are small servers,
not large desktops)
- In the Linux world Ubuntu comes in desktop, server, and cloud varieties
- RHEL is almost entirely server oriented (can you say "Enterprise",
Gluster, JBoss, ....?)
- SUSE has desktop, server, and cloud varieties

Your point is lost - perhaps in your desperation to find fault with what
I've said in an uncharacteric personal issue. Clearly I've misjudged you
as someone who could be expected to provide an emotion free technical
discussion.

Post by Miles Fidelman
Again - if you didn't know that, then you're talking out of ignorance.

If you can't understand the single sentence you are so angrily, and
wrongly responding to, you are too emotionally invested in a point of
view. Take a breath and re-read it. It's not an attack on you, your
views - or an argument.

Post by Miles Fidelman
Miles Fidelman
https://wiki.debian.org/DebianMailingLists#Gmail

[Jonathan Dowland]

Post by Miles Fidelman
- it's the rare desktop that has a fiber channel interface

snip

It's a rare server, too.

Nearly all of our physical servers are VM hosts, onto which we fit around 100
VMs. Physical servers are at best <5% of all our "servers", and the traits of
physical servers are therefore relatively scarce.

[Patrick Bartek]

Post by Scott Ferguson

[snip]
So, what would you all propose? For a server? Or for a user
desktop? Or something that fulfills both scenarios? And why?

One of the difficulties is that there is no clear distinction between
a desktop and a server - just degrees.

In general, that may be true, but servers can be highly customized for
their tasks and that may have a bearing on inits and startup
routines. User Desktops, I think, must be by their very use more
generic in startup to cover a multitude of different user
requirements. So, it is possible and, perhaps, even desirable to have
different inits. That's why I posed the question that way.

Post by Scott Ferguson

Just wondering.
B

I suspect, despite my interest in the subject, this would be better on
the off-topic list.
If that sounds hypocritical, perhaps it is - but I see it as
acceptance that I've been wrong before.

I don't think it's off-topic. After all, systemd is now, by default,
the official Debian init system. And there are alternative inits in
the repos that work with Debian. And this is the Debian-User list.
So, my query is relevant. But some here are more particular of what
constitutes on or off topic. I'm not one. I consider this list a
general Debian discussion list and not a technical forum as such.

Now, if I were to ask for everyone's favorite gumbo recipe... Now,
that would be off-topic even though those recipes came from Debian
users. ;-)

Thanks for your input.

B

[Steve Litt]

On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative?

* Nosh
* Runit
* Upstart
* S6
* Probably more I don't know about.

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit were
saying "let's wait until we have something good." We also pointed out
the false choice of prematurely narrowing it to systemd, Upstart or
sysvinit.

Now of course, the systemd cabal will argue that we can't wait any
longer. My question to them is, why was sysvinit not a dire emergency
until Red Hat's systemd juggernaut came along, and then all of a
sudden we just couldn't wait?

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

[Ludovic Meyer]

Post by Steve Litt
On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative?

* Nosh

So this one is fun, it is just a direct copy of the systemd service format.
Guess the proof that's at least a feature that people do want, dropping shell.

And of course, not only the format is copied, it took the set of systemd
services and copied them like this. I am sure ftp-masters wouldn't accept
a GPL violation ( as the .service file are likely not un the BSD ).

Post by Steve Litt
* Runit

was non free for a long time, not sure if developped
anymore, especially since last post on one of the ml date back to
June 2013.

Post by Steve Litt
* Upstart

no longer developped, and suffer from several bugs, go read the tech-ctte
debate.

Post by Steve Litt
* S6

likely the same as runit when it come to be alive.

Post by Steve Litt
* Probably more I don't know about.

You could add openrc, the only serious contender.

Post by Steve Litt

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit were
saying "let's wait until we have something good." We also pointed out
the false choice of prematurely narrowing it to systemd, Upstart or
sysvinit.

You mean "let's do like we did since 20 years, wait, in case if something will happen".
None of the alternatives you propose have been widely adopted by anyone except upstart.
And that's mostly because no one cared about them up to the point to even propose them.

Post by Steve Litt
Now of course, the systemd cabal will argue that we can't wait any
longer. My question to them is, why was sysvinit not a dire emergency
until Red Hat's systemd juggernaut came along, and then all of a
sudden we just couldn't wait?

You mean that after waiting several years, the solution is to wait again, because
no one cared before, and when 1 group came and changed, the solution is to refuse
and go back doing nothing ?

--
l.

[Steve Litt]

On Tue, 21 Oct 2014 08:12:17 +0200

Post by Ludovic Meyer

Post by Steve Litt
On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative?

* Nosh

So this one is fun, it is just a direct copy of the systemd service
format. Guess the proof that's at least a feature that people do
want, dropping shell.

I think you meant a direct copy of daemontools, didn't you?

http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html

It's not a direct copy, it's an enhanced superset of daemontools, kind
of. Daemontools preceded systemd by several years, and I sincerely doubt
daemontools and systemd have anything in common.

Post by Ludovic Meyer
And of course, not only the format is copied, it took the set of
systemd services and copied them like this. I am sure ftp-masters
wouldn't accept a GPL violation ( as the .service file are likely not
un the BSD ).

Daemontools wasn't GPL'ed, it was Public Domained, so anyone can do
absolutely anything with it.

Post by Ludovic Meyer

Post by Steve Litt
* Runit

was non free for a long time, not sure if developped
anymore, especially since last post on one of the ml date back to
June 2013.

Funtoo is using it, and I seriously doubt they'd be using something not
developed anymore.

Post by Ludovic Meyer

Post by Steve Litt
* Upstart

no longer developped, and suffer from several bugs, go read the
tech-ctte debate.

I read it, and if Upstart problems were the most distressing thing in
that debate, I'd be a happy man. If Upstart is no longer under
development, the reason would be that the Debian CTTE decided on
systemd, so Cannonical reluctantly followed suit.

Post by Ludovic Meyer

Post by Steve Litt
* S6

likely the same as runit when it come to be alive.

Post by Steve Litt
* Probably more I don't know about.

You could add openrc, the only serious contender.

Thanks. I hereby add openrc, assuming it's ready now.

Post by Ludovic Meyer

Post by Steve Litt

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's
been patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit
were saying "let's wait until we have something good." We also
pointed out the false choice of prematurely narrowing it to
systemd, Upstart or sysvinit.

You mean "let's do like we did since 20 years, wait, in case if
something will happen". None of the alternatives you propose have
been widely adopted by anyone except upstart. And that's mostly
because no one cared about them up to the point to even propose them.

The reason nobody paid attention to them yet is the alternative wasn't
systemd until now. systemd is a mighty motivator, I'll say that for it.

Post by Ludovic Meyer

Post by Steve Litt
Now of course, the systemd cabal will argue that we can't wait any
longer. My question to them is, why was sysvinit not a dire
emergency until Red Hat's systemd juggernaut came along, and then
all of a sudden we just couldn't wait?

You mean that after waiting several years, the solution is to wait
again, because no one cared before,

That is *exactly* what I mean. Don't move to a worse position, and if
this had really been life or death, systemd would have been gone a few
years ago.

Post by Ludovic Meyer
and when 1 group came and
changed, the solution is to refuse and go back doing nothing ?

Now that, I didn't say. Go back and read the quoted text.

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

[Miles Fidelman]

Post by Steve Litt
On Tue, 21 Oct 2014 08:12:17 +0200

<snip>

Post by Steve Litt

Post by Ludovic Meyer

Post by Steve Litt
* Upstart

no longer developped, and suffer from several bugs, go read the
tech-ctte debate.

I read it, and if Upstart problems were the most distressing thing in
that debate, I'd be a happy man. If Upstart is no longer under
development, the reason would be that the Debian CTTE decided on
systemd, so Cannonical reluctantly followed suit.

And this is where the Tech. Committee decision really hurt the Linux
community as a whole.

Essentially, this came down to giving in to blackmail (if you want GNOME
you have to take systemd) - and yes, I read all the email about the
decision, but that's really what it comes down to (IMHO). And in doing
so, basically led to a general decline in the overall Linux ecosystem.


Miles Fidelman

[Ludovic Meyer]

Post by Steve Litt
On Tue, 21 Oct 2014 08:12:17 +0200

Post by Ludovic Meyer

Post by Steve Litt
On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative?

* Nosh

So this one is fun, it is just a direct copy of the systemd service
format. Guess the proof that's at least a feature that people do
want, dropping shell.

I think you meant a direct copy of daemontools, didn't you?

No. I mean't the format of the service is exactly the one of systemd, download the
tarball, and look at the code, like smbd.service :

$ cat smbd.service
## **************************************************************************
## For copyright and licensing terms, see the file named COPYING.
## **************************************************************************

[Unit]
Description=SAMBA file and print services daemon

[Service]
systemdWorkingDirectory=false
ExecStart=smbd -F -s /usr/local/etc/smb.conf
Restart=always

[Install]
WantedBy=server.target

Post by Steve Litt
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
It's not a direct copy, it's an enhanced superset of daemontools, kind
of. Daemontools preceded systemd by several years, and I sincerely doubt
daemontools and systemd have anything in common.

Indeed, one is used and alive, and the other is written by djb.

Post by Steve Litt

Post by Ludovic Meyer
And of course, not only the format is copied, it took the set of
systemd services and copied them like this. I am sure ftp-masters
wouldn't accept a GPL violation ( as the .service file are likely not
un the BSD ).

Daemontools wasn't GPL'ed, it was Public Domained, so anyone can do
absolutely anything with it.

nosh take the same file for ssh with a service, a socket file and a separate
service for the keys generation than systemd, and this is not a copy ?

Look at the code, it use the same exact naming : Unit, Install etc section, and everything.
If that's not a copy, that's a rather strong inspiration, showing again that
people recognize that systemd is doing the right thing when it come to dropping shell.
And since you recommend nosh, I guess you agree on this point.

Nosh also take over the job of showing a tty ( login-banner.cpp ), of setting the
network hostname ( set-dynamic-hostname.cpp ), of mouting ( nmount.cpp ), and maybe more.
See for example common-manager.cpp where it take over lots of configuration.

So yeah, nosh is basically following systemd steps, which is also likely showing that
systemd is doing the right thing.

And while the code is not that ugly, there is still some very specific ugly stuff like
mixing goto and exception for checking of errors, or there is magic constants
everywhere in some place of the code like service-is-up.cpp , common-manager.cpp

Post by Steve Litt

Post by Ludovic Meyer

Post by Steve Litt
* Runit

was non free for a long time, not sure if developped
anymore, especially since last post on one of the ml date back to
June 2013.

Funtoo is using it, and I seriously doubt they'd be using something not
developed anymore.

You would be surprised to see the number of people who are using cron and at.
At least, cron have been forked by RH to become cronie, but at didn't involve since
years.

Post by Steve Litt

Post by Ludovic Meyer

Post by Steve Litt
* Upstart

no longer developped, and suffer from several bugs, go read the
tech-ctte debate.

I read it, and if Upstart problems were the most distressing thing in
that debate, I'd be a happy man. If Upstart is no longer under
development, the reason would be that the Debian CTTE decided on
systemd, so Cannonical reluctantly followed suit.

No, in fact, it was already not much developped during the previous
years :

https://www.openhub.net/p/upstart/commits/summary

Compare with more active projects :

https://www.openhub.net/p/systemd/commits/summary
https://www.openhub.net/p/python/commits/summary
https://www.openhub.net/p/perl/commits/summary

In fact, I would postulate that's systemd that made upstart being developped again
after the developper went to Google and the reason why Canonical switched so fast was because they were
not totally unhappy to drop it, and I guess their biggest concern was doing the integration
work, and guess what, as soon as they found Debian would do it for "free",
they decided to switch.

And they even do collaborate with systemd people quite well:

https://wiki.debian.org/Sprints/2014/SystemdGNOMESprint
( 3 people from Canonical there, even if 1 had to cancel )

or
https://plus.google.com/107564545827215425270/posts/d5Gufn8Q2qE

Post by Steve Litt

Post by Ludovic Meyer

Post by Steve Litt

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's
been patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit
were saying "let's wait until we have something good." We also
pointed out the false choice of prematurely narrowing it to
systemd, Upstart or sysvinit.

You mean "let's do like we did since 20 years, wait, in case if
something will happen". None of the alternatives you propose have
been widely adopted by anyone except upstart. And that's mostly
because no one cared about them up to the point to even propose them.

The reason nobody paid attention to them yet is the alternative wasn't
systemd until now. systemd is a mighty motivator, I'll say that for it.

Gentoo created openrc, Canonical created ubuntu, Apple created launchd,
Solaris created SMF. Communities that struggled for ressources ( like the BSD and
Debian ) due to their volunteer based nature didn't.

So yeah, people did take a look before starting from scratch. And several
profesionnal developpers all happened to have the same conclusion, none of the
existing tool did fit the requirement of their os. The mere fact that
both s6 and nosh not reuse daemontools or didn't chose to improve it
say a lot on the state of the code.

Post by Steve Litt

Post by Ludovic Meyer

Post by Steve Litt
Now of course, the systemd cabal will argue that we can't wait any
longer. My question to them is, why was sysvinit not a dire
emergency until Red Hat's systemd juggernaut came along, and then
all of a sudden we just couldn't wait?

You mean that after waiting several years, the solution is to wait
again, because no one cared before,

That is *exactly* what I mean. Don't move to a worse position, and if
this had really been life or death, systemd would have been gone a few
years ago.

Hyperbolic statement do not really seems to help you discourse.
Nothing is life or death, that's just software.

[Rusi Mody]

Post by Ludovic Meyer

Post by Steve Litt
On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative?

* Nosh

So this one is fun, it is just a direct copy of the systemd service format.
Guess the proof that's at least a feature that people do want, dropping shell.
And of course, not only the format is copied, it took the set of systemd
services and copied them like this. I am sure ftp-masters wouldn't accept
a GPL violation ( as the .service file are likely not un the BSD ).

Post by Steve Litt
* Runit

was non free for a long time, not sure if developped
anymore, especially since last post on one of the ml date back to
June 2013.

Post by Steve Litt
* Upstart

no longer developped, and suffer from several bugs, go read the tech-ctte
debate.

Post by Steve Litt
* S6

likely the same as runit when it come to be alive.

Post by Steve Litt
* Probably more I don't know about.

You could add openrc, the only serious contender.

Post by Steve Litt

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit were
saying "let's wait until we have something good." We also pointed out
the false choice of prematurely narrowing it to systemd, Upstart or
sysvinit.

You mean "let's do like we did since 20 years, wait, in case if something will happen".
None of the alternatives you propose have been widely adopted by anyone except upstart.
And that's mostly because no one cared about them up to the point to even propose them.

Post by Steve Litt
Now of course, the systemd cabal will argue that we can't wait any
longer. My question to them is, why was sysvinit not a dire emergency
until Red Hat's systemd juggernaut came along, and then all of a
sudden we just couldn't wait?

You mean that after waiting several years, the solution is to wait again, because
no one cared before, and when 1 group came and changed, the solution is to refuse
and go back doing nothing ?

Fallacy of False Dilemma: http://en.wikipedia.org/wiki/False_dilemma

There are other choices to
- do nothing as weve done for 20 years
- do it now

In particular, one can take a holistic view: not just Stable -> Jessie,
but rather Stable -> Jessie -> Jessie+1

and work out the least disruptive, most generally acceptable solution
in that +1ed widened frame

[Ludovic Meyer]

Post by Rusi Mody
There are other choices to
- do nothing as weve done for 20 years
- do it now
In particular, one can take a holistic view: not just Stable -> Jessie,
but rather Stable -> Jessie -> Jessie+1
and work out the least disruptive, most generally acceptable solution
in that +1ed widened frame

The fact is that this is already what happened. Systemd is a option in the current
stable, and I just tested, it run fine.
So the plan was more "Stable -> Wheezy -> Jessie". What you are asking is not what you say, this is to
push again now the moment to switch have happened.

And this happened because upstream has a need for feature proposed by systemd, and they waited
long enough ( as the plan was first proposed 2 years, in october 2012 ago
and likely being discussed before during Guadec and others events ).

KDE people, wayland developpers among others also decided to reuse systemd
features, so if you think that Debian should wait 2 or 3 years more than the 2 or
3 years that was already done, sure. But the more time you wait, the less Debian
will be a attractive target to upstream, the more work will have to be done to integrate, and
the less innovation will happen. Ubuntu pushing for new stuff is why we see
ubuntu and not Debian as the goto OS for docker and amazon.

For example, spotify decided to switch to Ubuntu rather than keeping Debian, and
if you look around, they are not the only ones.

Procrastination and protests are not really a solution. If people want to keep
sysvinit, they should help adopt systemd-shim and do bug reports, not wait on
others to do the work when there is obviously not much people who care about that ( since besides
ubuntu, almost no big community do use systemd-shim, so hope of getting wide coverage and
tests are rather slim ).

[Miles Fidelman]

Post by Ludovic Meyer
For example, spotify decided to switch to Ubuntu rather than keeping Debian, and
if you look around, they are not the only ones.

And you're attributing that to Debian dragging its feet on systemd?

As I recall, the explicit reason Ubuntu finally decided to adopt systemd
was the Debian decision to adopt systemd.

Let's not re-write history here.

Miles Fidelman

[Andrei POPESCU]

Post by Miles Fidelman

Post by Ludovic Meyer
For example, spotify decided to switch to Ubuntu rather than keeping Debian, and
if you look around, they are not the only ones.

And you're attributing that to Debian dragging its feet on systemd?
As I recall, the explicit reason Ubuntu finally decided to adopt systemd was
the Debian decision to adopt systemd.

You seem to forget Ubuntu was already using upstart since 6.10 Edgy Eft,
released in 2006. That's 8 (eight) years.

Upstart was the only real contender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being replaced
by systemd everywhere.

http://en.wikipedia.org/wiki/Upstart#Adoption

Kind regards,
Andrei

[Tanstaafl]

Post by Andrei POPESCU
Upstart was the only real contender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being replaced
by systemd everywhere.

And why was OPenRC not a contender?

[Andrei POPESCU]

Post by Tanstaafl

Post by Andrei POPESCU
Upstart was the only real contender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being replaced
by systemd everywhere.

And why was OPenRC not a contender?

It's all in the debate, but from the top of my head: not ready, lack of
documentation, not much gain compared to the migration costs, could have
been more.

Kind regards,
Andrei

[Jonathan de Boyne Pollard]

Upstart was the only real contender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being
replaced by systemd everywhere.
And why was OPenRC not a contender?

Your question takes a falsehood as its premise. It actually was,
contrary to what M. Popescu dismissively stated. Several members of the
technical committee took it and tried to use it themselves, just as they
did the other systems; and it was included on the formal ballots and in
the votes. Contrastingly, the people who were propounding OpenRC at the
time provided a good example of how NOT to go about doing so. Their
several mistakes are worth learning from.

[Tanstaafl]

On 10/24/2014 4:49 AM, Jonathan de Boyne Pollard

Post by Jonathan de Boyne Pollard

And why was OPenRC not a contender?

Your question takes a falsehood as its premise. It actually was,
contrary to what M. Popescu dismissively stated. Several members of the
technical committee took it and tried to use it themselves, just as they
did the other systems; and it was included on the formal ballots and in
the votes.

I actually do remember reading a fleeting mention of it somewhere in
the vast sea of stuff I read when trying to catch up on this issue...

Post by Jonathan de Boyne Pollard
Contrastingly, the people who were propounding OpenRC at the
time provided a good example of how NOT to go about doing so. Their
several mistakes are worth learning from.

Not sure I understand what you are saying here...

Are you saying that some of the people who suggested OpenRC actually
provided BAD examples - meaning, examples that were destined to result
in problems - of how to use it in Debian? If so, maybe that was on
purpose, to decrease the chances of OpenRC being a real contender?

The fact is, OpenRC has been the default init system on gentoo since I
don't know when, and I have *never* had an init problem on any of my
gentoo systems - although I admittedly never use unstable/testing for
system-critical packages either...

[Jonathan de Boyne Pollard]

Contrastingly, the people who were propounding OpenRC at the time
provided a good example of how NOT to go about doing so. Their
several mistakes are worth learning from.
Not sure I understand what you are saying here...
Are you saying that some of the people who suggested OpenRC actually
provided BAD examples - meaning, examples that were destined to
result in problems - of how to use it in Debian?

No; it was more an entirely bungled presentation. For example: They
reacted badly and disproportionately to being told about simple
problems, like the fact that what they had presented didn't have any
doco at all. That's a mistake worth learning from.

[Andrei POPESCU]

Upstart was the only real contender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being
replaced by systemd everywhere.
And why was OPenRC not a contender?

Your question takes a falsehood as its premise. It actually was, contrary
to what M. Popescu dismissively stated.

Quote from above, with added emphasis:

Upstart was the only *real* contender to systemd *at the time* of
the evaluation for the Technical Committee, [...]

Several members of the technical
committee took it and tried to use it themselves, just as they did the other
systems; and it was included on the formal ballots and in the votes.

In my opinion that was more a formality, it was quite clear that OpenRC
would be beaten by both systemd and upstart. It did reach quorum though
(i.e. better than Further Discussion), which SysV did not.

https://lists.debian.org/debian-ctte/2014/02/msg00402.html

Contrastingly, the people who were propounding OpenRC at the time provided a
good example of how NOT to go about doing so. Their several mistakes are
worth learning from.

Fully agreed.

Kind regards,
Andrei

[Jonathan de Boyne Pollard]

Upstart was the only realcontender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being
replaced by systemd everywhere.
And why was OPenRC not acontender?
Your question takes a falsehood as its premise. It actually was,
contrary to what M. Popescu dismissively stated. Several members of
the technical committee took it and tried to use it themselves, just
as they did the other systems; and it was included on the formal
ballots and in the votes.

Post by Andrei POPESCU
Upstart was the only *real* contender to systemd *at the time* of
the evaluation for the Technical Committee, [...]

Yes, that's exactly where you were dismissive. It ill behove you, and
you were wrong.

[Lisi Reisz]

Post by Jonathan de Boyne Pollard

Upstart was the only realcontender to systemd at the time of the
evaluation by the Technical Committee, but it has or is being
replaced by systemd everywhere.
And why was OPenRC not acontender?
Your question takes a falsehood as its premise. It actually was,
contrary to what M. Popescu dismissively stated. Several members of
the technical committee took it and tried to use it themselves, just
as they did the other systems; and it was included on the formal
ballots and in the votes.

Post by Andrei POPESCU
Upstart was the only *real* contender to systemd *at the time* of
the evaluation for the Technical Committee, [...]

Yes, that's exactly where you were dismissive. It ill behove you, and
you were wrong.

No, the final vote was between upstart and systemd.

Lisi

[Tanstaafl]

Post by Lisi Reisz

Post by Jonathan de Boyne Pollard

Post by Andrei POPESCU
Upstart was the only *real* contender to systemd *at the time* of
the evaluation for the Technical Committee, [...]

Yes, that's exactly where you were dismissive. It ill behove you, and
you were wrong.

No, the final vote was between upstart and systemd.

Yes, apparently because someone actively sabotaged any possibility of
OpenRC being considered by giving improper bad information on how to use
it...

[Andrei POPESCU]

Post by Tanstaafl
Yes, apparently because someone actively sabotaged any possibility of
OpenRC being considered by giving improper bad information on how to use
it...

OpenRC was "represented" by its Maintainer in the init debate (Thomas
Goirand). Are you saying he intentionally sabotaged it to not be
considered?

Kind regards,
Andrei

[Tanstaafl]

Post by Andrei POPESCU

Post by Tanstaafl
Yes, apparently because someone actively sabotaged any possibility of
OpenRC being considered by giving improper bad information on how to use
it...

OpenRC was "represented" by its Maintainer in the init debate (Thomas
Goirand). Are you saying he intentionally sabotaged it to not be
considered?

I'm not, but that seemed to be what someone else said - although when I
asked for clarification, none was forthcoming:

On 10/24/2014 7:07 AM, Tanstaafl <***@libertytrek.org> wrote:> On
10/24/2014 4:49 AM, Jonathan de Boyne Pollard

Post by Andrei POPESCU

Post by Tanstaafl

And why was OpenRC not a contender?

Your question takes a falsehood as its premise. It actually was,
contrary to what M. Popescu dismissively stated. Several members of
the technical committee took it and tried to use it themselves,
just as they did the other systems; and it was included on the
formal ballots and in the votes.

I actually do remember reading a fleeting mention of it somewhere in
the vast sea of stuff I read when trying to catch up on this issue...

Post by Tanstaafl
Contrastingly, the people who were propounding OpenRC at the
time provided a good example of how NOT to go about doing so. Their
several mistakes are worth learning from.

Not sure I understand what you are saying here...
Are you saying that some of the people who suggested OpenRC actually
provided BAD examples - meaning, examples that were destined to result
in problems - of how to use it in Debian? If so, maybe that was on
purpose, to decrease the chances of OpenRC being a real contender?
The fact is, OpenRC has been the default init system on gentoo since I
don't know when, and I have *never* had an init problem on any of my
gentoo systems - although I admittedly never use unstable/testing for
system-critical packages either...

[Patrick Bartek]

Post by Steve Litt
On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative?

* Nosh
* Runit
* Upstart
* S6
* Probably more I don't know about.

OpenRC, God, and another one -- I can't recall the name -- come to
mind. Been studying them all. Runit as a partial or full "drop-in"
replacement for sysvinit seems promising.

Post by Steve Litt

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's
been patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit
were saying "let's wait until we have something good." We also
pointed out the false choice of prematurely narrowing it to systemd,
Upstart or sysvinit.

This I realize, but for some "something good" is never ever good enough
to replace the old, the familiar, the comfortable.

Post by Steve Litt
Now of course, the systemd cabal will argue that we can't wait any
longer. My question to them is, why was sysvinit not a dire emergency
until Red Hat's systemd juggernaut came along, and then all of a
sudden we just couldn't wait?

Doesn't GNOME3 now require systemd to work? GNOME has been the default
desktop environment for Debian, Fedora, and Red Hat (and others) for a
long time. I never much liked it or KDE. Resource hogs. Fedora
went with GNOME3 as the default at 13, I think. They are now at 20.
Went systemd with 15. I abandoned Fedora a couple years after 12 went
EOL, and switched to Debian Wheezy with just a window manager.

B

[Steve Litt]

On Tue, 21 Oct 2014 18:41:21 -0700

Post by Patrick Bartek

Post by Steve Litt
On Mon, 20 Oct 2014 12:45:11 -0700

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative?

* Nosh
* Runit
* Upstart
* S6
* Probably more I don't know about.

OpenRC, God, and another one -- I can't recall the name -- come to
mind. Been studying them all. Runit as a partial or full "drop-in"
replacement for sysvinit seems promising.

Post by Steve Litt

Post by Patrick Bartek
And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's
been patched and bolted onto and jury-rigged

Nobody's arguing for sysvinit as a long term solution, for the exact
reasons you post above. Those of us who appeared to favor sysvinit
were saying "let's wait until we have something good." We also
pointed out the false choice of prematurely narrowing it to systemd,
Upstart or sysvinit.

This I realize, but for some "something good" is never ever good
enough to replace the old, the familiar, the comfortable.

I spoze. But there's little good about systemd, and a whole lot of bad.
Like I listed near the beginning of this thread, there are plenty of
"something good"s that I'd gladly replace sysvinit with. But systemd is
a catastrophe if you want a computer controlled by you and not
Red Hat.

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

[Lee Winter]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

One key component of an effective startup process is dependency handling.
So why not look for one of the best as a model? I suggest DJB's redo
system. It is excruciatingly simple. But very effective. And it is the
opposite of monolithic.

But the real answer to this question will be found in the specs for the
better system. So someone needs to go through the specs for both sysv-init
and its competitors marking features to keep and features to kill. Then
the real discussion will begin.

Lee Winter
Nashua, New Hampshire
United States of America

[Jonathan de Boyne Pollard]

One key component of an effective startup process is dependency
handling. So why not look for one of the best as a model? I
suggest DJB's redo system. It is excruciatingly simple. But very
effective. And it is the opposite of monolithic.

Is "practically nonexistent" the opposite of monolithic, now? (-: He
never actually published it, you know (although a few of his other
unfinished works that did get published contain glimpses in their build
systems). The task of constructing and publishing working redo toolsets
was left to Alan Grosskurth, Avery Pennarun, and some other bloke.

redo is a useful tool that can have a use in system initialization.
Someone asked me an interesting question about /etc/rc.conf.local in
FreeNAS recently and I came up with an interesting answer that made use
of redo which I have to write up at some point. But it's another tool
in a good toolbox, not the whole of the toolbox. Nor is it necessarily
the starting point for everything that has the word "dependency"
somewhere in its description. I can think of three things in the
various implementations of redo that will interact quite poorly with the
notion of repeatably starting up daemons with controlled initial process
states and dropped privileges: maintaining database and job control
access, alternative routes, and what the process tree ends up looking
like. And that's skipping over the whole notion of shutdown. There are
ways to marry service dependencies with the
the-filesystem-is-the-database paradigm, but one doesn't really start
here to reach them.

Maybe Alan Grosskurth, Avery Pennarun, or that other bloke have written
some tools for system and daemon management.

*
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/introduction-to-redo.html
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html

[Lee Winter]

On Thu, Oct 23, 2014 at 6:45 PM, Jonathan de Boyne Pollard <

Post by Jonathan de Boyne Pollard

One key component of an effective startup process is dependency
handling. So why not look for one of the best as a model? I
suggest DJB's redo system. It is excruciatingly simple. But very
effective. And it is the opposite of monolithic.

Is "practically nonexistent" the opposite of monolithic, now? (-: He
never actually published it, you know (although a few of his other
unfinished works that did get published contain glimpses in their build
systems). The task of constructing and publishing working redo toolsets
was left to Alan Grosskurth, Avery Pennarun, and some other bloke.

There are more than three implementations of what little DJB did publish,
each with its own strengths and weaknesses. But building software and
booting (including careful shutdown) are two quite separate goals. I
suspect you interpreted my suggestion a bit too literally.

redo is a useful tool that can have a use in system initialization. Someone

Post by Jonathan de Boyne Pollard
asked me an interesting question about /etc/rc.conf.local in FreeNAS
recently and I came up with an interesting answer that made use of redo
which I have to write up at some point. But it's another tool in a good
toolbox, not the whole of the toolbox. Nor is it necessarily the starting
point for everything that has the word "dependency" somewhere in its
description. I can think of three things in the various implementations of
redo that will interact quite poorly with the notion of repeatably starting
maintaining database and job control access, alternative routes, and what
the process tree ends up looking like. And that's skipping over the whole
notion of shutdown. There are ways to marry service dependencies with the
the-filesystem-is-the-database paradigm, but one doesn't really start here
to reach them.

DJB's design for redo is not aimed at an init tool. It is aimed at a make
tool. It might be possible to adapt a make tool into an init tool, but
that does not sound to me like it would be fun. The missing concept is a
replacement for timestamp sequencing as used by make et al with a set of
events that mean approximately "ready". And initing requires a systematic
approach to determining readiness for every step of the boot process. I
don't think timestamps will cut it. We need a different boolean
predicate. And I agree that it has to be bidirectional in an
edge-triggered sense.

Post by Jonathan de Boyne Pollard
Maybe Alan Grosskurth, Avery Pennarun, or that other bloke have written
some tools for system and daemon management.

It's possible. I do not track those implementations. I did study redo
intensively as part of a better build search about a year ago. There were
two finalists in my search, of which redo was one. But IMHO redo has too
much human element to be reliable for large software development projects.

But with redo it is _extremely_ easy to determine what is going on and just
as easy to customize. Those are both properties that I also value for
system software.

Lee Winter
Nashua, New Hampshire
United States of America

[Marty]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.

One that doesn't divide the FOSS world. We have enough challenges
without that.

Post by Patrick Bartek
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.

Whichever one the user wants is the best. The users should decide,
individually and collectively. The distro should be the testbed for new
ideas, with users trying out and choosing solutions that work best for
them. Debian should not make that choice for users. "Upstreams" should
not make that choice for Debian.

This is official Debian Policy but some people seem upset about it.
I don't understand antipathy toward user choice, especially here. I
sometimes wonder if they have lost sight of the purpose of FOSS, which
would be sad, because they (especially volunteers) have given us so much
in the name of software freedom. They have changed the world.

I hope this just a misunderstanding that gets cleared up after the dust
settles and everyone starts talking again, instead of just yelling at
each other. I hope some people change their minds about the importance
of user choice. I hope Ian Jackson stops being bitter. :)

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

We all should be able to propose our ideal solution with a reasonable
expectation that if it's a good idea, and somebody does the work, it
could be adopted and help other people, without being unduly hindered by
a software bundle laying exclusive claim to PID 1. That is the unique
gate-keeper spot in all systems, and it's probably why the policy pays
special attention to it. That button belongs to me, the user. Hands off
my computer at its most vulnerable spot.

Post by Patrick Bartek
Just wondering.

Me too.

Post by Patrick Bartek
B

[Patrick Bartek]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative? And it can't
be sysvinit.

Why not? I do not see sysvinit -- or any other legacy init system,

Systemd is intended as a "modern" replacement for sysvinit. I wanted
to know if not systemd, what init others would choose to replace
sysvinit. Simple question. Difficult to answer.

B

[Erwan David]

Post by Patrick Bartek

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative? And it can't
be sysvinit.

Why not? I do not see sysvinit -- or any other legacy init system,

Systemd is intended as a "modern" replacement for sysvinit. I wanted
to know if not systemd, what init others would choose to replace
sysvinit. Simple question. Difficult to answer.
B

Please define "modern". And no, new is not equivalent of better.

[Martinx - ジェームズ]

1- Fork udev (out from systemd's tree or before it got merged / engulfed);
2- Start testing uselessd;
3- Remove systemd from Debian sources, since it is uselessd now lol ;

I vote for upstart too (instead of uselessd), since I'm using without any
problems (and it is not trying to take over the world).

I believe (because I'm not a software engineer), that the main problem with
systemd started when they merged udev. That was a smart move (for Them)
but, there is time to take udev back and use another init, as good old days.

Jut my two bitcents...

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.
B
--
with a subject of "unsubscribe". Trouble? Contact

[Jonathan Dowland]

Post by Martinx - ジェームズ
2- Start testing uselessd;

You missed 'package uselessd' for Debian - not yet done.

[Martinx - ジェームズ]

That's true... Can't wait to try it!

If uselessd provides ONLY a new init, based on CGroups and lots of
cool ideas from systemd itself, then, it worth trying it! Just for
fun...

Systemd will be still around, acting only as udev, I know... But,
then, it will be more easy to live without it.

If that becomes true, I mean, if uselessd can act as systemd to
mange/supervise process in a new fashion (i.e. no init scripts), then,
it will be doing what systemd was supposed to be doing (in Debian) in
first place!

Sorry about my poor English.

-
Thiago

Post by Jonathan Dowland

Post by Martinx - ジェームズ
2- Start testing uselessd;

You missed 'package uselessd' for Debian - not yet done.
--

[Jonathan Dowland]

Hi,

Please do not top-post.

Post by Martinx - ジェームズ
If uselessd provides ONLY a new init, based on CGroups and lots of
cool ideas from systemd itself, then, it worth trying it! Just for
fun...

I think it's an interesting project and I might contribute towards the
packaging, so long as it's a team effort, but currently nobody has
taken ownership of the 'request for package' bug, so there is almost
no chance of uselessd being a part of jessie. (it would have to be
packaged, uploaded and pass NEW in under 2 weeks.)

Post by Martinx - ジェームズ
Systemd will be still around, acting only as udev, I know... But,
then, it will be more easy to live without it.

udev and systemd are not the same things. Their source co-exists in
the same version control repository, and they are developed in concert,
but they are (currently) independent, and will certainly be independent
for jessie. (whether they remain independent in the future is another
question.)

Post by Martinx - ジェームズ
Sorry about my poor English.

No need to apologise!

[Rob Owens]

----- Original Message -----

Post by Jonathan Dowland

Post by Martinx - ジェームズ
If uselessd provides ONLY a new init, based on CGroups and lots of
cool ideas from systemd itself, then, it worth trying it! Just for
fun...

I think it's an interesting project and I might contribute towards the
packaging, so long as it's a team effort, but currently nobody has
taken ownership of the 'request for package' bug, so there is almost
no chance of uselessd being a part of jessie. (it would have to be
packaged, uploaded and pass NEW in under 2 weeks.)

Jonathan,

I'm not sure what is meant by "nobody has taken ownership of the 'request for package' bug". If that's something that needs to be done, tell me what is required and I'll see if I can do it.

-Rob

[Jonathan Dowland]

Post by Rob Owens
I'm not sure what is meant by "nobody has taken ownership of the 'request for
package' bug". If that's something that needs to be done, tell me what is
required and I'll see if I can do it.

There is a bug, it's currently a "request for package", to progress, someone
prepared to maintain uselessd in Debian should take over the bug and rename it
to "ITP" for "intent to package". See
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage

At present nobody has indicated that they are going to do the work.

[Rob Owens]

----- Original Message -----

Post by Jonathan Dowland

Post by Rob Owens
I'm not sure what is meant by "nobody has taken ownership of the 'request for
package' bug". If that's something that needs to be done, tell me what is
required and I'll see if I can do it.

There is a bug, it's currently a "request for package", to progress, someone
prepared to maintain uselessd in Debian should take over the bug and rename it
to "ITP" for "intent to package". See
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage
At present nobody has indicated that they are going to do the work.

Ah, I see. Unfortunately that's not something I'm able to do (I lack the skills).

-Rob

[Jonathan de Boyne Pollard]

I'm not sure what is meant by "nobody has taken ownership of the
'request for package' bug". If that's something that needs to be
done, tell me what is required and I'll see if I can do it.

It is Debian bug #763499, for reference.

[Steve Litt]

On Tue, 21 Oct 2014 09:11:32 +0100

Post by Jonathan Dowland
Hi,
Please do not top-post.

Post by Martinx - ジェームズ
If uselessd provides ONLY a new init, based on CGroups and lots of
cool ideas from systemd itself, then, it worth trying it! Just for
fun...

I think it's an interesting project and I might contribute towards the
packaging, so long as it's a team effort, but currently nobody has
taken ownership of the 'request for package' bug, so there is almost
no chance of uselessd being a part of jessie. (it would have to be
packaged, uploaded and pass NEW in under 2 weeks.)

Hey Jonathan,

First, if you do contribute to uselessd, thank you very much.

I want to make sure I'm reading your paragraph correctly: The
Debian uselessd package cannot be finished in time to make it into
Jessie, so there will be no uselessd package in Jessie. Is that correct?

Let's say that, in six months from now, Debian's uselessd package is
ready for prime time. Would there be any reason some enterprising
person couldn't simply copy it to another repository (hopefully a
trusted one), so that people could add that repository and thus install
uselessd on Jessie?

Thanks,

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

[Martinx - ジェームズ]

You guys can count on me to help testing uselessd in Debian/Ubuntu! I would
like to participate.

Post by Steve Litt
On Tue, 21 Oct 2014 09:11:32 +0100

Post by Jonathan Dowland
Hi,
Please do not top-post.

Post by Martinx - ジェームズ
If uselessd provides ONLY a new init, based on CGroups and lots of
cool ideas from systemd itself, then, it worth trying it! Just for
fun...

I think it's an interesting project and I might contribute towards the
packaging, so long as it's a team effort, but currently nobody has
taken ownership of the 'request for package' bug, so there is almost
no chance of uselessd being a part of jessie. (it would have to be
packaged, uploaded and pass NEW in under 2 weeks.)

Hey Jonathan,
First, if you do contribute to uselessd, thank you very much.
I want to make sure I'm reading your paragraph correctly: The
Debian uselessd package cannot be finished in time to make it into
Jessie, so there will be no uselessd package in Jessie. Is that correct?
Let's say that, in six months from now, Debian's uselessd package is
ready for prime time. Would there be any reason some enterprising
person couldn't simply copy it to another repository (hopefully a
trusted one), so that people could add that repository and thus install
uselessd on Jessie?
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
--
with a subject of "unsubscribe". Trouble? Contact

[John Hasler]

Post by Steve Litt
Let's say that, in six months from now, Debian's uselessd package is
ready for prime time. Would there be any reason some enterprising
person couldn't simply copy it to another repository (hopefully a
trusted one), so that people could add that repository and thus
install uselessd on Jessie?

Yes, of course that could be done. The name of the appropriate
repository is Debian/Unstable, also known as Sid. The package could
then be backported and made available for installation in Jessie on
backports.debian.org.
--
John Hasler
***@newsguy.com
Elmwood, WI USA

[Raffaele Morelli]

Here are some interesting things one should be aware of before
http://0pointer.de/blog/projects/the-biggest-myths.html

Read enough about but still haven't read something really valuable against
systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link)

I believe the main issue with systemd and the community mainly the "badass-ness" of
the guys in this "init system war" or whatever you prefer to address at.

Using systemd since 2014-08-09 with no issues.

[Jonathan Dowland]

Post by Raffaele Morelli
Here are some interesting things one should be aware of before
http://0pointer.de/blog/projects/the-biggest-myths.html
Read enough about but still haven't read something really valuable against
systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link)

Please don't, because that isn't on topic for this mailing list.

[Raffaele Morelli]

Post by Jonathan Dowland

Post by Raffaele Morelli
Here are some interesting things one should be aware of before
http://0pointer.de/blog/projects/the-biggest-myths.html
Read enough about but still haven't read something really valuable against
systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link)

Please don't, because that isn't on topic for this mailing list.

you know, it's been months that this systemd thing is going on
and I thought it was tolerated (though I learned to use ^D in mutt :-) )


I apologize

[Martin Steigerwald]

Hi Raffaele,

Post by Raffaele Morelli
Here are some interesting things one should be aware of before
http://0pointer.de/blog/projects/the-biggest-myths.html
Read enough about but still haven't read something really valuable against
systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link)
I believe the main issue with systemd and the community mainly the
"badass-ness" of the guys in this "init system war" or whatever you prefer
to address at.
Using systemd since 2014-08-09 with no issues.

I think this is certainly a good read for background.

I also suggest to revisit


[systemd-devel] I wonder… why systemd provokes this amount of polarity and
resistance
http://lists.freedesktop.org/archives/systemd-devel/2014-September/023290.html


Rob from this list voiced some concern there.

And I added hints about debianfork.org and also raised some issues here now.

This is where upstream really gets to see the feedback. So I again suggest you
voice your concerns there. Politely and in enough detail.


Or as some of you do, work on the alternatives.

Lets see what comes out of the GR: I hope it goes for restricting dependencies
to PID 1 tightly.

Ciao,

[Steve Litt]

On Tue, 21 Oct 2014 10:18:49 +0200

Post by Raffaele Morelli
Here are some interesting things one should be aware of before
http://0pointer.de/blog/projects/the-biggest-myths.html

We've all read that. My favorite Poettering manifesto is the one where
he talks of systemd subsuming packaging systems:

http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

Post by Raffaele Morelli
Read enough about but still haven't read something really valuable
against systemd from eg. Torvalds, Eric Steven Raymond, etc... (if
you do, post the link)

Isn't this quote from ESR enough "against systemd"?

http://en.wikipedia.org/wiki/Systemd#Reception

"very prone to mission creep and bloat and likely to turn into a nasty
hairball over the longer term."

As far as Torvalds, would this qualify as something really valuable
against systemd?

http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA

"Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause."

Post by Raffaele Morelli
I believe the main issue with systemd and the community mainly the
"badass-ness"

Badass is a complement. Poettering is just an ass. But if I used
ass-ness as a filter on software I use, I wouldn't use anything RMS
created, because he can be an ass, and I wouldn't use anything from the
Linux kernel, because Linus can be an ass. Ass-authored software is
used every day, by all of us. The thing is, asses like Linus and RMS
don't have a roadmap to the destruction of the software ecosystem that
created them (any more).

Post by Raffaele Morelli
of the guys in this "init system war" or whatever you
prefer to address at.
Using systemd since 2014-08-09 with no issues.

Good for you. Let's see if you have no issues 2016-08-09, if Red Hat
wins its war against Linux.

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance

[Miles Fidelman]

Post by Steve Litt
On Tue, 21 Oct 2014 10:18:49 +0200

Post by Raffaele Morelli
Here are some interesting things one should be aware of before
http://0pointer.de/blog/projects/the-biggest-myths.html

We've all read that. My favorite Poettering manifesto is the one where
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

Post by Raffaele Morelli
Read enough about but still haven't read something really valuable
against systemd from eg. Torvalds, Eric Steven Raymond, etc... (if
you do, post the link)

Isn't this quote from ESR enough "against systemd"?
http://en.wikipedia.org/wiki/Systemd#Reception
"very prone to mission creep and bloat and likely to turn into a nasty
hairball over the longer term."
As far as Torvalds, would this qualify as something really valuable
against systemd?
http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA
"Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause."

Post by Raffaele Morelli
I believe the main issue with systemd and the community mainly the
"badass-ness"

Badass is a complement. Poettering is just an ass. But if I used
ass-ness as a filter on software I use, I wouldn't use anything RMS
created, because he can be an ass, and I wouldn't use anything from the
Linux kernel, because Linus can be an ass. Ass-authored software is
used every day, by all of us. The thing is, asses like Linus and RMS
don't have a roadmap to the destruction of the software ecosystem that
created them (any more).

More than that, I think. RMS and Linus take a professional approach to
software development, and pay attention things like architecture,
interfaces, regression testing, design review and other feedback - in a
way that Poettering does not seem to.

Post by Steve Litt

Post by Raffaele Morelli
of the guys in this "init system war" or whatever you
prefer to address at.
Using systemd since 2014-08-09 with no issues.

Good for you. Let's see if you have no issues 2016-08-09, if Red Hat
wins its war against Linux.

Not quite sure I'd go that far - personally, this seems more like
Poettering on a mission to reshape Linux in his image, and is taking Red
Hat along for the ride. But I could be wrong.

Miles Fidelman

[Peter Nieman]

Post by Miles Fidelman

Post by Steve Litt
On Tue, 21 Oct 2014 10:18:49 +0200

Post by Raffaele Morelli
Using systemd since 2014-08-09 with no issues.

Good for you. Let's see if you have no issues 2016-08-09, if Red Hat
wins its war against Linux.

Not quite sure I'd go that far - personally, this seems more like
Poettering on a mission to reshape Linux in his image, and is taking Red
Hat along for the ride. But I could be wrong.

I hope you're not, because the only other explanations I can think of
would be far more frightening. In one of the links Steve provided
(http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html),
Mr. "Pid Eins" (= "Pid One") tries to talk *all* Linux distributions
into adopting his "reinvention how distributions work" [sic] "as part of
the systemd project". Who would be interested in such a "unification" of
all Linux distributions? Red Hat? Under normal circumstances, no
corporation could possibly be interested in seeing its excellent ideas
and its unique selling point being copied by all competitors. A
corporation would want its competitors to adopt *bad* ideas - and then
step back and watch the competitors dismantle themselves. And if we
start thinking about who else would certainly benefit from such a
homogenous landscape of highly opaque systems as that proposed by Mr.
Pid Eins, we'll quickly enter the realm of what user or developer John
Doe would call "conspiracy theories".

p.

[Miles Fidelman]

Post by Peter Nieman

Post by Miles Fidelman

Post by Steve Litt
On Tue, 21 Oct 2014 10:18:49 +0200

Post by Raffaele Morelli
Using systemd since 2014-08-09 with no issues.

Good for you. Let's see if you have no issues 2016-08-09, if Red Hat
wins its war against Linux.

Not quite sure I'd go that far - personally, this seems more like
Poettering on a mission to reshape Linux in his image, and is taking Red
Hat along for the ride. But I could be wrong.

I hope you're not, because the only other explanations I can think of
would be far more frightening. In one of the links Steve provided
(http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html),
Mr. "Pid Eins" (= "Pid One") tries to talk *all* Linux distributions
into adopting his "reinvention how distributions work" [sic] "as part
of the systemd project". Who would be interested in such a
"unification" of all Linux distributions? Red Hat? Under normal
circumstances, no corporation could possibly be interested in seeing
its excellent ideas and its unique selling point being copied by all
competitors. A corporation would want its competitors to adopt *bad*
ideas - and then step back and watch the competitors dismantle
themselves. And if we start thinking about who else would certainly
benefit from such a homogenous landscape of highly opaque systems as
that proposed by Mr. Pid Eins, we'll quickly enter the realm of what
user or developer John Doe would call "conspiracy theories".

It occurs to me to wonder if anyone in the BSD or Illumos ecosystems
might want to see Linux die (at least for server-side use). ;-)

[Tanstaafl]

Post by Martinx - ジェームズ
1- Fork udev (out from systemd's tree or before it got merged / engulfed);

Maybe Gentoo's eudev would be a good place to start with that.

I also don't see why OpenRC isn't on the list of obvious choices. It is
the default in Gentoo and has been for ages, and it 'just works'.

[Jimmy Johnson]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.

sysvinit will do just fine until other init-systems can be developed and
installed from the repos.

Post by Patrick Bartek
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.

You sound like my X-wife.

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[Martin Steigerwald]

Post by Jimmy Johnson

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.

Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to
work with sysvinit as well.

Squeeze has security support through the LTS initiative that only provides
this support for a reduced set of packages.

[Jimmy Johnson]

Post by Martin Steigerwald

Post by Jimmy Johnson

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.

Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to
work with sysvinit as well.
Squeeze has security support through the LTS initiative that only provides
this support for a reduced set of packages.

Hi Martin,

I have Squeeze installed on my laptop too and Squeeze works well for my
needs which are audio and video when I'm not testing other systems..now
Lenny was probably my favorite and was hard to let go. Using Squeeze is
like stepping out of the current picture and getting a none bias look at
current situation. I still have more than a few Wheezy installs, a
couple Jessie installs, one Sid, a couple Tanglu installs and all
configured, tested and updated and then I try to keep up with other
current systems that are not following current trends. While looking at
Sid I can see the future and the future is a bit too much for my needs.
There are a bunch of upgraded applications out there for Squeeze and
are already packaged to be installed and I think Squeeze is a good place
to start if someone wanted to remove themselves from the current trend.
I already know that people want upgrades because there are upgrades,
but that's not me.

Martin this is 'debian-live-6.0.10-amd64-kde-desktop'.
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[Jimmy Johnson]

Post by Martin Steigerwald

Post by Jimmy Johnson

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.

Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to
work with sysvinit as well.

Hi Martin, Something I did not know at the time you asked the question:
Why Squeeze?.

Is that Wheezy was used by Debian to test systemd and even though I did
not know this at that time I did not feel comfortable using Wheezy as my
main desktop and now knowing that Wheezy is capable of installing
systemd it will not be my main desktop until systemd is proven to be
safe to use, I need to know more than words from a blog or a wiki to
feel comfortable.

I have been able to customize Squeeze to do all and behave as good as
Wheeze but probably a little faster and once again I feel like a "Happy
Debian User". :)
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[Martin Steigerwald]

Hi Jimmy,

Post by Jimmy Johnson

Post by Martin Steigerwald

Post by Jimmy Johnson

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.

Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to
work with sysvinit as well.

Why Squeeze?.
Is that Wheezy was used by Debian to test systemd and even though I did
not know this at that time I did not feel comfortable using Wheezy as my
main desktop and now knowing that Wheezy is capable of installing
systemd it will not be my main desktop until systemd is proven to be
safe to use, I need to know more than words from a blog or a wiki to
feel comfortable.
I have been able to customize Squeeze to do all and behave as good as
Wheeze but probably a little faster and once again I feel like a "Happy
Debian User". :)

While Wheezy has systemd packages and it somewhat works, but also had lots of
issues in my testing with really systemd packages, its optional.

So as long as you do not install it, you will have sysvinit just as with
Squeeze. So systemd is not a reason to delay an update from Squeeze to Wheezy.

Its Jessie/Sid that are under some circumstances difficult to use without
systemd. As to my current knowledge one of the circumstances is an installed
GNOME desktop.

Ciao,

[Jimmy Johnson]

Post by Martin Steigerwald
Hi Jimmy,

Post by Jimmy Johnson

Post by Martin Steigerwald

Post by Jimmy Johnson

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.

Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to
work with sysvinit as well.

Why Squeeze?.
Is that Wheezy was used by Debian to test systemd and even though I did
not know this at that time I did not feel comfortable using Wheezy as my
main desktop and now knowing that Wheezy is capable of installing
systemd it will not be my main desktop until systemd is proven to be
safe to use, I need to know more than words from a blog or a wiki to
feel comfortable.
I have been able to customize Squeeze to do all and behave as good as
Wheeze but probably a little faster and once again I feel like a "Happy
Debian User". :)

While Wheezy has systemd packages and it somewhat works, but also had lots of
issues in my testing with really systemd packages, its optional.
So as long as you do not install it, you will have sysvinit just as with
Squeeze. So systemd is not a reason to delay an update from Squeeze to Wheezy.

As I have posted elsewhere, I have more than a few installs of Wheezy, I
also have testing and unstable installed too, they will remain as always
until I no longer have an interest in Debian and that will be a sad day
if and when it happens.

Post by Martin Steigerwald
Its Jessie/Sid that are under some circumstances difficult to use without
systemd. As to my current knowledge one of the circumstances is an installed
GNOME desktop.

I install using the Debian-Live-KDE-iso(another project I have helped
with) and will continue my testing and upgrading of Debian systems for
as long as Debian fits my needs.

Upon the first sign of a backdoor and/or keylogger being installed and
used in Debian by default it will begone and mentally ripped to shreds.
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[Jimmy Johnson]

Post by Jimmy Johnson

Post by Martin Steigerwald
Its Jessie/Sid that are under some circumstances difficult to use without
systemd. As to my current knowledge one of the circumstances is an
installed GNOME desktop.

I install using the Debian-Live-KDE-iso(another project I have helped
with) and will continue my testing and upgrading of Debian systems for
as long as Debian fits my needs.
Upon the first sign of a backdoor and/or keylogger being installed and
used in Debian by default it will begone and mentally ripped to shreds.

Huh? Where does your fear of that come from?

Martin, "fear"..I have no fear..but I'm not naive ether and taking this
subject any further on list I will not do, but you are welcome to
contact me off list.
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[Martin Steigerwald]

Post by Jimmy Johnson

Post by Jimmy Johnson

Post by Martin Steigerwald
Its Jessie/Sid that are under some circumstances difficult to use without
systemd. As to my current knowledge one of the circumstances is an
installed GNOME desktop.

I install using the Debian-Live-KDE-iso(another project I have helped
with) and will continue my testing and upgrading of Debian systems for
as long as Debian fits my needs.
Upon the first sign of a backdoor and/or keylogger being installed and
used in Debian by default it will begone and mentally ripped to shreds.

Huh? Where does your fear of that come from?

Martin, "fear"..I have no fear..but I'm not naive ether and taking this
subject any further on list I will not do, but you are welcome to
contact me off list.

Jimmy, I wrote to you off list, and you put my personal reply on the list.
Please don´t do that. I mean personal replies as personal replies.

I think I am not interested into digging into this topic further anyway.

[Jimmy Johnson]

Post by Martin Steigerwald
Jimmy, I wrote to you off list, and you put my personal reply on the list.
Please don�t do that. I mean personal replies as personal replies.
I think I am not interested into digging into this topic further anyway.

No problem and sorry as I did not realize you where posting off list.
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[Ric Moore]

Post by Jimmy Johnson

Post by Martin Steigerwald

Post by Jimmy Johnson

Post by Patrick Bartek
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?
Just wondering.

See above and unless you are a tester or developer you may want to
roll-back to Squeeze.

Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect
Jessie to work with sysvinit as well.

Why Squeeze?.
Is that Wheezy was used by Debian to test systemd and even though I did
not know this at that time I did not feel comfortable using Wheezy as my
main desktop and now knowing that Wheezy is capable of installing
systemd it will not be my main desktop until systemd is proven to be
safe to use, I need to know more than words from a blog or a wiki to
feel comfortable.
I have been able to customize Squeeze to do all and behave as good as
Wheeze but probably a little faster and once again I feel like a "Happy
Debian User". :)

You have to make a concerted effort to enable systemd to Wheezy. I mean,
you really have to try hard. :) Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256

[Jonathan de Boyne Pollard]

You have to make a concerted effort to enable systemd to Wheezy. I
mean, you really have to try hard. :)

It isn't that hard. But one does have to regularly type in a barefaced lie.

[Tanstaafl]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

OpenRC has been working just fine on my Gentoo server for many years.

[Curt]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,

Oh shit.

[g***@riseup.net]

On Tue, 10/21/14, Steve Litt <***@troubleshooters.com> wrote:

Subject: Re: If Not Systemd, then What?
To: debian-***@lists.debian.org
Date: Tuesday, October 21, 2014, 1:02 PM

On Tue, 21 Oct 2014 09:11:32 +0100

Post by Jonathan Dowland
Hi,

Post by Martinx - ジェームズ
If uselessd provides ONLY a new init, based on CGroups and lots of
cool ideas from systemd itself, then, it worth trying it! Just for
fun...

I think it's an interesting project and I might contribute towards the
packaging, so long as it's a team effort, but currently nobody has
taken ownership of the 'request for package' bug, so there is almost
no chance of uselessd being a part of jessie. (it would have to be
packaged, uploaded and pass NEW in under 2 weeks.)

Hey Jonathan,

First, if you do contribute to uselessd, thank you very much.

I want to make sure I'm reading your paragraph correctly: The
Debian uselessd package cannot be finished in time to make it into
Jessie, so there will be no uselessd package in Jessie. Is that correct?

Let's say that, in six months from now, Debian's uselessd package is
ready for prime time. Would there be any reason some enterprising
person couldn't simply copy it to another repository (hopefully a
trusted one), so that people could add that repository and thus install
uselessd on Jessie?

Thanks,

SteveT

---------------------------------

If I'm understanding this post correctly, exbarx over on FDN already
managed to port uselessd to Debian Jessie. (Most of the discussion is
way over my pay grade.):

http://forums.debian.net/viewtopic.php?f=20&t=117944

golinux

[Jimmy Johnson]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. <snip>

And it still works and is completely customizable. Wow! Just maybe I can
get by using it for a couple more years.
--
Jimmy Johnson

Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11
Registered Linux User #380263

[koanhead]

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder... What is a better alternative? And it can't be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's been
patched and bolted onto and jury-rigged to get it to do things that
weren't even around (or dreamt of) at its inception. It's long past
due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user desktop?
Or something that fulfills both scenarios? And why?

I propose OpenRC, having recently tried it. So far I'm liking how it
works, and it solves most of the problems I had with sysvinit. It's not
a replacement for PID1, and is supposed to be compatible with arbitrary
PID1 programs (sysvinit, sytemd, runit, etc.) I expect to test it with
other PID1 programs at some point, but for now I'm still learning it.
There's also runit, which I haven't tried yet but about which I've heard
good things; and daemontools, which has already been talked up on this
list. All these are already in Debian's repositories.

[Patrick Bartek]

Post by koanhead

Post by Patrick Bartek
After much vitriolic gnashing of teeth from those opposed to
systemd, I wonder... What is a better alternative? And it can't
be sysvinit.
Yes. Syvinit still works, but it is after all 20 years old. It's
been patched and bolted onto and jury-rigged to get it to do things
that weren't even around (or dreamt of) at its inception. It's
long past due for a contemporary replacement. Whatever that may be.
So, what would you all propose? For a server? Or for a user
desktop? Or something that fulfills both scenarios? And why?

I propose OpenRC, having recently tried it. So far I'm liking how it
works, and it solves most of the problems I had with sysvinit. It's
not a replacement for PID1, and is supposed to be compatible with
arbitrary PID1 programs (sysvinit, sytemd, runit, etc.) I expect to
test it with other PID1 programs at some point, but for now I'm still
learning it. There's also runit, which I haven't tried yet but about
which I've heard good things; and daemontools, which has already been
talked up on this list. All these are already in Debian's
repositories.

I myself have been looking at runit for a just-for-fun try at replacing
systemd in Jessie running in a VM. One of the reasons for considering
runit is it purports to be a "drop-in" replacement for sysvinit, either
in part or wholly.

I've heard of OpenRC, but haven't really researched it much. I'll take
a more lengthy look at it.

Thanks for the reply.

B

[Tanstaafl]

Post by koanhead
I propose OpenRC, having recently tried it. So far I'm liking how it
works, and it solves most of the problems I had with sysvinit. It's not
a replacement for PID1, and is supposed to be compatible with arbitrary
PID1 programs (sysvinit, sytemd, runit, etc.) I expect to test it with
other PID1 programs at some point, but for now I'm still learning it.
There's also runit, which I haven't tried yet but about which I've heard
good things; and daemontools, which has already been talked up on this
list. All these are already in Debian's repositories.

Seconded...

OpenRC has also been the default init system for gentoo for as long as I
can remember knowing what init system I was running on my gentoo server
(I had help setting up the first one ten years ago, so I don't know if
it was the default then)...

[Ansgar Burchardt]

Hi,

1. Reviving the existing init systems. Modernizing them, making them
into true, interchangeable drop-in replacements of each other, which do
the task assigned, and do it well. Each of them accomplishing at least
the common subset of tasks an init system is supposed to provide.
2. Complementing them with existing or new tools (again, drop-in
interchangeable replacements of each other) which build on them and
provide the next layer. For example, the kernel autofs facility provides
very nice automounting and could be deployed to the majority of desktop
installs (instead of being just an optional package, as it is now), thus
making the various automount daemons of the various desktop
environments/file managers virtually superfluous. As a further example,
the former udev (prior to being merged into systemd) has already been
forked and could/will serve us well for years to come. And so on.

+1 for being reasonable and making sense
It's an approach that would keep a lot of people happy and, more
importantly (at least to me), it gives the user choice instead of taking
it away. At least this way each user could choose the loosely-coupled
components s/he wanted.

Nobody is stopping anybody from improving sysvinit if they want to. So,
have fun hacking on it. ;)

Ansgar

[Martin Read]

1. Reviving the existing init systems. Modernizing them, making them
into true, interchangeable drop-in replacements of each other, which do
the task assigned, and do it well. Each of them accomplishing at least
the common subset of tasks an init system is supposed to provide.

Given the profundity of disagreement about what "init systems" are
"supposed to provide", I believe that this would be a Sisyphean task.
Positions people hold on the topic include, but:

1. The init daemon should fork exactly once; in the child it should exec
another program, while the parent (PID 1) does nothing except reap zombies.

2. As (1), except that if the initially-forked child process exits, PID
1 should repeat the fork and exec-in-child procedure.

3. The init daemon should have a simple integrated service management
mechanism akin to sysvinit's "/etc/inittab".

4. The init daemon should have a complex integrated service management
mechanism, perhaps akin to those of upstart or systemd.

5. The init program should do some basic setup, then exec a service
manager daemon *within PID 1*.

Moving on from *there*, let's take a look at two of the things you
suggest, each of which are quite reasonable in isolation.

On the one hand, "making them into true, interchangeable drop-in
replacements of each other" suggests to me that you think they should
all have exactly the same set of interfaces and functionality. I don't
agree with this position, but it's reasonable, though it's rather
stifling (since now you can't add new functionality unless you can
persuade all the other init maintainers to add it).

On the other, "each of them accomplishing at least the common subset of
tasks an init system is supposed to provide" suggests to me that you
think it would be all right for some of them to have extra interfaces
and functionality - but as soon as you allow extra interfaces and
functionality, you no longer achieve the "true, interchangeable drop-in
replacements" part.

[Miles Fidelman]

Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service scripts.

I just went through the documentation, and in some cases, the source
trees, for the following:

bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav

Most come with sysvinit scripts, several come with their own startup
scripts (e.g., apachectl) that get dropped into rc.local. Not a one
comes with a native systemd service file (even though, when you search
through the mysql documentation it tells you that oracle linux has
switched to systemd).

So... with systemd, one has to:
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which

In the later case, one just has to read:
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Among the implications of this, the old standby of installing software
from upstream (bypassing packaging), has just gotten a lot riskier.

[Andrei POPESCU]

Post by Miles Fidelman
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

I don't see any item that would matter on a Debian system, care to
elaborate?

Kind regards,
Andrei

[Miles Fidelman]

Post by Andrei POPESCU

Post by Miles Fidelman
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

I don't see any item that would matter on a Debian system, care to
elaborate?

It's very simple. I have a bunch of stuff running on my system that I
compiled from upstream code, including init scripts that work just
fine. Now I have to worry that some of those scripts are incompatible
with systemd.

[Marty]

Post by Miles Fidelman
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Each one a bug as per Debian policy (sysvinit support). Looks like we have
our work cut out for us.

Would you please be so kind to point out which bullet point contradicts
which Policy section?
Kind regards,
Andrei

Don't they all by definition? Did I miss something?

I suspect the workaround in all cases is sysvinit-core, but the warning
still applies to anyone who runs the default configuration.

For the record, since you omitted my smiley, I don't assume these are
not already well known, or that I am planning to file bug reports. :)

[Andrei POPESCU]

Post by Marty

Post by Miles Fidelman
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Each one a bug as per Debian policy (sysvinit support). Looks like we have
our work cut out for us.

Would you please be so kind to point out which bullet point contradicts
which Policy section?

Don't they all by definition? Did I miss something?

Others have addressed those bullets one by one, explaining why they are
not relevant to Debian. If you disagree you might want to reply to one
of those posts with specific concerns.

Kind regards,
Andrei

[Laurent Bigonville]

Le Sun, 16 Nov 2014 11:50:25 -0500,
Miles Fidelman <***@meetinghouse.net> a écrit :

[...]

Post by Miles Fidelman
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

Do you have any bug reports at hand that show that there are issues
with the initscripts that are shipped in the debian archive? Or are you
spreading FUD again?

Post by Miles Fidelman
Among the implications of this, the old standby of installing
software from upstream (bypassing packaging), has just gotten a lot
riskier.

That's indeed true, but usually 3rd party vendors of (commercial)
software are certifying their software for a limited set of
distributions/version anyway.

[Ludovic Meyer]

Post by Miles Fidelman
Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service scripts.
I just went through the documentation, and in some cases, the source
bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav
Most come with sysvinit scripts, several come with their own startup
scripts (e.g., apachectl) that get dropped into rc.local. Not a one
comes with a native systemd service file (even though, when you
search through the mysql documentation it tells you that oracle
linux has switched to systemd).
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared

In practice, what would be broken ?

Taking the list :

- the fact that direct invocation is deprecated is a good thing, since
this was previously broken. Starting stuff
directly from the script mean that your environment leak in the daemon
environment, which is a source of fun bug ( like sorting in php
depending on the locale, and the locale not being always C, something
that US people tend to forget ). It also help when you are
using SELinux or another MAC, since the domain of the admin do
not leak to the daemon, and things are clearly separated.

- LSB information have to be correct anyway in Debian, or you would have bug anyway. LSB
is also old enough to have no excuse to have transitionned, and is a standard.
See https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

- timeout that would block boot are a bug, since this mean that your server could not boot
if the timeout was undefinite. Again, i can't see why a correct execution would depend on "not
booting due to 1 system blocking everything", especially in the list of service
you gave.

- again, clean env just requires you to make sure that what is needed to be set is present.
That's a question of correctness, and I think no one will advocate that being correct is
a regression.

- none of the script you gave seems interactive, and that's kinda already causing issue anyway
( for example, when automating restart accross a cluster with a tool like ansible, or when you
are not near the keyboard when the server reboot and the script start at boot ).

- additional verbs are supported on service binary, not on the script level, at least on Centos.
If that's misisng, I am sure that can be done on Debian as well, if that's not done already.

- stopping non running service seems again a weird things to do. I do not see anything that would depend
on this behavior to be correct, as that's more "we stop something that said to be stopped, but wasn't".
None of the service you gave rely on this behavior, and I would be interested into getting precise details on
what service would need this.

- run levels support is limited, but it still exist. Again, explain what is your usecase, so we can see
if that's broken or not ( because you do not test and do not give details ).
Migration to target is likely not hard ( just different directory to make symlinks ),
so i do not see why you would fear it.

- chkconfig is already returning misleading information, due to a complete lack of standard on
the return code of the initscript, despites LSB trying to clean that mess. Again, it will just
be broken in a different way. At least, mediating the interaction
with systemd make script more reliable once they use it, because there is no local variation
in return code.

- next one is again on runlevels. Please tell what local variation you have, then people can judge
if that's a reason to fear or not. Otherwise, that's just spreading FUD since most people do not
have complex runlevels systems, as "running/not running" is enough for most cases I did see.

- early boot scripts would be the biggest challenge for your setup I guess.
While you didn't gave any details , you seems to use some customs script instead of Debian, so
you would have to change that integration. Yet, without giving the usecase, no one know and maybe
I am wrong. If your setup cannot be handled by Debian regular script, maybe the Debian developpers
would be interested to fix that use case.

And last:
- no real time privs. No service you gave use that, but then there is workaround. At most 1 line to
add and a reboot. That's not what I would qualify as a cause of fear.

Post by Miles Fidelman
Among the implications of this, the old standby of installing
software from upstream (bypassing packaging), has just gotten a lot
riskier.

What is the risk ? before, you were on your own, now, you would be on your own. Differences, before, you
had to write a initscript, now you have to write a initscripts or a systemd unit. Systemd unit that
even the most anti systemd person see as "not that hard to write".

What is more risky now ?

( again, the lack of details make you look like you are spreading the very definition of FUD,
and I am sure that's not what you want, so I would advice to try to avoid that if you do not
want to be labelled as hater and spreading FUD ).

[Miles Fidelman]

Post by Miles Fidelman
Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service
scripts. I just went through the documentation, and in some cases, the
bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav
Most come with sysvinit scripts, several come with their own startup
scripts (e.g., apachectl) that get dropped into rc.local. Not a one
comes with a native systemd service file (even though, when you search
through the mysql documentation it tells you that oracle linux has
switched to systemd).
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared
Among the implications of this, the old standby of installing software
from upstream (bypassing packaging), has just gotten a lot riskier.

Interesting, since I posted this, a bunch of people have jumped on my
comment that relying on packagers and systemd to support sysvinit
scripts seems increasingly risky, but...

Not a single person has commented on the observation that upstream
developers, at least of core server applications, are thoroughly
ignoring systemd. So tell me again about all the great features that
are in such demand, that systemd is a solution for? Where's the
demand? Maybe upstream knows something that seems to elude systemd
proponents?

Miles Fidelman

[Ludovic Meyer]

Post by Miles Fidelman

Post by Miles Fidelman
Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service
scripts. I just went through the documentation, and in some cases,
bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav
Most come with sysvinit scripts, several come with their own
startup scripts (e.g., apachectl) that get dropped into rc.local.
Not a one comes with a native systemd service file (even though,
when you search through the mysql documentation it tells you that
oracle linux has switched to systemd).
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared
Among the implications of this, the old standby of installing
software from upstream (bypassing packaging), has just gotten a
lot riskier.

Interesting, since I posted this, a bunch of people have jumped on
my comment that relying on packagers and systemd to support sysvinit
scripts seems increasingly risky, but...
Not a single person has commented on the observation that upstream
developers, at least of core server applications, are thoroughly
ignoring systemd.

No one commented because that's false.
I also guess that you will use anyone response to later justify
"see, it try to force its way by forcing people to
integrate with systemd". Either way, that's gonna be used
as a way to criticize.

Post by Miles Fidelman
So tell me again about all the great features
that are in such demand, that systemd is a solution for?

Most of the features do not requires anything upstream.
For example :
- being able to autorestart when crashed. Done on the distribution
side, and usually, that's a policy left to the admin, not upstream

- limiting the service with cgroups. Again, dependent on the
installation, so left to the admin.

- limiting the access with namespaces. Again, depend on the setup,
so left for the admin.

- starting on demand, that can be achieved with either
xinetd protocol ( ie, reading stdin, writing stdout instead
of a socket ), so no need here.

- clean environment, that's not a feature that requires any
patch upstream

- journald integration, again, most software do use syslog, so no
special need to have something that work.

There is a few feature that requires any upstream patches.
1) socket activation using the systemd way ( ie, not xinetd )
2) using journald to have more metadata that regular syslog
3) notifcation protocol and automated restart

Post by Miles Fidelman
Where's
the demand? Maybe upstream knows something that seems to elude
systemd proponents?

Apache has support as a module in trunk :
https://httpd.apache.org/docs/trunk/mod/mod_systemd.html
There is support for journal too, see mod_journal.

And also see
https://github.com/apache/httpd/commit/9e6638622be042eb00af5234a48049f7b5487a15#diff-92a02cae0d4feb2dfea5d1532ba1b977
for support directly in apache.


HAProxy do have some support for integration
https://github.com/jvehent/haproxy/blob/master/src/haproxy-systemd-wrapper.c

Php-fpm does too :
http://thanatos.be/2014/04/12/php-fpm-ondemand.html

Nodejs has a module for nodejs application:
https://savanne.be/articles/deploying-node-js-with-systemd/

Docker has support for it in various place ( socket activation,
support in libcontainer ), and I could surely find lots of
core stuff and newer code that do have native support.

Dovecot have support for it, there is a service
file :
http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/dovecot.service.in
There is support for it :
http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/src/master/service-listen.c

There is the upstream of mdadm who even wrote 2 articles
on how to do it for nfs :
http://lwn.net/Articles/584175/
http://lwn.net/Articles/584176/

Older software are just integrated with xinetd do not need anything.
So for example, openssh already support socket
activation like it does for xinetd.

Had you done your homework and spent 5 minutes double checking
your affirmation, you would surely have found the same links
as me. just search for HAVE_SYSTEMD on github, bitbucket, etc.

And to show there is demand, you can even look on modern configuration
tools and you can see they all support to configure systemd :
To give the 4 most spoken of at the moment :

- ansible
https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L396

- chef
http://www.rubydoc.info/github/opscode/chef/Chef/Provider/Service/Systemd

- puppet
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb

- saltstack
http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.systemd.html

If no one wanted to use systemd on a server, they wouldn't have specific module
for it.

So instead of trying to find endless reasons to justify your position,
please start to work on making sure sysvinit work as you want.
Show the way of constructive contribution.

--
l.

[Miles Fidelman]

Post by Ludovic Meyer

Post by Miles Fidelman

Post by Miles Fidelman
Given all the talk about not being able to influence upstream, it
occurred to me to actually take a look at which of the major
applications I rely on actually come with native systemd service
scripts. I just went through the documentation, and in some cases,
bind9
apache
sympa
mailman
mysql
mariadb
postgres
postfix
spamassassin
amavisd
clamav
Most come with sysvinit scripts, several come with their own
startup scripts (e.g., apachectl) that get dropped into rc.local.
Not a one comes with a native systemd service file (even though,
when you search through the mysql documentation it tells you that
oracle linux has switched to systemd).
- rely on packagers to generate systemd service files, and/or,
- rely on systemd's support for sysvinit scripts, which
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
to get very, very scared
Among the implications of this, the old standby of installing
software from upstream (bypassing packaging), has just gotten a
lot riskier.

Interesting, since I posted this, a bunch of people have jumped on
my comment that relying on packagers and systemd to support sysvinit
scripts seems increasingly risky, but...
Not a single person has commented on the observation that upstream
developers, at least of core server applications, are thoroughly
ignoring systemd.

No one commented because that's false.
I also guess that you will use anyone response to later justify
"see, it try to force its way by forcing people to
integrate with systemd". Either way, that's gonna be used
as a way to criticize.

False, how? I went through the release notes, install instructions,
support wikis, source trees, and did some googling for good measure, and
all that I found re. systemd scripts for pretty much the most popular
server-side programs were a few emails in the Arch users list about how
to get these things working w/ systemd.

[Ansgar Burchardt]

Hi,

So why, instead of spending all this time on a new init system didn't
developers already familiar with sysvinit work on it? Systemd wasn't
one person alone.

Presumably nobody was interested enough to do so.

Maybe someone SHOULD have had enough interest.

Which doesn't change the fact that nobody was...

I can write long lists of what SHOULD be done in my opinion, but that
won't make any of it happen.

1. Reviving the existing init systems. Modernizing them, making them
into true, interchangeable drop-in replacements of each other, which do
the task assigned, and do it well. Each of them accomplishing at least
the common subset of tasks an init system is supposed to provide.

[...]

It's not going to happen, because...
... nobody wants to work on it (at least not for free).

So why don't YOU work on it?

Oh, that's easy to answer. There is no motivation for me to do so: I
don't care about support for sysvinit. I care even less thanks to the
behavior of some people who write angry mails (no, really: why should
I waste my free time to do something for them?).

Ansgar

[Martin Read]

Are you aware that this is the approach that systemd and upstart have
taken, right?
1) Both systemd (PID1) and upstart are drop-in replacement for the good
old SysVinit as they both support the common "standard" that are LSB
scripts (A really good share of the existing LSB initscripts in the
debian archive are just working out of the box).

Well. They're (mostly) a drop-in replacement for sysvrc and its
supporting tools. They're certainly not a *drop-in* replacement for
*sysvinit*, because they don't support all of sysvinit's interfaces;
specifically, they don't support /etc/inittab.

Luckily (for some values of lucky), /etc/inittab was such a terrible
interface (it's unpleasantly reminiscent of Angband's monster, item,
etc. databases) that it seems even most people who prefer sysvinit to
systemd or upstart were using a factory-default /etc/inittab.

[Ludovic Meyer]

Post by Martin Read

Are you aware that this is the approach that systemd and upstart have
taken, right?
1) Both systemd (PID1) and upstart are drop-in replacement for the good
old SysVinit as they both support the common "standard" that are LSB
scripts (A really good share of the existing LSB initscripts in the
debian archive are just working out of the box).

Well. They're (mostly) a drop-in replacement for sysvrc and its
supporting tools. They're certainly not a *drop-in* replacement for
*sysvinit*, because they don't support all of sysvinit's interfaces;
specifically, they don't support /etc/inittab.
Luckily (for some values of lucky), /etc/inittab was such a terrible
interface (it's unpleasantly reminiscent of Angband's monster, item,
etc. databases) that it seems even most people who prefer sysvinit
to systemd or upstart were using a factory-default /etc/inittab.

Writing a generator would be trivial.

http://www.freedesktop.org/wiki/Software/systemd/Generators/

No one seemed to care enough for writing one however, but reading
the file and generating a unit file ( with the automated restart behavior )
is easy to do.

[Laurent Bigonville]

Le Sun, 16 Nov 2014 18:08:48 +0000,

Post by Martin Read

Are you aware that this is the approach that systemd and upstart
have taken, right?
1) Both systemd (PID1) and upstart are drop-in replacement for the
good old SysVinit as they both support the common "standard" that
are LSB scripts (A really good share of the existing LSB
initscripts in the debian archive are just working out of the box).

Well. They're (mostly) a drop-in replacement for sysvrc and its
supporting tools. They're certainly not a *drop-in* replacement for
*sysvinit*, because they don't support all of sysvinit's interfaces;
specifically, they don't support /etc/inittab.
Luckily (for some values of lucky), /etc/inittab was such a terrible
interface (it's unpleasantly reminiscent of Angband's monster, item,
etc. databases) that it seems even most people who prefer sysvinit to
systemd or upstart were using a factory-default /etc/inittab.

Note that there were plans to either abort systemd-sysv installation or
at least display a big fat warning in case /etc/inittab was modified on
the machine.

[Tanstaafl]

As a further example, the former udev (prior to being merged into
systemd) has already been forked and could/will serve us well for
years to come. And so on.

Is eudev in the debian sources?

Or do you mean another fork?

[Klistvud]

Post by Tanstaafl

As a further example, the former udev (prior to being merged into
systemd) has already been forked and could/will serve us well for
years to come. And so on.

Is eudev in the debian sources?
Or do you mean another fork?

I meant eudev, I am not aware of any other forks.
--
Kinda regards,
my beast washes

Klistvud
http://bufferoverflow.tiddlyspot.com
Certifiable Loonix Oozer #481801 Please reply to the list, not to
me.

[The Wanderer]

Le Sun, 16 Nov 2014 13:53:24 +0000, Nuno Magalhães

1. Reviving the existing init systems. Modernizing them, making
them into true, interchangeable drop-in replacements of each
other, which do the task assigned, and do it well. Each of them
accomplishing at least the common subset of tasks an init system
is supposed to provide.
2. Complementing them with existing or new tools (again, drop-in
interchangeable replacements of each other) which build on them
and provide the next layer. For example, the kernel autofs
facility provides very nice automounting and could be deployed
to the majority of desktop installs (instead of being just an
optional package, as it is now), thus making the various
automount daemons of the various desktop environments/file
managers virtually superfluous. As a further example, the former
udev (prior to being merged into systemd) has already been
forked and could/will serve us well for years to come. And so
on.

+1 for being reasonable and making sense
It's an approach that would keep a lot of people happy and, more
importantly (at least to me), it gives the user choice instead of
taking it away. At least this way each user could choose the
loosely-coupled components s/he wanted.

Are you aware that this is the approach that systemd and upstart have
taken, right?
1) Both systemd (PID1) and upstart are drop-in replacement for the
good old SysVinit as they both support the common "standard" that
are LSB scripts (A really good share of the existing LSB initscripts
in the debian archive are just working out of the box).

Not a "full" drop-in replacement; with systemd replacing sysvinit,
unless you change configuration settings elsewhere, you will see
behavior changes that aren't unambiguous 100% improvements.

A drop-in replacement must, at minimum, Just Work in all of the same
environments and with all of the same configurations where the thing
being replaced already worked. systemd mostly does that, but not
entirely - fstab-related boot failures (lack of noauto / nofail leading
to a boot failure with systemd, where with sysvinit it would not),
issues with booting on/from/to encrypted filesystems, et cetera.

A drop-in replacement should, theoretically and ideally, work *exactly
the same way* as the thing being replaced, when presented the exact same
configuration, except possibly when it can work in a way which is
obviously and incontrovertibly better. There are cases in which systemd
does not do that - consider the "quiet" kernel command-line option, for
example.

Now, there may be good reason to have systemd prefer to not behave in
the same way as sysvinit in these regards, and there's certainly nothing
saying that it can't or shouldn't do so in its own configuration.

But to the extent that it does not do so *by default*, in a
configuration inherited from a sysvinit machine, it is not a full
drop-in replacement for sysvinit.

But then you cannot blame the systemd project for 3rd party software
taking advantages of these new functionalities if they think they
fit their usecases.

I can, however, blame the systemd project for having implemented these
new functionalities in a way which only works in the presence of
functionality which is only provided by their own init system. But
that's a mostly separate argument, which I don't really care to rehash
at present.