4 ms·

You must be joking. What meritocracy? The guy who wrote systemd had already a major failed projects under his belt. PulseAudio rings a bell? Every reasonable pe

You must be joking. What meritocracy? The guy who wrote systemd had already a major failed projects under his belt. PulseAudio rings a bell? Every reasonable person understand that separation of concerns is a good thing. Systemd does the exact opposite. Few articles to be familiar with regarding systemd: https://www.dedoimedo.com/computers/software-development-cancer.html https://www.dedoimedo.com/computers/software-development-can... "The same can be said of the init systems in Linux, like systemd. In a nutshell, the system should start quickly and get into a working session. We had this in 2010 or so, with boot times down to mere 10 seconds using init. No flaws, no bugs. Even in the commercial sphere, working with init, I do not recall any major problems. Then, suddenly, we have this new binary diarrhea with a hundred million modules, and for the past five years, this unstable, half-baked, undebuggable nonsense is the backbone of most Linux distros. The invasive and pervasive nature of the systemd framework has also affected the stability of the user space, the very thing it should never have touched, and pretty much all problems with the quality of the Linux desktop nicely coincide with the introduction of systemd. The development continues, of course, and for no good reason than trying to reach the level of stability, maturity and functionality that we had half a decade ago. Someone landed themselves a lot of monthly pay checks by writing complex code to solve a problem that did not exist." https://ewontfix.com/14/ https://ewontfix.com/14/ "None of the things systemd "does right" are at all revolutionary. They've been done many times before. DJB's daemontools, runit, and Supervisor, among others, have solved the "legacy init is broken" problem over and over again (though each with some of their own flaws). Their failure to displace legacy sysvinit in major distributions had nothing to do with whether they solved the problem, and everything to do with marketing. Said differently, there's nothing great and revolutionary about systemd. Its popularity is purely the result of an aggressive, dictatorial marketing strategy including elements such as: Engulfing other "essential" system components like udev and making them difficult or impossible to use without systemd (but see eudev). Setting up for API lock-in (having the DBus interfaces provided by systemd become a necessary API that user-level programs depend on). Dictating policy rather than being scoped such that the user, administrator, or systems integrator (distribution) has to provide glue. This eliminates bikesheds and thereby fast-tracks adoption at the expense of flexibility and diversity." Solaris already had a better replacement for initv so did some linux distros. I think we need a better alternative that does not behave as a black hole, ntp, dns resolution, logging etc. do not get sucked into it and finally we need a way better implementation that does not have a remove or local priv escalation every other week[1]. https://github.com/systemd/systemd/issues https://github.com/systemd/systemd/issues

theamk 8y ago
Are you saying that entire TC of Debian was intimidated by Poettering? And then later, in general election, he forced majority of votes to say "we are fine with systemd"? [0] I find this highly unlikely. Here is my take: people were tired with "sysvinit". Of all alternatives, systemd sucked less. So they went with it. [0] https://news.ycombinator.com/item?id=18874100 https://news.ycombinator.com/item?id=18874100
- geggam 8y ago
  Surely you enjoy the irony of the move to microservices and isolation when merging so many functions into init ?
  - theamk 8y ago
    I am not sure what you are getting at. "systemd" deb package does contain lots of binaries, 73 in my case: dpkg -L systemd | xargs stat -c '%F %A %n' | grep file.*rwx | wc -l 73 Each binary does one thing. So for example /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else. Now, some people complain that "systemd" package contain other binaries, like systemd-networkd, or systemd-journal-gatewayd (the HTTP server). I don't understand their problems. Sure, it is annoying that "systemd" package contains network manager -- but you don't have to use it; in fact, I am not using it at all. So I do not see the irony. I think 73 binaries, each optional, easily replaceable, and doing only one thing, is very much inline to microservices philosophy.
    - rleigh 8y ago
      The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all together. There are two major things to consider here: - how easy is it to replace each of these with an independent third-party implementation - if it is possible, why should the design of that component be dictated by the systemd upstream A huge amount of the value of Linux was the fact that the system was a loosely-coupled collection of parts. Much of that flexibility has been lost, and with it the utility which drove a lot of the adoption of Linux in the first place.

theamk 8y ago

Are you saying that entire TC of Debian was intimidated by Poettering? And then later, in general election, he forced majority of votes to say "we are fine with systemd"? [0] I find this highly unlikely. Here is my take: people were tired with "sysvinit". Of all alternatives, systemd sucked less. So they went with it. [0] https://news.ycombinator.com/item?id=18874100 https://news.ycombinator.com/item?id=18874100

geggam 8y ago
Surely you enjoy the irony of the move to microservices and isolation when merging so many functions into init ?
- theamk 8y ago
  I am not sure what you are getting at. "systemd" deb package does contain lots of binaries, 73 in my case: dpkg -L systemd | xargs stat -c '%F %A %n' | grep file.*rwx | wc -l 73 Each binary does one thing. So for example /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else. Now, some people complain that "systemd" package contain other binaries, like systemd-networkd, or systemd-journal-gatewayd (the HTTP server). I don't understand their problems. Sure, it is annoying that "systemd" package contains network manager -- but you don't have to use it; in fact, I am not using it at all. So I do not see the irony. I think 73 binaries, each optional, easily replaceable, and doing only one thing, is very much inline to microservices philosophy.
  - rleigh 8y ago
    The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all together. There are two major things to consider here: - how easy is it to replace each of these with an independent third-party implementation - if it is possible, why should the design of that component be dictated by the systemd upstream A huge amount of the value of Linux was the fact that the system was a loosely-coupled collection of parts. Much of that flexibility has been lost, and with it the utility which drove a lot of the adoption of Linux in the first place.