[svlug] Desktop software and systems management

Rick Moen rick at svlug.org
Thu Nov 20 13:28:28 PST 2014


Steve Litt wrote:

> As a first class anti-systemd ranter and one of the first and most verbal
> members of modular-debian, allow me to offer an alternative
> characterization in describing modular-debian. I wouldn't call it in any
> way ranty. What we're doing on modular-debian is constructive, not
> destructive.

Yeah, fair cop.  It's a mailing list that includes ranters (which is
more-or-less what I said), not one primarily about ranting.  And, for the
lazy, URLs: 

http://www.freelists.org/list/modular-debian  (info and signup)
http://www.freelists.org/archive/modular-debian/ (direct link to Web archive)


I should also hasten to say that there are probably any number of half-assed 
statements and outright (minor, I hope) errors in my long screed.  If I
intended to nitpick-proof that posting so that it could not be derailed 
by basically bullshit objections, I'd have spent a lot more time researching
and checking every little thing.  At a glance, I see one small blunder (an
edit error), for example:  

  The Freedesktop.org people branched out to create D-Bus, a general
  messaging bus feature inside the Linux kernel, usable as yet another 
  novel (and opaque) way to do interprocess communication [...]

Well, no, D-Bus isn't in the kernel.  A compatible replacement, kdbus, is 
being developed that, if accepted, _would_ be in the kernel.
https://lwn.net/Articles/580194/


> He may be right about the init part of systemd being good
> (I have no way of knowing).

I _think_ so, judging by comments in various places and some very telling
comments by the architect of the uselessd fork.  Again, some URLs might be
in order:  

http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
http://uselessd.darknedgy.net/

Note the characterisation:  'a project to reduce systemd to a base initd,
process supervisor and transactional dependency system, while minimizing
intrusiveness and isolationism. Basically, it’s systemd with the
superfluous stuff cut out, a (relatively) coherent idea of what it wants to
be, support for non-glibc platforms and an approach that aims to minimize
complicated design.'

I like the way this guy thinks.  In fact, there's gold all throughout that 
front page.

I'm not sure I need a process supervisor built into the init.  As the author
points out, there are plenty of good process supervisors ('daemontools, runit
and s6' being listed there), nor am I all that thrilled about socket
activation, being fonder of the 'run this daemon because the sysadmin said
so' model.  But I'm willing to consider the advantages.






More information about the svlug mailing list