Gentoo Gets GNOME 3.30 Running Without Systemd

[F.Ultra]

This is just typical of the way people respond to criticism towards SystemD... Criticism is always just "pissing" on the devs or "harassment" even thou the toxic relationship between the devs and the userbase isn't almost entirely due the non-productive approach to user feedback that a certain someone has had since he ran PulseAudio development.

If we were really just "pissing" on him we'd be telling him to "end himself" (i.e how you tell someone to commit suicide on 4chan) or something...

That's because that is what you do when you make implications on "viral aspects" such as "Normally if you start using one component, like loginD, you're basically forced to adopt the whole thing due to how heavily interconnected all of the parts are" when the reason the various components are interconnected is for a good reason.

Basically your whole complaint boils down to "damn the systemd project for providing something that other developers finds useful". And btw the "he should end himself" we already see by the millions on say Slashdot, it used to exist here as well but thankfully that have more or less disappeared in the last year.

[F.Ultra]

As expected from systemd fanboys, can't make a difference between a utility and a library.

So we are now playing the game of pretending that a utility cannot provide functionality for other applications/utilities? The outcome is the exact same regardless of if the utility expresses the interface as a shared library (as if that would have stopped you from complaining) or via a message bus such as D-BUS.

No because they had to make changes.

Changes to what dear riddler?

[L_A_G]

Yeah let us all piss on the systemd devs for exposing useful functionality for us developers... One thing to remember here is that elogind is not just a fork of systemd-logind, it's a fork of systemd-logind with restrictions.

This is just typical of the way people respond to criticism towards SystemD... Criticism is always just "pissing" on the devs or "harassment" even thou the toxic relationship between the devs and the userbase isn't almost entirely due the non-productive approach to user feedback that a certain someone has had since he ran PulseAudio development.

If we were really just "pissing" on him we'd be telling him to "end himself" (i.e how you tell someone to commit suicide on 4chan) or something...

[Weasel]

And if you rm /lib/x86_64-linux-gnu/libc.so.6 does this now mean that the whole distribution now might as well be one large blob since nothing works after that?

As expected from systemd fanboys, can't make a difference between a utility and a library.

The very existence of this thread, that Gentoo have replaced systemd-logind with elogind, is a prime example of this.

No because they had to make changes.

[F.Ultra]

SystemD and Android share the problem that they aren't divided up into packages with interfaces. The kernel isn't either but everyone is watching that so it's impossible for the government to sneak spyware in, which is presumably why SystemD was built in this manner.

So in other words you have no actual idea what so ever how systemd works (considering that all communications are done via documented interfaces and that packaging are done by distributions and i.e Ubuntu have several different systemd packages).

edit: Btw here is the interface: https://www.freedesktop.org/wiki/Software/systemd/dbus/

[F.Ultra]

ssokolow Let's use a simple example. You say systemd is a collection of utilities so it's not any different than, say, patchutils. So it doesn't break the Unix philosophy, according to you. Fair enough.

Can you do, e.g. rm -f /usr/bin/fixcvsdiff for a systemd component? Will it still work? Yes? No?

There's your answer. Can't really make it more obvious than this. If things are dependent on each other they might as well be one large blob. Splitting it into modules doesn't change shit except semantics if they cannot be simply REMOVED separately.

And if you rm /lib/x86_64-linux-gnu/libc.so.6 does this now mean that the whole distribution now might as well be one large blob since nothing works after that? The key here is modules that when being dependent, performs that dependency via some well established API. Then the dependency is on the API and not of the particular module; which is exactly how the systemd suite is designed.

The very existence of this thread, that Gentoo have replaced systemd-logind with elogind, is a prime example of this.

[ssokolow]

ssokolow Let's use a simple example. You say systemd is a collection of utilities so it's not any different than, say, patchutils. So it doesn't break the Unix philosophy, according to you. Fair enough.

Can you do, e.g. rm -f /usr/bin/fixcvsdiff for a systemd component? Will it still work? Yes? No?

There's your answer. Can't really make it more obvious than this. If things are dependent on each other they might as well be one large blob. Splitting it into modules doesn't change shit except semantics if they cannot be simply REMOVED separately.

Re-read the comment just above your reply. My three issues are:

1. People mis-characterizing the UNIX philosophy.
2. People not getting their facts straight about why systemd isn't modular enough before complaining.
3. People fouling the air with whining about systemd rather than either doing something productive about it or shutting up.

None of those is a defense of systemd.

[Weasel]

ssokolow Let's use a simple example. You say systemd is a collection of utilities so it's not any different than, say, patchutils. So it doesn't break the Unix philosophy, according to you. Fair enough.

Can you do, e.g. rm -f /usr/bin/fixcvsdiff for a systemd component? Will it still work? Yes? No?

There's your answer. Can't really make it more obvious than this. If things are dependent on each other they might as well be one large blob. Splitting it into modules doesn't change shit except semantics if they cannot be simply REMOVED separately.

[ssokolow]

I've read it and it HAS to be some sort of a "tunnel-vision" thing that let's some people actually quote the Unix principles and claim systemd dissenters are in the wrong. I could in fact argue that not only systemd's but Linux development paradigm itself being at odds with Unix

McIlroy agrees with you and so do I.

Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option.
-- "Ancestry of Linux — How the Fun Began (2005)". (UNIX Pioneer Doug McIlroy's speech to the Dartmouth-Lake Sunapee Linux User Group on November 3rd on the early history of computing and UNIX.)

I'm not sure if you've seen the comment in question, but I said before that I think that the problem he describes with manpages stems from UNIX providing insufficient APIs for composing simple components and that, if UNIX development had continued, in addition to Plan9's further extending the "everything is a file" metaphor, we'd have also seen shell pipelines re-standardize on something with basic structure, comparable to what JSON can represent.

My issue is with people who are so obsessed with the minutia of a specific interpretation of the UNIX philosophy that they say things like "The UNIX Philosophy is at odds with using something like JSON to pass structured data from program to program" or "The UNIX philosophy forbids the introduction of new APIs and system functionality because it's at odds with the UNIX philosophy's stance on loose coupling and composability".

Let's see
1)make each program do one thing well. To do a new job, build a fresh, rather than complicate old programs by adding "new features".
So what "is" systemd? Is it a collection of multiple sub-components under single umbrella? You could claim so - but it's components are inter-connected to a quite large degree and there are hardwired dependencies that just do not allow "do away" with certain components. So, it's not actually "(single) program doing it's job well" but always a case of "multiple programs supporting single program doing it's job". Quite a bit further away from desired KISS principle.

Now, ill throw additional fresh blood into an raging inferno: does Linux devs habitual feature creep (which btw involves systemd) is against the latter portion of Point 1 in Unix Principles, or not?

No argument. I especially hate how fragile PID 1 is because they couldn't bother to make it as tiny as possible and design all the fancy stuff into a helper process that can be killed and restarted without messing up work in progress if it starts to misbehave.

(Same reason I won't be using Wayland in the near future. I have yet to find an X11 window manager that hasn't needed restarting to continue my work.)

My two main issues with anti-systemd people on this point are:

1. Do your damn research before complaining about what in systemd is actually tightly coupled and what is just developed under the same umbrella.
2. Rant productively. We're sick of you whining in ways that can only be interpreted as productive if it's assumed that you feel entitled to free work from others.

2.Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
Binary logs? Excessive amount of 'debug' information, extremely colourful console outputs.

Again, no argument. My preferred way to use systemd is to install rsyslogd, set up forwarding, and crank journald retention down to minimum. (Among other reasons, I found that it resulted in a reduced RAM footprint on Debian 8.6 VPSes.)

3.Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
So, million LOCs tightly interconnected systemd code by 2017. Interconnected meaning - Even when you try to use minimum amount of systemd components, you'll be forced to run extras you cannot around it. Conflicting with Points 1 and 3.

I'll readily admit that I don't know enough to judge on this one. It's more about "Dogfood early, dogfood often" and I don't know how quickly new systemd functionality becomes dogfoodable.

4.Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
Linux had the 'existing' alternatives, why 'unskilled help' treating bug requests as hate mail felt like a better option to go with- color me clueless - individual laziness perhaps as "it will help me make my work bit easier, so i'll gladly trade more freedom for community against me having to work less. And since Iack of skill, motivation or wisdom of creating better tools (instead of existing alternatives or systemd)- i'll gladly bite the heads off anybody remotely endangering my selfish wellbeing in the womb of systemd".

I'm going to have to disagree with you here, since this point is more about automating in-house tasks in the hope that you'll build up a stable of reusable components.

As for "it will help me make my work bit easier, so i'll gladly trade more freedom for community against me having to work less", again, you're free to develop an alternative but, apparently, of the options that people took the effort to write, systemd's value proposition is the most appealing to big-name distros and business customers.

(I remember seeing all this discussion surrounding OpenRC when Debian was considering OpenRC, Upstart, or systemd and far too much of it boiled down to "OpenRC doesn't have feature X" being countered with "You're mistaken in thinking you need feature X". No wonder OpenRC lost.)

[eigenlambda]

SystemD and Android share the problem that they aren't divided up into packages with interfaces. The kernel isn't either but everyone is watching that so it's impossible for the government to sneak spyware in, which is presumably why SystemD was built in this manner.