Devuan 4.0 Released As Debian 11 Without Systemd

[sinepgib]

There's a difference between init(1) and systemd. BSD has an init(1) for fuck's sake. To paraphrase Potering himself, systemd is a complete, interconnected ecosystem.

This invalidates the vast majority of your arguments about dependency and reliance. It is not in fact possible to run the majority of systemd software without all systemd core components.

Next time read before replying. Of course BSD has an init(1), pretty much everything remotely related to unix does. But the core of systemd is an init(1), and all over the thread everyone referred to the systemd daemon as such, so I thought you'd be clever enough to understand what I meant.
If you take the time to read properly, I said exactly what you say here, maybe in a more detailed way. You can't run the higher level systemd components without (systemd as) init(1). You can use anything else that isn't part of systemd with (systemd as) init(1) instead if you wish, and that's what most mainstream distros do.

Multiple independent programs are absolutely a useful thing to have. Had sysvinit been more tightly coupled to the kernel or other parts of the userland, it would have been impossible for systemd to begin in the first place.

It's fundamental to the replacement of incumbents with better alternatives. Now if anyone wanted to replace systemd they would have to emulate all of the myriad things that it does. It's largely pulled up the latter after it, in that regard, although the hard work by devuan and others might someday lower it.

Inconsistency and broken assumptions have and always have had a simple and straightforward solution: communication and standardization. It's a shame that the first instinct of all programmers is to build their projects in isolation and keep others out, maintaining control over their codebase. When all the unixes of the 80's started to go their separate ways the standard picture of what a unix system should look like was codified in POSIX and later in documents like the linux Filesystem Hierarchy Standard. Suddenly everyone could know what basic utilities they could expect to find (even text editors; hi vi fans!) and what libraries would be available.

An example of this kind of collaborative standards-making can be found no further than one level below, in the linux kernel where lots of people with different needs meet to hash out what system interfaces should look like. The kernel's rules about breaking userspace are strict, to be sure, but they reliably provide standard interfaces and post reasonable deprecation schedules.

Having an immutable incumbent dictate standards through action is one way to resolve uncertainty but it is by no means the best way.

I mostly agree here, but POSIX in particular dictates how things should look more or less halfways, in the sense that lots of it was just setting in stone whatever was in the wild at the time, no matter how bad the solution was. Exaggerating, it would be as if we had a standards body just to pretend systemd is a standard by copy-pasting Lennart's blog. Said that, yes, the programmers' knee jerk reaction is doing their own and see if it catches attention, but it's sadly not just something about the programmers, but their employers. It's useful for companies to retain control over an ecosystem and so they try to come up with their own solution so the maintainer of the popular project answers to them.

Regarding replacing systemd tho, it depends on how much of the stack depends on each component. Just as things are now, off the top of my head I can only think about socket activation, readiness notification and logind as things commonly depended upon by userspace.
The first two could have been much more general and agreed upon but the sd guys decided to impose their own without discussion. skarnet wrote a protocol that is much more decoupled for that and should work just as well, and it will sadly get ignored because of corporate interests essentially; I think Ian Jackson wrote one as well. At the same time, I know of no server that forces you to use it to work, so it's probably isolated enough to make it easy to replace on projects.
The latter is the most problematic AFAIK, but it's still a single component. If you can do with just reaping logind in favor of, say, ConsoleKit2, you can probably remove systemd from a previously coupled system.
DNS resolver, DHCP client (systemd's implementations, obviously, but I need to be extra explicit it seems), etc, is simply not depended upon by userspace, and mainstream distros don't even enable them by default, so _currently_ you can use whatever is around for those functionalities rather than reimplement anything to replace systemd.

Not that it isn't systemd's devs' intent to make it harder to replace, the problematic part is that that criticism is completely accurate. I'm just saying we still have time, most higher level tools are not only not depended upon, but pretty much unused in the mainstream, so their "replacements" actually predate the effort.

[jacob]

Just because tight integration is part of the design brief doesn't necessarily make it a good idea. I can put lots of things in a design breif.

Multiple independent programs are absolutely a useful thing to have. Had sysvinit been more tightly coupled to the kernel or other parts of the userland, it would have been impossible for systemd to begin in the first place. It's fundamental to the replacement of incumbents with better alternatives. Now if anyone wanted to replace systemd they would have to emulate all of the myriad things that it does. It's largely pulled up the latter after it, in that regard, although the hard work by devuan and others might someday lower it.

Inconsistency and broken assumptions have and always have had a simple and straightforward solution: communication and standardization. It's a shame that the first instinct of all programmers is to build their projects in isolation and keep others out, maintaining control over their codebase. When all the unixes of the 80's started to go their separate ways the standard picture of what a unix system should look like was codified in POSIX and later in documents like the linux Filesystem Hierarchy Standard. Suddenly everyone could know what basic utilities they could expect to find (even text editors; hi vi fans!) and what libraries would be available.

An example of this kind of collaborative standards-making can be found no further than one level below, in the linux kernel where lots of people with different needs meet to hash out what system interfaces should look like. The kernel's rules about breaking userspace are strict, to be sure, but they reliably provide standard interfaces and post reasonable deprecation schedules.

Having an immutable incumbent dictate standards through action is one way to resolve uncertainty but it is by no means the best way.

I didn't say that a loosely coupled design isn't easier. It certainly is. What I contend is that it's not better in any sense that matters to actual end users. Software should be designed to be easy to use, not easy to write.

By the same token, having something declared as a "standard" doesn't mean that it's better. In fact POSIX in particular really isn't all that good (many POSIX APIs and semantics are actually truly evil) and there is no universal "duty" for Linux to be POSIX-compliant for ever and ever.

[jacob]

There's a difference between init(1) and systemd. BSD has an init(1) for fuck's sake. To paraphrase Potering himself, systemd is a complete, interconnected ecosystem.

This invalidates the vast majority of your arguments about dependency and reliance. It is not in fact possible to run the majority of systemd software without all systemd core components.

It's also not possible to run the Linux kernel or GCC or GNOME or Apache or PostgresQL without all its interconnected core components. Your point being...?

[Danielsan]

> Devuan 4.0 allows the choice of SysVInit, Runit, or OpenRC as the init system in place of systemd.

Is S6 available/easy to set up too? Has anyone experience with it to report wrt Runit and OpenRC?

About S6 so far I know is only available as docker image.
I use Devuan with OpenRC and haven't had an issue while I had some issues with Debian and malformed systemd-units, it looks like that aren't so intuitive...

[deepclutch]

Using Devuan since ascii. It has become much easier to use, since Beowulf and now upgraded to Chimaera. As a desktop user, I hoped can get Gnome-40 at least in Chimaera, but it has only Gnome-3.38.
EDIT: Using openRC init now. I had tried runit also. runit is faster.
BTW, anyone wonder if systemd can be used as init helper except for PID 1 (I'm not knowledgeable in this). What arrangement does MX Linux uses with sysvinit & systemd co-existing in the same system? If systemd looses PID 1 for a init program, isn't it a better solution.

[sinepgib]

I didn't say that a loosely coupled design isn't easier. It certainly is. What I contend is that it's not better in any sense that matters to actual end users. Software should be designed to be easy to use, not easy to write.

I think the point (valid, IMO, even if overrated) is that you have a smaller chance of making big mistakes, and a higher chance of being able to replace components where fixing that kind of mistake is unfeasible. Being easy to use is one quality. Being stable (enough) is another one, that may be more important for many.

By the same token, having something declared as a "standard" doesn't mean that it's better. In fact POSIX in particular really isn't all that good (many POSIX APIs and semantics are actually truly evil) and there is no universal "duty" for Linux to be POSIX-compliant for ever and ever.

Not only that, but pretty much all *nixes deviate from it by extending with their own APIs. POSIX ends up being your least common denominator. You can write your userspace with strictly POSIX and have it somewhat kinda work everywhere, but it will most likely be a suboptimal solution everywhere.

[sjukfan]

Debian is finally doing it right™ I spotted these two among the new packets the other day

• systemd-standalone-sysusers -- Standalone sysusers binary for use in non-systemd systems (1 days old)
• systemd-standalone-tmpfiles -- Standalone tmpfiles binary for use in non-systemd systems (1 days old)

I probably won't use them but it allows people to pick and chose what parts of systemd they want or not

[jacob]

I think the point (valid, IMO, even if overrated) is that you have a smaller chance of making big mistakes, and a higher chance of being able to replace components where fixing that kind of mistake is unfeasible. Being easy to use is one quality. Being stable (enough) is another one, that may be more important for many.

I think the idea that big mistakes don't happen with the loosely coupled mix & match approach is simply not true. The reality as I see it is that because no-one can really make any assumptions about the other components, big mistakes are much harder to predict and especially avoid because they end up just happening out of nowhere. Here's a cartoonish but still very real example: the *nix approach treats everything as mere strings (and null-terminated at that). No-one can make a difference between an option, a parameter and a file name. What happens to 'rm *' if you happen to have a file called '-r' (which NOTHING can stop you from creating)?

But not only do those mistakes exist and not only they are more or less inherently unfixable (whereas if the system was designed to be tightly coupled, it would be possible to address them in an unified way), but what's worse, they are effectively passed down on the user, which is the ultimate sin in my books. Software is there, or at least should be, to solve a problem as in make the problem non-existent for the user, not to pass the buck. I like to always remind myself of one very good point made by Linus years ago during a debate about what should be done to make Linux drivers easier to install and configure: he said that a user-friendly OS is not one that has a better UI to manage drivers, it's one where users never have to care about drivers at all. Among other things this led to the virtual elimination of Xorg.conf, which of course didn't happen without the obligatory flames that this is somehow a bad thing and makes Linux "like Windows".

Experience seems to confirm this anyway: essentially no-one is designing anything using the unix philosophy any more. Modern programming languages like rust or go come with a compiler, linker, configuration manager, build system, package manager and code analysis tools all tightly coupled and taking advantage of each other. Even languages that tried to resist that trend are now switching to it, like D with dub. Cgi-bin is long dead, cremated and not missed by anyone, vim/ctags and emacs may still have some fans but most of the world's developer population, regardless of the type of projects, clearly prefer IDEs that can process the source code at the AST level, not just strings and regexes. Etc.

[billyswong]

I think the idea that big mistakes don't happen with the loosely coupled mix & match approach is simply not true. The reality as I see it is that because no-one can really make any assumptions about the other components, big mistakes are much harder to predict and especially avoid because they end up just happening out of nowhere. Here's a cartoonish but still very real example: the *nix approach treats everything as mere strings (and null-terminated at that). No-one can make a difference between an option, a parameter and a file name. What happens to 'rm *' if you happen to have a file called '-r' (which NOTHING can stop you from creating)?

Hmmm could we block filenames starting with hyphen to be created, or at least escape such filename when fetched by '*"? This remind me that in DOS / Windows, command options are done like '/r' traditionally. They don't allow '/' as part of filename while their folder separator is a '\'. So the issue you describe here just can't happen in old DOS commands / scripts.

Experience seems to confirm this anyway: essentially no-one is designing anything using the unix philosophy any more. Modern programming languages like rust or go come with a compiler, linker, configuration manager, build system, package manager and code analysis tools all tightly coupled and taking advantage of each other. Even languages that tried to resist that trend are now switching to it, like D with dub. Cgi-bin is long dead, cremated and not missed by anyone, vim/ctags and emacs may still have some fans but most of the world's developer population, regardless of the type of projects, clearly prefer IDEs that can process the source code at the AST level, not just strings and regexes. Etc.

Not too sure about package manager and code analysis tool, but I always think the distinction of compiler, linker, configuration manager, build system etc is arbitrary. From a user point of view, the ideal is one single or at most a few number of fixed mouse clicks / command lines to translate any code source folders or code source files into ready-to-use portable executable or installation package. Target selection should have been a simple parameter change or dropdown selection. Unfortunately, usually things are much more complicated today. Even when people want to write a program project using multiple languages at the same time, the modules should be communicating in an interface defined by one particular language and we can use build system of that language. I miss the old days when I was learning in school, the ease of use of Turbo Pascal / Free Pascal...

[jacob]

Hmmm could we block filenames starting with hyphen to be created, or at least escape such filename when fetched by '*"? This remind me that in DOS / Windows, command options are done like '/r' traditionally. They don't allow '/' as part of filename while their folder separator is a '\'. So the issue you describe here just can't happen in old DOS commands / scripts.

But in order to do that you must first ensure and enforce that there really is The One True character that identifies options, implement the required safeguard in the kernel that it can't be used as part of a filename (and can't be accidentally returned if the data on disk are corrupt or deliberately modified), and you must then design your userland so that executables receive options in the form of a pre-parsed structure (where the parser is system-wide, not optional, and handles the Character correctly) rather than as an array of strings (or to be more precise, of random byte arrays that may or may not make some sense).

That's what I mean by tightly coupled design: make sure and require that all components know about each other, work together and maintain consistency.

Not too sure about package manager and code analysis tool, but I always think the distinction of compiler, linker, configuration manager, build system etc is arbitrary. From a user point of view, the ideal is one single or at most a few number of fixed mouse clicks / command lines to translate any code source folders or code source files into ready-to-use portable executable or installation package. Target selection should have been a simple parameter change or dropdown selection. Unfortunately, usually things are much more complicated today. Even when people want to write a program project using multiple languages at the same time, the modules should be communicating in an interface defined by one particular language and we can use build system of that language. I miss the old days when I was learning in school, the ease of use of Turbo Pascal / Free Pascal...

Turbo Pascal was great, unfortunately it didn't really scale beyond small-ish one person projects. But compared to other tools at the time, even to its siblings Turbo Basic and Turbo C, it was a pleasure to use.

There are many distinctions that are really purely arbitrary. In fact large aspect of the often touted unix philosophy fall in that category, largely because unix didn't really have any unifying vision or philosophy. Rather, features were being added ad-hoc as afterthoughts or workarounds, and almost always with the all-overriding concern of being simple *to implement* rather than correct and simple *to use* or to integrate. For example, there is really no reason why there should be init, cron, atd, (x)inetd and various desktops' session managers. All of these things (fail to) solve the same problem: launch and manage jobs in certain defined circumstances. It should all be done by exactly one component.