Re: Micro-report: using Stable without systemd
On Wednesday 17 October 2018 04:11:00 tomas@tuxteam.de wrote:
> On Tue, Oct 16, 2018 at 05:28:04PM -0400, Gene Heskett wrote:
>
> [...]
>
> > The point is that no one from the systemd camp has, to my knowledge,
> > posted a list of things it can do better than sysvinit. Point out
> > sysvinit's warts, and what systemd does to excise the ugly stuff.
>
> Now this is unfair. There *has* been a lot of discussion, by both
> sides. Lennart Poettering himself (you /may/ like his ways or you
> may dislike them) has gone out of his way to explain how the whole
> thing works.
>
> Off the top of may head, what systemd has to offer over
> (out-of-the-box) sysvinit:
>
> - process supervision: when a daemon is started by sysvinit,
> it (typically) plonks its PID in some pid file. sysvinit
> forgets about it. If the proc dies, it's up to you to do
> something about it (there are "third-party" process supervisors
> like runit, or you can just bricolage your own, a thing I've
> done myself some times).
>
> This actually brings something back we (those old enough who
> weren't wasting their time back then with Norton Commander ;-)
Norton Commander? Heard of it, never used it, never had a dos or windows
box of my own. I went from trs-80 color computers running the unix-like
os9, to amigados, to linux, and have never missed amigados's lack of a
memory management. I recall the early days when CED would scribble all
over memory it didn't own so you were looking at the guru entirely too
often. That finally got fixed but it took years.
> used to have with /etc/rc style booting. Those still showing
> some Pavlovian kind of salivation at the sight of "getty"
> and "respawn" will know what I mean
>
> - socket-based activation: systemd listens on IPC or network
> sockets, and whenever a "client" knocks on them, it starts
> the service supposed to be serving this socket: i.e. whenever
> someone tries to contact the PosrgreSQL database at port
> 5432, the database is started.
>
> This takes a lot of manual work usually done to sort the
> starting order of services, because they "sort themselves",
> based on who needs whom.
>
> This will remind some of us of (x)inetd. It is similar, but
> not the same
And amanda, being very old school, is still managed by it.
>
> - Init configuration is expressed in a more declarative way
> ("what" you want to achieve) instead of the traditional
> imperative way ("how" you get there), which is deemed to
> be more robust wrt. change.
>
> Now there are counter-arguments to all of that, and on my balance
> they dominate (that's why I stick with sysvinit), but saying that
> "no one from the systemd camp has ... posted a list of things ..."
> is highly unfair. Look again.
Where?
> You ask where? My go-to site for fundamental knowledge is lwn.net.
> A (hpoefully *not* Google) network search "systemd site:lwn.net"
> yields, among other things, those gems:
Not an lwn subscriber. I mean publically available sites. lwn is not.
> Systemd programming part 1: modularity and configuration
> https://lwn.net/Articles/584175/
>
By golly, the embargo has expired, so the public can access them. I WILL
read them when I have working eyes again.
> Systemd programming part 2: activation and language issues
> https://lwn.net/Articles/587385/
>
> Enjoy. And apologize to the systemd proponents ;-)
We'll see, after I have absorbed what lwn has to offer. I've never been
bashfull about that when I find I'm wrong.
>
> (And all of this from a systemd opponent. Sheesh.)
That figures, Tomas, many thanks.
> Cheers
> -- tomás
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: