Debian Buster release to partially drop non-systemd support

golinux · 2018-10-15 18:20:49

Also posting this news here to keep all Devuan users in the loop. Solutions are being discussed . . .

Many of us knew this day would come. The lock-in is nearly complete.

Holger Levsen Sat, 13 Oct 2018 04:15:19 -0700
On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
> > Has policy changed regarding support for multiple inits, or is it just that
> > no one is maintaining the shim and sysvinit-core?
>
> The latter. systemd-shim has been orphaned for over 2 years, and has
> RC bugs. sysvinit currently has two maintainers, but they've only
> ever made one upload (over a year ago).
It seems that these facts are either largely ignored or unknown and I
wonder if some noise should be made so that interested people can pick
up the work now and not only complain later.

Source: https://www.mail-archive.com/debian-dev … 55832.html

As Christopher Barry said in his Aug 12 2014 Open letter to the Linux World:

OneLinux == zero-choice

dxrobertson · 2018-10-16 00:22:45

Source: https://www.mail-archive.com/debian-dev … 55832.html

I read most all the posted thread and find it an "interesting" discussion.

What does this really mean for Devuan? I imagine it means that Devuan would have to not only support sysvinit itself, but every package that requires an "init", to be modified to use sysvinit inteast of systemd?

Naively; currently, how is OpenRC handled in Devuan? Is this handled on the Debian side, or does Devuan "make OpenRC happen"? trying to get an understanding of what Devuan already has done in regard to custom init development/maintain, and what it depends on from Debian.

golinux · 2018-10-16 01:39:42

Recent openrc/runit thread on DNG

Panopticon · 2018-10-16 11:28:20

just goes to show systemd's scope creep. Soon to be systemd linux with various underling operating systems based on it.

How could average userland people like myself help devuan with this if at all?

Last edited by Panopticon (2018-10-16 11:28:31)

Panopticon · 2018-10-16 12:09:54

golinux wrote:

As Christopher Barry said in his Aug 12 2014 Open letter to the Linux World:
OneLinux == zero-choice

Read that open letter but the proceeding reply is an absolute gem!

Nice rant, I sympathize with you (just complaining about this on G+).
I'm just waiting for Linus to get pissed enough to write his own init
routine. Maybe he'll call it "Boot Init Through Computer Hardware".
Of course he'll have to make that an acronym.
-- Steve

Unfortunatly linus has submitted to the CoCs.

Last edited by Panopticon (2018-10-16 12:11:35)

golinux · 2018-10-16 16:48:50

Panopticon wrote:

Unfortunately linus has submitted to the CoCs.

He's between a rock and a hard place. CPS has been called and he's been deemed unfit to run a daycare. Having his baby snatched from him is unthinkable but a real possibility if he doesn't submit to this crap. He should fork the kernel and kiss the LF behind. Hey, I can dream . . .

thezeit · 2018-10-17 01:37:01

Boot Init Through Computer Hardware

Golden. In fact... I could find myself supporting that and proudly telling everyone what I'm working on!

Here's a thought: Would it be possible to make an init system that understood systemd's unit files but maintained it's scope to ONLY an init system? Or is the scope of the init files themselves too unwieldly?

Maybe I'm thinking too much in the frame of cryptocurrencies... but when a primary crypto starts to lose its way... almost invariably a "classic" version emerges that sticks to the original stated goals. It would be sort of a funny way to maintain upstream compatibility without using the ACTUAL systemd. The only problem I see here is it would invent a project (that people would have to use neurons for) dedicated to keeping up with the imaginations of Pwnering... (that's my official name for him).

The only other thought that doesn't require massive loads of manpower to brute force package maintenance is a dedicated init script converter from one init system to another. But... it would have to be like... flawless.

I'm spitballing here. Anything to lower the level of unnecessary pain this is going to cause.

arjan · 2018-10-18 12:00:59

Sad

golinux wrote:

CPS has been called and he's been deemed unfit to run a daycare. Having his baby snatched from him is unthinkable but a real possibility if he doesn't submit to this crap.

What?!

Panopticon · 2018-10-18 14:48:17

^ The Linux Kernel

Panopticon · 2018-10-18 14:51:10

thezeit wrote:

Boot Init Through Computer Hardware
The only other thought that doesn't require massive loads of manpower to brute force package maintenance is a dedicated init script converter from one init system to another. But... it would have to be like... flawless.
I'm spitballing here. Anything to lower the level of unnecessary pain this is going to cause.

Maybe something like a Lua script, ala conkyrc to conky.config ?

Last edited by Panopticon (2018-10-18 14:54:01)

thezeit · 2018-10-18 16:24:59

Panopticon wrote:

Maybe something like a Lua script, ala conkyrc to conky.config ?

There's a Python-based converter from systemd to sysvinit here:
https://github.com/akhilvij/systemd-to- … -converter

It hasn't been updated in awhile so not sure how well it would track with modern systemd.

I was looking at doing something similar with the Tails porting since the scope is fairly narrow there. Something I'm concerned about though is apps/tools starting to expect the existence of systemd and invoking its methods directly. For instance I notice that in Tails network scripts they invoke systemd-related network management commands directly.

Since Tails is tailored it's permissible that they do that. But I wonder how long it'll be before this precedent of "one init system to rule them all" will carry to "one network manager to rule them all" and so on. I cringe at the idea of source upstream of Debian being written specifically to expect the existence of systemd tools such that even the downstream package maintainers lose their autonomy.

golinux · 2018-10-18 16:28:51

thezeit wrote:

Panopticon wrote:
Maybe something like a Lua script, ala conkyrc to conky.config ?
There's a Python-based converter from systemd to sysvinit here:
https://github.com/akhilvij/systemd-to- … -converter.

Yes. We already are aware of that. There will be a way forward.

thezeit · 2018-10-18 17:17:07

golinux wrote:

Yes. We already are aware of that. There will be a way forward.

Some passing thoughts:

- An automated converter could help keep the scope narrow (more focus on one thing)

- Even if it can't automate the conversion for everything it may be possible to automatically detect which ones need special attention to insert some kind of stub for specific packages with convoluted systemd-scope. (i.e. automation of the bulk would still be a payoff)

What I don't like about this whole thing is we're forced to keep up with "the ways of systemd". Interpreting archaic symbols depending on which way the crow flies and all that. I'm not seeing a way around it for as long as people are stupid though.

thezeit · 2018-10-18 17:30:48

It just hit me that attention on an automated converter could not only benefit package maintenance... it could also help people "un-systemd" their favorite distros and export clean images. Much like I'm doing with the Tails remaster.

The payoff there could be fairly wide.

My hesitation is in wondering how deep of a rabbit hole automatic conversion is when we're talking about doing it to scale. Everything looks great on paper!

golinux · 2018-10-18 17:31:53

@thezeit . . . Already being discussed. Care to do more than suggest solutions? Maybe roll up your sleeves and get your hands dirty? We can always use more hands on deck.

thezeit · 2018-10-18 17:57:11

@golinux - Absolutely. I'm primarily checking my thoughts for errors before going too far out on that limb, haha. I half expected someone to tell me, "You're wrong. Go away."

One of my lingering concerns was that the Tails remaster was going to become an incremental PITA as the systemd scope creep kept on. But now I'm thinking that if there's a common denominator here (package upgrades / distro remastering) that we can leverage each other's efforts and that issues will get detected/fixed more rapidly.

Is there a specific place where the huddle is happening for this? Or should I retreat to my remaster thread and play with the incendiary devices over there?

ChuangTzu · 2018-10-18 20:24:21

Was just a matter of time.

What about using the init packages from Slackware? They have absolutely no plans on using systemd.
https://packages.slackware.com/

Or going default openRC.
https://wiki.debian.org/Debate/initsystem/openrc
https://wiki.gentoo.org/wiki/OpenRC

dxrobertson · 2018-10-18 22:17:29

ChuangTzu wrote:

Or going default openRC.
https://wiki.debian.org/Debate/initsystem/openrc
https://wiki.gentoo.org/wiki/OpenRC

I saw no mention of retiring OpenRC support on the Debian thread, I am also thinking this should be considered in regards to Devuan; default to OpenRC. I am running OpenRC on all my Devuan installs and havent encountered any problems. This is personal opinion, but I find OpenRC easier to understand over sysvinit, and prefer it. Please, dont want to start any flames nor arguments here.

golinux · 2018-10-18 22:32:24

dxrobertson wrote:

ChuangTzu wrote:
Or going default openRC.
https://wiki.debian.org/Debate/initsystem/openrc
https://wiki.gentoo.org/wiki/OpenRC
I saw no mention of retiring OpenRC support on the Debian thread, I am also thinking this should be considered in regards to Devuan; default to OpenRC. I am running OpenRC on all my Devuan installs and havent encountered any problems. This is personal opinion, but I find OpenRC easier to understand over sysvinit, and prefer it. Please, dont want to start any flames nor arguments here.

Currently openrc relies on sysvinit helpers so still tied to it. Please refer to that thread on DNG. If those helpers are removed, openrc will be in trouble until there is a mature substitute to take over that function like runit. we're not there yet.

thezeit · 2018-10-19 00:13:44

This pissed me off:
https://lists.debian.org/debian-devel/2 … 00181.html

> Is it worth interested parties reaching out to the Devuan project
> regarding person-power for sysvinit maintenance? As a derivative
I’m not sure, but I’d rather not, as a general case, unless there’s
one or more of theirs who’s willing to cooperate and able to keep
quality. Devuan is… questionable, when one’s used to all of Debian.
> distribution, I imagine their lives would become much harder if we did
> drop sysvinit; they would have to pay the cost of maintaining the
Several people have said they believe that to be the end of Devuan,
and I concur, from what I’ve read.

Now I want to kick their ass. I'm not one for mailing lists normally. My anti-social/don't-need-the-approval-of-the-group thing... but I'm glad I dove in on this one.

Is there a mailing list thread where people are talking about sysvinit script automation on our end? Admittedly my aversion to mailing lists has resulted in an inability to navigate the DNG. Is there a mailing list search engine by chance?

golinux · 2018-10-19 00:16:14

@thezeit . . . I sent you an email. You might have it blocked

thezeit · 2018-10-19 01:07:19

golinux wrote:

@thezeit . . . I sent you an email. You might have it blocked

Replied and my email here is now updated.

I got caught in the forum's Tor filter on the first go & switched to an email address I never use.

Tatwi · 2018-10-24 16:00:19

As a former Slackware user from 1998-2008ish, the convenient package management system and the larger amount of directly related documentation (in large part due to Ubuntu's popularity) are why I went with Debian (and Debian-based distros). Honestly, I don't really care about the init system, I just don't want to use garbage software like pulseaudio and systemd.

I could use Slackware, but it's just so much easier to configure and update a Debian-based system. Devuan is pretty bare bones when it comes to configuration, yet the only thing I had to manually change when I installed it recently was the order of my sound devices. That's it, for the whole system! Slackware 14.2 on the other hand... I just gave up trying to get X.Org to run properly...

Sorry, my point here is that Debian used to be something special, something ... not Slackware... and now Devuan is what Debian used to be. It's annoying and it's stupid that such a thing had to occur, but it is what it is and think that's the way Devuan should be looked at going forward. If that means having to maintain packages from the software developer's source, well I guess that's what will have to be done, right? That's what Slackware and PCLinuxOS do.

I've never maintained any packages, but I am quite certain that I am capable of doing so. However, I'm sure I don't truly appreciate the scope of such a project and I'm not familiar with the associated commitments of one's time and resources. With that in mind, I'm willing to maintain some part of the system.

So I ask,

What would it take to for Devuan to be a stand-alone distro that doesn't require anything from Debian at all?

Would the end result be basically the same "Debian" we had in Wheezy and prior releases?

Is it worth the effort?

With that last question, I was imagining putting the time into making a Debian-like system using Slackware packages or just joining PCLinuxOS and perhaps making a "stable" release (using the Debian installer) based off their rolling release. I mean, time is after all the ultimate currency; Where's it best spent?

yeti · 2018-10-24 16:57:11

What would it take to for Devuan to be a stand-alone distro that doesn't require anything from Debian at all?

Hundreds of highly active developers.

I hope there will be more cooperation between Debian and Devuan.
Otherwise too many things are solved by independent teams simultaneously.
That's a waste of energy.

willbprogz227 · 2018-10-25 20:10:36

Man, this stinks.

I am very much an opponent of systemd. I actively seek out and use non-systemd distros. I've been using PCLinuxOS for quite a few weeks now with much success, but Devuan has a special place in my heart (and on its own hard-disk).

I believe each non-systemd distro is becoming weakened and ends up idle or dying because there seems to be a lack of unity among the remaining non-systemd distros. If work and plans to 'circle the wagons' hasn't yet started, it should soon, otherwise in the future we'll be forced to use distros with systemd and our freedom to choose will be pretty much gone.

What would it take to for Devuan to be a stand-alone distro that doesn't require anything from Debian at all?
Hundreds of highly active developers.

I wish I was a more skilled developer then I'd be on-board. I just make small utility apps and don't do 'big guy' stuff. Unfortunately most of the skilled developers out there have been heavily influenced by the pro-systemd crowd and probably don't see much benefit from non-systemd distros. Many of the things I've read out there show folks' apathy toward the systemd situation. "What's the big deal? It works, I don't care" they might say about systemd. But if you've used as many Linux distros with systemd as I have, you see the mess systemd makes. :'(

I hope, and want, Devuan to succeed.

The officially official Devuan Forum!

#1 2018-10-15 18:20:49

Debian Buster release to partially drop non-systemd support

#2 2018-10-16 00:22:45

Re: Debian Buster release to partially drop non-systemd support

#3 2018-10-16 01:39:42

Re: Debian Buster release to partially drop non-systemd support

#4 2018-10-16 11:28:20

Re: Debian Buster release to partially drop non-systemd support

#5 2018-10-16 12:09:54

Re: Debian Buster release to partially drop non-systemd support

#6 2018-10-16 16:48:50

Re: Debian Buster release to partially drop non-systemd support

#7 2018-10-17 01:37:01

Re: Debian Buster release to partially drop non-systemd support

#8 2018-10-18 12:00:59

Re: Debian Buster release to partially drop non-systemd support

#9 2018-10-18 14:48:17

Re: Debian Buster release to partially drop non-systemd support

#10 2018-10-18 14:51:10

Re: Debian Buster release to partially drop non-systemd support

#11 2018-10-18 16:24:59

Re: Debian Buster release to partially drop non-systemd support

#12 2018-10-18 16:28:51

Re: Debian Buster release to partially drop non-systemd support

#13 2018-10-18 17:17:07

Re: Debian Buster release to partially drop non-systemd support

#14 2018-10-18 17:30:48

Re: Debian Buster release to partially drop non-systemd support

#15 2018-10-18 17:31:53

Re: Debian Buster release to partially drop non-systemd support

#16 2018-10-18 17:57:11

Re: Debian Buster release to partially drop non-systemd support

#17 2018-10-18 20:24:21

Re: Debian Buster release to partially drop non-systemd support

#18 2018-10-18 22:17:29

Re: Debian Buster release to partially drop non-systemd support

#19 2018-10-18 22:32:24

Re: Debian Buster release to partially drop non-systemd support

#20 2018-10-19 00:13:44

Re: Debian Buster release to partially drop non-systemd support

#21 2018-10-19 00:16:14

Re: Debian Buster release to partially drop non-systemd support

#22 2018-10-19 01:07:19

Re: Debian Buster release to partially drop non-systemd support

#23 2018-10-24 16:00:19

Re: Debian Buster release to partially drop non-systemd support

#24 2018-10-24 16:57:11

Re: Debian Buster release to partially drop non-systemd support

#25 2018-10-25 20:10:36

Re: Debian Buster release to partially drop non-systemd support

Board footer