3 ms·

Lennart and the systemd team did exactly that 10 years ago. Why can't you? The code is there for someone with enough skill to show how bad systemd is right?

josefx 7y ago
> Lennart and the systemd team did exactly that 10 years ago. Why can't you? It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor. Not much an individual programmer can do compared to a corporation throwing its weight around to break things.
- AsyncAwait 7y ago
  > It would be impressive if Lennart managed that by himself. Red Hat wanted it done RedHat wanted it done once Lennart convinced them it is the right thing to do and Lennart put in the effort to be at RedHat at the right time to have the ability to convince them. In fact Lennart is one of the few people willing to put in the effort to touch the fundamental building blocks that otherwise rot, but nobody is willing to touch. > Projects like Gnome were Red Hat is by far the biggest contributor Yeah, I guess it's not that bad that in FLOSS, the people willing to ultimately sit down and put in the time and effort to actually write the code, even the non-sexy bits, get to steer the project over Hacker News commenters. That's not the worst outcome out there if you ask me.
  - nlgza 7y ago
    RedHat has several people who take over projects and rewrite everything they see, with little or no benefit other than getting a high commit count.
    - AsyncAwait 7y ago
      Any examples?
      - SSLy 7y ago
        Don't except a reply from a systemd hater's sockpuppet (nlzga was created just for this thread to shill FUD.)
- brmgb 7y ago
  > Red Hat wanted it done Red Hat had zero interest into a new init system when Lennart started systemd. They had just moved to upstart and Red Hat customers don't really care about init systems. Red Hat customers pay for their systems to be stable and to have someone to call when something goes wrong. Systemd gives Red Hat no competitive advantage whatsoever. I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents. The components systemd is slowly replacing or sitting on top, most of the low level userspace of linux, is mostly garbage and poorly documented garbage at that. PAM is aweful. I don't even want to talk about ConsoleKit. Cron has one of the worst configuration format ever and I'm certainly not going to miss fstab. I would find journald a step in the right direction even if the only thing it brought to the table was the ability to configure logging from the service file and not have to fiddle with logrotate. Networkd gives you a nice, uniform and well documented way to configure both interfaces, rules, custom routing tables and vpn tunnels from declarative files. Who in their right mind can miss the hodgepodge of scripts that was there before ?
  - kbenson 7y ago
    > I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents. I think sections 3.5 and 3.6 (all of them, including subsections outlines current problems pretty clearly. Summarized, systemd is complex to reason about, ambiguous in how it functions, and poorly documented in many cases. All the very similar directives with slight nuances paint a picture of people that didn't really understand the problem space as well as they thought they did (and to be fair, nobody did, and they probably had the best understanding, as woefully inadequate as it was). For a sysadmin, who rarely (but not never!) has to dive into the intricacies of unit files and the myriad directives and their nuanced behavior for creating a server but less rarely is affected by odd behavior introduced by systemd, it's a liability. What we have now is a chance to learn from those missteps and build something even better. Systemd as a catalyst for rapid chance was wildly successful. As an init system that capitalizes on those changes in a way that users (that is, system/distro packagers) can take advantage of, not so much, since it's so wildly complex. The article posits that BPF will be used to create programs to take over some of these tasks, which may be right. Alternatively, we could start pulling out the components that systemd subsumed, and formalizing them into new standards that others could develop for. Whether that means actually pulling out the component (e.g. logind) to a new repo, or just formalizing API is up for debate.

josefx 7y ago

> Lennart and the systemd team did exactly that 10 years ago. Why can't you? It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor. Not much an individual programmer can do compared to a corporation throwing its weight around to break things.

AsyncAwait 7y ago
> It would be impressive if Lennart managed that by himself. Red Hat wanted it done RedHat wanted it done once Lennart convinced them it is the right thing to do and Lennart put in the effort to be at RedHat at the right time to have the ability to convince them. In fact Lennart is one of the few people willing to put in the effort to touch the fundamental building blocks that otherwise rot, but nobody is willing to touch. > Projects like Gnome were Red Hat is by far the biggest contributor Yeah, I guess it's not that bad that in FLOSS, the people willing to ultimately sit down and put in the time and effort to actually write the code, even the non-sexy bits, get to steer the project over Hacker News commenters. That's not the worst outcome out there if you ask me.
- nlgza 7y ago
  RedHat has several people who take over projects and rewrite everything they see, with little or no benefit other than getting a high commit count.
  - AsyncAwait 7y ago
    Any examples?
    - SSLy 7y ago
      Don't except a reply from a systemd hater's sockpuppet (nlzga was created just for this thread to shill FUD.)
brmgb 7y ago
> Red Hat wanted it done Red Hat had zero interest into a new init system when Lennart started systemd. They had just moved to upstart and Red Hat customers don't really care about init systems. Red Hat customers pay for their systems to be stable and to have someone to call when something goes wrong. Systemd gives Red Hat no competitive advantage whatsoever. I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents. The components systemd is slowly replacing or sitting on top, most of the low level userspace of linux, is mostly garbage and poorly documented garbage at that. PAM is aweful. I don't even want to talk about ConsoleKit. Cron has one of the worst configuration format ever and I'm certainly not going to miss fstab. I would find journald a step in the right direction even if the only thing it brought to the table was the ability to configure logging from the service file and not have to fiddle with logrotate. Networkd gives you a nice, uniform and well documented way to configure both interfaces, rules, custom routing tables and vpn tunnels from declarative files. Who in their right mind can miss the hodgepodge of scripts that was there before ?
- kbenson 7y ago
  > I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents. I think sections 3.5 and 3.6 (all of them, including subsections outlines current problems pretty clearly. Summarized, systemd is complex to reason about, ambiguous in how it functions, and poorly documented in many cases. All the very similar directives with slight nuances paint a picture of people that didn't really understand the problem space as well as they thought they did (and to be fair, nobody did, and they probably had the best understanding, as woefully inadequate as it was). For a sysadmin, who rarely (but not never!) has to dive into the intricacies of unit files and the myriad directives and their nuanced behavior for creating a server but less rarely is affected by odd behavior introduced by systemd, it's a liability. What we have now is a chance to learn from those missteps and build something even better. Systemd as a catalyst for rapid chance was wildly successful. As an init system that capitalizes on those changes in a way that users (that is, system/distro packagers) can take advantage of, not so much, since it's so wildly complex. The article posits that BPF will be used to create programs to take over some of these tasks, which may be right. Alternatively, we could start pulling out the components that systemd subsumed, and formalizing them into new standards that others could develop for. Whether that means actually pulling out the component (e.g. logind) to a new repo, or just formalizing API is up for debate.