OpenBSD 6.5-release ports seems to have the same version of gnome and gdm as Debian unstable (3.3x ?). There is of course no systemd - but also no forking of bits of systemd going on. I have no idea who uses gnome (or KDE for that matter) in OpenBSD, I'd imagine it would be a tiny minority of users as it hardly gets mentioned on the ports mailing lists.

I'm not sure of the specifics, but it's likely that the port maintainers, decided they didn't need any of this kind of functionality:

https://www.freedesktop.org/software...d.service.html

Personally I think all the "systemd emulation" and workarounds is just the proverbial slippery slope and very self defeating...

gnome project are very much invested in systemd and Red Hat, so it makes more sense to just ditch both systemd and gnome and find alternatives. But based on the above example and with the likes of FreeBSD, I wonder just how hard this "hard dependency" really is.

1 members found this post helpful.

Well, if there is no systemd emulation (daemon??) in another init system, there will be issues with poorly written software which depend on (unnecessary) bits (software) swallowed up or created by systemd and included in their blob.

I think this issue will only become worse in the future as more software will choose the easy way and make unnecessary dependencies. It is a somewhat familiar issue in the GNU/Linux world already and I think has been explained in many different ways in the "dependency hell" thread.

https://www.linuxquestions.org/quest...ke-4175637215/

You have two issues there:

1) The unnecessary dependencies
2) The nasty hacks and workarounds and forked bits of systemd to work around those

Both of those equally contribute to increased exposure / proliferation / market penetration for systemd.

This is the "problem" that has to be solved, thus systemfree.

What a silly remark. Seriously. It is only not one by virtue of the fact of Red Hat forcing the issue and people like yourself making ridiculous remarks like this. It is there. It works. If both are there, then it's a potential alternative to it all. Same goes for runit (In the interests of clarity, honesty, etc. I will own I am the lead maintainer of the currently openly maintained fork of runit and the meta-runit OpenEmbedded metadata layer that enables runit services as init and logging for any Yocto/Angstrom/etc. system. Things in use by a well-known Fortune 500 company right now.) and anything else out there. It's not an alternative if it doesn't work or doesn't exist. Popularity or lack thereof doesn't make for something NOT being an alternative.

Well, there's a reasonable thing instead. Funny that you should mention this. There's already a lot of those things out there. udev is being provided by eudev in my day-job's distribution and MY own personal one. We use runit for init. There's some other options for the others. What we all need to be talking about is going the Unix/Linux original philosophy and being strong in this regard. One can take runit, Open-RC, s6 or some other init/supervision system as the core. Make it interchangeable- not everything or everyone is going to be served there; inasmuch as I'd love to see people take on runit in this role, that'd be a bit more than arrogant on my part to insist. Make sure it does, generally, one thing and one thing- and does it well. Move on from there. And, no, you CAN move away from things. It should be solidly noted that my embedded distros use E22 right now- no systemd. PERIOD. That should be your first hint on things that it's not QUITE as you're seeing it.

Trying to make, "SystemFree," be the discussion is not the right idea here. You already have about a half-dozen answers in the, "SystemFree," space, already- you're just discounting a lot of them because they're not relevant in your eyes because, "almost nobody is using them," which is a, while your heart's in the right place, you're barking up completely the wrong tree there. The real discussion here should be one of can we leverage one of the other init/supervision systems realistically and cleanly- and can we grab stuff that works or used to work and move them forward like I, and others, did with runit, socklogd, and a few others? If so, what needs to be filled and how?

1 members found this post helpful.

Does it provide a solution for systemd-dbus? If so, yes, this is likely to be a good answer. If not...it needs to provide one or someone needs to in order to backfill a few failings in the space to provide an alternative solution.

That's because it's Red Hat's solutions to getting people to pay them money in the Enterprise space.

As for providing, "emulation," this is a waste of time. If you can peel off a few select pieces of functionality that they've oddly welded onto systemd, I think you could be free of it.

@zeebra

Right now, the Embedded Linux distributions I'm responsible for producing are systemd free and by willful design. I am the lead maintainer on the current actively maintained fork of runit and for the OpenEmbedded meta-runit layer that welds runit support as a first class citizen into Yocto/Angstrom/etc. No systemd. Security risk in a device that needs to ensure chain of evidence on it. Security risk for LEO, Defense, etc. products. Major one. Too many attack faces to even keep track of.

The list we're using -

init : runit
udev : eudev
dhcp : connman
dns config : connman
sound : ALSA (Pulse is another set of exposed attack faces...)
syslog : socklogd
klog : nanoklogd
Desktop when appropriate: Enlightenment 22 (Disproves the comment about E being tied to systemd, now doesn't it?)

What else does one need? That was asked as a serious question. It leads to figuring out where it needs to have drop-ins, etc. For example, there's a lot of good stuff that's working off of systemd-dbus, where a replacement or a rip-out made standalone, would be helpful as it's probably one of the "cleaner" reimplementations of dbus support.

If you think you need a new init just because of it, "not being used by anyone," that's fine. I'm mindful of the XKCD cartoon...

https://xkcd.com/927/

Do we need yet another, "not used by anyone," init- or should we grab one that makes sense and run with it...? I did. You can too. If none of them make for what you had in mind, then it sort-of makes sense to go where you're all plugging. I'd rather you and everyone else spent time finding out how we can decouple stuff from that travesty of code that calls itself systemd. If a new init is called for past the good ones already available and provably so for a LONG time now, then so be it. But I don't think you honestly looked at all of them- it doesn't sound like it from your defense of the position.

3 members found this post helpful.

@madscientist42, can you please provide a list of links of the projects you are talking about, those that you're involved in?

It's not a silly remark, it is a real remark. A simple init is no longer a replacement for systemd and with time it will get even worse. OpenRC with their elogind and eudev just speaks to that.

I like openrc, even more knowing Gentoo do what they must to adapt replacement software for systemd, like elogind and eudev. This cannot be underestimated. But openrc in itself is not a replacement for systemd, this is the whole problem.

First of all, good and interesting post, thank you.

Actually this was in reference to their own specifications on their own website. They list systemd under "dependencies":
https://www.enlightenment.org/download

I didn't check or verify it beyond that. I just assumed they would put correct info on their own website, especially about something that important.

The problem is not so much with the alternatives as with systemd itself and it's viral spread and behaviour. You can't just rip systemd out of whatever distro and replace it with sysv or something else. For me this is the main problem. If you can't do that, why would any distro care to choose another "init" than systemd? And this is the bad downward spiral.

Let's say systemd = init+systemsoftware+random software to simplify it. We need a generally available replacement for that "systemsoftware" to get any of the inits to work as a replacement for systemd. I know embedded is different, and you know that too, but I respect you for bringing it up and I'm not going to lecture you on anything, but when end user software (let's call it "desktop software") starts to depend on the "systemsoftware" part of systemd, you simply cannot just replace the init.

I'm not an OS genious or software engineer or programmer, but I'm pretty sure about this situation being problematic. My viewport of this situation is more from a philosophical and pragmatic understanding. What choice do the distroes have now? I know they have choice, but that choice is becoming worse and worse due to the way systemd works, and it may become even worse in the future.
I'm not a fortune cookie, but this issue is now becoming so big that it has to be addressed. Sure replacing systemd with any init manager is possible, but realistically, what pragmatic mind would do that with the current alternatives? Systemd is even making those alternatives slowly obsolete, which would be status critical.

Those who HAVE chosen the non-systemd approach need to put in significant effort, either in making a scratch distro or maintaining a generic distro without systemd. This effort need in my mind to be more unified and a community effort. This was kind of the point of systemfree. Something needs to be done, not just by a few, but together, an organized alternative to systemd, which ensures systemd does not make other inits obsolete.

I guess you could say the critical point is the "systemsoftware" part of systemd, more so than writing an optimal init, but then again, there are some murmurs against how sysv works as well.

I don't know what my point is exactly, but I'll nonetheless leave it to you to decipher it from what I've written.

I think the point Zeebra is trying to make is that alternative inits, however popular at the moment, will eventually stop working if application software isn't made init-agnostic as it used to be. It shouldn't be the job of e.g. cups to know or care whether you used systemd to start up the computer. But it does care. It expects daemons of the systemd family to be running and goes on strike if they aren't. There seem to be only two ways around this (apart from capitulation):

1) Patch all the programs to avoid systemd-dependency. This is the approach of AntiX. It has a separate repository with systemd-free versions of those packages that require systemd in their upstream versions. But that's a losing battle and requires a lot of work.

2) Write a permanent set of shims that provide the information the programs require, for example by reading it out of the normal system configuration files. The programs will then run happily and you can use whatever init system you like.

1 members found this post helpful.

Wholeheartedly agree. I don't know enough to say which if any system is better. But when the whole world moves in a direction, a few people won't sway it. Face it, most people could care less. There have been plenty of movements in the last few decades to stop some changes in our day to day lives. None of them worked. They fizzled out because it just becomes to hard and not enough people care about them. I'm not saying roll over. I'm saying there are better things to do with your time than waste it on a frivolous pursuit that will end up crashing and burning.

I dislike how people blame Red Hat as well. Systemd must have it's merits. Red Hat didn't force Debian, or anyone else to use it. They moved to it on their own. It's safe to say that the majority of users haven't got a clue about anything other than reading a few websites occasionally. Unless we have read the code and found the possibilities with Systemd then we have no right to say yea or nay either way.

I think people are just afraid of change in general. The *nix ecosystem is changing whether you like it or not. There will be efforts to maintain the status quo, but they will all fail. Without the support of the major players, it is all for naught.

See what you can accomplish instead of whining about the way it used to be is a better philosophy. Your other option is to fork stuff and maintain it, but it will become more work than anyone is willing to do.

2 members found this post helpful.

Exactly.