Systemd 251-rc1 Released With Experimental systemd-sysupdate Tool

[RahulSundaram]

It seems optional

Nope, it doesn't merely seem optional. It is optional. No other technical claim here.

[mSparks]

Nope, it doesn't merely seem optional. It is optional. No other technical claim here.

Now you have just confused me.
Is updating systemd optional or not?

[RahulSundaram]

Now you have just confused me.

You are just very confused about everything on this topic and talking in circles at this point. All the best

[mSparks]

You are just very confused about everything on this topic and talking in circles at this point. All the best

I said this seems like a bad idea, not touching it with a bargepole

You said not using it would leave known vulnerabilities on the system.

I said that isnt a reason to switch to remote code execution by design (the real name for auto discover auto install)

You hand waved about android (a decent non systemd alternative)

Then said its ok cos making a bad idea optional makes it a good idea.

Pretty sure its just you confused about how to spin a feature no one wants or needs and is harmful by design.

Im just confused over whether you will decide it is or isnt optional in your next post (and why you think that is a justification for making a linux install more worm friendly)

[Jabberwocky]

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.

You have summarized it much better than I would.

Another advantage would be to start from the same abstract base between different environments (e.g. desktop-AMD64 and desktop-ALT_ARCH). You can package additional drivers for the specific environment as an extension. You can also share prebuilt packages or even stages between different environments (e.g. desktop and cloud). Many Distros quickly hack up a build script that builds env/arch X and that script evolves overtime to add a package or rename a config etc. The script sometimes doesn't even see the light of day and lives on a random Jenkins server. This it causes a lot of frustration for people wanting to support the different environments but don't know what the difference is until they actively start supporting it.

I want to see people make a windows style "safe mode" but better using the rollback capability, but instead of just rolling back you can boot into an recovery mode and from there decide where you want to go to or maybe just tweak some configurations in later boot stages/layers. You should also have the option to just "factory reset" the system. There's so much potential to save people's time reinstalling and maintaining systems.

Off-topic: This is the only feature that I miss from OS/X days to reduce personal system downtime. The OS isn't an option for me after Apple refuses to acknowledge security issues e,g, https://twitter.com/patrickwardle/st...37929497235457 and https://ironpeak.be/blog/crouching-t2-hidden-danger/

[sinepgib]

You have summarized it much better than I would.

Another advantage would be to start from the same abstract base between different environments (e.g. desktop-AMD64 and desktop-ALT_ARCH). You can package additional drivers for the specific environment as an extension. You can also share prebuilt packages or even stages between different environments (e.g. desktop and cloud). Many Distros quickly hack up a build script that builds env/arch X and that script evolves overtime to add a package or rename a config etc. The script sometimes doesn't even see the light of day and lives on a random Jenkins server. This it causes a lot of frustration for people wanting to support the different environments but don't know what the difference is until they actively start supporting it.

I want to see people make a windows style "safe mode" but better using the rollback capability, but instead of just rolling back you can boot into an recovery mode and from there decide where you want to go to or maybe just tweak some configurations in later boot stages/layers. You should also have the option to just "factory reset" the system. There's so much potential to save people's time reinstalling and maintaining systems.

Off-topic: This is the only feature that I miss from OS/X days to reduce personal system downtime. The OS isn't an option for me after Apple refuses to acknowledge security issues e,g, https://twitter.com/patrickwardle/st...37929497235457 and https://ironpeak.be/blog/crouching-t2-hidden-danger/

So, let's say there's a way to make a buildroot distro run over any of these techs. Does that mean that I can do something like have several different ARMv7 devices sharing userspace and easily keep a different kernel for each?

[Jaxad0127]

You said not using it would leave known vulnerabilities on the system.

No, they said not upgrading systemd, which you promised to do, would leave you vulnerable.

[mSparks]

No, they said not upgrading systemd, which you promised to do, would leave you vulnerable.

From the OP

A new component "systemd-sysupdate" has been added that automatically discovers / downloads / installs A/B style updates for the host installation itself or container images / portable service images.

[Jaxad0127]

From the two of you:

Thanks for the offer but I think I'll just stick with a version of systemd that doesn't have this "feature" then laugh at you when I'm inevitably proved right.

So you failed to prove the issue or even coherently explain the threat model as expected and your plan is to stick with an older unmaintained version which will have known security vulnerabilities in order to avoid an entirely optional feature in a new version?

[Jabberwocky]

So, let's say there's a way to make a buildroot distro run over any of these techs. Does that mean that I can do something like have several different ARMv7 devices sharing userspace and easily keep a different kernel for each?

You can make that work, but there's probably other tools that might make it easier to maintain than this theoretical feature. The advantage, the way that I see it, is to target the opposite scenario. For example distributing the same kernel* but very different userland configurations. Think of merging the maintenance burden of mini/server/desktop/containers userland-configurations and at the same time giving people an easy way to extend every one of the configurations that are provided. I'm sorry if I'm doing a poor job of explaining it. I don't have much time at the moment.

*I know this sounds contradictory to what I said in previous posts, but there's a fine line between kernel drivers or modules and the kernel itself.