systemd according to Luke Smith

[timkb4cq]

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.

[timkb4cq]

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.

[Head_on_a_Stick]

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.

[timkb4cq]

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.

[KBD]

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

[sunrat]

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.

[KoO]

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.

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.

[AK-47]

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.

[skidoo]

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.

[skidoo]

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