Re: If Not Systemd, then What?
On Tue, Oct 21, 2014 at 02:46:46AM -0400, Steve Litt wrote:
> On Tue, 21 Oct 2014 08:12:17 +0200
> Ludovic Meyer <ludo.v.meyer@gmail.com> wrote:
>
> > On Mon, Oct 20, 2014 at 09:34:48PM -0400, Steve Litt wrote:
> > > On Mon, 20 Oct 2014 12:45:11 -0700
> > > Patrick Bartek <nemommxiv@gmail.com> wrote:
> > >
> > > > 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
> 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.
> >
> > 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
> >
> > > * 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.
> >
> > > * 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
> > > > 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.
> > > 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.
--
l.
Reply to: