[ale] semi OT: systemd-homed

[Steve Litt]

On Fri, 01 May 2020 07:18:04 -0400
Jim Kinney <jim.kinney at gmail.com> wrote:

> On every laptop I've ever handed to a user with an encrypted hard
> drive it uses LUKS. The user selects a password for the unlock and
> the admin team has theirs. User forgets their password and admins can
> reset it. Remember, LUKS supports multiple key slots. Brilliant
> design. 

True. You're right. I had forgotten about multiple key slots, which
negate my argument, so I withdraw that argument.

> 
> In order to make sense of what systemd is and why it does things the
> way it does, it helps to see the the cloud processes as being the
> huge driving force behind the need to rethink the per process, per
> machine, and now per user instantiation process. 

OK, let's stipulate the preceding, temporarily disregarding the fact
that not every user needs "the cloud", wants the cloud, or even trusts
his data in the cloud.

Per process? That's always been there.

Per machine? Every machine has an init, so that's always been there.

Per user? Soon after the release of daemontools in 2001, djb
demonstrated how processes can be started, with daemontools, on a
per-user basis. Daemontools-inspired inits s6 and runit likewise can do
this. None of these softwares can *currently* meter or throttle cpu,
processes, ram or disk per user, machine or process, but I'm pretty
sure that would be an easy addition for whoever wants to scratch that
particular itch.

> Is it perfect? Nope.
> Not yet. But it works rather well. 

With a million dollars a year of Redhat salary to systemd developers, I
*hope* it would work rather well. Runit isn't maintained at all right
now, and it consistently works perfectly. s6 is maintained by one guy,
always works perfectly, and is continuing to add *meaningful* systemd
benefits. Let's compare systemd's 1.1 million lines of code with s6':

[slitt at mydesk s6]$ find . -name *.[ch] -exec cat {} + | wc -l
11738
[slitt at mydesk s6]$

11738 lines of code. That's about 8x less lines than systemd, and it
works perfectly, all the time. 8x less attack surface. 8x less
complexity, because it's a component that plays nicely with all other
Linux components, instead of subsuming other Linux components' actions
as a less-tested substitute.

> It's different so it's hard to
> wrap my head around it sometimes. Like firewalld. The thinking
> started making sense for me after using for a while. Learning curve
> was nearly vertical for a while. Worth it.

"Worth it" is an interesting concept. Water is worth $100/gallon. If I
had to, I'd pay $100/gallon for the water necessary to keep me alive.
So would anyone who could afford it. But you can buy a gallon of water
for $0.86 at the grocery store, so of course nobody would spend
$100/gallon.

Similarly, the benefits of systemd, as nice as they may be, could have
been obtained at much less cost: Cost of complexity, cost of failure to
interoperate, cost of non-modularity through entanglement via thick and
complex interfaces, and cost of telling users "my way or the highway",
which usually backfires on the proclaimer, eventually.

True story. A systemd advocate particularly skilled at repeating
talking points from Poettering's PID Eins responded to me telling me
that systemd bestowed the oh-so-necessary ability to respond to the
plugging in of a thumb drive in real time. He ended his reply quite
satisfied with his complete destruction of my central point. An hour
later, in another email, I presented an inotify based shellscript that
did exactly what he said systemd was needed for. Of course, for the
Poetteristic who consider the word "simple" an insult, I could have
written a C program that used the inotify library, but so many PID Eins
repeaters, so little time: I left it as a shellscript.

I use Vim. Others use Emacs. No harm, no foul, one can run either or
both. Imagine if one precluded the use of the other. THAT's the source
of the dissatisfaction with systemd.

SteveT

Steve Litt
March 2020 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb