MX Linux Forum

Posted: **Fri May 10, 2019 10:55 pm**

This is Luke Smith on one of he's bush walk rants..
I must say that I have been using Debian buster for a couple of months now which is systemd and I have a not one problem with it, everyone has a different opinion but each to their own..

https://www.youtube.com/watch?v=IglXPVJ98t0

Also here is a response form Distrotube.

https://www.youtube.com/watch?v=Dt815yGk8Ho

Posted: **Sat May 11, 2019 6:30 am**

What an excellent video, thanks for posting.

I do agree with most of what he is saying but I do have specific concerns about systemd in respect of the size of the codebase and the memory usage.

Here's the (cropped) ps_mem output for my Debian buster system with systemd as PID1:

Code: Select all

 Private  +   Shared  =  RAM used       Program
  1.2 MiB + 488.5 KiB =   1.7 MiB       systemd-logind
  1.3 MiB + 482.5 KiB =   1.8 MiB       systemd-timesyncd
  2.1 MiB + 153.5 KiB =   2.2 MiB       systemd-udevd
  4.7 MiB + 464.5 KiB =   5.1 MiB       systemd-journald
  4.5 MiB +   3.6 MiB =   8.1 MiB       systemd (3)

And here are the same functions being run in my Alpine Linux system using OpenRC:

Code: Select all

 Private  +   Shared  =  RAM used       Program
 84.0 KiB +  35.5 KiB = 119.5 KiB       openrc-init
 44.0 KiB + 128.5 KiB = 172.5 KiB       syslogd
116.0 KiB + 106.5 KiB = 222.5 KiB       login
172.0 KiB + 100.0 KiB = 272.0 KiB       supervise-daemon (2)
288.0 KiB +  23.5 KiB = 311.5 KiB       chronyd
472.0 KiB + 975.0 KiB =   1.4 MiB       udevd (2)

That's quite a saving :-)

And for the actual binaries we have:

Code: Select all

shinken:~$ ls -lh /lib/systemd/systemd
-rwxr-xr-x 1 root root 1.5M Apr  8 11:59 /lib/systemd/systemd
shinken:~$ ls -lh /mnt/alpine/sbin/openrc-init                                                     
-rwxr-xr-x 1 root root 14K Mar 10 10:59 /mnt/alpine/sbin/openrc-init
shinken:~$

So systemd has a significantly larger attack surface as well.

Oh, and I run Alpine without PulseAudio...

Posted: **Sat May 11, 2019 8:32 am**

I stopped watching when he started dissing "boomers" (baby boomers) for being resistant to any and all changes since I am one. (A boomer, not a change.(Also, Gnome is pronounced "nome", not "ganome", The "g" is silent, like the "l" is in luser.

) (Kids these days! Get off my lawn!

)

Here's an even better (IMHO) albiet more technical video about systemd by Benno Rice, a FreeBSD dev: https://www.youtube.com/watch?v=o_AIw9bGogo

Posted: **Sat May 11, 2019 8:57 am**

He also said that the other init systems were good too.

He just doesn't have anything really for or against it.

Maybe this thread kind of illustrates what he was talking about. As soon as somebody says anything not negative about systemd. People advocating for will take that as an endorsement as and agenda to bring everyone into the borg hive. Which systemd has taken over on allot of distros. So much so that it is becoming the only option for many.

Maybe there is also some justified dislike for systemd too.

I have my reasons for not wanting systemd. And I for sure would not like all packages to be developed only for systemd. Which allot cater to the ubunto userbase.
I would rather have the init be a background process and have the aps developed where they could run without int integration. Allowing for more choice.

Regardless, people should be able to like or not like whatever they want.

I do watch Luke Smith sometimes. It is kinda like hanging out.

Posted: **Sat May 11, 2019 9:42 am**

I can understand the dislike for systemd in a way, but alas it has a rubbish name. The name "systemd" suggests to me it's one daemon and one binary that tries to do everything, which as almost everyone knows (and Microsoft found out the hard way) is not such a good idea after all. I bet if it was called the "Linux System Layer" or something people wouldn't have been so negative. Welcome to the wonderful world of marketing.
At least it isn't anything like svchost.exe and hopefully will never end up that way.

Posted: **Sat May 11, 2019 10:02 am**

The name "systemd" suggests to me it's one daemon and one binary that tries to do everything

it's not only the name, they do try to do everything.

Posted: **Sat May 11, 2019 10:14 am**

I think the problem with systemd is that it tries to be everything instead of just a boot manager. It gets it's fingers into every part of the system. But on the Distros I have tried that use it I have had no real problems from an ops view. But It does break the code of do one thing and do it well. JMHO.

Posted: **Sat May 11, 2019 10:42 am**

The Benno Rice video that JayM posted (post #3) is very informative. If you have not, I suggest you watch it. It gave me a better understanding of systemd from what appears to be an informed and neutral source. What I got out of it is that it s not all that bad as some would have you believe and provides advantages.

I have booted MX to it on occasion with no ill affects. I am running it now for an extended trial period and I doubt that any problems will arise. I really do not care what init system I use as long as it works.

Posted: **Sat May 11, 2019 10:49 am**

JayM wrote: Sat May 11, 2019 8:32 amGnome is pronounced "nome", not "ganome", The "g" is silent

I think Luke's pronunciation is actually correct (for the desktop at least).

kc1di wrote: Sat May 11, 2019 10:14 am I think the problem with systemd is that it tries to be everything instead of just a boot manager

You don't have to use any of the extra features at all, they are all optional.

If you find something you don't like then you can just disable it or use

Code: Select all

# systemctl mask nasty.service

It will then not be started at all, ever.

And Debian already splits out some of the functionality, for example machinectl(1) is part of the systemd-container package.

Adrian wrote: Sat May 11, 2019 10:02 am they do try to do everything

I really like having a set of unified userspace tools all created and maintained by the same team, it reminds me of true UNIX systems :-)

For me systemd is a bit like cheesecake: I know it's bad for me but it tastes so good...

Posted: **Sat May 11, 2019 11:22 am**

richb wrote: Sat May 11, 2019 10:42 am The Benno Rice video that JayM posted (post #3) is very informative. If you have not, I suggest you watch it. It gave me a better understanding of systemd from what appears to be an informed and neutral source. What I got out of it is that it s not all that bad as some would have you believe and provides advantages.

I have booted MX to it on occasion with no ill affects. I am running it now for an extended trial period and I doubt that any problems will arise. I really do not care what init system I use as long as it works.

I used systemd for a good long time on manjaro (arch-base). If things work well, they are just fine. However, when you get in trouble (and many people here know, I can get there a lot) debugging and fixing can be a horror show (not always... but enough such that it is worth avoiding). I think that point speaks to Torvald's issues with systemd.

Posted: **Sat May 11, 2019 11:31 am**

I get the feeling that you do modify your system quite a bit. I do not. I will share my experiences as time passes if i do get in trouble.

Posted: **Sat May 11, 2019 12:22 pm**

This discussion will never end because he clearly doesn't understand what's wrong with systemd. It's not a question of technology. It's a question of monopolization, centralization and tech lock-in. You can't just switch systemd components for alternatives, because it hasn't been designed to allow for that.

I haven't had any problems with systemd in Xubuntu 19.04 for more than 24 hours. What does that prove? I didn't have any problems with Upstart for more than 8 years and I didn't have any problems with sysvinint for more than 2 years. How to create a problem-free init for desktop users has already been solved.

Systemd is Red Hat's way to standardize and gain control and that can make perfect sense in an enterprise environment. What if "competitors" like Suse and Canonical use your technology? Then you have a competitive advantage, because you decide how Linux will evolve and they can't do anything but follow your lead.

Without knowing the details I don't think comparing systemd to svchost.exe is far-fetched. Although systemd consists of many binaries it has to be treated as one binary and the only way to escape is to run something else as PID1. You can compile your own kernel, but it's not like anyone is going to compile their own version of systemd and replace the original systemd in their distro. So with systemd you have to accept the version your distro gives you or do what antiX/MX Linux did and remove it from PID1. So in that respect systemd is more monolithic than the Linux kernel, because many people compile their own kernels, but with systemd it's hard to change it in a meaningful way (get rid of binary logs for example).

I agree that there is no reason to get upset over systemd if you accept that desktop Linux is an enterprise product given to you by Red Hat. If you are more idealistic like I am and think that desktop Linux (and desktop Linux applications) should be engineered in a more tech agnostic and Unix way then systemd is basically like using a top-down system like Windows. It's open source, but it's also more than a million lines of interconnected code so I doubt anyone outside the systemd developer circle really tries to understand the code. Except the NSA guys of course because they are paid to understand systemd and everything else and maybe contribute a line or to. Poettering actually stated that it is important to keep three-letter-agencies happy. He is working for Red Hat and Red Hat is a big defense contractor so I assume Red Hat doesn't want to anger the guys working for US intelligence.

To be honest I don't have a problem with backdoors in software (I use Windows from time to time), because there are many ways for intelligence agencies to track you even if you use 100 % backdoor-free software (which probably doesn't exist because a security bug is a potential backdoor). But I do have a problem with systemd pushing out other players from desktop Linux and establishing itself as a mandatory component for desktop Linux. I never liked the idea that the alternative to Windows is another top-down product called Red Hat Linux (in all its variations).

Posted: **Sat May 11, 2019 12:25 pm**

The introduction of systemd stopped the learning experience in Linux what many distros were proud about when comparing with Windows. Learning was not about what the apps do but being able to know and config inside the system. One of the beauty was to write your own bash scripts in init.d. Example, this how KNOPPIX made the first live CD. If systemd had been in beginning of Linux, who-knows, this feature may not have been today (not been discovered). Before systemd It was said, Windows creates "illiterate" computer users. Can this also be said about systemd?

Posted: **Sat May 11, 2019 1:10 pm**

Luke was mostly justifying the idea of systemd rather than its implementation (and he said that pretty explicitly).
The most profound thing he said in the talk was that if they had created APIs for managing these tasks first there wouldn't be the sort of strong negative reactions there were (and still are).

If they had done that, then systemd wouldn't have to be at PID1 to use any of the other bits of it through defined APIs and I would be a lot happier with the project.

But that's also not the way code hackers usually start projects. And once you have something that works in place you don't tear it apart to create APIs between the bits unless you really, really have to.

You don't have to be a conspiracy theorist or hate Mr. Poettering or even disagree with the concept of a system manager to dislike the implementation that now exists. I don't think systemd is a Red Hat plot, nor an NSA one.

I haven't used systemd much - just on the leased VPNs. And the only problems I have ever had with it were when trying to add systemd service files to small programs without them so I wouldn't have to manually start and background them. I would follow all the steps, read all the guides that worked for others with no results. The service won't start. So I start it manually and background it.
A week later I find that systemd has finally deigned to notice it and it is now running as a systemd service instead of under my user and the commands that refused to work before now do.
In another case it never worked.

Now this can't be a common problem with systemd or debian packages that install services would frequently fail, and that's not the case. But I couldn't diagnose why things wouldn't work, nor why they started to.

I hate unpredictable systems.

Posted: **Sat May 11, 2019 1:57 pm**

There are no shortage of corporations and agencies that want into everyone's computer.

Cellphones are being tracked and censored, the big techs all have their invasive ToS. And now MS Office is preventing people from typing select words and phrases into a word processor.

I have heard that IBM has bought shares into Canonical.

Even with the minuscule market-base that linux has, they will not leave that alone.

So at least for me, I share that concern with others.

Posted: **Sat May 11, 2019 2:14 pm**

Would it help any for basic versions of the distro to be made available with just a means of accessing Package Manager so we get just a bare bones distro that we can add, or not, the programs we want rather than having suites like Libra Office, etc pre-installed? For me I can count the number of times I use LO Writer per year on the thumbs of one hand and I never use any of the other pre-installd LO offerings.

Posted: **Sat May 11, 2019 2:51 pm**

In the video, the presenter claims "never met a systemd detractor who can articulate what, specifically..."

sorted: the topmost links are intended as "easy reading", the last is the most "in depth"
15-logical-fallacies
persuasive-reasoning-and-fallacies
https://yourlogicalfallacyis.com/
https://en.wikipedia.org/wiki/List_of_fallacies
The Internet Encyclopedia of Philosophy::Fallacies

Really? The presenter has never visited the following pages, has never met anyone who has done so and can, quite clearly, articulate dozens of specific problematic systemd characteristics // anti-features...

Arguments_against_systemd
and
List_of_articles_critical_of_systemd

Regardless of the presenter's agenda for swaying the hearts n minds of bobbleheads... in the absence of critical thinking skills, we're doomed.

Posted: **Sat May 11, 2019 3:14 pm**

I've been using Debian since Sarge, nearly 15 years by now. In the past year I switched my laptops over to MX from Xubuntu and love it.

I was predisposed to dislike systemd when it came out but it really does make so many things so much easier. It's intuitive and well engineered, easy to debug, and contrary to popular belief, entirely modular. When the controversy around switching the init system in Debian started getting really heated I messed around with various configurations of it in a Gentoo VM for a couple months until I was reasonably sure it was nothing too evil. I kept trying to find things wrong with it and other than philosophical problems I just couldn't.

Crap like insecure language specific package managers (looking at you npm) and the idea that snap and flatpack should replace traditional Linux file managers are much bigger problem, IMHO.

Posted: **Sat May 11, 2019 3:17 pm**

turtlebay777 wrote: Sat May 11, 2019 2:14 pm Would it help any for basic versions of the distro to be made available with just a means of accessing Package Manager so we get just a bare bones distro that we can add, or not, the programs we want rather than having suites like Libra Office, etc pre-installed? For me I can count the number of times I use LO Writer per year on the thumbs of one hand and I never use any of the other pre-installd LO offerings.

The definition of a Linux distro is an integrated suite of software made to be used together. It's better to have it on the install image and not need than to have people trying to download it from random web sites. Also, countries with inexpensive, unmetered broadband are still in the minority.

Posted: **Sat May 11, 2019 3:23 pm**

manyroads wrote: Sat May 11, 2019 11:22 am debugging and fixing can be a horror show

I find debugging with systemd to be much easier because of the journal (which can even be read from a machine which is not running systemd by using the strings(1) command).

dreamer wrote: Sat May 11, 2019 12:22 pm Although systemd consists of many binaries it has to be treated as one binary and the only way to escape is to run something else as PID1.

That's just nonsense: my Debian buster system doesn't use systemd-networkd or systemd-resolved until I enable the services and I can't run systemd-nspawn until I install the systemd-container package.

And as I already mentioned any unwanted unit files can be disabled or masked, there is no need to recompile the systemd package at all.

rasat wrote: Sat May 11, 2019 12:25 pm One of the beauty was to write your own bash scripts in init.d

And one of the beauties of systemd is that you don't have to learn how to script to get services running to your liking.

timkb4cq wrote: Sat May 11, 2019 1:10 pm I couldn't diagnose why things wouldn't work, nor why they started to.

The systemd journal is great for that, guide here:

https://www.digitalocean.com/community/ ... stemd-logs

turtlebay777 wrote: Sat May 11, 2019 2:14 pm Would it help any for basic versions of the distro to be made available with just a means of accessing Package Manager so we get just a bare bones distro that we can add, or not, the programs we want rather than having suites like Libra Office, etc pre-installed?

The Debian netinstall ISO image does just that if you de-select all of the desktops.

Arch & Alpine Linux both install minimal systems by default.

skidoo wrote: Sat May 11, 2019 2:51 pm IThe presenter has never visited the following pages

Yeah, the "guides" on your linked site for removing systemd from Debian will break your box so I'm not sure anybody should trust anything there.

Posted: **Sat May 11, 2019 3:31 pm**

turtlebay777 wrote: Sat May 11, 2019 2:14 pm Would it help any for basic versions of the distro to be made available with just a means of accessing Package Manager so we get just a bare bones distro that we can add, or not, the programs we want rather than having suites like Libra Office, etc pre-installed?

antiX does this with net, core, base & full options. antiX is also designed to be essentially WM/DE neutral so starting with a small core iso and building your own customized environment is quite reasonable. Before MX-14 debuted I used antiX core to make a KDE desktop resembling MEPIS for a machine which was unable to run the MEPIS 12 beta.

This makes less sense for MX since it is designed and customized around XFCE4. This already means having a lot of stuff installed. Taking away all LibreOffice would still leave the iso well over 1 GB. The software has grown beyond the point where we can fit a reasonably complete MX version on a CD. While reasonable people can disagree we feel that having an immediately usable environment for most common tasks is more important than the difference between a 1.1 GB & 1.3GB iso.

Posted: **Sat May 11, 2019 3:38 pm**

I'm not a dummy - I use the logs. However the systemd logs weren't at all helpful in my situation. They showed no errors running the service file but ps -ax showed the service wasn't running. I couldn't tell whether it had never started at all or been started then somehow exited.

Posted: **Sat May 11, 2019 3:55 pm**

timkb4cq wrote: Sat May 11, 2019 3:38 pm I couldn't tell whether it had never started at all or been started then somehow exited.

The journal would show that.

Did you try

Code: Select all

journalctl -u custom.service

^ That would show all journal entries for custom.service

Or

Code: Select all

systemctl --failed

^ That would show all failed units.

I'm not trying to suggest that you are a "dummy" but I have created quite a few custom unit files and the journal always shows exactly what's happening with them.

Posted: **Sat May 11, 2019 4:09 pm**

Yes, the journal is supposed to show that.
It didn't. It showed that I ran the start command. It showed the service wasn't running. Nothing more.
Given, this is on a self-managed VPS. I'm running debian & have root but it's not my hardware.

Posted: **Sat May 11, 2019 8:01 pm**

dreamer wrote: Sat May 11, 2019 12:22 pm
Systemd is Red Hat's way to standardize and gain control and that can make perfect sense in an enterprise environment. What if "competitors" like Suse and Canonical use your technology? Then you have a competitive advantage, because you decide how Linux will evolve and they can't do anything but follow your lead.

I agree that there is no reason to get upset over systemd if you accept that desktop Linux is an enterprise product given to you by Red Hat. If you are more idealistic like I am and think that desktop Linux (and desktop Linux applications) should be engineered in a more tech agnostic and Unix way then systemd is basically like using a top-down system like Windows. It's open source, but it's also more than a million lines of interconnected code so I doubt anyone outside the systemd developer circle really tries to understand the code. Except the NSA guys of course because they are paid to understand systemd and everything else and maybe contribute a line or to. Poettering actually stated that it is important to keep three-letter-agencies happy. He is working for Red Hat and Red Hat is a big defense contractor so I assume Red Hat doesn't want to anger the guys working for US intelligence.

Red Hat/IBM is what this all boils down to. Red Hat says 'jump', and Debian asks 'how high' and Ubuntu has no choice but to follow suit. Once Red Hat makes a decision, we get stuck with a Default Gnome desktop, systemd, and whatever else comes down the pipe.
Right now we can resist systemd and put up with a few slight bugs, wifi doesn't consistently connect, brightness issues upon resume, a few other bugs here and there on certain hardware that pops up when you don't use systemd. I think those type issues will get much worse over time and more serious because I don't see a stopping point with systemd.
I fear in the end we will have to grit our teeth and accept systemd or continue to bang our head against the wall over it :(

Posted: **Sat May 11, 2019 10:42 pm**

Funny how a post about a video bemoaning the fact that a lot of discussion about systemd is fuelled by uninformed populist opinions and biases should spawn pages in the thread and become sprinkled with comments fuelled by uninformed populist opinions and biases.

Posted: **Sat May 11, 2019 11:48 pm**

Wow systemd is a popular topic. But as in my 1st post update from Distrotube in response to Luke Smith we have choices, meaning users it is also nice to see some great responses.

This reminds me of systemd.

sunrat wrote: Sat May 11, 2019 10:42 pm Funny how a post about a video bemoaning the fact that a lot of discussion about systemd is fuelled by uninformed populist opinions and biases should spawn pages in the thread and become sprinkled with comments fuelled by uninformed populist opinions and biases.

Posted: **Sat May 11, 2019 11:58 pm**

Head_on_a_Stick wrote: Sat May 11, 2019 3:55 pm
timkb4cq wrote: Sat May 11, 2019 3:38 pm I couldn't tell whether it had never started at all or been started then somehow exited.
The journal would show that.

Did you try
Code: Select all
journalctl -u custom.service
^ That would show all journal entries for custom.service

Or
Code: Select all
systemctl --failed
^ That would show all failed units.

I'm not trying to suggest that you are a "dummy" but I have created quite a few custom unit files and the journal always shows exactly what's happening with them.

I think the point is that the idea of binary logs in this position is retarded at best. The purpose of a diagnostic log is so that you can find out what went wrong. Note I said "in this position." There are places for binary logs, such as firewalls where you can expect packet logs to not be translatable in text form easily, and also where many entries are made at a given time.
This isn't the case for what systemd is trying to do and only makes log file corruption much more difficult to recover from. If you really want to save space, compress the logs upon rotation (points to syslogd). Most daemons and other programs using syslogd will produce human-readable text entries for the syslog() function. Moving to a binary-only format for that won't help anything.

Posted: **Sun May 12, 2019 3:29 am**

Head_On_A_Stick wrote:
skidoo wrote:The presenter has never visited the following pages
Yeah, the "guides" on your linked site for removing systemd from Debian will break your box so I'm not sure anybody should trust anything there.

If you can cite URLs for one or more known-broken "guides" within the wiki pages (perhaps well-intended, but now outdated?), I will followup by removing them or at least editing and placing warning::outdated disclaimers. If you cannot, then your quoted reply stands as unsubstantiated and unwarranted FUD.

Mistakes happen, and previously accurate information becomes outdated.
edit:
removed links unrelated to the topic-at-hand

@4:50 "systemd is all over the place; systemd might as well be a part of linux. I'm sorry, get over it."

@5:26 "systemd starts a lot of these services in parallel"
Yes, it does, but he (along with many blathering ill-informed "supporters") claims this as a benefit of systemd.
spartpar has been available since 2003 (per the date shown in that online manpage)
and it is utilized by the status quo antiX init, as well as the MX live init.

@7:40 "There's no such thing as running linux without pulseaudio."

takeaway: Another day, another terrible (weak) video from a "buy my merch" attention-seeking Tuber.

Posted: **Sun May 12, 2019 4:13 am**

re: the second, belatedly linked video

@4:50 "do we have a double standard? None of you systemd haters seem to have a problem with the linux kernel."

skidoo doesn't "hate" systemd (and, FWIW, skidoo uses pulseaudio on antiX)

Double standard?!? I cherish the "don't break userspace" mantra of the kernel developers.
I have learned to loathe the predictably recurring break/fix modus operandi of the systemd//polkit//gnome//freedesktop.org camp ~~ I recognize it as a tactic, intended to "wear down" any would-be developers of non-camp components who attempt to maintain "compatibility with"

@6:53 "I want legit answers of how using systemd caused you some sort of pain in your computing life"

Right, and that's exactly what//why I linked to those wiki pages which linkthru to attestations written by in-the-trenches sysadmins and (dis)affected users.

If the Tubertalkers would bother to visit, the "pain(s)" are evident across any desktop-oriented distro forum.
Oops. UUID of the swap partition has changed. Fullstop.
^---- arguably the correct behavior on a server, but painful (and ridiculously, infuriatingly opaque) when a casual user encounters inability to boot on a desktop PC

Posted: **Sun May 12, 2019 5:37 am**

skidoo wrote: Sun May 12, 2019 3:29 am If you can cite URLs for one or more known-broken "guides" within the wiki pages (perhaps well-intended, but now outdated?), I will followup by removing them or at least editing and placing warning::outdated disclaimers.

Specifically: the advice for pinning systemd to -1 will break most desktops completely because they all depend on a working login session, which is provided by systemd-logind and this requires the systemd package.

Links:

http://without-systemd.org/wiki/index.p ... ge_Systemd

http://without-systemd.org/wiki/index.p ... variant.29

And the steps listed on the Debian buster page will result in a desktop with no access to input devices, thus forcing a hard shutdown that may corrupt the filesystem:

http://without-systemd.org/wiki/index.p ... stallation

Thanks in advance for correcting those pages, they've been bugging me for a while now

skidoo wrote: Sun May 12, 2019 3:29 am we must now distrust anything posted by Head_On_A_Stick, eh?

Absolutely.

I would always advise people to only ever trust one person: themselves.

skidoo wrote: Sun May 12, 2019 3:29 amstill awaiting cleanup of your reduntantly posted misinformation here: http://forum.mxlinux.org/viewtopic.php? ... bunsenlabs

Ah, thanks for reminding me, I forgot about that.

That was rather embarrassing for me, I haven't been involved in BunsenLabs for quite a while now and my memory clearly isn't what it used to be.

Posted: **Sun May 12, 2019 5:41 am**

Oops. UUID of the swap partition has changed. Fullstop.
^---- arguably the correct behavior on a server, but painful (and ridiculously, infuriatingly opaque) when a casual user encounters inability to boot on a desktop PC

I filed a bug on this at systemd in early 2014, when my Manjaro hung up after installing a second distro and the stated instructions failed.
They said it was user error but no clue as to why.

Posted: **Sun May 12, 2019 6:03 am**

AK-47 wrote: Sat May 11, 2019 11:58 pm I think the point is that the idea of binary logs in this position is retarded at best.

The binary format allows messages from such sources as ATA SMART blobs, SCSI sense data, coredumps & firmware dumps to be included directly (which is not possible with syslogd) and also makes direct export in, for example, JSON format possible.

The journal data is also authenticated, which makes undetected manipulation impossible (unlike with syslogd).

AK-47 wrote: Sat May 11, 2019 11:58 pm makes log file corruption much more difficult to recover from

If the journal entry is corrupted then it is rotated out and stored, the functionality of the logging mechanism is not compromised further.

AK-47 wrote: Sat May 11, 2019 11:58 pm If you really want to save space, compress the logs upon rotation (points to syslogd).

The rotation that occurs under syslogd is time-based whereas the systemd journal can be configured to limit disk usage to specific amounts.

There are many problems with syslogd and the systemd journal was designed to overcome the limitations, here is an explanation for those who are interested:

https://docs.google.com/document/pub?id ... UEHIX3MSTs

And anyway on my Debian systems the journal and syslogd both run together so either can be used.

Richard wrote: Sun May 12, 2019 5:41 am
Oops. UUID of the swap partition has changed. Fullstop.
^---- arguably the correct behavior on a server, but painful (and ridiculously, infuriatingly opaque) when a casual user encounters inability to boot on a desktop PC
I filed a bug on this at systemd in early 2014, when my Manjaro hung up after installing a second distro and the stated instructions failed.
They said it was user error but no clue as to why.

There is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.

I think it is correct for the init system to alert the user to failed mountpoints and the fix is to edit /etc/fstab with the correct swap UUID.

Posted: **Sun May 12, 2019 6:39 am**

One thing we miss here is the average op doesn't really care if it is SysV or systemd as long as the machine boots and works for what he/she has to accomplish. I have no hate for systemd, Just stating the fact that it was forced upon folks in many distros and is more complicated for the average person to understand, not because it's of itself more complicated but because it not the way it was always done. One of the wonderful things about linux has always been choice. MX gives that choice right not something Debian and other distro do not do easily when it comes to boot systems. Which ever one you like use it and be glad you have a choice.

Posted: **Sun May 12, 2019 8:14 am**

Yup. First it was PulseAudio foisted on everyone, now systemd. I wonder what's next. All these big new "improvements" that take away the users' choice seem to be multiplying in Linux. Mine works fine now (I use Linux Lite on the laptop, and MX with sysinit on the desktop), but when they were first forced on me they were buggy and resource-hungry pains in the arse. And both are becoming impossible for most users to avoid. Nothing was broken to begin with before these monsters arrived, so why was it "fixed?" Because devs of certain DEs and apps insisted on making it necessary.

Posted: **Sun May 12, 2019 8:58 am**

Linux is still all about choice, isn't it? Nothing is being "forced on" anyone. I've chosen to use Linux, and I could choose to use something else instead. And it's clear that not everyone agrees that systemd is as awful as some make it out to be.

Posted: **Sun May 12, 2019 9:10 am**

Head_on_a_Stick wrote: Sun May 12, 2019 5:37 amI would always advise people to only ever trust one person: themselves.

So presumably then you don't run MX Linux or antiX Linux, but rather a custom hand-crafted OS on custom hand-crafted hardware with custom hand-crafted components such as a custom hand-crafted CPU, that you made from beach sand.

Head_on_a_Stick wrote: Sun May 12, 2019 6:03 amThe binary format allows messages from such sources as ATA SMART blobs, SCSI sense data, coredumps & firmware dumps to be included directly (which is not possible with syslogd) and also makes direct export in, for example, JSON format possible.

Although a log is meant to be a diagnostic tool, not the diagnosis itself. I don't see why a log should be in a binary format unless there's primarily binary data associated with it.

Head_on_a_Stick wrote: Sun May 12, 2019 6:03 amThe journal data is also authenticated, which makes undetected manipulation impossible (unlike with syslogd).

I admit that is a bit of a problem, where processes can claim to be another program. However that doesn't mean the journal is immune, if you're in root you can just write some gibberish to the log file and corrupt it. No different to good ol' syslogd.

Head_on_a_Stick wrote: Sun May 12, 2019 6:03 amIf the journal entry is corrupted then it is rotated out and stored, the functionality of the logging mechanism is not compromised further.

I didn't say logging would be compromised, only it would be harder to get a glimpse of existing log entries. Although having thought about this a bit further I'll gladly retract my statements about the binary logging format, since it is possible to have a binary log format that's quite resistant to corruption (eg. one which is ammend-only and doesn't try to be a database with indices etc), and in fact I can see a benefit to it in some ways.

Head_on_a_Stick wrote: Sun May 12, 2019 6:03 amThe rotation that occurs under syslogd is time-based whereas the systemd journal can be configured to limit disk usage to specific amounts.

It is possible to set this up with a shell script that deletes old archives, although I agree there should be an easier way to do it with logrotate.

Head_on_a_Stick wrote: Sun May 12, 2019 6:03 amThere are many problems with syslogd and the systemd journal was designed to overcome the limitations, here is an explanation for those who are interested:

https://docs.google.com/document/pub?id ... UEHIX3MSTs

And anyway on my Debian systems the journal and syslogd both run together so either can be used.

Fantastic, now there are two entirely different logging systems to look at when something goes wrong. Credit where credit is due though, I can see why they would want to make these design decisions, although it appears overengineered (eg. totally random UUIDs for log entries). They like to throw around the "syslogs are not indexed" argument a bit, but I don't see why this is even necessary. It hasn't been necessary for the last 30 years and is probably not going to be necessary in the future. They are log files, after all, and not databases. If your logs become so large that they can't be managed without the log system doing the indexing, perhaps you should read them.

Head_on_a_Stick wrote: Sun May 12, 2019 6:03 amThere is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.

Which is still a waste of 90 seconds. It's not FUD, it's a genuine issue that a genuine user faced, reported, and got told to get stuffed.
The developers' attitudes are a bit concerning too. Here's an example of where a systemd developer tried to make the developer of tmux add systemd-specific code to their program: https://github.com/tmux/tmux/issues/428

Artim wrote: Sun May 12, 2019 8:14 am Yup. First it was PulseAudio foisted on everyone, now systemd. I wonder what's next.

Pardon my ignorance, but what was wrong with PulseAudio? Was there something that was better than PulseAudio that was in use before?

Posted: **Sun May 12, 2019 9:42 am**

AK-47 wrote: Sun May 12, 2019 9:10 am So presumably then you don't run MX Linux or antiX Linux

No, I'm testing Debian buster at the moment but my main operating system is OpenBSD, which doesn't include systemd at all (but can run the GNOME desktop, interestingly).

I don't really like pre-configured distributions, I prefer a tabula rasa which I can configure myself.

AK-47 wrote: Sun May 12, 2019 9:10 am if you're in root you can just write some gibberish to the log file and corrupt it.

My point was that it is not possible to tamper with the systemd journal without alerting the administrator.

Anybody who manages to compromise a system will want to doctor the logs to conceal their malfeasance — this is possible with syslogd but not possible with the journal, which is a major advantage of the binary format.

AK-47 wrote: Sun May 12, 2019 9:10 am Fantastic, now there are two entirely different logging systems to look at when something goes wrong.

Not on my system:

Code: Select all

shinken:~$ systemctl is-enabled rsyslog
disabled
shinken:~1$

The systemd journal records everything, syslogd doesn't record everything and requires several other logging services to provide full coverage.

AK-47 wrote: Sun May 12, 2019 9:10 am They like to throw around the "syslogs are not indexed" argument a bit, but I don't see why this is even necessary. It hasn't been necessary for the last 30 years and is probably not going to be necessary in the future. They are log files, after all, and not databases. If your logs become so large that they can't be managed without the log system doing the indexing, perhaps you should read them.

The systemd journal collates all the logs and offers an interface by which to filter the results with a variety of methods.

For example, syslogd lacks monotonic or timezone-based timestamps whereas with systemd I can do this:

Code: Select all

shinken:~$ journalctl -u systemd-networkd --since "3 hours ago" --no-p
-- Logs begin at Sun 2019-05-12 08:34:31 BST, end at Sun 2019-05-12 14:26:05 BST. --
May 12 12:20:08 shinken systemd-networkd[355]: wlp2s0: Lost carrier
May 12 12:20:08 shinken systemd-networkd[355]: wlp2s0: DHCP lease lost
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: Gained carrier
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: DHCPv4 address 192.168.1.212/24 via 192.168.1.254
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: Configured
shinken:~$

Neat, eh?

AK-47 wrote: Sun May 12, 2019 9:10 am Which is still a waste of 90 seconds. It's not FUD, it's a genuine issue that a genuine user faced, reported, and got told to get stuffed.

I was responding to the allegation of a "fullstop" and the suggestion that the system could not boot, which are both nonsense.

And the timeout can be reduced by editing DefaultTimeout{Start,Stop}Sec in /etc/systemd/system.conf

AK-47 wrote: Sun May 12, 2019 9:10 am The developers' attitudes are a bit concerning too. Here's an example of where a systemd developer tried to make the developer of tmux add systemd-specific code to their program:

Well I have actually submitted an issue to the systemd team myself I was very pleased with how Lennart dealt with it:

https://github.com/systemd/systemd/issues/6684

Posted: **Sun May 12, 2019 11:13 am**

@HOAS,

There is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.

I respectfully submit that you might be correct that there is no longer a fullstop; however, I may be wrong about the year, might have been earlier.
The point is, I waited over 5 minutes, applied the suggested commands but systemd remained adamant and unyielding.
I am relieved if that particular gotcha has been corrected. At the time I filed the bug report it had not.
Thanks for your comment.

Posted: **Sun May 12, 2019 11:39 am**

Sorry Richard, my FUD accusation was directed at skidoo rather than your good self, I should have made that more clear.

And yes, the default timeout for a swap failure is now 90 seconds.

Posted: **Sun May 12, 2019 12:37 pm**

This thread doesn't lead anywhere when users pull selected sentences out of the content to support their opinion.

Posted: **Sun May 12, 2019 12:58 pm**

Luke Smith point that people are just uninformed haters, or the argument that, some give is that people are crazy, nothing like that would ever happen. Or somebody would see it and blow the whistle.

These are variations of the same old thing.

But of course the alarmists for the most part always been right, The Riichard Stallman's, Edward Snowden's, and William Binney's, have only confirmed what others what regular alarmists were worried about.

I will reply with one of Luke Smith's own videos.

https://www.youtube.com/watch?v=btHano6wHgA

In the video, He says straight out that he is not that ethical, and the only reason that he uses free software is because it is better, not because he is ethical.
Not because he has principals.

My position is different from Luke's position is that I use free software on principal And in many cases I use it over software that in some cases is better.

I get that for many, the ethics don't come into the picture.

I asked women, if a man gave you a diamond, but you knew it was a blood diamond (where people were killed to get the diamonds), would it matter to you?
I have never gotten an answer, just hmm, that is a good question.

Truth is, most never ask where that diamond came from.

But I am happy that there are some ethical people in the world or we would never have the society that we have.

Posted: **Sun May 12, 2019 2:21 pm**

Pardon my ignorance, but what was wrong with PulseAudio? Was there something that was better than PulseAudio that was in use before?

Good ol' ALSA was fine, and less of a resource hog than PulseAudio, which was buggy at first, and actually still Beta when Ubuntu first foisted it on their users. It didn't happen in Debian Stable until it was pretty much bug-free and well-tested.

Posted: **Sun May 12, 2019 2:25 pm**

there is no longer a fullstop; however, I may be wrong about the year, might have been earlier.
The point is, I waited over 5 minutes, applied the suggested commands but systemd remained adamant and unyielding.
I am relieved if that particular gotcha has been corrected. At the time I filed the bug report it had not.

Thanks for corroborating, first-hand, the "pain point" I mentioned. I presented it as a sole example of how any of these Tubertalkers could easily find such examples if they bothered (you know, "background research" prior to professing to be authoritative speakers) to visit the user forums of any now systemd-encumbered linux distribution.

Thanks also for the factchecking & reporting that a 90sec timeout is now the (Debian configured?) default

Posted: **Sun May 12, 2019 2:58 pm**

Links:
http://without-systemd.org/wiki/index.p ... stallation
http://without-systemd.org/wiki/index.p ... variant.29
http://without-systemd.org/wiki/index.p ... stallation

okay, I "nuked" the content of those pages (didn't test whether kriv has wiki page deletion privileges)

contents of this page were more than a year old and, reputely, were no longer accurate.
(still available via the "history" of this page if you care to review them)

Please repost a known/tested accurate set of instructions here.

If anyone discovers additional inaccuracies, post here or send me a PM.
specialPages}}}allPages may still find one or two others that are currently "unlinked" (per the "what links here" info)

Posted: **Sun May 12, 2019 8:52 pm**

Luke mentions in the video that he's only been using Linux for two years, yet he deems it necessary to make a selfie video giving his two cents worth on the systemd controversy as though he's some sort of authority. Why? He seems very full of himself, especially for a newb. I tried to ignore this and pay attention to the content in case he actually had something to contribute and I learned anything useful, but it was pretty much just "hatters gotta hate", Nobody likes change" and "boomers are sticks-in-the-mud." I liked the woods he was strolling in though: pretty country, wherever it is.

Posted: **Mon May 13, 2019 12:31 am**

Head_on_a_Stick wrote: Sun May 12, 2019 9:42 ambut my main operating system is OpenBSD

I don't really like pre-configured distributions, I prefer a tabula rasa which I can configure myself.

I also use OpenBSD, and if it could run Wine and if vmm could be used to run full-blown VMs with Windows or something on it, I would probably not be using MX Linux. My point is though, that your advice is almost impossible to follow unless you end up being a hermit.

Head_on_a_Stick wrote: Sun May 12, 2019 9:42 amMy point was that it is not possible to tamper with the systemd journal without alerting the administrator.

Anybody who manages to compromise a system will want to doctor the logs to conceal their malfeasance — this is possible with syslogd but not possible with the journal, which is a major advantage of the binary format.

And likewise for syslogd. You have to be root to write to the files in /var/log anyway. There's no intrinsic advantage in security of a binary format over a regular text format in this case, it has exactly the same security concerns as any regular file would.

Head_on_a_Stick wrote: Sun May 12, 2019 9:42 amThe systemd journal records everything, syslogd doesn't record everything and requires several other logging services to provide full coverage.

That's quite a good setup if you have the journal record the stuff from syslog() as well. At least it's all in the one place then.

Head_on_a_Stick wrote: Sun May 12, 2019 9:42 amThe systemd journal collates all the logs and offers an interface by which to filter the results with a variety of methods.

For example, syslogd lacks monotonic or timezone-based timestamps whereas with systemd I can do this:
Code: Select all
shinken:~$ journalctl -u systemd-networkd --since "3 hours ago" --no-p
-- Logs begin at Sun 2019-05-12 08:34:31 BST, end at Sun 2019-05-12 14:26:05 BST. --
May 12 12:20:08 shinken systemd-networkd[355]: wlp2s0: Lost carrier
May 12 12:20:08 shinken systemd-networkd[355]: wlp2s0: DHCP lease lost
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: Gained carrier
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: DHCPv4 address 192.168.1.212/24 via 192.168.1.254
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: Configured
shinken:~$
Neat, eh?

Hopefully Lennart was smart enough to store them all as GMT and you can view them in the local time zone.

Head_on_a_Stick wrote: Sun May 12, 2019 9:42 amI was responding to the allegation of a "fullstop" and the suggestion that the system could not boot, which are both nonsense.

And the timeout can be reduced by editing DefaultTimeout{Start,Stop}Sec /etc/systemd/system.conf

While you're technically right, it's still a ridiculous situation that wasn't there before.

Head_on_a_Stick wrote: Sun May 12, 2019 9:42 amWell I have actually submitted an issue to the systemd team myself I was very pleased with how Lennart dealt with it:

https://github.com/systemd/systemd/issues/6684

I guess each to their own experience, but that still doesn't dismiss cases where users have been blamed for problems developers caused. Honestly I have yet to make up my mind about Lennart, and I'm not keen on jumping to conclusions about him just because everyone else has.

Posted: **Mon May 13, 2019 3:42 pm**

AK-47 wrote: Mon May 13, 2019 12:31 am I also use OpenBSD, and if it could run Wine and if vmm could be used to run full-blown VMs with Windows or something on it

I can't see Windows ever being supported under vmm(4) but I have Debian & Arch running nicely:

https://forum.archlabslinux.com/t/may-2 ... ad/3202/54

AK-47 wrote: Mon May 13, 2019 12:31 am My point is though, that your advice is almost impossible to follow unless you end up being a hermit.

That advice was specifically about trusting anything I post — I am horrified by the thought that people might take my words as the gospel truth and I would much rather they think for themselves and seek to independently verify anything I may claim.

AK-47 wrote: Mon May 13, 2019 12:31 amHopefully Lennart was smart enough to store them all as GMT and you can view them in the local time zone.

The journal records timestamps in µseconds from epoch UTC and converts them to the local timezone, as can be seen from the BST (British Summer Time) zone in my posted code snippit.

AK-47 wrote: Mon May 13, 2019 12:31 amWhile you're technically right, it's still a ridiculous situation that wasn't there before.

It's not ridiculous at all, I think it's a useful feature.

Consider this: under sysvinit the user would be blissfully unaware that their swap wasn't working until their system ground to a halt under an intensive workload...

Posted: **Mon May 13, 2019 10:21 pm**

Head_on_a_Stick wrote: Mon May 13, 2019 3:42 pm
AK-47 wrote: Mon May 13, 2019 12:31 amWhile you're technically right, it's still a ridiculous situation that wasn't there before.
It's not ridiculous at all, I think it's a useful feature.

Consider this: under sysvinit the user would be blissfully unaware that their swap wasn't working until their system ground to a halt under an intensive workload...

It certainly is a useful feature. A stall during boot is a sure sign that I should look at the journal to find out what the issue is and attempt to fix it.
It's not systemd's fault that another distro's installer reformatted a pre-existing swap file.

Posted: **Mon May 13, 2019 10:46 pm**

Well, at least most installers nowadays,
ask before reformatting the swap area. :)

Posted: **Mon May 13, 2019 11:10 pm**

Richard wrote: Mon May 13, 2019 10:46 pm Well, at least most installers nowadays,
ask before reformatting the swap area. :)

True, Richard, but most is not all. I have installed a few random distros lately and a couple have given no option to not format swap. IIRC in one I did not specify a swap partition in the installer to get around it. systemd can automatically mount a swap partition on a GPT disk without an fstab entry anyway - https://wiki.archlinux.org/index.php/Sw ... by_systemd

Posted: **Wed May 15, 2019 10:52 am**

I am still a Linux beginner and for me the existence of systemd would be the last thing I check when choosing a distro. My priority is the distro have to be stable and doesn't rely on only one or two developers to maintain it.

As a beginner, I can only rely on the experts' opinions. When I heard Linus Torvalds himself mentioning the benefits of systemd, that was enough for me to relax and not think too much about it.

Posted: **Wed May 15, 2019 3:28 pm**

mx-2018 wrote: Wed May 15, 2019 10:52 am I am still a Linux beginner and for me the existence of systemd would be the last thing I check when choosing a distro. My priority is the distro have to be stable and doesn't rely on only one or two developers to maintain it.

As a beginner, I can only rely on the experts' opinions. When I heard Linus Torvalds himself mentioning the benefits of systemd, that was enough for me to relax and not think too much about it.

Like you , I dont know much about the inner workings of these init systems . But philosophically, I like the idea of small programs that do one thing well. Thats why I would never install an iphone controlled home thermostat system or electronically controlled blinds, - I think the ones made in the 1960s work just fine ! I like the nice sturdy up/down mechanical light switches. I would never by a software controlled car (tesla). Why? Because things break. There are bugs. And you want to minimize bugs in critical infrastructure.

I like to think of things like systemd and pulseaudio as "middle managers", bureaucrats, - always sounds good at first - after all why not have a middle manager take charge of what 10 different employees are doing - and coordinate things. Over time , often, the overhead associated with such systems gets unwieldy, and bug prone, and takes on a life of its own. This is the problem with Windows.

It may be a bit more effort upfront to , for instance setup alsa audio ( compared to pulse). But once it is set, it just works. And it is optimized for ME - and how I use my system. I dont need to worry about what my "middle manager" is doing. I may not agree with the tradeoffs he is making. he may be doing things to solve problems some else is having - adding overhead to my system.

Posted: **Sat Jun 15, 2019 9:14 pm**

You know for me the systemd debate is silly, I am a end user so the inter politics do not matter to me as long as my system boots and I can get from point A to Point B.
Sure I get the logistics of what is wrong and right about systemd but as it stands from a end user.... I kind of am on the systemd side, init is a bit slow on bootup compared to systemd and I actually had more issues in the past with init than with systemd.
But thats just my opinion, again end user here so the innter power struggle nonsense really doesnt concern me until it actually is a concern of mine.

Posted: **Sun Jun 16, 2019 9:04 am**

MadmanRB wrote: Sat Jun 15, 2019 9:14 pm [...]
But thats just my opinion, again end user here so the innter power struggle nonsense really doesnt concern me until it actually is a concern of mine.

and then it's too late to fix....

Posted: **Sun Jun 16, 2019 9:35 am**

manyroads wrote: Sun Jun 16, 2019 9:04 am and then it's too late to fix....

+1

Posted: **Fri Oct 22, 2021 6:29 pm**

Funny how a post about a video bemoaning the fact that a lot of discussion about systemd is fuelled by uninformed populist opinions and biases should spawn pages in the thread and become sprinkled with comments fuelled by uninformed populist opinions and biases.

Posted: **Fri Oct 22, 2021 6:36 pm**

Welcome, but probably not the best first post in the community, not just because of the comment but because you just bumped an ancient thread that needed to be close anyway.

Posted: **Sat Oct 23, 2021 2:42 am**

Thread locked.
Henry

MX Linux Forum

systemd according to Luke Smith

systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith

Re: systemd according to Luke Smith