Live data from Hacker News

Introducing stronger dependencies on systemd

blogs.gnome.org

131–140 of 179 posts

Re: Introducing stronger dependencies on systemd

#131
post #7

Earlier quoted context omitted.

What do you recommend instead?

I would like to recommend Mate, which is a continuation of Gnome 2. I like to think of my Desktop Environment as little as possible - if I'm thinking about it it's usually because it's getting in my way. In particular, I switched to Mate when the Gnome 3 team went Steve Jobs on us and implemented menus that couldn't be moved out of the way and a new desktop philosophy that didn't fit my current workflow. Gnome 2 work…

To add to that: I keep trying out other new, interesting or high-profile distros, and whenever they use KDE Plasma (esp. on older HW) it is a grating experience, especially because it's slow. And after you log in, you have to wait again with an animation before your desktop shows up. On my son's desktop, I just replaced it with MATE, and now it's instantly available right after login. SO much nicer!

Re: Introducing stronger dependencies on systemd

#132
post #117

Earlier quoted context omitted.

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

If openssh isn't a monoculture this whole thing you've got falls apart.

And pipewire is fine and good? Ask a sound engineer.

Re: Introducing stronger dependencies on systemd

#133
post #105
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…

I believe you are making assumptions about my beliefs that don't follow from what I said. > I believe that systemd won out because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialization by calling shell scripts and then disappearing. I made a point to clarify I do not think SysV init scripts are a good solution for most systems Start…

systemd isn't even a constraint solving system, it's highly "imperative", there's just memes floating around that think it is??? not even poettering would claim that

Re: Introducing stronger dependencies on systemd

#134
post #118
post #114

Earlier quoted context omitted.

I notice you choose to shift the goalpost instead of engaging with the central point. The central point, stated clearly and unequivocally, is that the project maintainer wrote he welcomes anybody and does not care about race, and you call this racist, and thus there is a huge contradiction. I suspect you double down because you are so captured by your emotions that you cannot possibly admit the lapse in critical thin…

> he welcomes anybody and does not care about race, Ah yes, the "all lives matter" rebuttal.

What's that supposed to mean?

Re: Introducing stronger dependencies on systemd

#135
post #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"

Still is?

Re: Introducing stronger dependencies on systemd

#136
post #85
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…

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…

> You make it sound like systemd manufactured this monoculture somehow.

Where are you getting this from? I do not see it at all. The parent comment just says that it is an emergent compromise they don't think is a good one. That the code cannot be audited is also not necessarily a quality issue, either. It is just impossible to feasibly audit over 10 million lines of C. (this criticism applies equally to the kernel, although I doubt anyone would claim the kernel is less audited than systemd)

> Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.

Nobody is pretending this. the comment you are replying to literally says "I don't think it represents the current state of the community".

Re: Introducing stronger dependencies on systemd

#137
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.

Systemd is crap. Works in the main use case, mess up otherwise. It is the windows kernel of linux distributions. Here for example, suddenly systemd will be mandatory despite systemd not caring for multiple session of a single user. Not only not yet implemented but totally that don't need it personally so no one can want to have it. And so again the capability of our linux based distribution will be restricted for som…

It's more comparable to the Windows Registry.. (well ok the registry isn't also dozens of daemons that run everything...)

Re: Introducing stronger dependencies on systemd

#138
post #29
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.

with 4.20, there is experimental wayland support for almost all xfce4 applications. I've used it and didn't even face a single crash. So, it's not far away.

great! Do you feel is a "good" change? does using a DE with wayland feels better or different? not talking about technical advantages...

Re: Introducing stronger dependencies on systemd

#139
post #134
post #118

Earlier quoted context omitted.

> he welcomes anybody and does not care about race, Ah yes, the "all lives matter" rebuttal.

What's that supposed to mean?

A common refrain against any attempt to mitigate unjust effects of past racial injustice (affirmative action, protesting against unjust policing, DEI, etc) is that the mitigation itself is racist, and the best thing would be to treat everyone "equally" going forward. Thus the "all lives matter" and "we welcome everybody regardless of race" are the same coin.

Re: Introducing stronger dependencies on systemd

#140
What's interesting here isn't a strict dependency on systemd, but dependencies on some APIs it provides. Given the ability and existence of things which implement those APIs outside of systemd, it's worth considering that the APIs themselves should be the focus. Perhaps they should be spun out of systemd itself. It seems sensible to that gnome would want to move to a better API which is almost defacto a standard these days anyways. Versioning the API and allowing more folks outside of the systemd organization to participate in its continued evolution should be the focus imo.
Post reply on HN