News: 1591188367

systemd, snap and even the Linux kernel itself all seem pretty monolithic to me. Is this the new "microkernel" architecture, then, made out of a few big blocks?

I'm very far from being anything like an expert in OS matters so perhaps someone can assist my understanding ... If systemd provides all the essential services userspace needs to make effective use of the Linux kernel, why isn't it part of the kernel? On the other hand, if it's important that these sorts of services are kept separate from the kernel might that not imply they should be kept separate from each other and not all bound up into another monolithic layer?

Give them time. Rome wasn't destroyed in a day you know.

It might help to think of it as GNU/Linux.

The init process and the rest of the system is GNU, while the kernel is Linux.

The reason that init is not in the kernel, is that, the kernel doesn't care once it's booted.

It's a userspace problem to select and use an appropriate init.

lets say, in my use case I want to mount a fileysystem and give me a shell. A plain shell script will be fine, and init can simply be /bin/sh

Init or pid-1 more specifically has responsibilities for cleaning up zombies, and then the divergent implementations add other things. Typically init will mount the filesystems, and spawn a getty.

busybox/uclibc specialises in this sort of very customised, small userland, shipping an init.

Also Init has to be integrated with the rest of the system services, so it's a difficult to ship an init without having made all the other downstream choices that implies, at which point, you've rolled your own distro, again;)

It seems like a Judean People's Front vs Peoples' Front of Judea sort of argument. I'm sure it's very important though.

.. relics of history! Join Judnetum the only truly representative of the people of Judea -- we know whats right for them.

No-one has yet managed to articulate to me what that problem is.

The problem that sysvinit has evolved into a big ball of mud. Few doubt that, the argument is what it should be replaced with.

I'm quite enjoying runit on [1]void linux. YMMV

Bit harsh downvoting him for saying that nobody has explained it well.

[1] https://voidlinux.org/

sysvinit has some learning curve.

By I'd suggest that systemd has an even steeper one - and you can't easily learn by looking at simple files.

Despite the fact that I work with it every day I still have to go and look up syntax which would be a simple `grep` in sysvinit.

Any arguments about parallel startup or faster startup rather miss the point - that's a pretty trivial saving of time on a one time basis every - well, worst case scenario once a day - more usually once a month (or less) - and is therefore not a benefit worth changing anything for.

The 'restart' services... We used to use these things call watchdogs - and they were pretty good, you could even have cron spin up a watchdog watcher every minute if you are really paranoid. Aside from that you could have a script which execs your daemon and then waits for it to fail before incrementing the count of failures and restarting (with some backoff based on count of recent failures). Doesn't justify the massive changes of systemd.

init scripts might not be the easiest things to write, but I just wrote one for a local slackware server in about 30 seconds (ok, I cribbed the ssh one - so sue me).

What actual benefit does systemd bring?

Because I'm not saying sysinitv is perfect, but I don't get what problem is *solved* by systemd. Certainly don't get the impression that such problems are worth the loss of readability (albeit by a reasonably skilled user) that was inherent in the sysvinit scrupts (which you could simply step through, or litter with debug statements printed to screen....)

> Bit harsh downvoting him for saying that nobody has explained it well.

Oh please. It is trivial to find pretty much all criticism online. Whether one agrees or not is of course another thing.

Virtually all criticism I can find is criticism of systemd. The only consistent criticism I can find of sysvinit is that it doesn't support hot-plug devices, which seems like a solvable problem.

Sysvinit executes scripts in lexigraphical order. This was dumb at the time, but really, really hard to change. There is tribal knowledge about what sort of things should have what sort of numeric prefixes which types of services should have. This works well enough that I've never heard any complaints about it except the obvious theoretical concerns.

Sysvinit executes all tasks in a serial fashion. While this is no big deal on average, server init time is quite important in a number of scenarios (especially the "serverless" setups).

The start/stop/restart/status pattern is clunky. Personally, I wonder if the real problem here is the use of bash when ruby, python, and perl are nigh-universal.

This is what I hear from my sysadmin friends. What I know about sysvinit is that I were asked to jump in and modify the init scripts, I feel perfectly comfortable that I can learn everything I need by studying they directory layout and the content of a few init scripts. The setup is _simple_. It is well contained.

Systemd, on the other hand was created "because init scripts are hard". If that is your justification for replacing process 1 with the Blob, I don't want you anywhere near my computer. Ever.

The recent failure for random happened because one of their devs decided to roll their own random number generator, and did not even deign to mix in the kernel-provided one. That this made it past their code reviews & shipped make it clear that they are a bunch of arrogant fools.

I really don't care what kind of problems you think systemd is solving for you. When things like the above are going on, you can be assured that systemd is creating problems that you really, really don't want to have in the end.

The problem is the previous init solution rc.1, rc.2 etc. required several messy scripts, and, did not include any monitoring, and left everybody to come up with thier own shutdown strategy.

On HP-UX this got even worse with their practice of combining all of the above into a single script which then had to work out where in the statup/shutdown cycle it was.

I recently had my first experience of implementing systemd control for a service and was surprised how simple, effective and straightforward it was -- given the opprobrium heaped on it by the youngsters.

It seems to be a better implementation of the excellent Windows NT service interface!

It works well, its easy to use and offers far more control than other solutions -- get over it.

You consider having a script per service to be a problem, I perceive it as an advantage.

I can easily sprinkle debug statements into said script, or step through it manually, if anything is broken.

Shutdown strategy? Don't.

OK - for laptop users etc you might need something a little better, but you just pull back through the run levels...

I don't recall systems I used to run having issues shutting down with sysvinit, have I been exceptionally lucky or is it not actually a problem. Having multiple different ways to do something isn't a problem.

You consider having a script per service to be a problem, I perceive it as an advantage. .... John Robson

A script servering service would be a real boon for such an advantage to present, JR. .......... even if it is too much like listening to AI Virtual Machinery spooking out Human Resources to be anything else Viable as a Viral Treat and/or ACTive Cyber Threat.

Dear amanfromMars 1, I do thing you are pulling a leg here. Please tick as appropriate.

[ ] This leg is mine!, MINE!, ***MINE***!!!eleventy!!!!

[ ] Oops, middle leg. I am very sorry. Very, very.

[ ] Leg: no such device.

> The problem is the previous init solution rc.1, rc.2 etc. required several messy scripts, and,

So they replaced those scripts with a bunch of configuration files that aren't gemerally on the root file system, filled with arcane verbs and sections that TBH look like they were invented to cover special cases as Pottybrain discovered them. And then, just to make it interesting they decided that logging to the console was a bad idea (though TBH all the distros now default to clearing the console, --no-clear is your friend...) When it couldn't get any worse, they then decided that we needed a whole new set of command line utilities to manage the complete POS that they had created.

Nope, I'm not a fan :-)

"-- get over it."

And this attitude is *exactly* why some people perceive the friends of systemd as a bunch of &^&^%^&.

Me included.

left everybody to come up with thier own shutdown strategy.

# sync;sync;halt

always seemed fine to me...

"On HP-UX this got even worse with their practice of combining all of the above into a single script which then had to work out where in the statup/shutdown cycle it was."

That was particularly useful. The script could be edited so that we could inhibit the system from starting new applications, tell the users to log out with time to finish their current tasks and then let the grace period pass before actually forcing them out.

"It seems to be a better implementation of the excellent Windows NT service interface!"

The epitome of damning with faint praise.

> damning with faint praise

Damning with fake praise, I think.

You need to understand shell inorder to maintain sysv init scripts.

Personally I don't see that as a problem, but that is basically at the heart of it.

Once you've bought into that bit of dogma, then the justifications start to snowball.

For example socket-activation, because xinetd something..

So what do you get out of it, It's the same across red-hat/debian. Some convention over configuration, but I think at a loss to clarity, since the systemd unit files, contain shell snippets, mixed with magic logic provided by systemd. So one throws up ones hands, and hopes for the best. Which I suspect is what people do when confronted with an expertly written shell scripts. ${1:-'missing'}

Thus I understand that what is needed is a new shell.

OK, I will take my coat and look for that beast outside.

Oh, just wait for systemd-shell-handling-deamon.

I had used Debian since v2.0 in 1998 and Slackware before that on my personal servers. Switched to Devuan on servers (Mint on my laptops since Ubuntu 10.04 went EOL) in the past year or two(fortunately a fairly seamless upgrade, no re-installs just apt-get upgraded to Devuan).

Most of my issues with systemd could be easily addressed if it would just co-exist nicely with init scripts. It sort of does, but not nearly far enough, I would be happy with systemd if it ran an init script that it just goes into "dumb" mode and run it like any other interactive script. Don't try to be smart, don't try to keep track of state, no timeouts, none of that stuff just run it.

The old labrador's getting a bit old and his fur is falling out... so let's buy an elephant!

systemd - why would I want it to manage DNS, NTP and more? There are perfectly good, previously "out of the box", solutions for them that can be managed by experts in their field without wondering what cute security hole some weenie has dropped into the systemd elephant.

This was absolutely the final straw for me. I'd already been trying devuan ASCII out on one machine. Once I heard of this all my other machines got blitted to ASCII, and a couple of them are now confirming Beowulf.

I just wanted to write a udev script that ran when my camera was plugged into USB, copy the images off it with progress in a window, and exit when the camera was unplugged.

That didn't seem possible with systemd. Trying to correlate the unplug event to the script running the progress window was something it actively fought.

managed to install ascii the other day, nice and quick when booting.

. . . is a Linux distro which combines the efficiency of systemd with the beautiful user interface of Windows 10, possibly including the new Snap package manager from Canonical.

If Linux Mint could be based on Devuan especially with the Cinnamon interface and their pretty decent set of fairly up to date apps installed & a decent application store and ease of installation, you would pretty much have it.

However Mint took a stand against Snap which I think is a good thing:

https://www.theregister.com/2020/06/02/linux_mint_team_snap/

You can enable it if you want.