Systemd 251-rc1 Released With Experimental systemd-sysupdate Tool

[Scellow]

Damn, i thought all the tin foil hat troll brigade had grown up and gone away

yeah, i wouldn't be surprised if you worked for microsoft, as clueless as red hat

[sinepgib]

Damn, i thought all the tin foil hat troll brigade had grown up and gone away

Well, they won't if we keep feeding them...

[khanich]

Can we name systemd at this point just straight up "system management suite" instead of naming every job it does individually?

[jacob]

Can we name systemd at this point just straight up "system management suite" instead of naming every job it does individually?

Nah, it's a good name. Rather they should just rename the service manager component "systemd-pid1" to put an end to the trolls' deliberate FUD.
Otherwise if you want to rename the whole thing then I think "Linux userland base" is a good description.

[mSparks]

LOL. How does supporting A/B updates increase the chance of a data breach? This is probably for projects like Red Hat Automotive, or did you think they planned to do a YOLO DNF upgrade on infotainment units in cars? This is useful in tons of places instead of rolling your own seamless updates like the Steamdeck had to.² Hell, this would be far better for low maintenance systems for elderly relatives. Reliable updates/boots are kind of important.

"automatic discovery and installation of a/b updates"
where a is malicious
and b is the non malicious version that is built from source.

Sounds like npm modules for root system init.

[Jabberwocky]

I do and am very satisfied with it. There is even a mention on its website that it could be the future of Fedora long-term.

This is really cool! I must have missed it.

Makes sense for that to happen, seems like a step in the right direction IMO.

[RahulSundaram]

"automatic discovery and installation of a/b updates"
where a is malicious
and b is the non malicious version that is built from source.

If you bothered to read the details at all, you would know that it is not possible to take a random malicious source and push that as an automatic update. Verity integrity data partition images are used here. If you don't know what that means, I would start with reading https://source.android.com/security/...boot/dm-verity. It is the same security mechanism used by millions of systems already.

[khanich]

Nah, it's a good name. Rather they should just rename the service manager component "systemd-pid1" to put an end to the trolls' deliberate FUD.
Otherwise if you want to rename the whole thing then I think "Linux userland base" is a good description.

I more meant Micheal's "init system and service manager".
It's a lot more than that and naming every single thing would be annoying.

[jacob]

This is really cool! I must have missed it.

Makes sense for that to happen, seems like a step in the right direction IMO.

I think so too. Immutable, atomically updated systems with rollback capability are the way to go. But what makes ostree and the systems based on it great IMO is that it manages to hit the sweet spot that gives you the best of both worlds. It has all the advantages of the immutable approach and yet it still lets you customise the installation, add your own packages and even patch and rebuild the shipped ones if you want to (like I do for Nautilus). The traditional A/B image-based approach comes annoyingly close to tivoisation for comfort. Even when it's possible in principle to create and deploy a custom image (and often it isn't, e.g. with Android), the procedure can be dauntingly complex and time consuming. With rpm-ostree it's no more difficult that building and installing an ordinary rpm on a classic fedora.

[mSparks]

If you bothered to read the details at all, you would know that it is not possible to take a random malicious source and push that as an automatic update. Verity integrity data partition images are used here. If you don't know what that means, I would start with reading https://source.android.com/security/...boot/dm-verity. It is the same security mechanism used by millions of systems already.

And if you had bothered paying any attention to any of the current "automatic discovery and install" tools, from upnp to windows update and solarwinds you would know they are a massive attack surface for pwnage.

Couple that with the dubious proficiency of systemd developers over the years and it screams "bad idea".

But then they went all in with A/B deployment, which is nothing if not a perfect method of masking a compromise.

Why all that risk? dont know, reasons I guess.