Devuan 4.0 Alpha Builds Begin For Debian 11 Without Systemd

[jacob]

Nope, GNOME just decided to depend on systemd on PID 1, threatening and blackmailing everyone without the slightest addition to anything, or without the slightest benefits.

And they also fly around in black helicopters spreading chemtrails.

[markus40]

People who glee when thinking about systemd will be replaced by something else in the future and think current 'pro-systemd' people will 'wail and gnash their teeth' really miss the point. Systemd brought, for me, consistency in the boot process for Linux. Play with your Devuan and all the other 'best' things. But at my work I only encounter systemd enabled systems. In the past, I had to look up Ubuntu, Debian or OpenSuse syntax to change things. But now it is all the same. That is the win of systemd and this not going away anymore. Systemd may disappear, but the uniformity will stay. That is the point!
Just like I pulseaudio will go away and pipewire will be its replacement. Who cares.

Really... The people who are in 'war' with systemd, get a life...

[pmorph]

Oh no! People using their time how they see fit! We can't have any of that! Into the gulag with them!

I think it was a sarcastic comment, since without "init system freedom" Systemd likely wouldn't exist either.

[jacob]

People who glee when thinking about systemd will be replaced by something else in the future and think current 'pro-systemd' people will 'wail and gnash their teeth' really miss the point. Systemd brought, for me, consistency in the boot process for Linux. Play with your Devuan and all the other 'best' things. But at my work I only encounter systemd enabled systems. In the past, I had to look up Ubuntu, Debian or OpenSuse syntax to change things. But now it is all the same. That is the win of systemd and this not going away anymore. Systemd may disappear, but the uniformity will stay. That is the point!
Just like I pulseaudio will go away and pipewire will be its replacement. Who cares.

Really... The people who are in 'war' with systemd, get a life...

Systemd will be replaced by something else in the future because that's called evolution. It's only the *nix neckbeards who live with the firm held belief that use cases, user expectations and requirements have not changed a bit since 1972 and that a teletype emulator is forever the last word in UI design.

[Bigon]

The Debian project literally only switched to systemd bc the GNOME guys said that they will depend on it. It was not a conspiracy, but a public threat and blackmail.

Sure, it's all the fault of GNOME and not the result of an open discussion that lasted about 5 mouths during which the debian technical committee discussed the matter...

Nope, GNOME just decided to depend on systemd on PID 1, threatening and blackmailing everyone without the slightest addition to anything, or without the slightest benefits.

The fact that you are talking about PID1 only shows that you don't know anything about the topic. Back in 2014 when debian switched to systemd, the only required systemd component required by GNOME was logind, GNOME itself never required systemd PID1 (and I'm pretty sure it still doesn't even if I'm not spending time to confirm this).

[Alexmitter]

Nope, GNOME just decided to depend on systemd on PID 1, threatening and blackmailing everyone without the slightest addition to anything, or without the slightest benefits.

No they do not. You can launch Gnome on any PID 1, you just need a replacement for logind, like elogind.

[skeevy420]

How is that GTK responsibility? The fact GNOME developers don't care about consistency with other toolkits is not related to GTK. Yes, GNOME developers don't seem to care about consistency with other toolkits but community do. There is Adwaita for Qt. There are many themes that works on both GTK and Qt. Why would you limit yourself to the things created by GNOME developers?

Because their developers decided to use CSD. Again why would you blame GTK for that? As I said there is no requirement in GTK to make your application look like GNOME application. You can still design your application in traditional way (that's what MATE and Cinnamon are doing) and totally ignore GNOME HIG. GTK even supports KDE server side decoration on Wayland despite the fact GNOME Wayland has no SSD support at all. Also libadwaita was created to avoid putting GNOME-centric things directly in GTK. So how GTK "don't want to play ball with others on"?

Are we talking about GTK or GNOME here?

Both. There's enough overlap in regards to their design trends and developers working on them that they come off as one and the same; especially if you're a casual.

It's their responsibility up to a point. Much like KDE and Qt have tried to cater to GTK and GNOME, GNOME and GTK have to try to cater to others. That's why in KDE you can change one theme and both Qt and GTK programs will be themed. Best with GNOME is flipping on Dark Mode. KDE also comes with a built-in tool that brings in themes from all sorts of developers, not just themes from the KDE devs (it's hit and miss if we're being honest, but it's there by default). On GNOME I have to know about the right packages to install, the right web site, install web browser plugins, and then install themes and stuff (and like KDE: it's hit and miss if we're being honest). So to answer the question of "Why would you limit yourself to the things created by GNOME developers?": Because that's how GNOME developers want it done. They don't include the tools to tweak it.

Why blame them for CSD? Because people have tried to bring up SSD work in the past and upstream never accepts. Libadwaita is also a very recent thing that I am very excited for and was created to address a lot of the complaints I'm raising. While yes it does exist, it hasn't been around long enough to matter in a significant manner. Perhaps in a year's time that'll be more of an argument one way or the other -- we just have to wait and see what all happens. But that exists because enough people have had the same complaints that I'm having. Hopefully it will revert the G in GTK from GNOME back to GIMP. Would be cool if libadwaita spearheaded GTK4 to pick up things like libwindows, libqt, libefl, and other things where a properly written program could change system UI styles and increase how cross-platform GTK is. Like I said, that's actually something I'm excited for.

This is just me and I'm not trying to start something here, but something about MATE and Cinnamon just feels off. It's weird because I like that design style, but just not those environments. I think most of it is because cut my teeth on GNOME2 and the GNOME2 style in GTK3 is just weird to me. It just never has seemed right. I suppose I get nostalgic for the old way I preferred and just have to use something else. Does that make sense?

[F.Ultra]

They are used in Arch and Debian, RHEL is considering switching away from NetworkManager for systemd-networkd in RHEL9 (makes sense for a server-oriented OS). Ubuntu and Fedora don't use systemd-networkd because they are desktop OSes and Network Manager is the right one for a desktop, but they still use systemd-resolved.

Actually Ubuntu also uses systemd-networkd since 20.04LTS, at-least on server installs. They leave Network Manager if you upgrade so it's only used on new installs.

I'm not a systemd hater, I just dislike it. Systemd is like an Brussels bureaucrat who thinks it knows what's best for my system. When bureaucratd decides i'm not aloud to log back in after a period of inactivity, Drops me to a tty for 2 mins and then reboots! That's a bit too much power for pid#1.
BTW love it or hate it this is a good read https://suckless.org/sucks/systemd/

So you are clueless on how but systemd and the EU works.

[skeevy420]

This conflates a lot of unrelated things and it is helpful to start with the understanding that the path chosen by Fedora and Red Hat for RHEL can and is different, in major part because the goals and lifecycle is very different.

* Btrfs effort in Fedora is largely driven by Facebook because they rely on CentOS stream for their production workflows and integrating better with Fedora is useful for them.

* Stratis - Red Hat has on the other hand invested heavily into XFS and Stratis is just a userspace tool that integrates a lot of the existing components into a new userspace tool. It is not a new filesystem.

* systemd-homed is not a filesystem, in Fedora it uses Btrfs and is not integrated into either Fedora or RHEL. It is a purely upstream component.

* Silverblue uses ostree which is underlying userspace component for among other things, Flatpak and it is not tied to any specific filesystem.

Unless I'm missing something, it seems like all of that would tie into some Btrfs feature. Definitely OpenZFS, but this is RHEL and Fedora we're talking about so that's a crack pipe dream.

I never got Stratis and XFS. I get Stratis, just not the XFS part of it. To me, just seems like a bad idea to base something on a non-shrinkable file system. Those can be hell if you have limited resources and are dealing with issues. Literally why I quit using XFS 10 years ago. I ran into one of those situations and had to sit on a broken system until I could afford a new drive. Just seems like most any other FS would have been a better choice.

systemd-homed is upstream for Fedora and RHEL? Isn't Lennart a RHEL employee? So they only pay the guy, give him an office, and just happen to use his software and call it upstream ? That's one hell of an "upstream"

Thank you for saying ostree. Had a brainfart yesterday. When using SB I always wondered why it didn't integrate into file systems to leverage their features instead of doing what seems to be the same things on a higher level...like snapshots and subvolumes instead of different ostrees when applicable if that makes sense.

[RahulSundaram]

Unless I'm missing something, it seems like all of that would tie into some Btrfs feature

Clearly not since as you are already aware of, Stratis doesn't use Btrfs and Red Hat doesn't have a single Btrfs developer on payroll.

I never got Stratis and XFS. I get Stratis, just not the XFS part of it. To me, just seems like a bad idea to base something on a non-shrinkable file system. Those can be hell if you have limited resources and are dealing with issues. Literally why I quit using XFS 10 years ago. I ran into one of those situations and had to sit on a broken system until I could afford a new drive. Just seems like most any other FS would have been a better choice.

Beyond what is supported through LVM thin provisioning, shrinking is just not a feature that enterprise customers want all that much.

systemd-homed is upstream for Fedora and RHEL? Isn't Lennart a RHEL employee? So they only pay the guy, give him an office, and just happen to use his software and call it upstream ? That's one hell of an "upstream"

I meant systemd-homed is an upstream systemd feature. It is not used by either Fedora or RHEL yet as I already noted and you seem to be unaware that in many cases, Red Hat just pays the upstream developers and doesn't dictate individual features. Lennart wasn't asked by Red Hat to work on systemd at all in the first place. He happened to do it on his own time while Red Hat was invested into moving forward with upstart originally. It's just not a top down organization.

Thank you for saying ostree. Had a brainfart yesterday. When using SB I always wondered why it didn't integrate into file systems to leverage their features instead of doing what seems to be the same things on a higher level...like snapshots and subvolumes instead of different ostrees when applicable if that makes sense.

Because flatpak's goal was to provide something usable on every distribution without depending on a specific filesystem and the model is more like git for operating systems in the sense that it needs to be support branches and deltas and so forth.