Systemd "Path Images" Feature Allows Mounting Images At Arbitrary Paths

[Brane215]

Nothing, the new option is to configure a mount in a systemd service unit, not to replace the mount command

so how is it different than existing systemd-mount ?

[emerge-e-world]

My stance is that Poettering in fact has such undue power in Linux ecosystem. What he does with systemd does affect about 3/4 of the distros and he has proven himself (to me at least) as an asshole. You are free to disagree.

btw, he is employed by RH and it's his job. It'd be 'giving away' when he did it off his free time.

I disagree, yes. Sure lot of distros chose to distribute Poettering's software and that gives him more influence than say me. But that does not mean he has power over me like a dictatorial ruler or even just a superior. Me and you, we can chose to not use his software, patch it or fork it, and all the 'power' is gone. Sure, you have to pick your distro carefully if you don't like systemd and don't want to do it yourself, but then it is the 'power' of the people maintaining the distros. They as well give away their stuff for free, and they chose to include it because they found it useful, not because they were intimidated by Poettering. And you're free to use their distro as is or modify it, or not use is and opt for another. Sure, everybody who writes code or makes packaging decisions along those line has in some sense 'power'. In any case though, that is a very different from the power of a dictator, a boss, a superior etc. They can harm you, they can take things and freedoms from you. Most times you can't just walk away and make you're own state/company/whatever. A free software developer on the other hand can just refuse to give you what you want (for free).

And yes granted, you're right, he's paid by Red Hat, so that's different than someone contributing in their free time. Nevertheless, you and I, we don't pay for it and get it for free, so maybe we then should give the thank you to Red Hat as well.

[aht0]

I disagree, yes. Sure lot of distros chose to distribute Poettering's software and that gives him more influence than say me. But that does not mean he has power over me like a dictatorial ruler or even just a superior. Me and you, we can chose to not use his software, patch it or fork it, and all the 'power' is gone. Sure, you have to pick your distro carefully if you don't like systemd and don't want to do it yourself, but then it is the 'power' of the people maintaining the distros.

If it was that simple, I'd be pretty ambivalent about it. As "I don't use it, I don't care". Problem his, his influence is more subtle. By slowly causing disappearance of alternative system components (which generally tend to be portable, POSIX compatible etc..) and replacing these standard pieces of software with systemd monoculture - which, btw is strictly "Linux-only" - he specifially influences even software not using systemd and not in a good way. I'd be ambivalent about it even if he had designed systemd so that shimming it out was easy. He hasn't. Thus the title of "asshole" because it goes against the concept of "live and let live".

[emerge-e-world]

If it was that simple, I'd be pretty ambivalent about it. As "I don't use it, I don't care". Problem his, his influence is more subtle. By slowly causing disappearance of alternative system components (which generally tend to be portable, POSIX compatible etc..) and replacing these standard pieces of software with systemd monoculture - which, btw is strictly "Linux-only" - he specifially influences even software not using systemd and not in a good way. I'd be ambivalent about it even if he had designed systemd so that shimming it out was easy. He hasn't. Thus the title of "asshole" because it goes against the concept of "live and let live".

I see what you're alluding to, but my intepretation of what's going on is quite different.

Neither systemd nor poettering have undue power over other devs to not maintain legacy or alternative software or to improve upon it. The only power systemd devs have is to write their own software and be very convincing with what they have to offer. Maintaining sysvinit scripts across distros was a mess before systemd (and upstart) and the plumbing tool set was a hodge podge of some good, some barely maintained and some borderline abandoned tools, as well as some fragile glue, really tricky to even get to run reliably, that no one dared to touch too much. That has accumulated over decades and was hard to maintain or take forward without some serious rework. Systemd provided what a lot of maintainers and distros wanted: a consistent and easy to maintain replacement that works, and offers some long needed improvements. So they went with it.

On top of that, contrary to the narrative repeated ad neaseum online, systemd is very modular and actually has well defined interfaces, when external interfaces are concerned. A lot of the optional systemd-* daemons can be replaced/ignored. Someone just has to do the work to write or maintain those alternatives and do all the work necessary to keep that stuff working together properly – which is a lot of work, hence why systemd came about in this way in the first place. I really don't see how it is Poettering's job to do so.

And its not like there are no alternatives that work fine. Don't want to use systemd-resolved? use the good old resolv.conf, or run bind, dnsmasq, etc! Don't want to use the journal? use rsyslogd, syslog-ng whatever. Don't want to use systemd-timesyncd? use ntpdate/ntpd! Except for journald, neither of those tools are required if systemd is running as PID1 – and conversely, the existance of those tools don't make alternatives not work with openrc/sysvinit/etc anymore. What tool specifically disappeared because of systemd, that you'd like to retain? why is no one maintaining them?

Even some efforts to replace systemd specific stuff exist: For example, elogind did replicate systemd-logind's interfaces. And that was easily doable, because logind's interface is not that complicated. Or eudev forked udev, when its maintainer decided it was the proper way forward to merge it into systemd's tree. It was a decision by udev to merge with systemd, based on udev's devs/maintainers technical reasoning. But, low and behold, what happened? eudev was forked, because, well, one can fork free software and continue to maintain it, if you don't like what upstream does. Thats the freedom you get with free software, not just free of cost, but free to not be beholden by one upstream.

Some projects of course were dropped by their maintainers in favor of systemd. Not because of the undue influence of a devious cabal of poettering's minions, but because those maintainers also felt systemd was the proper path forward for their projects. If I remember correctly, polkit/consolekit and related *kit tools were such examples where the maintainer(s) decided to drop them, as they felt there was a better alternative to them now – or even wrote the systemd replacements themselves. They fixed issues those tools had, that were just not easily fixable in their previous design. That's also why projects like gnome switched to logind, as no alternative provided the features they wanted, and there was no one whom they could have asked for it, except systemd. That again, is a result of other people's decisions what to work on, not because systemd did anything specificaly to make it hard for them to continue with their projects independently.

The only reason why it may become harder to use some alternative tools on linux on the other hand is, that other projects and distros want to rely on systemd features, that they cannot get anywhere else (see the case of gnome/logind), or just plain simply don't see a reason why on earth they shouldn't use what works fine. They are not forced to do so by a central commitee of systemd. They make choices, and maybe just maybe they have good reasons to do so – that you of course are free to disagree with. But then you're issue is with those people.

If you or a group of devs decide to make their systemd-free distro, maintain or upstream patches and implement alternatives – nothing poettering can do about it. I don't know how well Devuan is doing, and how much concerned they are with doing more then ripping out systemd of debian. Honestly don't know, maybe they have more good stuff I don't know about. I do know though that for example gentoo works fine with openrc (though it has been a while since I migrated my last older server installations over to use systemd).

TL;DR: Poettering can't do shit to prevent anyone from writing or maintaining code, and neither would he have any reason to even try. He doesn't own the decision making process of distros, user space projects relying on systemd feature, nor alternative projects. He just provided a piece of software that had enough advantaged to convinced enough people to use it, instead of other tools. Maybe inside of Fedora he has somewhat more to say, but I don't think that's the issue. If there is a lack of such alternatives, the people who don't want to use systemd must provide them, not the systemd devs. If someone else bothers to implement alternatives/better tools for specific tasks systemd handles, there is no power poettering could yield to stop that, or would have any reason to even attempt to. And lots of those are indeed around anyway.

[emerge-e-world]

Oh and, I don't know much about the state of the different *BSDs and what problems exactly they are facing (are there other POSIX compatible free software OSes besides *BSD and HURD?), so I can't say much to that. I know that systemd as in PID1 itself is not easily portable, as it uses Linux-specific interfaces like cgroups and linux namespaces for reasons I find convincing, as they are useful for process management. Those are either non-existant on other platforms or implemented differently. Isn't that more of a problem that POSIX just is way to narrow in its scope for todays OSes, and the various kernel devs didn't bother to come up with some way to make compatible interfaces for new features?
But that can't be the issue, when the demand is for alternatives, not for porting systemd. What tools don't work anymore, or where abandoned because of systemd? why don't the communities of those other platforms maintain them? Do they not have enough manpower to do it if linux people aren't? Sure if that is so, that sucks. But are you asking poettering to do it? Why? Do you really want him involved? And is it really the fault of systemd, or isn't that more of a problem between the linux and *BSD communities, and how they do or do not work together? Isn't it the 'power' of the 'dominant linux culture' then that is to blame for that, not anything specific to systemd?

[aht0]

Oh and, I don't know much about the state of the different *BSDs and what problems exactly they are facing (are there other POSIX compatible free software OSes besides *BSD and HURD?), so I can't say much to that. I know that systemd as in PID1 itself is not easily portable, as it uses Linux-specific interfaces like cgroups and linux namespaces for reasons I find convincing, as they are useful for process management. Those are either non-existant on other platforms or implemented differently. Isn't that more of a problem that POSIX just is way to narrow in its scope for todays OSes, and the various kernel devs didn't bother to come up with some way to make compatible interfaces for new features?
But that can't be the issue, when the demand is for alternatives, not for porting systemd. What tools don't work anymore, or where abandoned because of systemd? why don't the communities of those other platforms maintain them? Do they not have enough manpower to do it if linux people aren't? Sure if that is so, that sucks. But are you asking poettering to do it? Why? Do you really want him involved? And is it really the fault of systemd, or isn't that more of a problem between the linux and *BSD communities, and how they do or do not work together? Isn't it the 'power' of the 'dominant linux culture' then that is to blame for that, not anything specific to systemd?

3rd party software that relies on systemd-provided interfaces is increasingly hard to port.

Resource management is there (for platforms I use at least) but implemented differently compared to Linux. Im glad for it too, cgroups v1 was very haphazard, v2 is more or less usable.

Just an easy example. Gnome3 is stuck on 2+ years old version on BSD. Because hard systemd-dependencies. Is it usable? Yeah, for now. In a few years, its ancient.

Even well-established non-commercial Linux distros have to pick and choose what to maintain because amount of devs is very finite. Non-Linux OS
es have very finite dev-force. When all the energy goes to working around issues created by just systemd (which by the way is also like chasing a tail because systemd itself is developed actively) - who's going to develop OS'es themselves?
Not to mention having to do other necessary porting, like maintaining graphics drivers - which at least Intel takes care of but AMD is dumping us Linux-specific sources you'll have to sort out for yourself when you are not on Linux. Good luck going through hundreds of kLoC of very specific code. OpenBSD doesn't even bother, some others have used Linux KPI-emulation.

Poettering involved? Poettering has expressed opinion that other Unix-like OS'es are better off dead.

[emerge-e-world]

Just an easy example. Gnome3 is stuck on 2+ years old version on BSD. Because hard systemd-dependencies. Is it usable? Yeah, for now. In a few years, its ancient.

Hm, interesting, I'm wondering what is holding that back. On Gentoo/Linux gnome 3.32 is supported without systemd by using elogind. 3.34 should be coming soon.

I was under the impression elogind already implemented those interfaces on BSD, but I may utterly misremember that, I didn't follow that very closely. Could just be not yet achieved goal someone formulated that I read somewhere.

But looks to me, if elogind can be made to run on BSD, it should be able to provide everything systemd related that gnome needs: The issue with gnome mostly come's down to systemd-logind functionality via its DBUS interface, for power management and user/permission management stuff, as well as user processes management (cgrouping etc) delegated to systemd, stuff like that. Basically functionality that previously was handled by polkit or wasn't there at all (e.g. process management). All of that is either supported or shimed by elogind, which provides the same DBUS interface (which is one of those external interfaces that is not subject to change at any time). Gnome itself ships with an option to allow compiling against elogind since 3.30 without manually patching its source, so everything is there for gnome without systemd, at least on linux.

So yes, writing stuff like elogind for multiple platforms is more work than nothing. But with newer software and new features eventually come new libraries and code that someone either has to port, or make the effort up front to write some cross-platform abstractions. Same with init systems or graphics drivers, as you mentioned. Beforehand someone had to maintain polkit as well, and port any new feature etc. Otherwise one can only stick with old versions. And looks to me there are people working on projects like elogind, or putting it all together, like gentoo. So I don't think cross platform compatibility is dying because of systemd. Its just not a stated goal of systemd itself.

It just shows that there already was a limited number of people caring for and working on it – granted Poettering certainly is not one of them –, and it shows especially when the dominant platform goes through some major changes all on its own. If Poettering said what you quoted, I disagree with him, I'd be sad if BSDs weren't around any more – but I can also see where he's coming from, when he'd say something like he's a linux guy, works for a linux company and spends his timing writing things for linux, that's what he cares about/gets paid for.

So overall, I think this is more a broader issue, regardless of whether we have systemd or not: some work would need to be put into porting in any case, whenever something new is written that offers new and useful stuff that many other projects want to use. Especially if those features are closely tied to something platform specific like cgroups, or say, for example, BSD jails. That is more of an issue between the respective communities overall, how to keep cross-platform interoperability alive. Probably more so for the smaller ones, as they suffer the most. Demanding more work from devs not interested in or working on other platforms would not be a reasonable approach for that though.