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

Boycott Systemd (2014)

web.archive.org

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Boycott Systemd (2014)

#41

Post by tssva »

Cpoll wrote: post #22
kmeisthax wrote: post #9

>systemd's team is noticeably chauvinistic and anti-Unix ONE OF THESE THINGS IS NOT LIKE THE OTHER, ONE OF THESE THINGS IS a serious allegation against the values of systemd's maintainers that is not backed up by anything in the text. Unless the writer just doesn't understand what "chauvinism" is beyond being a malword. >systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a c…

If you're referring to the word "chauvinism" as a synonym for "male chauvinism": This is the common connotation, and the default understanding of the word. However, the dictionary definition of chauvinism isn't "male chauvinism," and it can be understood to mean something else in certain contexts (I argue such as this one). The first stanza of the Wiktionary definition: > Chauvinism is the unreasonable belief in the…

Nothing really backups the systemd maintainers displaying the dictionary definition either.

Re: Boycott Systemd (2014)

#42

Post by SAI_Peregrinus »

amelius wrote: post #12
qbasic_forever wrote: post #10

Earlier quoted context omitted.

Dbus doesn't have anything to do with systemd FYI. It's a communication bus for processes to talk to each other through structured RPC messages.

From the article: > udev and dbus are forced dependencies.

Dbus isn't a systemd project any more than a libc is a systemd project. Systemd just requires it as a dependency. It's a freedesktop project.

Re: Boycott Systemd (2014)

#43

Post by SAI_Peregrinus »

vidarh wrote: post #24
kmeisthax wrote: post #9

>systemd's team is noticeably chauvinistic and anti-Unix ONE OF THESE THINGS IS NOT LIKE THE OTHER, ONE OF THESE THINGS IS a serious allegation against the values of systemd's maintainers that is not backed up by anything in the text. Unless the writer just doesn't understand what "chauvinism" is beyond being a malword. >systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a c…

I think the biggest flaw of systemd was "political" in grouping too many different tools under the single project name.

Yeah, that's why everyone hates the GNU project, and Freedesktop.org!

Re: Boycott Systemd (2014)

#45

Post by qbasic_forever »

amelius wrote: post #31
toast0 wrote: post #21

Earlier quoted context omitted.

> Edit: thanks for all the replies, yes, I get that dbus is for sending messages between applications, but what is wrong with e.g. UNIX domain sockets? I think the reason for dbus is that all of these processes want to talk to all the other ones, and they need to rendezvous somewhere. You probably don't want to open a unix socket for every 'topic' you want to respond to, and anyway if there's multiple programs intere…

> if there's multiple programs interested in the topic, how do you make sure they all get all of the messages, if they all listen to the socket, only one gets the message. Well, you could listen on a socket for subscribers ... (Basically a decentralized approach vs a centralized approach) > OTOH, dbus doesn't transit over the network, so eog on a remote host can't communicate with your desktop environment, so that's…

Distributed RPC, i.e. dbus over the network, is an incredibly complex and still basically unsolved problem. To really do it right and guarantee correctness across systems (which may be in different states of working or failed!) you need a perfect message queue with exactly once delivery... but in practice implementing that is incredibly storage intensive (you'd have to store every message forever). You're basically asking for something as complex and difficult to run as kafka--it's not as simple as just send dbus messages over a network socket.

Re: Boycott Systemd (2014)

#46

Post by jraph »

dale_glass wrote: post #37
quicklime wrote: post #34

Earlier quoted context omitted.

The “Unix philosophy” is a core part of the user interface to Unix systems. You might not care about this yourself, but I’d bet that most people do care about UI consistency.

Right now I'm looking at this in Firefox in KDE. I'm not sure what "one thing" either of those does. Neither deals with plain text in a terminal. But if you want a comfortable commandline UI, I'd say journalctl does the job far better than grepping log files. And heck, it outputs text so you can still grep that if you really want to.

KDE, for one, is a big bag of specialized tools, built using a set of libraries that are also very modular.

But I agree with your general view.

Re: Boycott Systemd (2014)

#47

Post by lynguist »

Summary of the points: and what they mean.

1. Systemd's Complexity and Scope: The increased complexity allows for better integration and coordination of system components.

2. Journal Files in Binary Format: The binary format improves performance and allows for richer metadata storage.

3. Systemd's Team Being Anti-Unix: The tight integration with the Linux kernel API optimizes the use of Linux-specific features.

4. Forced Dependencies on udev and dbus: The integration of udev and systemd provides more streamlined and coordinated system management.

5. Saving Core Dumps to the Journal: Storing core dumps in the journal makes it easier to correlate system logs with crashes.

6. Systemd as a Single Point of Failure: Proper maintenance and security practices can mitigate the risks associated with any critical software component.

7. Systemd's Viral Nature: The adoption of systemd by major projects like GNOME can be seen as the natural evolution of the ecosystem around a dominant technology.

8. Systemd Clustering into PID 1: The role of systemd as PID 1 represents a trade-off between integration and risk.

9. Designing Systemd with glibc in Mind: The tight coupling with glibc is a pragmatic choice to optimize for the most commonly used C library in the Linux ecosystem.

10. Systemd's Complexity Hinders Extensibility: More features and integrated behavior in systemd naturally lead to increased complexity.

11. Systemd's Symbolic Shift in Linux Community: The shift towards a more integrated and monolithic approach represents a change in the Linux community's direction.

Re: Boycott Systemd (2014)

#48

Post by [deleted] »

lynguist wrote: post #47

Summary of the points: and what they mean. 1. Systemd's Complexity and Scope: The increased complexity allows for better integration and coordination of system components. 2. Journal Files in Binary Format: The binary format improves performance and allows for richer metadata storage. 3. Systemd's Team Being Anti-Unix: The tight integration with the Linux kernel API optimizes the use of Linux-specific features. 4. Fo…

[deleted]

Re: Boycott Systemd (2014)

#49

Post by vidarh »

SAI_Peregrinus wrote: post #43
vidarh wrote: post #24

Earlier quoted context omitted.

I think the biggest flaw of systemd was "political" in grouping too many different tools under the single project name.

Yeah, that's why everyone hates the GNU project, and Freedesktop.org!

It's not comparable. You don't install either. Nobody assumes you get every GNU project when you install one because its name coincides with the organization as a whole, because neither put themselves in the situation of creating that kind of confusion.

Re: Boycott Systemd (2014)

#50

Post by toast0 »

amelius wrote: post #31
toast0 wrote: post #21

Earlier quoted context omitted.

> Edit: thanks for all the replies, yes, I get that dbus is for sending messages between applications, but what is wrong with e.g. UNIX domain sockets? I think the reason for dbus is that all of these processes want to talk to all the other ones, and they need to rendezvous somewhere. You probably don't want to open a unix socket for every 'topic' you want to respond to, and anyway if there's multiple programs intere…

> if there's multiple programs interested in the topic, how do you make sure they all get all of the messages, if they all listen to the socket, only one gets the message. Well, you could listen on a socket for subscribers ... (Basically a decentralized approach vs a centralized approach) > OTOH, dbus doesn't transit over the network, so eog on a remote host can't communicate with your desktop environment, so that's…

> Well, you could listen on a socket for subscribers ... > (Basically a decentralized approach vs a centralized approach)

But who is going to listen on that socket for subscribers? When there's no owner of the resource, just some programs may want to send to it, and some may want to listen to it, you need someone to own all of that; and that's dbus, as I understand it.

> Yes, and what I find mysterious is that dbus was conceived by the freedesktop.org project. How could they have missed this important requirement?

My personal impression is that the freedesktop people have effectively abandoned network computing as X11 used to provide. Clearly, I haven't stepped up to do the work either, but both the single host / multiple user and single user / multiple host use cases are at best neglected, if not abandoned. It used to be feasible and useful to run a host with multiple X servers for multiple simultaneous users, and those sessions may have had a mix of local and remote X clients; but for various reasons, that doesn't work so well anymore.

Some of the lack of support is because addressing the full scope of everything is actually pretty hard. If you run networkmanager over remote X, which network is it expected to manage? If you have multiple users on a single machine with bluetooth and someone sends a file to the host, which user gets a notification?

That said, I think for many things where dbus fits, there's a connection to a graphical user session, and so IMHO, it would fit to coordinate in a way that all participants in the session could use, which for me would be through the X server (which already allows for communication between clients). And for things where it's really a connection to the host hardware, that should probably be through the host filesystem. And so some applications might need to connect to a message bus in both ways, and maybe sometimes tunneling --- an application may legitimately need to contact a system daemon on the host that controls the user's keyboard, but that might not be possible through X, or the host filesystem where the application is running. But that's super complex and weird, so it goes into the later pile, never to be solved.

Post reply on HN