Avoiding Complexity with Systemd

Post by Arnavion » Sun, Jun 27, 2021, 4:25 PM UTC

nh2 wrote: post #135

atoav wrote: post #4

Earlier quoted context omitted.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot. How does NixOS make that easier?

You can override NixOS's predefined systemd settings from _outside_ using NixOS module options. This allows you to change default settings that are not optimal for your use case, without having to patch NixOS itself, or write your own unit config. For example, systemd by default permanently gives up restarting services after a few number of tries (e.g. 5), even if you have set `Restart=always`. This is suboptimal for…

Post by [deleted] » Sun, Jun 27, 2021, 4:27 PM UTC

knorker wrote: post #149

Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

I don't think it's that people are warming to systemd. It's more that there are two kinds of people now: 1. People to young to remember stable software. 2. People who have given up, and just accepted that Linux too "just needs a reboot everynow and then to kinda fix whatever got broken". systemd has normalized the instability of shitty system software. And just like how you don't see front page news every day about 1…

Post by generalizations » Sun, Jun 27, 2021, 4:30 PM UTC

kaba0 wrote: post #152

spindle wrote: post #46

Earlier quoted context omitted.

This. I can easily believe that systemd is an improvement in many ways for people who have time to understand it (especially in NixOS, as noted by another commenter). But I'm not happy that so many parts of Linux now have such a steep learning curve.

But system init is a hard, complex problem. You can’t create a simple solution for that, since there is an inherent complexity. I prefer systemd over having a bunch of bash scripts trying to do service restart, logging, dependency management and failing at it. You would still get the same complexity but at a different (worse) level.

Post by dylan-m » Sun, Jun 27, 2021, 4:33 PM UTC

5e92cb50239222b wrote: post #128

geofft wrote: post #104

Earlier quoted context omitted.

I really don't understand the scenario where binary logging is a problem. journalctl is a command just like, I dunno, gzip, and people are fine with gzipped logs. If something goes horribly wrong with your system, you're not looking at logs with an oscilloscope, you're looking at logs by mounting the disk on some other working OS - whether it's the initramfs, or a live CD, or whatever. You can run gunzip (Not to ment…

A thoughtful comment downvoted into oblivion without any explanation. Classic HN. I too don't get the hate that binary logs receive. They aren't any harder to work with than text logs. journalctl makes it easy to read logs from an offline system, too. The compression it automatically provides saves a lot of space across our machines. I know that it can be achieved without binary logs, but does any popular distributio…

Post by GuidoW » Sun, Jun 27, 2021, 4:36 PM UTC

turminal wrote: post #14

The title is an oxymoron. Putting a huge complex piece of software between yourself and "complexity" doesn't make the system less complex.

   boot.kernelPatches = [ { name = "no-reserved-ports";  patch = path/to/no-reserved-ports.patch; } ];

  --- a/include/net/sock.h
  +++ b/include/net/sock.h
  @@ -1331,7 +1331,7 @@
  #define SOCK_DESTROY_TIME (10*HZ)

  /* Sockets 0-1023 can't be bound to unless you ares uperuser */
  -#define PROT_SOCK      1024
  +#define PROT_SOCK      24

  #define SHUTDOWN_MASK  3
  #define RCV_SHUTDOWN   1