Devuan 4.0 Released As Debian 11 Without Systemd

[sinepgib]

You admit it's correct, yet you still think it's unfair to point it out? Then try to deflect with an anecodote? Outside of politics systemd defenders like yourself are probably the most thin-skinned people in the open source community. You can't criticize either the software or the way you go around the issue without addressing the real issue.

I think it's unfair to only blame one side for the same practice both repeat. I'm OK with the criticisms and the same post you quote acknowledges a few of them. _Specially_ the politics part. Besides, you willfully omit I talk about _many_. Just as not all detractors deny there were issues solved by systemd, not all supporters think it's perfect. And I for one don't. And _both_ of those factions (those who deny the problems it solves and those who deny the problems it has) are guilty of debates not leading anywhere useful. That's why it's an unfair point.

Regarding anecdotes, your post explicitly says all detractors raise good points and none deny the previous problems. So it's not an anecdote, it's a counter example. It's proof that assertion is wrong. One is enough for that.

In a personal note, I only defend some technical aspects of systemd. I'm fully aware their politics are toxic, their author, while technically very capable and creative, simply sucks as a maintainer, and their tight coupling is a design defect. I think a better solution is needed, and right now I think the best candidate is s6. Said this, what I don't want is to go back to how things were before, which is what happens if we listen to the subset of detractors that just deny there were any issues before systemd. Just as we'll get nowhere fast if we listen to the supporters that deny systemd also has issues.

EDIT: also, dude, I made _one_ comment about systemd and then I'm a "politics systemd defender"? WTF is that ad hominem?

The issue is that systemd is set up very much in such a way that you any use of it has to be made dependent of it and the functionally monolithic nature caused by the massive cross-dependencies means you have to pull it in. This is basically a trap where if your project uses one part, it's more than safe to assume almost everything else from the project has been pulled in by systemd's design and hence it's very easy to just build further parts of the projects with this assumption. It's effectively another case of embrace-extend-extinguish.

Yes. Maybe I wasn't entirely clear, but I'm not saying systemd is not guilty of this, but the contrary. The real problem is that it expects everyone else to depend on it, it promotes it and forces it as much as it can. Whatever they do for the inside is a non-problem, because as long as you don't have to use it you don't care. The problem is what they do to the external ecosystem, which actually ends up forcing you to use it.

EDIT: clarifying, the mention to ConsoleKit has to do with the fact we used to have a working alternative on the logind issue. Of course there was politics involved in dropping it. It doesn't change the fact the opportunity was there, so that's also relevant. I read somewhere about some ConsoleKit2 that is actively maintained tho, but I didn't delve on it.

[sinepgib]

Well, I never really looked into it before but I always thought my /tmp was either in RAM or on disk and apparently they silently changed that. It's possible that explains the not too long but still tangible delay. I get the impression that if something's truly failing you get a minute-long countdown, not a failed to unmount /tmp followed by success something like 10 seconds later. Maybe I glanced over it in apt-listchanges five years ago. (Anyway, I don't actually shut down that often; mainly just standby, so it's a mild annoyance that seems to come along with systemd that I've never bothered to more than cursorily investigate.)
https://wiki.archlinux.org/title/Tmp...utomatic_mount

Hmmm, unless you manually told it to mount it differently on fstab systemd and your package manager should be smart enough to handle the change. Emphasis on "should".
Even if you did, doesn't the autogenerated mount unit (systemd processes fstab with a generator and uses a .mount unit behind scenes) take precedence over the other one?

[danmcgrew]

Anyway, in parallel with Devuian we have Alpine and Gentoo that also works well without systemd.

...also, the NUMBER ONE DISTRO on Distrowatch for at least two years running, or more---MX-Linux.
...and its stable-mate---AntiX.
...and 90 more.

All one has to do is go to DistroWatch's distro search page and select the "No 'systemd' " option, and you'll be presented with a list of 92 distros (as of today) which do not use systemd as the start-up package.


"All seemingly complicated problems have a very simple solution if you just look at them the right way."---Douglas Adams

[BesiegedAce]

I think the main point is always missed in most discussions.

Systemd is not an Init system, neither its a friednly Open Source alternative for some other OSS tools and solutions. And it had never been such a thing from the start.

1. Systemd is an extreme commercial marketing invasion from the ground up. It's all about aggressive commercial marketing and politics. Not free software for kind home hackers.

-snipped the rest of the babble-

I'm gonna stop you right there. Frankly, Linux stopped being some super anti-establishment statement against THE MAN ages ago. Linux is corporate. Microsoft even maintains at least one distro themselves nowadays. If you still think Linux is still some purely hobbyist thing for "kind home hackers" (lol), you're only fooling yourself.

And frankly, just because Linux and FOSS is getting wider corporate attention, doesn't stop others from being "kind home hackers" or whatever.

[jacob]

Was it? Doesn’t GNU predate those two? Not that it isn’t on the spirit of things. Besides, RMS is centered on the ethical aspects, and he explicitly says you should be willing to give up on functionality if given the choice between that and freedom. Of course, functional is better than dysfunctional, but it’s not the topmost priority there.

GNU started in 1983 so it doesn't predate them, both MS and Apple already existed. Technically you are correct in that RMS didn't explicitly name MS and Apple; rather he intended GNU to replace the proprietary OSes that were dominant at the time (mainly Unix and VMS). My point was that GNU and Free Software was always intended as a replacement for proprietary platforms that people could move to, do what they need and never look back; it wasn't meant to be a toy for home hobbyists who would then revert to Unix or VMS (or today Microsoft and Apple) whenever they need to get some actual stuff done. That's what Minix is for.

[jacob]

Oh, wow... I see you've never tried to significantly alter a tightly coupled software before. Back in 2011 I got tasked with tidying up our tightly coupled 250 kLOC PHP webapp that was complete spagetthi code into a well defined REST backend and JS frontend. It was a freaking nightmare and took about a year to redesign, all the while being nervous that the old codebase could hold it together well enough to support the rewrite. Was it worth it? Yes, 1000x more performant, more secure and much easier to bring on new people quickly. But it sure wasn't a pleasant experience. The system I built then still chugs happily along now, 8 years later, even though I quit that job soon after.

Not saying tightly coupled code is necessarily bad code; but it does lead to much higher complexity requiring much more knowledge about the entire system, instead of simply polishing a part of it. If you don't understand why tight coupling is bad, then you haven't truly worked with massive tightly coupled systems.

Of course I have, and duh, you can have badly written tightly coupled software. Most of it is actually bad (which doesn't mean that most of uncoupled software is magically good). But in reality, tightly coupled kernels like Linux have won over loosely coupled designs like Hurd; virtually no webserver or development framework that's actually used in prod follows the loosely coupled approach, everyone prefers Photoshop to ImageMagic except for batch scripting, the desktop designs that have actually succeeded and that people actually want to use are the tightly integrated ones, MS Exchange and now O365 have virtually exterminated SMTPd's and IMAPd's from existence and even many of the Unix religionistas swear by Busybox which is as tightly coupled as it gets (and unlike systemd, it even really is a single giant binary ). All of the above is for very good reasons and it's foolish to refuse to acknowledge them for the sake of ideology.

[jacob]

...also, the NUMBER ONE DISTRO on Distrowatch for at least two years running, or more---MX-Linux.
...and its stable-mate---AntiX.
...and 90 more.

All one has to do is go to DistroWatch's distro search page and select the "No 'systemd' " option, and you'll be presented with a list of 92 distros (as of today) which do not use systemd as the start-up package.


"All seemingly complicated problems have a very simple solution if you just look at them the right way."---Douglas Adams

And those 92 distros have what, a grand total of 30 users between them?

[sinepgib]

GNU started in 1983 so it doesn't predate them, both MS and Apple already existed. Technically you are correct in that RMS didn't explicitly name MS and Apple; rather he intended GNU to replace the proprietary OSes that were dominant at the time (mainly Unix and VMS). My point was that GNU and Free Software was always intended as a replacement for proprietary platforms that people could move to, do what they need and never look back; it wasn't meant to be a toy for home hobbyists who would then revert to Unix or VMS (or today Microsoft and Apple) whenever they need to get some actual stuff done. That's what Minix is for.

Right! Brainfart, somehow I got MS and Apple being from the 90s in my head :facepalm:
Regarding usability, I may have been too extreme. Of course GNU is not intended to stay a toy for hobbyists. But still, between fully functional and free (as in speech), RMS would tell you to pick free. If it isn't on par with the proprietary alternatives either help fix it (the actually proposed approach that's seldom followed) or live with it. That's what I meant.

[Developer12]

(I'm just going to erase all this spam. Nobody needs to scroll this much for a single post. Learn to quote individual people. Jeez.)

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.

[Developer12]

So firstly thank you for a civil and unemotional argument. As far as your points go, the fact that you can't pick and choose has been raised before, but in reality, tight integration is part of the systemd design brief. The idea of having multiple totally independent programs (none of which really does ONE thing and they never do it particularly well, by the way - heck, even /bin/false must contain a parser and has a CVE history!) has been used for decades and it hasn't really worked out - the *nix landscape (and Linux, who inherited it) has always been an inconsistent mess where application developers can't ever assume anything and must expect everything. So yes, you lose the possibility to replace your DNS resolver with yet-another DNS resolver. It comes down to what is more important: being able to do that, or being able to develop application software knowing exactly what the underlying platform is, what it does and how it does it? Personally I vote for the latter.

PS: regarding DBUS, I could be wrong but I believe systemd has its own basic DBUS implementation so if you want to write additional systemd modules or rewrite some existing one, you should be able to use just that.

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.