Live data from Hacker News

Introducing stronger dependencies on systemd

blogs.gnome.org

121–130 of 179 posts

Re: Introducing stronger dependencies on systemd

#121
post #90

Earlier quoted context omitted.

If Gnome cared about an easy to maintain codebase it would be radically different. Gnome's complexity is comparable to a large web browser (which is kind of insane considering how little it really does.)

To be completely fair to Gnome, they're doing some stuff that nobody else is doing. The idea of building an entire desktop off the backs of C and the gobject system is very novel and gives Gnome a lot of advantages. For example, it had binding for just about every language under the sun. Compare that to KDE and Qt, which is C++ or bust. Obviously it's a bit hacky and kind of a mess, but it is technically interesting.

I don't know how things are done in the GTK-land, but Qt definitely has bindings for Python, Go, and others. Maybe GObject has some other advantages, but I don't know.

Re: Introducing stronger dependencies on systemd

#123
post #121

Earlier quoted context omitted.

To be completely fair to Gnome, they're doing some stuff that nobody else is doing. The idea of building an entire desktop off the backs of C and the gobject system is very novel and gives Gnome a lot of advantages. For example, it had binding for just about every language under the sun. Compare that to KDE and Qt, which is C++ or bust. Obviously it's a bit hacky and kind of a mess, but it is technically interesting.

I don't know how things are done in the GTK-land, but Qt definitely has bindings for Python, Go, and others. Maybe GObject has some other advantages, but I don't know.

Kind of, but those binding are incomplete and not all modules are supported.

When I say GTK has bindings for every language, I do literally mean every language. It's the nice thing about choosing C as the language to make your entire API in.

Re: Introducing stronger dependencies on systemd

#124
post #98
post #91

Earlier quoted context omitted.

Care to share any evidence to back up the tall claim that systemd authors forced their code on anyone?

The claim was "shopped around" and if you are going to change people's words do not be surprised when nobody takes your challenge. And preemptively: absence of evidence is not evidence of absence.

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.

Re: Introducing stronger dependencies on systemd

#125
post #97
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…

> good tooling My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.

Ths only issue that non-human readable log storage has caused is the endless nagging on forums. Literally never been an issue besides.

Re: Introducing stronger dependencies on systemd

#126
post #117

Earlier quoted context omitted.

Yeah, the Linux monoculture is also bad. In fact, one reason the systemd monoculture is bad is because it enforces the Linux monoculture.

What about the Windows monoculture in business? What about the seemingly Apple monoculture on HN? What about the OpenBSD monoculture with OpenBSD!!!!! You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.

I remember reading PipeWire is more stable than Pulseaudio because it removed a buggy and hard-to-implement-correctly feature. So not completely backwards compatible.

Re: Introducing stronger dependencies on systemd

#127
post #117

Earlier quoted context omitted.

Yeah, the Linux monoculture is also bad. In fact, one reason the systemd monoculture is bad is because it enforces the Linux monoculture.

What about the Windows monoculture in business? What about the seemingly Apple monoculture on HN? What about the OpenBSD monoculture with OpenBSD!!!!! You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.

> What about the Windows monoculture in business?

...yes? Obviously?

> What about the seemingly Apple monoculture on HN?

I don't think that exists, but if it did then I would object to it.

> What about the OpenBSD monoculture with OpenBSD!!!!!

What would that even mean? ...Actually, no, even if I sort of pretend that the concept makes sense it's not really a thing; OpenBSD constantly exports their software to be usable on other systems (ex. OpenSSH is an OpenBSD project) and imports general unix-like software to work on it. So no, there is no OpenBSD monoculture and wouldn't be even if it was that popular.

> You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.

See, the real reason that this is funny is that PipeWire is a new audio system, is mostly superior to its predecessors, and largely is successful because it is backwards compatibile. So... Yes, actually, exactly what you said but unironically and without the slightest bit of sarcasm.

Re: Introducing stronger dependencies on systemd

#128
post #38

The fact that the next blog post (linked at the bottom of the article) is titled "a desktop for all" is deliciously ironic in context.

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.

Re: Introducing stronger dependencies on systemd

#129
post #41
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.

Agreed. I wonder how many people in this thread hating on systemd have actually tried to work with upstream. They are an extremely pleasant and welcoming community who are willing to work with you on the most trivial stuff.

systemd maintainers were extremely unpleasant, unwelcoming, and unwilling to work with others in my experience.

Re: Introducing stronger dependencies on systemd

#130
post #98

Earlier quoted context omitted.

The claim was "shopped around" and if you are going to change people's words do not be surprised when nobody takes your challenge. And preemptively: absence of evidence is not evidence of absence.

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.

Post reply on HN