On Fri, 8 Feb 2019 at 16:18, o1bigtenor via talk <talk@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?" --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk