5 ms·

The need to replace sysvinit was/is valid but systemd is truly a horrible piece of software. I would argue that systemd has (greatly) increased overall complex

by na85 11y ago

The need to replace sysvinit was/is valid but systemd is truly a horrible piece of software. I would argue that systemd has (greatly) increased overall complexity and simply camouflaged it by moving most of the logic out of init scripts (unit files) and into program logic. And then added an http server and binary logs. The original submission title, while editorialized, was pretty apt in my opinion. There really does seem to be a core group of people involved with the GNOME, RedHat, and systemd projects that seem to want to add features just for the sake of adding features, or perhaps so that they have something to claim ownership of. Gnome basically decided that text-basd configuration was too sane and opted for a mix of config files and the Windows Registry (gconf, dconf) which is a hilariously poor design choice. One-size-fits-all doesn't work unless you are Apple and your users will happily swallow your marketing BS and wait in line to buy a new iphone every 2 years. The startup world is rife with the notions of "out with the old, in with the new" and "change for change's sake" so it's not surprising to me that a great deal of HN readers are Poettering apologists. But to me, it sure seems like systemd is just a chance for Poettering and some others to pad their resumés, or else perhaps simply an ego trip. I honestly can't find anything about it that makes me go "hmm, that's a good feature that outweighs all the other negative parts".

vezzy-fnord 11y ago
systemd clicked for me when I started realizing that a lot of its decisions mapped directly to Red Hat business decisions in cloud computing and containers, like their backing of Project Atomic. nspawn, the "stateless" system features through dynamic configuration population, GPT partition discovery deprecating fstab(5), having a big centralized blob journal, the embedded network management (which is mostly useful for container deployments rather than desktops) and NSS extensions, the GNOME system upgrade logic and so on. It's theoretically meant to be general-purpose, but it really shines at virtualized deployments and some desktops because of the multi-seat integration (though logind these days has some power management features that is just as relevant for servers).
- davidstrauss 11y ago
  I don't think Red Hat was the driving force behind systemd's container and VM integration. systemd-nspawn was created to provide rapid testing of systemd, and it was (and, for now, still is) marked as an experimental utility that isn't for production purposes. If you look at many of the early blog posts mentioning systemd and containers/VMs, you'll actually see my work and my company (Pantheon) mentioned more than Red Hat. In more recent posts, you'll see lots of CoreOS influence. Project Atomic isn't working with systemd in any direct, significant way; you won't see much coordination other than in some shared philosophy about a stateless base OS, and even that is more attributable to CoreOS's influence than Red Hat's. I think the influence of Red Hat on systemd is overstated. Of the two perspectives: (1) Red Hat driving everything and (2) Lennart answering mostly to himself, the latter is way more accurate, for better or worse (depending on your opinion of him).
  - vezzy-fnord 11y ago
    Well, Red Hat were quick to adopt CoreOS' appc, before a lot of companies ultimately united under the Open Container Project banner. As for: and it was (and, for now, still is) marked as an experimental utility that isn't for production purposes. rkt used nspawn for a while, and it's still systemd-based. The fact that Lennart was giving out presentations about nspawn specifically makes me believe it's very much intended to be used in production, as a "chroot on steroids".
    - davidstrauss 11y ago
      > The fact that Lennart was giving out presentations about nspawn specifically makes me believe it's very much intended to be used in production, as a "chroot on steroids". This is a recent development -- and why I put the caveat "for now." systemd-nspawn is probably going to be marked production-ready quite soon, especially because it's the foundation for the CoreOS Rocket container tool.
- gaius 11y ago
  Of course. Systemd is Red Hat's "embrace, extend, extinguish" strategy. Just as Microsoft were once the plucky upstart who became their rival IBM, so Red Hat are becoming Microsoft.

by na85 11y ago

vezzy-fnord 11y ago

systemd clicked for me when I started realizing that a lot of its decisions mapped directly to Red Hat business decisions in cloud computing and containers, like their backing of Project Atomic. nspawn, the "stateless" system features through dynamic configuration population, GPT partition discovery deprecating fstab(5), having a big centralized blob journal, the embedded network management (which is mostly useful for container deployments rather than desktops) and NSS extensions, the GNOME system upgrade logic and so on. It's theoretically meant to be general-purpose, but it really shines at virtualized deployments and some desktops because of the multi-seat integration (though logind these days has some power management features that is just as relevant for servers).

davidstrauss 11y ago
I don't think Red Hat was the driving force behind systemd's container and VM integration. systemd-nspawn was created to provide rapid testing of systemd, and it was (and, for now, still is) marked as an experimental utility that isn't for production purposes. If you look at many of the early blog posts mentioning systemd and containers/VMs, you'll actually see my work and my company (Pantheon) mentioned more than Red Hat. In more recent posts, you'll see lots of CoreOS influence. Project Atomic isn't working with systemd in any direct, significant way; you won't see much coordination other than in some shared philosophy about a stateless base OS, and even that is more attributable to CoreOS's influence than Red Hat's. I think the influence of Red Hat on systemd is overstated. Of the two perspectives: (1) Red Hat driving everything and (2) Lennart answering mostly to himself, the latter is way more accurate, for better or worse (depending on your opinion of him).
- vezzy-fnord 11y ago
  Well, Red Hat were quick to adopt CoreOS' appc, before a lot of companies ultimately united under the Open Container Project banner. As for: and it was (and, for now, still is) marked as an experimental utility that isn't for production purposes. rkt used nspawn for a while, and it's still systemd-based. The fact that Lennart was giving out presentations about nspawn specifically makes me believe it's very much intended to be used in production, as a "chroot on steroids".
  - davidstrauss 11y ago
    > The fact that Lennart was giving out presentations about nspawn specifically makes me believe it's very much intended to be used in production, as a "chroot on steroids". This is a recent development -- and why I put the caveat "for now." systemd-nspawn is probably going to be marked production-ready quite soon, especially because it's the foundation for the CoreOS Rocket container tool.
gaius 11y ago
Of course. Systemd is Red Hat's "embrace, extend, extinguish" strategy. Just as Microsoft were once the plucky upstart who became their rival IBM, so Red Hat are becoming Microsoft.