Devuan 1.0 RC2 Released: Systemd-Free Debian

[dungeon]

Considering all three of those DE's (I interchange all the UI stuff. Bad habit) USED to support 'other' systems, what happened? Is it really that hard to test against?

Statistically Debian Jessie have 43K packages and Devuan touches 387 so far... which is about 0.8%

[stiiixy]

Dungeon, that doesnt have anything to do with query regarding the dev's of each of the DEs testing against SysV, OpenRC, systemd, et al.

It's not a Devuan thing, either. It's, as was noted above, seingly a lack of regard to the open approach that was GNU and all aboard the systemd integration choochoowagon!

[rtfazeberdee]

Can someone post a link to where it says that these DEs actually depend on the "init" part of systemd? All i can find is that they use logind (because consolekit is no longer developed or maintained) and a few of the utilities in the systemd project

[Gusar]

Can someone post a link to where it says that these DEs actually depend on the "init" part of systemd? All i can find is that they use logind (because consolekit is no longer developed or maintained) and a few of the utilities in the systemd project

Yeah, but nothing that even remotely smells of systemd can ever touch Devuan. Which means elogind is out. And so Gnome, KDE and Cinnamon are out. But hey, init freedom!

[Karl Napf]

Yeah, but nothing that even remotely smells of systemd can ever touch Devuan. Which means elogind is out. And so Gnome, KDE and Cinnamon are out. But hey, init freedom!

Sorry, but you are misrepresenting Devuan here: They have no problem with systemd technology, otherwise they would not use systemd-udev.

[DrYak]

I'm not so sure that a replacement for init is the right place for this functionality... I seriously hope the eyebrow raising over by a desktop environment having a dependency relationship this pronounced with an init system isn't lost on you.

You might have forgotten, but beside the init system itself (the systemd daemon running at PID 1), there are a few other things that are maintained by the systemd crew (sometimes because there's no one else volunteering to make the maintenance - like consolekit - sometime because systemd crew wants to be able to provide all the piece for a minimalistic system - hence stuff like ntp and dhcp clients).

They also maintain stuff like logind, which handles things like session management, seats management, sharding into cgroups, etc.
And *THAT* is the part of system that Gnome, KDE and co depend on.
Modern distro definitely need some way to manage this kind of facilities, and the classic sysvinit and its assorted bash script don't provide anything along this lines.
(Also sometime, some DE might need to start/stop some background daemons, and might actually interract with also the init part of systemd. But that's a weak dependency. Any init system will do)

But don't those desktop environments work on *BSDs with no systemd? They should work just like that on Devuan too.

I would strongly suspect that on BSD, these desktop environment are using whatever local facility fill the same role as the systemd-logind daemon (the same way as launchd is their modern init system) ?

[bitman]

I'm not so sure that a replacement for init is the right place for this functionality... I seriously hope the eyebrow raising over by a desktop environment having a dependency relationship this pronounced with an init system isn't lost on you.

However I guess this is proof that we truly are moving towards the horror scenario where GNU/Linux becomes SystemD/Linux and where SystemD slowly replaces or just absorbs the whole operating system...

Whatever gets linux desktop out of stone age - more of that please.

[starshipeleven]

I'm not so sure that a replacement for init is the right place for this functionality... I seriously hope the eyebrow raising over by a desktop environment having a dependency relationship this pronounced with an init system isn't lost on you.

However I guess this is proof that we truly are moving towards the horror scenario where GNU/Linux becomes SystemD/Linux and where SystemD slowly replaces or just absorbs the whole operating system...

Since when logind or udev became part of the init system, again?

They are just maintained by the same people of SyStEmD, and in the case of udev it's also the only ones that actually cared about it.

[starshipeleven]

Can someone post a link to where it says that these DEs actually depend on the "init" part of systemd? All i can find is that they use logind (because consolekit is no longer developed or maintained) and a few of the utilities in the systemd project

don't worry, it's still the same case of stupid people not understanding that there is a Systemd project containing various stuff that isn't part of the init system.

It's like saying that all GNU stuff is Hurd.

[Gusar]

Sorry, but you are misrepresenting Devuan here: They have no problem with systemd technology, otherwise they would not use systemd-udev.

Oh, please. If what you say was true, they wouldn't be making a big stink about procps linking to libsystemd so that top can show some additional info if systemd is PID1 but works just fine with other inits (minus the additional info of course, I think it's about showing which cgroup a process belongs to). But they are making a big stink out of it and any other instance of linking to libsystemd for optional additional functionality. Because libsystemd has cooties, so it must be purged from the system, even though it does pretty much nothing if systemd isn't PID1. All this does is increase the maintenance burden, because they're busy recompiling all these packages without libsystemd, instead of simply importing them from Debian.

You only need to skim their mailing list to see such stuff. They only begrudgingly tolerate udev because there's no alternative. vdev looked promising, but its dev is busy with real life(tm) stuff, so there hasn't been development activity lately.