Devuan 2.1 Released - Still Delivering Debian 9 Without Systemd

[k1e0x]

Yet this has been debunked a bazillion times and you darn well know this isn't really true, but like repeating it anyway.

Single program? No. Single project? Yes. But then so is coreutils.

Debunked? What are you talking about?

You would have to either
a) believe that the number of system components is somehow a fixed factual value or.
b) you don't know what the word means.

You're dealing with opinions here and people have a right to run their systems however they see fit.. 10 years ago we use to trumpet this as a strength of open source. You don't like RPM? Cool, we have Debian and Slackware.. now days we have people who somehow believe they have the right answer for everyone in every use case and somehow they are crazy illogical people for making the choices they do. That just isn't the case. People like things for different reasons and that is all ok.

Devuan is a good thing, it provides people options. It's good for me and good for you even if neither of us use it.

[NotMine999]

There are some really angry systemd fanboys in this thread.

The angry systemd fanboi contingent in this thread are very likely unhappy (deeply butthurt?) with the thought that a group of developers actually went out and did their own thing, and it actually works. After all, haven't we seen time again the old saying posted in this these forums that basically says: "If you think you can do better, fork it and develop your version of it."

So what if Devuan is currently a major release behind Debian right now. The personality issues within the Devuan community are not a secret to anyone. And now that the Devuan build system is working again it may only be a matter of months until Devuan releases their "spin" of Debian Buster.

Does anyone remember the lag in release time between CentOS (before the Redhat acquisition), or "White Box Linux", or "Scientific Linux", and the official Redhat Enterprise Linux (the paid version) release? The delay might have been a week or two or might have been a month or two, but they all released their own "unbadged" versions of RHEL (when those distributions existed). RHEL, after all, was based on FOSS, so the "unbadged" releases of RHEL were not really different except in Redhat proprietary software and RHEL badging.

Keep in mind that the Devuan distribution may exist, in part, as a response to the systemd fanboi community saying, "If you don't like systemd, go out and do your own thing." After all, the Debian distribution is FOSS, so developing a systemd-less "spin" of Debian is perfectly within the scope of FOSS guidelines & Debian licensing. It's not any different from the "unbadged" versions of RHEL, except for the init system differences and the desktop GUIs that have sold their souls to systemd (swallowed the blue pill).

[starshipeleven]

The angry systemd fanboi contingent in this thread are very likely unhappy (deeply butthurt?) with the thought that a group of developers actually went out and did their own thing, and it actually works.

Is this thread about Void or Gentoo? Because providing a custom Debian installation ISO is what Devuan project does. All the developing is done by Debian project.

[starshipeleven]

Really? Is there a compelling reason to have a declarative language interpreter, a dbus interface, or socket activation in PID1?

Is there a compelling reason not to?

Btw, most of that functionality is technically in a shared library so there is no code duplication.

[betam4x]

I have been using Devuan (testing) for a while with Runit as init system and it worked quite well, and for a desktop use is good enough to handle basic system use, eventually would be useful an alternative init system compatible with systemd but with a smaller footprint and lesser features.

Sorry, have to interject here. I tried to stay out of this argument. I tried very hard. However, I'm finding that absolutely NONE of the folks arguing for init diversity understand systemd, nor do they understand why 'init diversity' is impossible. First, to counter your direct comment: systemd does not have a large foot print. On my system, with KDE, Brave with a few tabs open, and steam, I'm looking at around 2 GB of RAM used. I'd have to go back and see how big the systemd files are installed, but I know that they do not take up much disk space either.

The userland portion of systemd allows for standardized startup scripts, timers, and MUCH more with a lot of really neat features like socket activation, dependency chaining, and the like. With the older init system, you had a cobbled together system of scripts, and writing new init scripts for stuff was a PITA. Systemd's scripts are far more structured, so it's pretty easy to build new scripts. There are also advanced use cases for systemd. It's entirely possible (without some crazy hack job) to bring up say, a backup web server (on another machine) if the main web server stops responding to requests. Of course, you'd need to dig into documentation for this (I had developed a working version of this at a previous job...but alas copyrights...)

That doesn't even begin to get into systemd timers, which can practically replace cron jobs.

As far as binary logs being corrupted, this is a non-argument: I've had text log files get corrupted. I've had such a thing happen recently even. The file type of a file does not matter when it comes to data corruption. Most people forget that UTF-8 is used by default by many (if not the majority of) systems. Flip a couple bits (or remove a byte, oh THAT destroys the log file completely) and you end up with log corruption. Now I haven't looked into how easily it is to corrupt these log files (for example, if 1 byte is wrong in a systemd log, is it corrupt? If so there are simply fixes to that: Error correction. So no, this argument doesn't get buy in for me.

As to the other arguments regarding PID 1. Some people use systemd for their bootloader. I don't honestly see anything WRONG with systemd being pid 1. I can understand if the tin foil hat folks take issue, however.

Now, conclusion time. Is systemd perfect? No. there are things that can be improved. One of the big boons of systemd, for example, was to make things a lot more plug and play. Unfortunately it is not. systemd-networkd requires manual configuration. In addition, systemd-bootd seems to be a rather pointless en-devour for most at this point. The Linux kernel can boot directly from UEFI. You can also disable initramfs. Systemd also has a higher learning curve because it is far more powerful than before. Finally, systemd does not appear to handle killing services that well, and the systemd folder in /etc appears to be disorganized at the moment.

Overall I consider systemd a good thing. People insisting on 'alternatives' for this or other init systems should really think long and hard about things like fragmentation, development simplicity, and whether or not that 'choice' hurts Linux, both on the desktop, and as a whole.

EDIT: In regards to this article, I think it's great that this 3rd party distro exists. Maybe the naysayers can stop complaining and go use that distro, and the rest of us can move on.

One more thing I forgot to mention. I have a custom web application using a custom web server which I need not only startups/restarts/shutdowns, but config sanity checking (and blocking of restarts and stops unless the config is valid) as well as socket activation. On systemd I can build such a script in 3-5 minutes. Can you create an init script that does that at the same time?

[S.Pam]

Beside its primary purpose of providing a Linux init system, the systemd suite can provide additional functionality, including the following components:

• journald systemd-journald is a daemon responsible for event logging, with append-only binary files serving as its logfiles. The system administrator may choose whether to log system events with systemd-journald, syslog-ng or rsyslog. The potential for corruption of the binary format has led to much heated debate.^[21]
• logind systemd-logind is a daemon that manages user logins and seats in various ways. It is an integrated login manager that offers multiseat improvements^[22] and replaces ConsoleKit, which is no longer maintained.^[23] For X11 display managers the switch to logind requires a minimal amount of porting.^[24] It was integrated in systemd version 30.
• networkd networkd is a daemon to handle the configuration of the network interfaces; in version 209, when it was first integrated, support was limited to statically assigned addresses and basic support for bridging configuration.^{[25][26][27][28][29]} In July 2014, systemd version 215 was released, adding new features such as a DHCP server for IPv4 hosts, and VXLAN support.^[30][31]
• tmpfiles systemd-tmpfiles is a utility that takes care of creation and clean-up of temporary files and directories. It is normally run once at startup and then in specified intervals.
• timedated systemd-timedated is a daemon that can be used to control time-related settings, such as the system time, system time zone, or selection between UTC and local time-zone system clock. It is accessible through D-Bus.^[32] It was integrated in systemd version 30.
• udevd udev is a device manager for the Linux kernel, which handles the /dev directory and all user space actions when adding/removing devices, including firmware loading. In April 2012, the source tree for udev was merged into the systemd source tree.^[33][34] On May 29, 2014, support for firmware loading through udev was dropped from systemd, as it was decided that the kernel should be responsible for loading firmware.^[35] libudev It is the standard library for utilizing udev, which allows third-party applications to query udev resources.
• systemd-boot systemd-boot is a boot manager, formerly known as gummiboot. Kay Sievers merged it into systemd with rev 220.

Don't forget the built in dns resolver and forwarder. It also mucks up fstab with new systemd specifics that can cause boot problems.

The journal system is by far the most hideous to me. Why on earth have binary logs that are difficult to read in case you need recovery options....

Other issues are tmpfiles and networkd that removes ip addresses (assigned by dhcp) as soon as it feels like it.

[Danielsan]

...

Ikey Doherty of Solus once said that systemd is an opensource software that (unfortunately) behaves like a closed one. As a matter of fact forking or stripping down (as the first objective of Devuan itself) systemd is almost impossible, because it is an overly complex software that can be handled only from people that can work full time on it.

It does too many things, it put the hands on too many critical components, it is too complicated to me. It is an init system for professional use cases while I would like to have on my personal computer an init system that does just the minimum: booting, running and shutting down. I also prefer using, maybe because are my habits rather than the Unix philosophy, separate software for each task. For example I prefer using CRON rather than systemd-timer, but I can understand that from a system administration perspective using just one tool is preferable.

At this point the issue is the lacking of proper alternatives, the fragmentation is an issue just as the homogenization, if tomorrow systemd handles also the packages management and all the distros use zfs, there will not be any difference among each distributions, and this is surely bad.

I think that we urgently need a lighter and compatible alternative to systemd.

[tuxd3v]

I have seen a lot of hate here.. against SysVInit, and also against Devuan..
woow...
Devuan always stood for freedom of choice, diversity, Simplicity..

But for those who have been ranting, against those values, I should let you know that Devuan, also stands for privacy..
And they seem to be doing a good Job( were a lot is failing to do so.. )

[Danielsan]

I have seen a lot of hate here.. against SysVInit, and also against Devuan..
woow...
Devuan always stood for freedom of choice, diversity, Simplicity..

But for those who have been ranting, against those values, I should let you know that Devuan, also stands for privacy..
And they seem to be doing a good Job( were a lot is failing to do so.. )

This is pretty bad indeed...

From the Debian side they raised the concerning but didn't apply any patch so far.

https://wiki.debian.org/MachineId

I wonder if you can use a systemd service to regenerate at each boot your id machine...

[unixfan2001]

The journal system is by far the most hideous to me. Why on earth have binary logs that are difficult to read in case you need recovery options....

Because proprietary binary logs are tamper proof, while I one could easily manipulate a regular text file.

Danielsan

You're talking about systemd the system manager. systemd the init system (AKA PID1) isn't much more complicated than any other init system.