4 ms·

This is a common mistake. systemd-oomd is not "in" systemd the init system. Similar to systemd-resolved, systemd-networkd, systemd-boot, and others it just has

This is a common mistake. systemd-oomd is not "in" systemd the init system. Similar to systemd-resolved, systemd-networkd, systemd-boot, and others it just has the systemd name because it is developed by the systemd team. A minimal system using sytemd for the init system and other software for everything else only needs sytemd, dbus, and journald. I use several of these projects because I like the systemd design philosophy (ex the way the CLI interface and config files are) and trust the developers of their software. However, there are popular altenatives available for all of these components, should you choose to use them: systemd-resolved: bind9, dnsmasq, powerdns systemd-networkd: NetworkManager, ConnMan systemd-boot: GRUB2, Refind, EFISTUB systemd-oomd: earlyoom, nohang, oomd (the facebook one, not systemd)

hexo 6y ago
This is exactly my problem. It is made by systemd team. "Everything" seems like it is getting replaced by stuff made by systemd team as if they had patented wisdom or what. Including other perfectly functioning software. I suddenly have to use systemd-* over them. Like, hell, what is systemd-boot and when and why it replaced grub2? I don't call this evolution. This is bad form of centralization and seizing power.
- IgorPartola 6y ago
  You know I feel that way about the Linux kernel. Everything is done by the Linux kernel developers and it’s shipped as one monolithic thing. Wouldn’t it be better to get drivers for networks cards from other places? Or have to pick from a list of memory management packages that get downloaded from GitHub on every reboot? And why do they include things like spin lock implementations? Should that be an NPM package? /s
  - badsectoracula 6y ago
    You're joking but having drivers separate from the rest of the Linux kernel and with a stable ABI would certainly help other OSes as well (e.g. ReactOS, Haiku).
- viraptor 6y ago
  > I suddenly have to use systemd-* over them. You really don't. You have the choice to go with a distro which doesn't use them, or to mix&match yourself.
- candiddevmike 6y ago
  I personally prefer systemd-boot over grub2, it's dead simple to configure and works really well for UEFI systems (and dual booting windows).
- zbentley 6y ago
  > Like, hell, what is systemd-boot and when and why it replaced grub2? I've been really happy with systemd-boot; in my limited (used it on probably a dozen machines across several distros at this point) experience, it's better at autodetecting nonstandard images/locations than grub, and is vastly friendlier to weird partitioning schemes. It also has a much more minimal config surface than grub, which I like (since, across distros, I no longer have to learn a distro-specific set of nested/included grub config files and conventions, nor do I have to worry about what will be auto-regenerated when a distro does a kernel update versus what configs I need to edit by hand). However, that limited config surface may be a drawback to people who need to customize very esoteric boot cases. I also aesthetically prefer systemd-boot's minimalism and focus on newer (UEFI) boot strategies compared to grub; the latter is huge in terms of functionality. A lot of that size is needed for rare cases and older boot configurations (and if you fall into either group, grub is what you should use), but it complicates the "happy path" on post-2010 computers. https://en.wikipedia.org/wiki/Gummiboot_(software) https://en.wikipedia.org/wiki/Gummiboot_(software)
dathinab 6y ago
I agree but I wouldn't call systemd a init system. It's a service manager for your Linux OS which manage all services down to initial startup related services. Just viewing it as a init system is misleading. As a side note I think a service manager directly above the kernel is a must have for any modern server or desktop operating system ;=)
- viraptor 6y ago
  > I agree but I wouldn't call systemd a init system. Systemd is the name of the init system. Systemd is also the name of the project developing multiple systemd-* services. Maybe they could help the situation a bit by renaming the service itself systemd-init, but we've had enough time for people to learn to deal with a tiny bit of ambiguity...

hexo 6y ago

This is exactly my problem. It is made by systemd team. "Everything" seems like it is getting replaced by stuff made by systemd team as if they had patented wisdom or what. Including other perfectly functioning software. I suddenly have to use systemd-* over them. Like, hell, what is systemd-boot and when and why it replaced grub2? I don't call this evolution. This is bad form of centralization and seizing power.

IgorPartola 6y ago
You know I feel that way about the Linux kernel. Everything is done by the Linux kernel developers and it’s shipped as one monolithic thing. Wouldn’t it be better to get drivers for networks cards from other places? Or have to pick from a list of memory management packages that get downloaded from GitHub on every reboot? And why do they include things like spin lock implementations? Should that be an NPM package? /s
- badsectoracula 6y ago
  You're joking but having drivers separate from the rest of the Linux kernel and with a stable ABI would certainly help other OSes as well (e.g. ReactOS, Haiku).
viraptor 6y ago
> I suddenly have to use systemd-* over them. You really don't. You have the choice to go with a distro which doesn't use them, or to mix&match yourself.
candiddevmike 6y ago
I personally prefer systemd-boot over grub2, it's dead simple to configure and works really well for UEFI systems (and dual booting windows).
zbentley 6y ago
> Like, hell, what is systemd-boot and when and why it replaced grub2? I've been really happy with systemd-boot; in my limited (used it on probably a dozen machines across several distros at this point) experience, it's better at autodetecting nonstandard images/locations than grub, and is vastly friendlier to weird partitioning schemes. It also has a much more minimal config surface than grub, which I like (since, across distros, I no longer have to learn a distro-specific set of nested/included grub config files and conventions, nor do I have to worry about what will be auto-regenerated when a distro does a kernel update versus what configs I need to edit by hand). However, that limited config surface may be a drawback to people who need to customize very esoteric boot cases. I also aesthetically prefer systemd-boot's minimalism and focus on newer (UEFI) boot strategies compared to grub; the latter is huge in terms of functionality. A lot of that size is needed for rare cases and older boot configurations (and if you fall into either group, grub is what you should use), but it complicates the "happy path" on post-2010 computers. https://en.wikipedia.org/wiki/Gummiboot_(software) https://en.wikipedia.org/wiki/Gummiboot_(software)

dathinab 6y ago

I agree but I wouldn't call systemd a init system. It's a service manager for your Linux OS which manage all services down to initial startup related services. Just viewing it as a init system is misleading. As a side note I think a service manager directly above the kernel is a must have for any modern server or desktop operating system ;=)

viraptor 6y ago
> I agree but I wouldn't call systemd a init system. Systemd is the name of the init system. Systemd is also the name of the project developing multiple systemd-* services. Maybe they could help the situation a bit by renaming the service itself systemd-init, but we've had enough time for people to learn to deal with a tiny bit of ambiguity...