And as with almost all systemd features it can be easily disabled and prevented from ever being used with

# systemctl mask systemd-sysext.service

Or by using this command on the system image so it isn't ever loaded at all:

# ln -s /dev/null /etc/systemd/system/systemd-sysext.service

EDIT: from my Arch system:

% apropos systemd|grep update
systemd-system-update-generator (8) - Generator for redirecting boot to offline update mode
systemd-update-done (8) - Mark /etc/ and /var/ fully updated
systemd-update-done.service (8) - Mark /etc/ and /var/ fully updated
systemd-update-utmp (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp-runlevel.service (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp.service (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd.offline-updates (7) - Implementation of offline updates in systemd
%

It only allows for extensions to /usr & /opt (at the moment) so any "forced updates" could only be applied to those directories, which would limit them to themes, fonts & icon sets. Anyway the paradigm is intended to be used with immutable system images, which would preclude permanent upgrades.

Thanks for the clarification
Although, as Steve_v implies, that could all change, right?

I can't help thinking it is a container system that can be implemented on a users system against their wishes
a bit like how windows updates are forced on people
Have I got hold of the wrong end of the stick on this?
Am I wrong?

It only allows for extensions to /usr & /opt (at the moment) so any "forced updates" could only be applied to those directories, which would limit them to themes, fonts & icon sets. Anyway the paradigm is intended to be used with immutable system images, which would preclude permanent upgrades.

back in 2000 i was working at dhl using wyse terminals.

Back in 2000 I had rather more free time than I do now. I was also recovering from a very traumatic experience with RPM dependency hell and exploring a custom package management solution for LFS. Sadly that one was lost to the sands of time along with the hardware.

I doubt it. The truth will reveal itself soon enough, but it sure looks like a container system to me.

Hello:

a feature called system extension images, designed to allow system files to be added, or appear to be added, even on read-only file systems.

I read about this and, although the systemd people themselves say, "Don't think of this as a flatpack system orcontainer system"
I can't help thinking it is a container system that can be implemented on a users system against their wishes
a bit like how windows updates are forced on people
Have I got hold of the wrong end of the stick on this?
Am I wrong?

dice wrote:

Ive only just discovered "immutable operating systems"

I was doing this sort of thing back in ~2000, when you could fit an entire GNU/Linux OS on a 1.44MB floppy disk. It's doesn't need to be complicated, it doesn't need containers, and it sure doesn't need systemd.
Of course you could do it with systemd + containers + whatever other bloated over-engineered garbage the shareholders are into at any given moment, but then you end up with something that's non-POSIX, non-portable, not even remotely Unix-like, and can't be reasoned about by a human sysadmin without 10 layers of abstraction and 30 management utilities... Not real surprising that's the approach the systemd devs are pushing, is it?

Then again. it could be a prank. If it is, it's a good one, because this is exactly the kind of "feature" I expect from the developers involved.

Right, back in 2000 i was working at dhl using wyse terminals.

it could be a prank

No, it's real. I'm using v248 of systemd in my Arch box.

For fuck's sake, does the shit never stop flowing?

Apparently not. At least not where corporate agendas are concerned, and shit always flows downhill.

By which we mean embedded systems integrators, which along with IBM, Microsoft, and the US military, is where the bulk of Redhat's funding is coming from at the moment.

I was doing this sort of thing back in ~2000, when you could fit an entire GNU/Linux OS on a 1.44MB floppy disk. It's doesn't need to be complicated, it doesn't need containers, and it sure doesn't need systemd.
Of course you could do it with systemd + containers + whatever other bloated over-engineered garbage the shareholders are into at any given moment, but then you end up with something that's non-POSIX, non-portable, not even remotely Unix-like, and can't be reasoned about by a human sysadmin without 10 layers of abstraction and 30 management utilities... Not real surprising that's the approach the systemd devs are pushing, is it?

Then again. it could be a prank. If it is, it's a good one, because this is exactly the kind of "feature" I expect from the developers involved.

% systemd-sysext status
HIERARCHY EXTENSIONS SINCE
/opt      none       -    
/usr      none       -    
%

Anyway stateless systems are a good idea IMO. Feel free to throw stuff at me

With the obvious proviso that your opinion with respect to this has much more weight that mine, I just see it as yet another one of systemd tentacles.
Reminds me so much of the MS registry.

Thanks for your input.

Best,

A.

I know that it's 01/04 today (at least here) but ...

https://www.theregister.com/2021/04/01/systemd_248/

For fuck's sake, does the shit never stop flowing?

Best,

A.