Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing stronger dependencies on systemd

blogs.gnome.org

Post reply on HN
Print view View original

141–150 of 179 posts

Re: Introducing stronger dependencies on systemd

#141

Post by surajrmal »

SpecialistK wrote: post #128
sph wrote: post #38

Earlier quoted context omitted.

For all in this context does not mean “all the infinite combinations of software for people that refuse to adopt the status quo” systemd is here to stay. It is ludicrous to imagine everybody to keep supporting that 1% that is ideologically opposed to it, no? As those people love to say, open-source is written by volunteers, you can always fork it.

What about the (admittedly small) % of operating systems that can't support systemd, like FreeBSD? systemd is pretty heavily dependent on Linux, and that's not an ideological thing.

Does gnome officially support non Linux kernels? It's possible to implement the systemd APIs gnome is taking dependencies on without strictly using systemd itself.

Re: Introducing stronger dependencies on systemd

#142

Post by Spivak »

probably_wrong wrote: post #72
pona-a wrote: 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…

This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-notify which is the way services can tell systemd that they're ready. The protocol is literally sending the string READY=1 over a file descriptor. libsystemd contains a reference implementation but it's a protocol specifically for the reason that every service isn't supposed to link to libsystemd. Maintainers thought it was easier to link in all of libsystemd (and therefore xz) into OpenSSH just for the sd_notify function.

Just link in a huge library into security critical code, what could go wrong?!

Re: Introducing stronger dependencies on systemd

#143

Post by LargoLasskhyfv »

LargoLasskhyfv wrote: post #119
growse wrote: post #103

Earlier quoted context omitted.

I'm interested in your idea that "merit" is some sort of objective measure. If it works for me but not for you, does it have more merit?

Some anecdotical evidence of mine. I tend to kill -9 Firefox or derivatives before system, or browser updates, to reliably get my tabs and cookies (for selected sites) back, without the need for any extensions. Usually I'm doing that from within htop, or btop++. Under systemd that is slow , the process-tree of FF takes several seconds to vanish. That felt very wrong. I increased the update frequency of htop and btop+…

Do you think this is any different on more modern systems? Fear not, it gets worse with more cores!1!!

Re: Introducing stronger dependencies on systemd

#145

Post by justinrubek »

nixosbestos wrote: post #130
pcpuser wrote: post #124

Earlier quoted context omitted.

What does "shopped around" mean? That's not a common or accepted idiom for code. Or not one I've come across anyway. Also show me evidence of them "shopping around" code. I'll wait.

Truly, don't bother. I've been watching this conversation play out for 10 years. I've watched it play out with systemd, udev, rust, Wayland. Just ignore them. Their validation is meaningless. Their ignorance is mostly meaningless, too, for reasons that feel mean to type out.

I'm getting the sense that both sets of parties here have a strong opinion and that this isn't a real discussion because of that.

Re: Introducing stronger dependencies on systemd

#146

Post by justinrubek »

msgodel wrote: post #56
sph wrote: 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…

Honestly this sounds like an apt problem. A properly robust package management system shouldn't be able to succumb to such a problem.

Your abrasiveness is not helping discussion. I'm also not a board.

Re: Introducing stronger dependencies on systemd

#147

Post by ihatepoop1234 »

airhangerf15 wrote: post #93
n3storm wrote: post #20

For all worried check out xfce. It works, is light, is customizable, has gtk responsiveness (I find Qt click and drag and drop downs odd) Only downside maybe is no Wayland support yet.

> no Wayland support yet That's not a downside.

My hardware doesn't work with X. Screen tearing. So im stuck with wayland, although I'd like to move to xfce when they support wayland

Re: Introducing stronger dependencies on systemd

#148

Post by hnlmorg »

jeroenhd wrote: post #113
criticalfault wrote: post #15

Earlier quoted context omitted.

Every time there is an interview of some startup and they show the offices with a glimpse of a monitor, it's always Ubuntu. Running gnome. Also a few people I know, if they used Linux on a desktop it was Ubuntu. Don't know anyone using KDE, steam deck being the only exception. So from a personal perspective, if it's Linux on the desktop, it's gnome.

KDE is quite popular for personal computers I believe. It's got things like HDR support much earlier than Gnome did. Corporate also seems to like OpenSUSE and RHEL. Universities seem to like Debian. Practically all of them default to Gnome or offer Gnome equivalently. Even several (relatively) big SteamOS-alikes are using Gnome despite SteamOS itself defaulting to KDE.

Things might have changed recently (though screenshots suggest otherwise) but Suse has always preferred KDE.

Re: Introducing stronger dependencies on systemd

#149

Post by AlotOfReading »

Spivak wrote: post #142
probably_wrong wrote: post #72

Earlier quoted context omitted.

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

This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-notify which is the way services can tell systemd that they're ready. The protocol is literally sending the string READY=1 over a file descriptor. libsystemd contains a reference implementation but it's a protocol specifically for the reason that every service i…

You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_n...) explicitly says:

    using this library should be preferred in order to avoid code duplication
Then, if you're not intimately familiar with systemd you might wonder which is more standardized and less likely change between the API and the protocol. Maybe you make the reasonable assumption that it's the API.

Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add.

All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.

Re: Introducing stronger dependencies on systemd

#150

Post by panick21_ »

msgodel wrote: post #89
pcpuser wrote: post #85

Earlier quoted context omitted.

There's so much I disagree with in the beginning but the ending is what actually grinds my gears. You make it sound like systemd manufactured this monoculture somehow. This is also the point I've seen people throw in a comparison to some closed-source org with money to burn and questionable morals. Systemd was chosen by distros and users across different communities because it solves hard problems better than the oth…

All of us paying attention saw how the systemd authors shopped their stuff around issue trackers and mailing lists telling everyone "it's just the way it is now." They absolutely did manufacture the situation. They pushed hard enough doing this that it's resulted in multiple large distros being forked by groups of former maintainers.

Oh my god, they told other people they are developing open source software and that they like their own software. Say it aint so. Have we informed the authorities about this?
Post reply on HN