systemd Rolling Out "run0" As sudo Alternative

[Artim]

Why don't you piss off first you little fuckwad? Who are you to talk to people like that? Go to reddit with this kind of behavior.

Why should I? Am I too thick to think? Am I throwing around utter nonsense that's lies upon lies? I think not.

[jacob]

So by that logic those users should have NEVER LEFT the Windows and Apple ecosystems and polluted the Wonderful World of Linux where FREE CHOICE reigned in pre-systemdeath days.

To distill the comments and diatribes that I find in this thread it comes down to this:

system(death) obviously and clearly breaks the fundamental rule of UNIX where many small programs work together, each specializing in their own unique tasks, to solve problems much greater than themselves. UNIX-style users could clearly swap out different small programs with other similar programs, albeit with different names (but a symlink can solve that), and for whatever reason they wanted; that's the essence of FREE CHOICE in UNIX and Linux.

Yes, users can still compile and build what they want out of system(death) and a few posters have clearly stated that certain distros tightly integrate system(death) into many aspects of that distro. At least Gentoo took a more rational approach when it came to system(death) that still allows a large amount of user choice, for example (borrowing from a poster here) systemd-boot or grub or whatever. system(death) would be acceptable to many if it and it's sycophant distros functioned on a level that allows FREE CHOICE, but they do not; they cater the the "I don't wanna Windoze or Fruit Cult crowd but I needs me a 'puter so I'z can play mez games on kewl Linux."

Where traditional UNIX-oriented distros have lost "mindshare" is in failing to improve integration among non-systemd components so they work well together. Distros claim "lack of developer hours", "lack of maintainer hours", "lack of funding" or whatever while pushing it all back to the priginal program developers (who have similar challenges). That is the "opening" that the systemd leaders spotted, how they wedged themselves into the Linux World ... and now like the roaches that they are we will never be rid of the system(death) infestation.

This would have taken so much effort to type and yet it's so silly

systemd, just like the Linux kernel and essentially every piece of software that actually does something nontrivial, breaks not one but literally dozens "fundamental rules" of UNIX. Linux, thanks God, is not UNIX. No-one ever promised that it would be. As far as UNIX itself goes, the FREE CHOICE mantra is the most ridiculous fallacy ever. You have no FREE CHOICE of your TCP/IP stack or VFS layer or executable binary format. Yet for some reason when it comes to the comparatively irrelevant pid1, FREE CHOICE is somehow the all-overriding cult. But let me remind you that there has been exactly zero FREE CHOICE in UNIX. Niet. Nought. Nada. UNIX has always been an uber-proprietary OS tied to lock-in support contracts that makes Windows look like GNU in comparison. You never had any FREE CHOICE of init systems in any actual UNIX OS. You don't in FreeBSD or any other BSD system. You didn't in SysV or any of its derivatives. At least, unlike the init in sysV & co, systemd is fully Open Source and Free Software.

[jacob]

Having started using Linux a few years after it first appeared, albeit just as a fun hobby, I found systemd to be a godsend.

I remember all those years dealing with run levels and incredibly convoluted init systems, and at times it was absolutely maddening. But now everything I need to do is incredibly easy, and I've rarely had a systemd related issue.

I understand that it's not perfect, and for many the fact that it violates the KISS philosophy will always render it unacceptable, but my goodness, I would never want to go back to the old days of hand woven init systems. The fact is that the init system is complicated, but systemd hides most of that complexity behind a standardized, easy to configure, user interface.

However I also hope the older init systems will always remain available, as I know there are quite a few users who really like them and will never give them up.

KISS matters when it comes to the simplicity of use and integration, in other words the simplicity of interfaces. It is entirely counter-productive to misconstrue it as a simplicity of implementation. The whole point of using software is to solve a problem, that is, to solve it fully, including, and especially, in the difficult corner-cases, and make the problem vanish from the user's point of view. That's what interface-KISS does. On the contrary, implementation-KISS means that something kinda sorta half works for the trivial functionality, and the more complex features and problems are left as an exercise to the user. There is no bigger Fail in software engineering than that.

[Artim]

KISS matters when it comes to the simplicity of use and integration, in other words the simplicity of interfaces. It is entirely counter-productive to misconstrue it as a simplicity of implementation. The whole point of using software is to solve a problem, that is, to solve it fully, including, and especially, in the difficult corner-cases, and make the problem vanish from the user's point of view. That's what interface-KISS does. On the contrary, implementation-KISS means that something kinda sorta half works for the trivial functionality, and the more complex features and problems are left as an exercise to the user. There is no bigger Fail in software engineering than that.

I'd argue KISS should also be true for implementation, but only to the degree that KISS is guaranteed for usability. Naturally, making implementations more complicated than necessary to reach that goal is only a preventable source of bugs and makes the code potentially hard to understand, so anyone doing a review - independent of closed or open source code - has an unnecessarily difficult time understanding the logic and finding flaws in the implementation.

[jacob]

I'd argue KISS should also be true for implementation, but only to the degree that KISS is guaranteed for usability. Naturally, making implementations more complicated than necessary to reach that goal is only a preventable source of bugs and makes the code potentially hard to understand, so anyone doing a review - independent of closed or open source code - has an unnecessarily difficult time understanding the logic and finding flaws in the implementation.

Of course. Unnecessary complexity is to be avoided. But the issue is that it's often not obvious which complexity is truly unnecessary. Once you look into the nitty gritty details of services management, for example, you realise that it's a devilishly complex problem if it's to be done right, work 100% of the time and not just 80%, and be user friendly and developer friendly. Systemd could probably have been implemented in many different ways but I honestly doubt that it could ever have been significantly simpler in terms of implementation without sacrificing interface KISS or usability KISS.

[Magissia]

Lately, I've been thinking about the following regarding systemd in general: It already has so many subprojects and it tries to do more and more stuff.. But the big question is, are all of these subprojects properly maintained and is there enough man power to properly maintain them?

I've already voiced my total dissatisfaction with systemd-resolved on this forum - about how it just stops resolving DNS randomly and its serious bugs that are still open for years, which makes me think systemd devs simply don't have the time or man power to fix them. I mean I can't come up with any other explanation to why these bugs are open for 3, 4 or even more years.

I haven't tried the other systemd subprojects, so I don't know about their quality. Maybe it's just systemd-resolved that is this bad. But because of my experience with resolved, I'm concerned about the quality of the other subprojects.

I use systemd-networkd on servers and desktop computers and I'm happy with it for this usage.
On laptops I'm still using Network-Manager because systemd-networkd doesn't support VPN the way I need it to.

I don't have issues with systemd-resolved and I'm happy to have the split dns feature. I didn't face issues where it randomly stops resolving domains, or if it happened I wasn't using the machine and it fixed itself.

[Sonadow]

This would have taken so much effort to type and yet it's so silly

systemd, just like the Linux kernel and essentially every piece of software that actually does something nontrivial, breaks not one but literally dozens "fundamental rules" of UNIX. Linux, thanks God, is not UNIX. No-one ever promised that it would be. As far as UNIX itself goes, the FREE CHOICE mantra is the most ridiculous fallacy ever. You have no FREE CHOICE of your TCP/IP stack or VFS layer or executable binary format. Yet for some reason when it comes to the comparatively irrelevant pid1, FREE CHOICE is somehow the all-overriding cult. But let me remind you that there has been exactly zero FREE CHOICE in UNIX. Niet. Nought. Nada. UNIX has always been an uber-proprietary OS tied to lock-in support contracts that makes Windows look like GNU in comparison. You never had any FREE CHOICE of init systems in any actual UNIX OS. You don't in FreeBSD or any other BSD system. You didn't in SysV or any of its derivatives. At least, unlike the init in sysV & co, systemd is fully Open Source and Free Software.

Linux also never even had free choice for the most part.

You do not get to choose the TCP/IP stack in Linux. It's part of the kernel.
You do not get to choose the WiFi stack in Linux. It's nl80211 + wext or nothing. While it's very uncommon now, at least some vendors do provide proprietary, vendor-only wireless stacks with their drivers for Windows. This was most common in the days of Windows XP and Vista.
You also do not get to choose the executable binary format and library format in Linux. It's all fixed.
You don't get to choose what format kernel modules come in, and more importantly, you don't get to use a .ko from kernel X.X in kernel X.X-1, or vice versa, while Windows is very, very lenient about allowing users to install older drivers into new systems, and even the other way round, that is, installing a new Windows's drivers into an older system, especially if the driver is already shipped in a way that is not tied to the Windows version.
You do not get to choose how your filesystem hierarchy is set. You either have the Debian-style layout of lib, lib32, and lib/<multiarch>, or the RPM-style layout of lib and lib64, or the Gentoo-style layout of lib and lib32

The only thing Linux users ever had the luxury of choosing is the choice of packaging format, which happens to be the bane of Linux and still is.

[jacob]

Linux also never even had free choice for the most part.

You do not get to choose the TCP/IP stack in Linux. It's part of the kernel.
You do not get to choose the WiFi stack in Linux. It's nl80211 + wext or nothing. While it's very uncommon now, at least some vendors do provide proprietary, vendor-only wireless stacks with their drivers for Windows. This was most common in the days of Windows XP and Vista.
You also do not get to choose the executable binary format and library format in Linux. It's all fixed.
You don't get to choose what format kernel modules come in, and more importantly, you don't get to use a .ko from kernel X.X in kernel X.X-1, or vice versa, while Windows is very, very lenient about allowing users to install older drivers into new systems, and even the other way round, that is, installing a new Windows's drivers into an older system, especially if the driver is already shipped in a way that is not tied to the Windows version.
You do not get to choose how your filesystem hierarchy is set. You either have the Debian-style layout of lib, lib32, and lib/<multiarch>, or the RPM-style layout of lib and lib64, or the Gentoo-style layout of lib and lib32

The only thing Linux users ever had the luxury of choosing is the choice of packaging format, which happens to be the bane of Linux and still is.

Not even that. The package manager is set by your distro. You can't install say Fedora's DNF on Ubuntu, Debian or Arch and expect it to work.

You do have a choice of distros / OSes, that's it. If for some reason you (rhetorical you) can't stand apt or dnf, or systemd, select your distro accordingly. If you can't stand the Linux kernel, use BSD or Windows. Seriously, I expect that next, those people will start moaning that Linux takes away their precious Freedom of Choice (tm) because they have decided to replace the kernel in their amd64 Fedora with an OpenBSD kernel compiled for ARM and it's a scandal that it doesn't work.

[matsukan]

systemd is cancer which turn Linux into M$ BSD zombie.

[oiaohm]

The package manager is set by your distro. You can't install say Fedora's DNF on Ubuntu, Debian or Arch and expect it to work.

Google with migrating server from redhat based to debian without stopping them did a serous abomination back in the day. So yes it would be possible to put fedora DNF on Ubuntu/Debian or Arch if you are willing to-do many highly risk/dangerous things and get it to work..

https://www.usenix.org/conference/lisa13/technical-sessions/presentation/merlin

Yes this 2013 thing is a demo option number 3 for mass system upgrade or then o hell I don't want to ever have to-do that nightmare if I can avoid it option. This nightmare method would allow DNF on Ubuntu, Debian or Arch.