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

[o1bigtenor]

On Fri, Feb 8, 2019 at 4:35 PM Christopher Browne via talk
<talk at gtalug.org> wrote:
>
> 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."

There's that and then there's the 'our software doesn't have any bugs'
thinking which when on a forced updating program means when there is
one - - - EVERYTHING goes for !@#$%^!
>
> 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.

Well to Canonical it means that you will be updating your system at
least every month - - - their preference is every day but you can back
it off to once a month. If you try to shut that 'feature' off - - - - life does
get interesting (which is why I want nothing to do with it as a result!).
>
> 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!

There are few people who seem to be looking at the 'big picture' and
trying to map out ways and means to move forward. Means that there
is much duplication of effort and needed backtracking too bad!
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"

A 56 cal rifle shot? (LOL)

Dee