Devuan Beowulf 3.0 release continues to resist the Debian fork's Grendel – systemd

The Devuan team has released Beowulf 3.0.0, based on Debian Buster, but with the systemd init system - now standard in Debian - removed. The project began in November 2014 as a fork of Debian with an announcement citing "diverging perceptions of the Debian project" after a battle over the adoption of systemd, and promising to …

[John H Woods]

multiple monoliths

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?

[Greybearded old scrote]

Re: multiple monoliths

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

[Anonymous Coward]

Re: multiple monoliths

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;)

[jake]

Re: multiple monoliths

"why isn't it part of the kernel?"

Simple answer: Linus says no.

[Anonymous Coward]

Re: multiple monoliths

Yes, that too.

[Anonymous Coward]

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

[James Anderson]

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

[Anonymous Coward]

6 x Judean People's Front

21 x People's Front of Judea?

Or vice versa?

[John Robson]

"It solves a problem that people have."

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

[Greybearded old scrote]

Re: "It solves a problem that people have."

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 void linux. YMMV

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

[John Robson]

Re: "It solves a problem that people have."

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....)

[DrewWyatt]

Re: "It solves a problem that people have."

I don't even buy in to the reduced startup time argument for SystemD. I changed a laptop from Ubuntu 20.04 to Devuan ASCII and enjoyed a much shorter startup time afterwards.

[jake]

Re: "It solves a problem that people have."

"sysvinit has some learning curve."

Any system as complex as *nix has a learning curve. There is no getting around this. Even thinking about trying to get around it shows the thinker has no concept of the totality of the system.

[jake]

Re: "It solves a problem that people have."

"What actual benefit does systemd bring?"

It's free, and it kinda works. Other than that ...

[DemeterLast]

Re: "It solves a problem that people have."

When I'm told about faster startup times with systemd, all I hear is "this is for VMs and embedded/hardware devices".

Faster startup makes a lot of sense if you're spinning up dozens or hundreds or thousands of VMs on a cluster. Clean configs and non-binary log files don't mean as much here because all that is just another service controlled by systemd. And if you want a Linux kernel based handheld device (like a phone, tablet, netbook, or maybe a piece of custom kit), then you want it to blaze through the startup.

I'm clearly too dumb to understand systemd, so I tend to use the BSDs where I can. I can never remember from one time to the next how to do certain things on systemd servers, so I prefer something that I can leverage my couple of decades worth of muscle memory. I also prefer to use bare metal whenever possible, so startup times are less meaningful than stability.

[Anonymous Coward]

Re: "It solves a problem that people have."

"What actual benefit does systemd bring?

I can only speak from my personal experience, but I have to say that quite separate from the improved startup times, the new shutdown duration is also a great new feature.

A lot of people poo-poo the decreased startup times, which in many cases are only a fraction of a second faster, saying they're really not that big a deal. But these people are forgetting the big picture, which is rebooting - you need to take both startup AND shutdown times into account.

For instance, take my laptop running xubuntu 14.04: I'd issue a 'sudo reboot' and 15 seconds later it would have completed the reboot sequence and be at the login screen waiting for my input.

This is a huge waste, because when I type 'reboot' I'm usually doing it because I'm about to go make coffee, which takes 5 or 10 minutes. So if making coffee takes 5 minutes then there's 4 minutes and 45 seconds where the machine is just sitting idle!

OTOH, when I "upgraded" that machine to 16.04 with systemd, I found that the shutdown process was suddenly taking 5+ minutes. So after upgrading I'm now able to go make that coffee, secure in the knowledge that the machine isn't sitting idle and being wasted. Also there's no risk of me typing in that reboot command and then getting distracted by a machine which shuts down too quickly, causing me to forget to make that coffee.

Systemd truly is a boon for coffee lovers everywhere.

"Why does it take so long to do this task that used to take literally one second?", I hear you ask, in your whiny, perfectionist, nitpicky, aspie, "expects things to improve rather than get worse" nerd voice. And I'd love to tell you the answer. But since there's zero feedback or log messages of any kind that I can see during this delay, and the system doesn't respond to anything (e.g sysreq hotkeys) during this time, I still haven't managed to figure it out. I suspect it's something to do with network mounts. I would spend time looking into why I have this amazing and exciting new 300+ second delay, but there was apparently a plague of locusts some time between 2014 and 2016, and they've absolutely decimated the field where I grow my fucks.

Interestingly, devuan lacks this...uh... "feature".

So to summarise and and to directly respond to your question: systemd brings coffee, because we now have more time to make it while it spends 5 minutes unnecessarily doing god-knows-what during shutdown.

[GrumpenKraut]

Re: "It solves a problem that people have."

> 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.

[Throatwarbler Mangrove]

Re: "It solves a problem that people have."

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.

[Claptrap314]

Re: "It solves a problem that people have."

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.

[Doctor Syntax]

Re: "It solves a problem that people have."

"Sysvinit executes scripts in lexigraphical order. This was dumb at the time, but really, really hard to change."

I wouldn't call it dumb at all. Things to be processed in a specific order on the one hand and a system which automatically addresses things in lexical order on the other are fairly obvious case of problem and solution. It doesn't matter whether they're scripts or anything else - PDF files to be assembled into a new file by pdfunite is something I've found myself using fairly often recently and used just that approach.

[fobobob]

Re: "It solves a problem that people have."

Being able to reorder and enable/disable your boot scripts with nothing more than 'mv' comes in handy from time to time, and can even be done through init=/bin/sh if something went wrong.

[Claptrap314]

Re: "It solves a problem that people have."

It was dumb because it has always been far better to have explicit dependency information driving the process. Certainly, it is "easy" to reorder your scripts currently--but it is _hard_ to know if you can do so safely. I call it "dumb" because tribal knowledge has never been an acceptable way to ensure good outcomes with computers.

[jake]

Re: "It solves a problem that people have."

"The problem that sysvinit has evolved into a big ball of mud."

Old and klunky, sure. But big ball of mud? Hardly. My 1915 Case traction engine is old and klunky, but it gets the job done for the two days per year that I need it. It squishes big balls of mud, too.

"Few doubt that, the argument is what it should be replaced with."

I recommend, and use, the amalgamation of BSDinit and SysVinit as seen in Slackware. Try it again if you haven't fiddled about with it for a few years.

[oiseau]

Re: "It solves a problem that people have."

... problem that sysvinit has evolved into a big ball of mud.

I see.

So the solution was to replace it with another, bigger ball.

Of steaming shit.

Great. 8^7

O.

[James Anderson]

Re: "It solves a problem that people have."

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.

[John Robson]

Re: "It solves a problem that people have."

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.

[amanfromMars 1]

IT Solves that People Problem following Greater Trails with Enlightening Tales to Tell

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.

[GrumpenKraut]

Re: IT Solves that People Problem following Greater Trails with Enlightening Tales to Tell

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.

[amanfromMars 1]

Re: IT Solves that People Problem following Greater Trails with Enlightening Tales to Tell

Dear amanfromMars 1, I do thing [sic] you are pulling a leg here. ..... GrumpenKraut

Your thinking is incorrect, GrumpenKraut, in this very particular and peculiar case ..... however it may have some encouraging support which ensures it survives on the surface in the mainstream a tad longer.

[Lunatic Looking For Asylum]

Re: "It solves a problem that people have."

> 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 :-)

[GrumpenKraut]

Re: "It solves a problem that people have."

"-- get over it."

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

Me included.

[Phil O'Sophical]

Re: "It solves a problem that people have."

left everybody to come up with thier own shutdown strategy.

# sync;sync;halt

always seemed fine to me...

[Doctor Syntax]

Re: "It solves a problem that people have."

"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.

[Doctor Syntax]

Re: "It solves a problem that people have."

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

The epitome of damning with faint praise.

[nijam]

Re: "It solves a problem that people have."

> damning with faint praise

Damning with fake praise, I think.

[James Anderson]

Re: "It solves a problem that people have."

Window NT. Was the fourth main stream OS architected by Dave Culter.

He is very talented software engineer and while NT was not as good as VMS it was very good.

Microsift may have since mucked it up but NT and its immediate successor XP were solid operating systems which established MS as a serious player in the Server room.

The services part of the OS was very well thought out and very well implemented. So I am not surprised that systemd looks very similar.

[Sven Coenye]

Re: "It solves a problem that people have."

Yes, let's adopt Poettering's shutdown strategy: change the event sequence in udev to suit systemd without giving a thought to anyone else. This had the lovely side effect of breaking shutdown completely if a LUKS partition was in use on SysV init.

(As in - upgrade from Debian Jessie to Stretch and find you can't shut down anymore. Lovely. I've used Debian since the 2.x days, but that was the last straw. Swicthed to Devuan and have not had a reason to look back. And Beowulf runs fine on a Raspberry Pi too.)

[Hans 1]

Re: "It solves a problem that people have."

I unplugged a data drive and could no longer boot with systemd, it waited for the non-essential device!

That is when I switched to devuan.

I have been laughing ever since:

systemd DNS blunder

system random number generator blunder

to name just two clusterfucks of arrogance.

[Denarius]

Re: "It solves a problem that people have."

James, why is this a problem ? Never had it in my HPUX boxen. One script, two links for start and stop and a third option for restart which simply call the stop start functions in the script. Not hard. AIX with its init scripts services manager and a strong preference for iniitab as in other unices. /etc/inittab had stop start respawn of services also if one died. No need for any stuffing around with scripts. AIX had a group of services which was neat and clean. Being able to restart all NFS rand related network services occasionly at one site was very time saving if unusual.

[Anonymous Coward]

Re: "It solves a problem that people have."

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'}

[sw guy]

Re: "It solves a problem that people have."

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

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

[GrumpenKraut]

Re: "It solves a problem that people have."

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

[Anonymous Coward]

Re: "It solves a problem that people have."

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

If you're the sys admin of a linux box and you don't understand shell script then frankly you're in the wrong OS and the wrong job. It would be like like driving a car without knowing how to use the steering wheel.

[Anonymous Coward]

Re: "It solves a problem that people have."

Oh I agree completely, you are hosed on *nix if you can't manipulate your environment in the shell, so much of the, "panic, we should never get here, and if we do, all is lost!" handling on *nix is "here's a shell, good luck."

[Sven Coenye]

Re: "It solves a problem that people have."

Beats a BSOD every day of the week (and twice on Sunday...)

[jake]

Re: "It solves a problem that people have."

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

The problem was that Pottering has a serious ego problem, and Linus kicked him out of Kernel development for not playing well with others. So he (along with fellow member of the kicked out of kernel development club, Kay Sievers) turned his attentions to the next step up in the boot process.

Another problem is that Red Hat needed to find a way to try to monopolize Linux (it's a thing that MBAs are taught to do with their businesses). Adding in a bottle-neck between booting the kernel and a running, usable system was an obvious place to do it ...

It was a match made in hell.

The result, systemd, is a cancer that needs to be cut out of Linux before it infects enough of the system to kill it permanently.

[oiseau]

Re: "It solves a problem that people have."

... systemd, is a cancer that needs to be cut out of Linux before it infects enough of the system to kill it permanently.

Thank you ... 8 ^)

I've been saying the very same thing ever since I finally left MS OSs for Linux and after going through quite a few distributions, realised just how much like the Windows registry systemd was.

The registry is nothing but a developer sanctioned virus running inside the OS and Poettering and his crew want to install the same thing running as systemd in Linux.

And while all this is happening, everyone thinks that all this new Microsoft loves Linux is just a happy turn of events.

O.

[Sitaram Chamarty]

Re: "It solves a problem that people have."

Damn; best comment I've seen about this in the whole thread (and many of the others were pretty good too, so that makes this even better!)

[Nate Amsden]

I like sysvinit

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.

[Steve Graham]

Re: I like sysvinit

I've disliked it ever since I was introduced to it in Solaris. All the multiple symbolic links and changing run order via filename sorting seems clunky to me.

Still, 30 (?) years later, all my boxes are Devuan and i'm still using sysvinit.

[Peter Galbavy]

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.

[Will Godfrey]

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.

[Gene Cash]

My problem with systemd

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.

[Doctor Syntax]

Re: My problem with systemd

Tell Pottering. He'll probably come up with GeneCashCamerad. Either that or WONT_FIX.

[cantankerous swineherd]

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

[Throatwarbler Mangrove]

All I want . . .

. . . 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.

[Jim-234]

Re: All I want . . .

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.

[Doctor Syntax]

Dddly enough I'd just started burning an MX disk, had a look here and found this. You wait ages for a systemd-free Debian 10 and.... Unfortunately Debian, and hence Devuan, never seem to settle on an LTS version of KDE.

Actually I've been using the testing Beowulf on a Pi for my Nextcloud server for months so that's updated.

[jake]

"Unfortunately Debian, and hence Devuan, never seem to settle on an LTS version of KDE."

Have you tried a recent Slackware yet, DrS?

[Citizen99]

"Unfortunately Debian, and hence Devuan, never seem to settle on an LTS version of KDE."

I run Trinity (the fork of KDE3, which does all I need without unnecessary eye-candy fashion changes from year to year) on Devuan, currently Beowolf.

I also keep Debian available on the workstation just to keep track of it, also running Trinity.

[Doctor Syntax]

I stuck with Trinity for a while but started to run into issues with building applications in later releases of Lazarus and wondered if the two weren't getting on. I might give it another try. KDE has followed the usual UI progression from KDE3 > KDE4 > KDE5 of putting shiny before function. UI designers are like an infestation of mice: they get into everything and once they're there they're almost impossible to get rfd of.

[mjflory]

KDE on MX Linux

Dr S, there have been some attempts at a KDE respin of MX. I had good luck with mikejade's one, described here: https://forum.mxlinux.org/viewtopic.php?f=127&t=54469 . My luck with the "Full Monty" respin was not so good. There are others I haven't tried. The KDE page in the MX wiki is very out of date, alas. There's a forum page devoted to KDE respins, though: https://forum.mxlinux.org/viewforum.php?f=127&sid=342539807776f8f77264344969732b9c . There is a list of all respins (not just KDE) here: https://forum.mxlinux.org/viewtopic.php?p=486469#p486469 .

[Doctor Syntax]

Re: KDE on MX Linux

Yup, one of those which seems to include Plasma 5.18. I'd need to spend a bit of time making sure I could reinstall into an LVM file system to preserve /home & other stuff. It's not immediately clear whether MX does that but I now Devuan does.

[Doctor Syntax]

Re: KDE on MX Linux

Damn keyboard!

"I know Devuan does"

Must persuade SMBO I need to replace this laptop.

[amanfromMars 1]

No Possible Mistakes/No Probable Failures .... Pedantic Reign/Semantic Rule.

Damn keyboard!

"I know Devuan does"

Must persuade SMBO I need to replace this laptop. .... Doctor Syntax

That's the secret of great coding, Doctor Syntax ...... to have perfectly accurate descriptors of tasks done to aid performance and expand and extend employment and enjoyment of Immaculate Facilities in Awesome Utilities with Almighty Abilities. It's surely the Holy AI Grail of Virtual Machine Coding, to be able to read and further write about/see and historically record for posterity Future ProgramMING with AI and IT Attending with All and Every Manner of Support and EMPowerment :-) ... and Grand Bewitching Bedevilment :-)

That simple way has anyone and everyone discovering exactly where there are in the Greater Schema of COSMIC Things .... and in Mk Ultra Sensitive Operations .... which is Never Ever No Longer Future Top Secret/Sensitive Compartmented Information.

Which is bound to have many a one a'pondering and a'wondering on what a choice few would be able to do with such a Future ProgramMING as IT Presents .......... well, a Gift indeed which regularly enough can Enjoy and Exalt the Swings from Hellish Curse to Heavenly Blessing ...... so that one is more than just adequately prepared for whatever is desired and to be encountered and satisfied fully.

Such then introduces and leaves one with the Greatest of Expectations that there be an awful lot more where all that came from, with the thought firmly implanted in one's brain too that one is progressing increasingly quickly in the right direction ..... which is both extremely encouraging and attractive, and even addictive, and awesomely exciting and sometimes oft seriously frightening if one be of any particular or peculiar nervous disposition.

But a tad further perseverance has all that unfounded anxiety realised as the phantom enemy, to be vanquished and expunged, which captures and captivates one with residence in the present and past rather than forging novel paths way out ahead and Leading in New Future JOINT AI Ventures ..... hence the advantage guaranteed when sticking to the right courses and simply failing to never ever stop beavering away at what pleases.

Pure simple raw common sense aint complicated like maybe rocket science is.

[Anonymous Coward]

Re: No Possible... ...Rule.

the 0ne that shakes the peers couldn't have said it better, amanfromMars

[jake]

Re: KDE on MX Linux

This laptop has a model M plugged into it. Just sayin'.

[jake]

Linux kernel maintainer Greg Kroah-Hartman's bullshit statement:

"Everybody who has ever worked at that level in the operating system has agreed that systemd is the proper solution."

This is such a bald-faced lie that I'm surprised ElReg is still propagating it.

"If you don't want to use it, you don't have to use it."

Gee, thanks, Greg. How munificent of you. Prat.

[steelpillow]

What most disappoints...

...about the debian adoption of systemd is the way they have encouraged/persuaded so may toolchain developers to abandon compatibility with any other init system. The devuan and other init freeks (sic) spend a lot of time feeding retro-compatible patches upstream where they can, but otherwise having to fork very basic things like udev. "All communities are equal but the systemd community is more equal than others".* FFS!

* Apologies to George Orwell

[Arbuthnot the Magnificent]

"false dichotomy"

They keep pushing it as being "sysvinit vs systemd" because sysvinit is old and not perfect, but completely ignore the existence of OpenRC, S6, runit... I use Artix Linux, Gentoo, GhostBSD, all on OpenRC, works perfectly, simply and understandably. You want to use systemd, fine, but don't try and make everyone else use it.

[steelpillow]

OpenRC oh yes

Just received this via my Devuan mailshot sub:

What's new in Beowulf 3.0.0?

* Based on Debian Buster (10.4) with Linux kernel 4.19.

* Support for ppc64el in addition to the existing i386, amd64, armel, armhf and arm64 architectures.

* runit optional alternative /sbin/init.

* openrc optional alternative to sysv-rc service and runlevel control.

* Standalone daemons (eudev, elogind) to replace aspects of monolithic systemd.

* New boot, display manager and desktop themimg.

Thank you my VUAs.

[Anonymous Coward]

My sole (and tiny) experience of systemd

I was on a call with one of our unix admin folk and I needed to know whether a couple of 3rd party services were up and running. I had no idea what their process names would be etc...

The unix admin person typed in systemctl ...some voodoo... and got a small listing of the services and their parents in a little ascii tree diagram (very xtree) along with service status and so forth. Just what I needed to know. Seemed pretty useful.

But I am not an admin, nor a kernel builder etc...

[Hans 1]

Re: My sole (and tiny) experience of systemd

Yeah, we would use pstree for that. The program to query the processes is ps, so the name is quite easily remembered.