Poettering announces tool in new systemd version to replace sudo

well,where is the important distros managers? like Debian , I'know ..they put without a choise systemd into their distro, but, they are accepting it
This is the point where the Linux distros put a foot in the ground and say "NO"
But..if they follow the path to be "the next windows" o the "Poettering universal distro" they deserve it...
 
  • Like
Reactions: mer
mer said:
I agree with hardworkingnewbie What was a premise behind systemd? Init system is too hard and complex and leads to errors. Does systemd improve on that or is it "as good as?"
Click to expand...
By my understanding the 2 main problems systemd tried to solve were

a) speedup of boot times by using parallelised start of services, which means you must be aware about cross service dependencies and attached hardware, so this is really a complex problem when trying to solve it,
b) the issues that come with lots of removable hardware during runtime of a system in modern hardware, so managing these devices.

Some would might add service supervision to that list, but there've been enough tools also available which are able to do that outside the init system. So it is not something an INIT system must do, though some would still argue something it should do.

The rest systemd does is just totally unnecessary feature creep, which makes it bloated, therefore too complex and a security nightmare. 92 CVE records in 12 years is really an aweful big number for something which primarily is an init system.

Well maybe some day something like similar to pipewire will emerge for systemd, who knows.

 
I will never trust a single word that... person says. systemd is just an extremely intrusive crapware which is broken by design. The only reason it has a broad adoption is its authors pushed it via RedHat (a.k.a Micro$oft's best friend in GNU/Linux ecosystem). There are plenty of true init systems for GNU/Linux, much better than systemd (with runit being my favorite).
Now I hear said... person strikes back with another thing nobody asked for. It has been years since I ditched sudo anyway. I am guessing this new "revolutionary" tool will be pushed as well, with the exact same ridiculous "argument" used when systemd was pushed: "Adopt this or else". Seriously, I'm wondering why do we even bother talking about this in FreeBSD forums.

My reaction is simple: No, thank you. doas all the way.
 
  • Like
Reactions: mer
hardworkingnewbie said:
By my understanding the 2 main problems systemd tried to solve were

a) speedup of boot times by using parallelised start of services, which means you must be aware about cross service dependencies and attached hardware, so this is really a complex problem when trying to solve it,
b) the issues that come with lots of removable hardware during runtime of a system in modern hardware, so managing these devices.

Some would might add service supervision to that list, but there've been enough tools also available which are able to do that outside the init system. So it is not something an INIT system must do, though some would still argue something it should do.

The rest systemd does is just totally unnecessary feature creep, which makes it bloated, therefore too complex and a security nightmare. 92 CVE records in 12 years is really an aweful big number for something which primarily is an init system.

Well maybe some day something like similar to pipewire will emerge for systemd, who knows.

Click to expand...

a) speedup of boot times by using parallelised start of services, which means you must be aware about cross service dependencies and attached hardware, so this is really a complex problem when trying to solve it

Correct me if I'am wrong, but the only point of systemd was the a)
that what the initial and only , later they took the userland more and more
 
i recently installed Ubuntu 24.04

you cant use chsh -s to change the shell anymore
it throws an error saying about pam

so you have to edit a config file and change the pam settings

what most people will end up doing is editing the /etc/passwd to change the shell
and of course new users will end up breaking the passwd file and locking themselves out

cue lots of posts on reddit saying i tried to change my shell by editing the passwd file
and now im locked out of the system

coupled with the fact you cant double click deb files to install them anymore
Ubuntu is becoming less and less user friendly for new users
 
wolffnx said:
Correct me if I'am wrong, but the only point of systemd was the a)
that what the initial and only , later they took the userland more and more
Click to expand...
Click to expand...
Indeed, at first they claimed it is just an "init system" - which is a joke, it was never intended to be just that, and that was obvious right from the beginning. Later on even them didn't dare to call an init system anymore, and the term used now is "a Linux system management suite". Basically that means a wanna-be kernel, on top of the already bloated Linux kernel.

NapoleonWils0n said:
cue lots of posts on reddit saying i tried to change my shell by editing the passwd file
and now im locked out of the system

coupled with the fact you cant double click deb files to install them anymore
Ubuntu is becoming less and less user friendly for new users
Click to expand...
I guess you know the old saying, "Ubuntu is an ancient African word meaning 'I can't configure Debian'". And Debian is infected by systemd to the bone. So really, expect anything. Anything goes.

I'm still wondering why a FreeBSD user would care, though. Even if you use GNU/Linux on the side (for things you can't yet do in FreeBSD, such as bluetooth or games), there are some systemd-free distributions. Also, doas was ported to GNU/Linux a long time ago, so who cares about run(), or whatever they are going to call it.
 
hardworkingnewbie said:
By my understanding the 2 main problems systemd tried to solve were

a) speedup of boot times by using parallelised start of services, which means you must be aware about cross service dependencies and attached hardware, so this is really a complex problem when trying to solve it...

Some would might add service supervision to that list, but there've been enough tools also available which are able to do that outside the init system. So it is not something an INIT system must do, though some would still argue something it should do.
Click to expand...
The fastest boot times in my house belong to Void Linux which boots to a login prompt in 6 seconds from the BIOS screen. It has parallel startup and supervision without Systemd. Turns out that's totally possible, as so many said it was.
 
Pap said:
"a Linux system management suite".
Click to expand...
Lets stick with this for a moment.
We have launchd, which according to their definition "launchd is an init and operating system service management daemon" and
Solaris Service Management Facility which again is init and service managment.
A lot of people have no issue with either launchd or Solaris SMF because they both stay in their box of "init and service management" which are closely related.

The problem I have with systemd is the "init and service management" box was not treated as a hard boundary.

init and service management are always about managing the who needs to run first, so those dependencies need to be explicitly stated or gleaned somehow (both difficult). Parallel init is basically thundering herd: start everything, everything must know to wait for what it needs. In practice that often leads to "everyone take two steps forward. Stop. now that group take one step. now that other group take 3 steps". Often a pain in the butt and actually detecting and reporting errors is difficult.
 
mer said:
Parallel init is basically thundering herd: start everything, everything must know to wait for what it needs. In practice that often leads to "everyone take two steps forward. Stop. now that group take one step. now that other group take 3 steps". Often a pain in the butt and actually detecting and reporting errors is difficult.
Click to expand...
Sounds like a nightmare for nothing, indeed. And not even needed, who really cares about... what? barely one second difference, if any, at boot time?
Furthermore, you don't need systemd at all, even for that. As Jose already pointed out, Void GNU/Linux boots really fast (and shuts down in an eye blink, I might add). I'm not quite ok with Void, because it uses elogind, and it's not free of Linuxisms. But they use runit, which is a very good init system. Very easy to use and really fast.

mer said:
As a warning perhaps? The old "Those who don't learn from history are doomed to repeat it"?
Kind of "If someone truly proposes and tries to implement a systemd-thing on FreeBSD, don't let them"
Click to expand...
You have a point here. However, I doubt anyone will ever propose such an abomination on FreeBSD. God/Devil forbid.
 
  • Thanks
Reactions: mer
mer said:
Parallel init is basically thundering herd: start everything, everything must know to wait for what it needs. In practice that often leads to "everyone take two steps forward. Stop. now that group take one step. now that other group take 3 steps". Often a pain in the butt and actually detecting and reporting errors is difficult.
Click to expand...

In the 1990s there was talk to use make(1) as an init system. Would give you the parallelism (-j) for free and knows all about dependency graphs.
 
hardworkingnewbie said:
By my understanding the 2 main problems systemd tried to solve were

a) speedup of boot times by using parallelised start of services, which means you must be aware about cross service dependencies and attached hardware, so this is really a complex problem when trying to solve it,
b) the issues that come with lots of removable hardware during runtime of a system in modern hardware, so managing these devices.
Click to expand...

a) There are things that are more important that a fast and faster boot.

b) Why should init do everything?
 
  • Thanks
Reactions: Pap
My opinon only.
Fast reboot is only meaningful if you reboot all the time.
My systems show uptimes in "quarters" package updates or freebsd-updates of kernel bits.
Based on that, who cares if it takes an extra 2 secs for my system to boot?

Telco systems or other "5-9s" Reboot time means how long until redundant. So maybe good for stats and billing but in real world?
I've never been convinced that shaving 0.5 sec off a boot/reboot is actually good.
Pap said:
But they use runit, which is a very good init system. Very easy to use and really fast.
Click to expand...
Yep; a lot of it still boils down to defining dependencies correctly.
"My service depends on network and local disk" trivial, but clear. But does network and local disk define their dpendencies correctly?
"I can guarantee that I define what I need correctly, but can't/shouldn't guaranteee everything else is correct"

hruodr said:
a) There are things that are more important that a fast and faster boot.

b) Why should init do everything?
Click to expand...
My opinon:
a: agree, I want Correct boot everytime
b: agree, init should only start then do nothing.
 
cracauer@ said:
In the 1990s there was talk to use make(1) as an init system. Would give you the parallelism (-j) for free and knows all about dependency graphs.
Click to expand...
In the 90s or early 00s, there were several experimental parallel init systems. I know my office mate had written one in his previous job at Transmeta. Ultimately, they all run into the problem mer described: You can't get any faster than the "longest pole in the tent". Since the variation between the duration of various init tasks is huge, doing them in parallel doesn't help all that much (not a factor of 100, perhaps a factor of 2 to 10).

The other problem people ran into back then was disk IO. It turns out that bringing up a system does a lot of disk IO: reading config files, reading various init "scripts" (whether they are encoded as shell files, or in the code segment of a compiled program makes little difference), loading a lot of executables for daemons and shared libraries. You end up often being disk and file system limited: As long as you keep your disk 100% busy, it doesn't actually matter what order you do things in, your bottleneck is right there. A friend wrote their PhD thesis about a way to improve that: Since you know ahead of time what tasks in booting are done in what order, you can place the files on disk such that the head barely has to move. As a contrived example, put the following files on disk in order: /etc/rc.d/mail /usr/sbin/sendmail /usr/sbin/mailwrapper /etc/mail/mailer.conf /usr/libexec/sendmail/sendmail /etc/mail/sendmail.cf ... and the boot goes much faster. It worked, the person got their degree, they're now a professor at a nice university, and the work got abandoned and ignored. SSDs made it somewhat irrelevant.

If doing IO in parallel is the *ONLY* justification for systemd, that would be ridiculous. But there is a better justification: The many parts of the init system are indeed really complex. This is "the other 90% of the work of writing an OS". Unifying them under a common configuration and change management system is a great idea, and systemd has done that ... except in a fashion that most people find disgusting, and with a lot of problems (security foremost).

To another point discussed above: Is the time to boot a system actually relevant? Yes and no. For servers that run "forever", it doesn't matter. My FreeBSD server at home has an uptime of months, which is only limited by (a) OS updates and (b) power outages where we want to rest our emergency generator after a day. Whether it boots in 10 seconds or 3 minutes makes little different *TO ME IN MY USE CASE*. Now, if I'm a kernel developer, the difference between 10 seconds and 1 minute is probably an hour a day, if I crash my machine (intentionally) 60 times per work day. Similarly, if I have a pair of servers with active/active redundancy, I really want my second server to reboot fast, because while it is down I'm no longer fault tolerant. Other use cases for really fast boot are stateless machines, for example a laptop that doesn't need to hibernate or sleep: when you open the lid, the OS boots (takes a second for a lightweight OS), you enter your password or fingerprint, and the state of the only application running on it (the browser, like in a Chromebook) is restored in another second for the exposed windows. Similar things happen in data centers with stateless servers that can be rebooted quickly.
 
I have a nuanced view on systemd. Not a hater and not a fanboi. I get the reasons it was picked over the "competition". It's not just parallelism but making the kernel primitives available to services,
etc.

That said, there are components that are utter crap like systemd-networkd (not even used by openSUSE), systemd-resolved (which pretends to take over dnsmasq but refusing to listen on interfaces other than loopback), systemd-homed, and all the tools to manage systemd containers which are not a serious competition to the likes of podman, docker, distrobox, etc.

This tool is also problematic and most people won't use it.
 
What Microsoft did from Windows 8 upwards, is to enable hibernation as standard and call it "fast startup"...

I don't think parallelised boot was ever a major goal of systemd, most likely just a neccessity in order for it to seem relevant at the time when they needed to gain some traction - and something to use as marketing in order to claim as a feature/benefit when compared side by side with alternatives. systemd project's main objectives were always to swallow up functionality provided by other "fragmented" software and bring about a "CoreOS" as publicly stated by Poettering himself. It was never enough to provide another alternative - Poettering wanted to obsolete those "legacy" components. You only have to read all the agenda driven blogs of around 10 years ago to see this.

Boot times were just all about enticing the average user. In my view it boots only a little faster than a sysvinit based setup on normal desktop hardware - ironically system halt is where you see the most significant difference.

The problem we have as BSD users is that systemd and wider corporate involvement in FOSS is leaving us with less and less choices as time goes on and many projects move towards systemd dependence and becoming more Linux centric. While the project will hopefully never adopt or implement something like systemd, we're not immune to the "collateral" damage caused to wider free software. Indeed Poettering actively encouraged developers to disregard systems he believes to be irrelevant, such as the BSDs, forget portability and focus on Linux only.
 
wolffnx said:
a) speedup of boot times by using parallelised start of services, which means you must be aware about cross service dependencies and attached hardware, so this is really a complex problem when trying to solve it

Correct me if I'am wrong, but the only point of systemd was the a)
that what the initial and only , later they took the userland more and more
Click to expand...
Yes, you are wrong. To prove my point I am linking to Poettering's blog, where he in April 2010 in his blog post "Rethinking PID 1" described the motivation behind systemd. Link is: https://0pointer.net/blog/projects/systemd.html

To quote him:

As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.​
​
For a fast and efficient boot-up two things are crucial:​
  • To start less.
  • And to start more in parallel.
And on the topic of hardware:

Modern systems (especially general purpose OS) are highly dynamic in their configuration and use: they are mobile, different applications are started and stopped, different hardware added and removed again. An init system that is responsible for maintaining services needs to listen to hardware and software changes. It needs to dynamically start (and sometimes stop) services as they are needed to run a program or enable some hardware.​
 
hardworkingnewbie thanks.
"To start less"
I find interesting, odd, makes me go hmmm. Why? Assuming "less" means fewer items to start/manage:
My opinions, thinking out loud without enough coffee:
Each runlevel has a roughly predefined number of things to start. Things being defined as "services or functionality". Lets say networking, locally attached disks, dns, ntp as the things; 4 things.
One could have 4 different services defined, so start and manage 4 or one meta-service that controls 4 meaning boot "starts only 1". But you still need to start and manage 4 bits of functionality.
Does 1 metaservice make boot faster?

Boot to me falls into either cold boot (start at power off) or warm boot (hibernate, suspend to disk, shutdown -r now). I think the best way to start less is to save state on shutdown and restore (hibernate and suspend) but there are lots of potential technical gotchas.
 
You must log in or register to reply here.
Back
Top