[GTALUG] video: Benno Rice on "The Tragedy of systed"

[Christopher Browne]

On Fri, 8 Feb 2019 at 16:18, o1bigtenor via talk <talk at gtalug.org> wrote:
> I appreciated this talk a lot. Made my wife sit through it to grin!
> He showed what was good AND what was bad about it and also
> lightly poked at the less than positive way it was introduced. What
> was impressive was that he could use humor in most interesting
> ways and yet wasn't denigrative in the process. Helped me to
> 'understand' things a bit better although I still am not clear on
> whether to move further into systemd or not.

The other interesting thing I recently watched that was rather
interesting was the following...

Is It Time to Rewrite the Operating System in Rust?
https://www.infoq.com/presentations/os-rust

His eventual thesis was that while there are interesting things about
this, there's too much already vested/invested in drivers and such for
it to be terribly worthwhile.

He observed that the notion that gave him "cold sweats" was the
thought of having to rewrite ZFS (he's a Solaris developer at whatever
Joyent is now) in Rust.

He points at 4 concepts, of which 3 would make sense:

1.  One could rewrite the OS in Rust, but that is an extraordinarily
large project

2.  It might be attractive to add some hooks so that *new* modules
that get added in are written in Rust.  I'm using Remacs these days,
which is gradually, function by function, getting rewritten into Rust.
Ooh, "git pull"; apparently (reverse) got implemented today.  Perhaps
the *next* nifty new filesystem would have improved type safety and
such.

3.  Reimplement parts of user space.  The conspicuous relevant
observation made in the talk was that he wouldn't have done SystemD in
C, but rather in Rust.  (Perhaps he might reimplement SMF in Rust;
that's the Solaris thing...)  Reimplementing individual services that
run in user space isn't nearly as scary as #1.  Doing one command at a
time shouldn't scare us too much; I don't care too much what language
is used to implement /usr/bin/cat

4.  Reimplement firmware.  Which is a surprisingly scary area that we
don't play with terribly much.  I reboot systems sufficiently rarely
that this perhaps oughtn't be valuable to me; improving firmware is
nevertheless a thing, and I'm a bit scared of what's out there.

> When it comes to containers - - - well I got royally burned by them suckers
> about a year ago so whilst I think that they're a great idea the implementation
> needs to be different than lxd before I'm going to touch the idea again.
> (LXD itself isn't the largest part of the problem. Its LXD has chosen to
> rely upon snapd and both have embraced the concept of the programmer
> knowing everything and the users being idiots that don't know how to
> keep a system up to date. If I had the skills I would be working on forking
> LXD - - - its a great idea.)

What "blandly" scares me about containers is that they might represent
a way of bundling up our 2038 bugs and preserving them until they
cause the world to cascade down in burning ashes in 2038.

I'm definitely a bit scared at the notion that containers let us keep
"bad old stuff" around in pretty bad ways.  Every time I see an error
message like the following one, I worry about containerization...
-----------------------------------------------------
Deprecated Gradle features were used in this build, making it
incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.0-rc-3/userguide/command_line_interface.html#sec:command_line_warnings
-----------------------------------------------------

That Gradle complaint obviously isn't actually about a
containerization problem; it's a low grade compatibility problem (that
I don't understand, because I really don't know Gradle, a Java-based
build tool very intimately).

Nobody has any incentive to fix whatever the problem is, and
"container world" seems to be pretty rife with "oh, there was a little
problem that we'll just ignore because it doesn't much matter today."

The notion in "Dockerworld" of having minimal containers where you
don't have a lot of extra crap that you're packing into the containers
is appealing, but I'm not sure how under control this is.

What does it mean to "keep system up to date?"  There's just enough
philosophical oddness to that that I'm left sufficiently off-put by it
all.

In a containerized world, I'll bet SystemD isn't the best application
for managing things, because it's rather centred on being process 1,
and a horde of containers has a horde of process 1's.  You need a
distributed service manager, and I'm not sure we have that just yet.
There's *lots* of interesting research to be done in that area, no
doubt!
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"