Live data from Hacker News

Introducing stronger dependencies on systemd

blogs.gnome.org

71–80 of 179 posts

Re: Introducing stronger dependencies on systemd

#71

Earlier quoted context omitted.

We are not lawyers. I don't care what their "parent" company is legally. In practice, IBM influences and affects every single decision of these projects/companies. So yes, It is their parent company. Just look at what they were doing to X11. Holding it's development back just to monopolize wayland more.

How were they holding X11 back? No one wanted to support it, not just Red Hat.

Give me an option to donate directly to X11 development and I am gonna support it.

Re: Introducing stronger dependencies on systemd

#72
post #57

Replying to some sibling comments asking why anyone wouldn't want to use systemd. People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd…

> Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone.

For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init system means that a significant portion of all Linux systems out there came this close to being backdoored.

[1] https://news.ycombinator.com/item?id=39911311

Re: Introducing stronger dependencies on systemd

#73

Earlier quoted context omitted.

How were they holding X11 back? No one wanted to support it, not just Red Hat.

Give me an option to donate directly to X11 development and I am gonna support it.

Give directly to X11 development? You'll need to find someone who actually wants to work on the codebase, and then you can donate to them?

No one wants to work on it.

Re: Introducing stronger dependencies on systemd

#74
post #5

What is Gnomes market share like these days? It used to be the de facto FOSS desktop in the GNOME 2.x days but things changed with the release of Gnome 3 and I’ve not really noticed Gnome ever bounce back since.

It's the default DE for RedHat, Fedora, Debian, Ubuntu, and many others.

Re: Introducing stronger dependencies on systemd

#75
post #61
post #3

This is a good move. Without having endless resources keeping the codebase small and focused just makes sense. I know it's going to be painful for non-Linux users but volunteer devs can't be expected to cover all bases.

>Keeping the codebase small and focused makes sense LMFAO. You have not even glanced at insane dumpster fire that is the gnome codebase.

Regardless of what it's currently like, supporting fewer things is going to make it easier to maintain.

Re: Introducing stronger dependencies on systemd

#77
post #56
post #40

I have yet to hear an argument against systemd which isn’t a variation of: - """bloat""" - I dislike Poettering. Remember pulseaudio? - a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984. Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this…

There aren't decent Pro systemd arguments other than "the Linux API confused me" and sysv init (which no one argues is good) was bad. Personally the last system I had systemd on corrupted my package database after killing apt that I was running in tmux. "Oh you can fix that with xyz systemd configuration." Here's my response: Kindly shove it up your ass and quit moving things around all the time just because you're b…

The pro argument is that writing shell scripts for starting/restarting/enabling/disabling/stopping is total garbage. Not to mention having to manage lock files. systemd units are not perfect, but they are a billion times better than the crap we used to deal with.

Re: Introducing stronger dependencies on systemd

#78
post #57

Replying to some sibling comments asking why anyone wouldn't want to use systemd. People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd…

> Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init sy…

If you think that's wild you should hear about kernel vulnerabilities!

Re: Introducing stronger dependencies on systemd

#79
post #39

This is a sensible move. systemd is a good piece of software, and foundational Linux infrastructure which by now is very widely deployed. I’ve been doing Linux a long time and my experience is that systemd is much more pleasant to work with than the brittle duct tape and shell script stuff which came before.

Xorg was also a "good piece of software, foundational Linux infrastructure and very wildly deployed"

Re: Introducing stronger dependencies on systemd

#80
post #54
post #36

Earlier quoted context omitted.

[flagged]

Interestingly enough Poettering works for Microsoft now.

Times change too. Microsoft does a ton of open source. They maintain an excellent immutable Linux distro. As always the true enemy is dogma and a cult-like adherence to it.
Post reply on HN