7 ms·

This is not true. systemd did standard multiple interfaces in Linux ecosystem. It is much easier to get things working nowadays than it used to be. systemd beca

by m45t3r 8y ago

This is not true. systemd did standard multiple interfaces in Linux ecosystem. It is much easier to get things working nowadays than it used to be. systemd became standard thanks to meritocracy (important people in most distros decided to adopt systemd, it was not a "political power play"). It is complex, and there are bugs like any other kind of software[1], however like any other software it is improving. [1]: For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux. The only way to fix them was to find the correct order that system worked. No more problems of this kind thanks to systemd dependency resolving.

geggam 8y ago
Important people choosing to use instead of letting the community decide is the definition of political and not merit
- theamk 8y ago
  At least for Debian, technical committee (elected by the community) could not choose between systemd and upstart [0], so systemd was the final winner. There was overwhelming desire that sysvinit should go. And when this question was brought to general election, community decided it did not care: [1] So I am not sure who those "important people" were, why do you feel they did not represent you, and what would community choose, in your opinion. I, having worked with upstart, can say it is worse than systemd. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672... [1] https://www.debian.org/vote/2014/vote_003#outcome https://www.debian.org/vote/2014/vote_003#outcome
  - codedokode 8y ago
    Interesting, I didn't know that Debian has a constitution.
  - kasabali 8y ago
    > technical committee (elected by the community) Technical committee members are not elected by community, they're appointed by the DPL. https://www.debian.org/devel/constitution#item-6 https://www.debian.org/devel/constitution#item-6
- tapoxi 8y ago
  The community did decide, each distribution chooses for itself what software to use. Debian's open debate process lasted for months.
  - geggam 8y ago
    And resulted in Devuan fork. I have used systemd and currently am forced to use it in production. It works great until it doesnt. There have been multiple times I have no idea what was wrong as it was faster to simply recreate the system from scratch and hope the same bug didnt happen again.
- diffeomorphism 8y ago
  Letting the wider community decide is also the opposite of a meritocratic decision.
- veeti 8y ago
  Who else has more merit to make this decision than the Debian developers (= the important people) themselves? Random neckbeards whining on online forums?
  - geggam 8y ago
    Developers make terrible system managers usually.
  - insertcredit 8y ago
    At least as far as Debian is concerned, you will find that the people with skin-in-the-game (administrators) were massively against systemd. The Devuan fork/split happened exactly because of that.
    - jamespo 8y ago
      That's because they only understand bash and not c
      - geggam 8y ago
        because configuring and managing systems in C seems suboptimal ?
    - amyjess 8y ago
      > you will find that the people with skin-in-the-game (administrators) were massively against systemd Let me offer you an anecdote from my company. Now, we're a RHEL shop and not a Debian shop, but we've been around since long before systemd. Most of our hosts now run RHEL 7, but we still have a handful of old boxen still running RHEL 6, and I've been personally involved with quite a few migrations from RHEL 6 to 7 during my time here. Whenever we retire a RHEL 6 host and replace it when a RHEL 7 host, the general consensus from the people who administrate it is "thank god we can now use systemd instead of having to deal with sysvinit". Every time I have to do anything on one of our remaining RHEL 6 hosts, I brace myself for pain, because our RHEL 7 hosts are just that much easier to manage.
na85 8y ago
>systemd became standard thanks to meritocracy (important people in most distros decided to adopt systemd...) But that's literally the exact opposite of a meritocratic selection.
- vetinari 8y ago
  They are important because of what they did, on their merit. They also selected systemd because it solved problems they had, unlike other candidates. Do not mistake that with any random Joe gets his opinion voiced.
  - geggam 8y ago
    We are smarter than you. Trust us :)
    - vetinari 8y ago
      It's not about being smarter and trusting, it's about doing stuff and having results vs taking a ride for doing nothing. When I'm getting a free ride, I'm not going to talk down the provider how he should be doing the job differently (not necessarily better; that might be my opinion, but not objective truth). I'm not in his shoes, solving problems he is solving, so my view could be diametrically different than his.
- diffeomorphism 8y ago
  Important people are important people because of their merit. The fact that their opinion counts and not random users' opinion is what makes it a meritocratic instead of a democratic selection. What you are arguing about is whether those people selected systemd based on its merits or based on other considerations is an entirely different question and an unsubstantiated accusation.
  - oceanplexian 8y ago
    I'm sorry but no, there's no such thing as an objective measure of merit. In 1991, most of the "important people" in technology would have laughed at Linux compared to OSes like Unix System V and DEC/HP Unix. Even as the 90s progressed most serious shops wouldn't adopt Linux and went for the BSDs (FreeBSD/ NetBSD, etc) or Solaris because Linux was considered hobbyist software. I know because I worked in tech at this time and the same attitude even continued into the early 2000s. The point I'm trying to make is that random users' opinions are exactly how certain software projects, open source or proprietary, become popular or fall out of public use. It starts with Systems Administrators or developers getting fed up with a certain solution and adopting alternatives until it reaches critical mass and the old is rendered irrelevant.
Tor3 8y ago
I need to run /usr/bin/expect from one of the init.d scripts. That breaks with systemd. Moving that box to Devuan (no systemd) fixed the issue. The alternative was to rebuild that particular application without systemd. So far systemd hasn't brought me anything particularly useful. I've never had any issues with getting things working (pre-systemd), and one of my pre-systemd laptops boots from power off to fully graphical in five seconds, so I don't buy the argument I hear from some that systemd is necessary for reducing boot-up time.
- ciupicri 8y ago
  How does systemd break Expect?
  - theamk 8y ago
    I am going to guess that process required a tty for some reason, and the systemd unit file did not specify StandardOutput=tty nor did he wrap the invocation in `unbuffer` program
- ibotty 8y ago
  You know you can run scripts to start something up with systemd as well?
- theamk 8y ago
  I made a typo in lighttpd's config once. sysvinit init script, which used start-stop-daemon, would report success, but would not start the server at all. There was no error messages, nothing in the system log. Systemd logs all process output by default, so things like this cannot happen at all. Just for that, I'd choose it over sysvinit any time.
  - codedokode 8y ago
    I had a similar issue with systemd in Debian. Restarting the service (Apache) via systemd actually had no effect, and calling init.d script worked. By the way, I am not a fan of sysvinit: I read all those shell scripts.
welterde 8y ago
> For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux Arch didn't really use SysVinit before systemd though, but their own BSD-like rc system, which I rather enjoyed actually.. And I got hit with concurrency issues after the switch to systemd, because seemingly the dependencies for disks and file systems aren't setup correctly by the Arch scripts requiring me to add a few fake units to fix up the dependencies (otherwise the system would just fail to boot at all most of the time).
StreamBright 8y ago
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

by m45t3r 8y ago

geggam 8y ago

Important people choosing to use instead of letting the community decide is the definition of political and not merit

theamk 8y ago
At least for Debian, technical committee (elected by the community) could not choose between systemd and upstart [0], so systemd was the final winner. There was overwhelming desire that sysvinit should go. And when this question was brought to general election, community decided it did not care: [1] So I am not sure who those "important people" were, why do you feel they did not represent you, and what would community choose, in your opinion. I, having worked with upstart, can say it is worse than systemd. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672... [1] https://www.debian.org/vote/2014/vote_003#outcome https://www.debian.org/vote/2014/vote_003#outcome
- codedokode 8y ago
  Interesting, I didn't know that Debian has a constitution.
- kasabali 8y ago
  > technical committee (elected by the community) Technical committee members are not elected by community, they're appointed by the DPL. https://www.debian.org/devel/constitution#item-6 https://www.debian.org/devel/constitution#item-6
tapoxi 8y ago
The community did decide, each distribution chooses for itself what software to use. Debian's open debate process lasted for months.
- geggam 8y ago
  And resulted in Devuan fork. I have used systemd and currently am forced to use it in production. It works great until it doesnt. There have been multiple times I have no idea what was wrong as it was faster to simply recreate the system from scratch and hope the same bug didnt happen again.
diffeomorphism 8y ago
Letting the wider community decide is also the opposite of a meritocratic decision.
veeti 8y ago
Who else has more merit to make this decision than the Debian developers (= the important people) themselves? Random neckbeards whining on online forums?
- geggam 8y ago
  Developers make terrible system managers usually.
- insertcredit 8y ago
  At least as far as Debian is concerned, you will find that the people with skin-in-the-game (administrators) were massively against systemd. The Devuan fork/split happened exactly because of that.
  - jamespo 8y ago
    That's because they only understand bash and not c
    - geggam 8y ago
      because configuring and managing systems in C seems suboptimal ?
  - amyjess 8y ago
    > you will find that the people with skin-in-the-game (administrators) were massively against systemd Let me offer you an anecdote from my company. Now, we're a RHEL shop and not a Debian shop, but we've been around since long before systemd. Most of our hosts now run RHEL 7, but we still have a handful of old boxen still running RHEL 6, and I've been personally involved with quite a few migrations from RHEL 6 to 7 during my time here. Whenever we retire a RHEL 6 host and replace it when a RHEL 7 host, the general consensus from the people who administrate it is "thank god we can now use systemd instead of having to deal with sysvinit". Every time I have to do anything on one of our remaining RHEL 6 hosts, I brace myself for pain, because our RHEL 7 hosts are just that much easier to manage.

na85 8y ago

>systemd became standard thanks to meritocracy (important people in most distros decided to adopt systemd...) But that's literally the exact opposite of a meritocratic selection.

vetinari 8y ago
They are important because of what they did, on their merit. They also selected systemd because it solved problems they had, unlike other candidates. Do not mistake that with any random Joe gets his opinion voiced.
- geggam 8y ago
  We are smarter than you. Trust us :)
  - vetinari 8y ago
    It's not about being smarter and trusting, it's about doing stuff and having results vs taking a ride for doing nothing. When I'm getting a free ride, I'm not going to talk down the provider how he should be doing the job differently (not necessarily better; that might be my opinion, but not objective truth). I'm not in his shoes, solving problems he is solving, so my view could be diametrically different than his.
diffeomorphism 8y ago
Important people are important people because of their merit. The fact that their opinion counts and not random users' opinion is what makes it a meritocratic instead of a democratic selection. What you are arguing about is whether those people selected systemd based on its merits or based on other considerations is an entirely different question and an unsubstantiated accusation.
- oceanplexian 8y ago
  I'm sorry but no, there's no such thing as an objective measure of merit. In 1991, most of the "important people" in technology would have laughed at Linux compared to OSes like Unix System V and DEC/HP Unix. Even as the 90s progressed most serious shops wouldn't adopt Linux and went for the BSDs (FreeBSD/ NetBSD, etc) or Solaris because Linux was considered hobbyist software. I know because I worked in tech at this time and the same attitude even continued into the early 2000s. The point I'm trying to make is that random users' opinions are exactly how certain software projects, open source or proprietary, become popular or fall out of public use. It starts with Systems Administrators or developers getting fed up with a certain solution and adopting alternatives until it reaches critical mass and the old is rendered irrelevant.

Tor3 8y ago

I need to run /usr/bin/expect from one of the init.d scripts. That breaks with systemd. Moving that box to Devuan (no systemd) fixed the issue. The alternative was to rebuild that particular application without systemd. So far systemd hasn't brought me anything particularly useful. I've never had any issues with getting things working (pre-systemd), and one of my pre-systemd laptops boots from power off to fully graphical in five seconds, so I don't buy the argument I hear from some that systemd is necessary for reducing boot-up time.

ciupicri 8y ago
How does systemd break Expect?
- theamk 8y ago
  I am going to guess that process required a tty for some reason, and the systemd unit file did not specify StandardOutput=tty nor did he wrap the invocation in `unbuffer` program
ibotty 8y ago
You know you can run scripts to start something up with systemd as well?
theamk 8y ago
I made a typo in lighttpd's config once. sysvinit init script, which used start-stop-daemon, would report success, but would not start the server at all. There was no error messages, nothing in the system log. Systemd logs all process output by default, so things like this cannot happen at all. Just for that, I'd choose it over sysvinit any time.
- codedokode 8y ago
  I had a similar issue with systemd in Debian. Restarting the service (Apache) via systemd actually had no effect, and calling init.d script worked. By the way, I am not a fan of sysvinit: I read all those shell scripts.

welterde 8y ago

> For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux Arch didn't really use SysVinit before systemd though, but their own BSD-like rc system, which I rather enjoyed actually.. And I got hit with concurrency issues after the switch to systemd, because seemingly the dependencies for disks and file systems aren't setup correctly by the Arch scripts requiring me to add a few fake units to fix up the dependencies (otherwise the system would just fail to boot at all most of the time).

StreamBright 8y ago

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