Debian considering going systemd init only

HevyDevy · 2019-12-28 12:47:35

Focus is on systemd and it sounds as if other inits will only be picked up if enough volunteers are actively working on exploration of other inits, otherwise would it be a case of just not be supported at all but a side interest?

Explore; to travel through (an unfamiliar area) in order to learn about it.

yeti · 2019-12-28 14:46:50

aut0exec wrote:

Didn't go as badly as thought but not as promising either. :-/

This result's "we support exploring alternatives" suffix will not fruit.
This result will make some overly optimistic and/or inert users stay with Debian instead of looking for an alternative.

More is lost than gained with this wishy-washy result.

Let's just face reality: Debian is "systemd only" now.

Let's use a new thread for brainstorming forward.

Geoff 42 · 2019-12-28 14:53:45

aut0exec wrote:

That tallying system made the head hurt...

It looks as though it is the Condorcet method of voting

https://en.wikipedia.org/wiki/Condorcet_method

Geoff

aut0exec · 2019-12-31 14:31:43

yeti wrote:

aut0exec wrote:
Didn't go as badly as thought but not as promising either. :-/
This result's "we support exploring alternatives" suffix will not fruit.
This result will make some overly optimistic and/or inert users stay with Debian instead of looking for an alternative.
More is lost than gained with this wishy-washy result.

Good point. Didn't look at it that way but I can definitely see things going that route, sadly.

ToxicExMachina · 2020-01-07 16:52:49

yeti wrote:

Let's just face reality: Debian is "systemd only" now.

The fact is: it's SystemD-only just for now, not for the future.

pj1967 · 2020-01-08 19:24:08

In the overall battle against systemd (not just limited to Debian and it's downstream affect on Devuan), what's to prevent kernel dependencies worming their way down from systemd creating a lockout of non-systemd components? Despite his rant against Sievers, Linus' apparent apathy to systemd doesn't speak well to protecting the kernel from such pollution. If such encroachments can be kept at bay, then it seems possible to continue with a systemd-less distro. But if not, we're looking at forking at the kernel level, no?

Ron · 2020-01-08 20:42:33

pj1967 wrote:
But if not, we're looking at forking at the kernel level, no?

Hyperbola already got plans just for that, albeit forking the OpenBSD kernel. I wish them success.
https://www.hyperbola.info/news/announc … d-roadmap/

Last edited by Ron (2020-01-08 20:43:41)

GNUser · 2020-01-08 20:56:21

Forking the OpenBSD kernel in order to avoid systemd and/or other linuxland woes makes no sense. By virtue of not being Linux, OpenBSD (as-is) does not suffer from linuxland woes.

yeti · 2020-01-09 04:16:33

GNUser wrote:

By virtue of not being Linux, OpenBSD (as-is) does not suffer from linuxland woes.

How long?
And what about the other BSDs?
In "The Tragedy of systemd" a FreeBSD member praises what systemd all does right and mentions experiments in FreeBSD to implement systemd like stuff that already have taken place but are fruitless up to now. I expect that to only be a delay instead of an end of such ideas in FreeBSD.

OpenBSD may resist a bit, byte or even longer. Never underestimate an angry Theo! \o/
But...

GNUser wrote:

By virtue of not being Linux, OpenBSD (as-is) does not suffer from linuxland woes.

How long?
What if the big players in the dimension userland start to insist that the systemd kernel extensions have to be present? Pulling systemd related implants from lots of ridiculously huge applications will converge to impossible because of the lacking woman power.

Optimism is caused by the lack of information.

Last edited by yeti (2020-01-09 04:17:30)

pj1967 · 2020-01-09 13:30:48

Ron wrote:

pj1967 wrote:
But if not, we're looking at forking at the kernel level, no?
Hyperbola already got plans just for that, albeit forking the OpenBSD kernel. I wish them success.
https://www.hyperbola.info/news/announc … d-roadmap/

OpenBSD seems like a viable starting point for a new opensource OS fork. It's clean, simple, and resists binary blobs.

However, if staying on the "linux" path is necessary, going back to the 2.6 kernel might be a good starting point?

Head_on_a_Stick · 2020-01-09 15:22:13

pj1967 wrote:

OpenBSD seems like a viable starting point for a new opensource OS fork. It's clean, simple, and resists binary blobs

No it doesn't, fw_update(1) is run automatically on first boot of a new system and that downloads any firmware blobs required by the hardware and loads it.

HevyDevy · 2020-01-09 16:15:24

Head_on_a_Stick wrote:

pj1967 wrote:
OpenBSD seems like a viable starting point for a new opensource OS fork. It's clean, simple, and resists binary blobs
No it doesn't, fw_update(1) is run automatically on first boot of a new system and that downloads any firmware blobs required by the hardware and loads it.

So you are saying openbsd arbitrary downloads non-free firmware upon booting a newly installed system?

as far as i am aware fw_update is/was a manual process?

are these the only firmware files openbsd supplies?

http://firmware.openbsd.org/firmware/6.6/

Head_on_a_Stick · 2020-01-09 16:41:08

HevyDevy wrote:

So you are saying openbsd arbitrary downloads non-free firmware upon booting a newly installed system?

Not arbitrarily, only firmware that is required by the hardware is downloaded. The reasoning is that any hardware that doesn't load firmware blobs from the operating system has them implanted in ROM at the factory instead so the battle is already lost, so to speak.

HevyDevy wrote:

as far as i am aware fw_update is/was a manual process?

No, it's run automatically on first boot and also after updating to a fresh snapshot in -current.

HevyDevy wrote:

are these the only firmware files openbsd supplies?
http://firmware.openbsd.org/firmware/6.6/

Yes, I think so.

Kelsoo · 2020-01-09 20:56:39

While that maybe the case with OpenBSD. It wont be with Hyperbola.

They don't tend to try and fix every package they just remove the one's they can and fix the ones they have to. ( Java and Rust) They know they will end up with a minimal system.

As you see they deblob
https://issues.hyperbola.info/index.php … ask_id=761

HevyDevy · 2020-01-10 10:32:25

Head_on_a_Stick wrote:

HevyDevy wrote:
So you are saying openbsd arbitrary downloads non-free firmware upon booting a newly installed system?
Not arbitrarily, only firmware that is required by the hardware is downloaded. The reasoning is that any hardware that doesn't load firmware blobs from the operating system has them implanted in ROM at the factory instead so the battle is already lost, so to speak.
HevyDevy wrote:
as far as i am aware fw_update is/was a manual process?
No, it's run automatically on first boot and also after updating to a fresh snapshot in -current.
HevyDevy wrote:
are these the only firmware files openbsd supplies?
http://firmware.openbsd.org/firmware/6.6/
Yes, I think so.

when i installed openbsd iwm firmware was already in the install i think as going by the boot messages i had a fatal failure for my card (intel wifi chip) , i had no working net connection until i finished installing the sets and booted into openbsd and connected from the smart phone. I havent touched that partition in a few weeks, maybe i dont understand the process properly in regards to firmware, is that firmware bundled with the sets and only installs when needed?

Last edited by HevyDevy (2020-01-10 10:36:43)

Head_on_a_Stick · 2020-01-10 15:24:07

HevyDevy wrote:

when i installed openbsd iwm firmware was already in the install

No, the install process does not include the firmware, that's why fw_update(1) is run at the first boot (or after an upgrade to a fresh snapshot).

From the FAQ:

Some manufacturers refuse to allow free distribution of their firmware, so it can't be included with OpenBSD.

czeekaj · 2020-01-11 11:21:37

HevyDevy wrote:

Head_on_a_Stick wrote:
HevyDevy wrote:
So you are saying openbsd arbitrary downloads non-free firmware upon booting a newly installed system?
Not arbitrarily, only firmware that is required by the hardware is downloaded. The reasoning is that any hardware that doesn't load firmware blobs from the operating system has them implanted in ROM at the factory instead so the battle is already lost, so to speak.
HevyDevy wrote:
as far as i am aware fw_update is/was a manual process?
No, it's run automatically on first boot and also after updating to a fresh snapshot in -current.
HevyDevy wrote:
are these the only firmware files openbsd supplies?
http://firmware.openbsd.org/firmware/6.6/
Yes, I think so.
when i installed openbsd iwm firmware was already in the install i think as going by the boot messages i had a fatal failure for my card (intel wifi chip) , i had no working net connection until i finished installing the sets and booted into openbsd and connected from the smart phone. I havent touched that partition in a few weeks, maybe i dont understand the process properly in regards to firmware, is that firmware bundled with the sets and only installs when needed?

Interestingly enough I have intel firmware-iwlwifi installed on a dell laptop but on the init logs I get a message failed to load firmware-iwlwifi. Yet I log in and I can use the wifi card and have working internet. It's all quite fantastic I havn't had any trouble getting wireless internet on a proprietary wifi card that requires proprietary drivers. You'd think it'd be nothing but trouble. I thought of replacing the wifi chip to one that doesn't need the driver. However, it's still working as is.

As regards to Debian development it sounds like they won't stop developers for making a package workable for non-systemd inits. However, I don't think developing a package that doesn't work with systemd is going to happen w/ the current state of debian.

Last edited by czeekaj (2020-01-11 11:23:42)

HevyDevy · 2020-01-11 15:11:04

^ afaik, that package houses intel wifi firmware for various devices, not sure why you get that message though, probably spurious.

https://packages.debian.org/buster/firmware-iwlwifi

Last edited by HevyDevy (2020-01-11 15:20:51)

czeekaj · 2020-01-11 23:45:41

Mm yes, I recall from devuan jessie. The dpkg manager was really easy to go through the firmware and find out for which card each firmware package was for. It would have a list of wifi chips it would support.

It only started recently giving me this error on booting. Before I never had the error. However, after installing the firmware I'd have to reboot the machine before the wifi would work. *shrugs* it works though.

In short, only since I migrated to beowulf I started getting an error early in boot. However, wifi still works so I think any non-free firmware with boot errors but still works is A OK with me. Again, probably better to get a new wifi card but the OS could get working Wifi easily with no tom foolery with the non-free packages provided.

Last edited by czeekaj (2020-01-11 23:47:42)

yeti · 2020-01-12 01:43:03

Maybe the initrd complains about the missing firmware and after switching to the real root the module is found and so loaded when needed?

ToxicExMachina · 2020-01-15 07:06:48

pj1967 wrote:

In the overall battle against systemd (not just limited to Debian and it's downstream affect on Devuan), what's to prevent kernel dependencies worming their way down from systemd creating a lockout of non-systemd components? Despite his rant against Sievers, Linus' apparent apathy to systemd doesn't speak well to protecting the kernel from such pollution. If such encroachments can be kept at bay, then it seems possible to continue with a systemd-less distro. But if not, we're looking at forking at the kernel level, no?

SystemD exclusivity will ruin embedded Linux. It will cause a big fork.

steelpillow · 2020-02-04 16:42:13

Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release: https://www.theregister.co.uk/2020/02/0 … o_systemd/

I tried searching Debian's public discussion forums for a reaction but could find nothing. On the other hand, the El Reg commentards are unanimous in their (or rather our, I confess) blistering condemnation: https://forums.theregister.co.uk/forum/ … o_systemd/

Makes me wonder which way the wind is really blowing.

Head_on_a_Stick · 2020-02-04 17:19:58

steelpillow wrote:

Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release

You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.

[1] Like most of systemd's tools.

steelpillow · 2020-02-04 17:43:22

Head_on_a_Stick wrote:

steelpillow wrote:
Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release
You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.
[1] Like most of systemd's tools.

Sorry, I see no connection between my quoted remark and your reply.

Head_on_a_Stick · 2020-02-04 18:07:56

I'm genuinely curious as to why an optional added feature for an init system you don't even use elicits "blistering condemnation". It's quite bizarre.

The officially official Devuan Forum!

#76 2019-12-28 12:47:35

Re: Debian considering going systemd init only

#77 2019-12-28 14:46:50

Re: Debian considering going systemd init only

#78 2019-12-28 14:53:45

Re: Debian considering going systemd init only

#79 2019-12-31 14:31:43

Re: Debian considering going systemd init only

#80 2020-01-07 16:52:49

Re: Debian considering going systemd init only

#81 2020-01-08 19:24:08

Re: Debian considering going systemd init only

#82 2020-01-08 20:42:33

Re: Debian considering going systemd init only

#83 2020-01-08 20:56:21

Re: Debian considering going systemd init only

#84 2020-01-09 04:16:33

Re: Debian considering going systemd init only

#85 2020-01-09 13:30:48

Re: Debian considering going systemd init only

#86 2020-01-09 15:22:13

Re: Debian considering going systemd init only

#87 2020-01-09 16:15:24

Re: Debian considering going systemd init only

#88 2020-01-09 16:41:08

Re: Debian considering going systemd init only

#89 2020-01-09 20:56:39

Re: Debian considering going systemd init only

#90 2020-01-10 10:32:25

Re: Debian considering going systemd init only

#91 2020-01-10 15:24:07

Re: Debian considering going systemd init only

#92 2020-01-11 11:21:37

Re: Debian considering going systemd init only

#93 2020-01-11 15:11:04

Re: Debian considering going systemd init only

#94 2020-01-11 23:45:41

Re: Debian considering going systemd init only

#95 2020-01-12 01:43:03

Re: Debian considering going systemd init only

#96 2020-01-15 07:06:48

Re: Debian considering going systemd init only

#97 2020-02-04 16:42:13

Re: Debian considering going systemd init only

#98 2020-02-04 17:19:58

Re: Debian considering going systemd init only

#99 2020-02-04 17:43:22

Re: Debian considering going systemd init only

#100 2020-02-04 18:07:56

Re: Debian considering going systemd init only

Board footer