1y ago

i find it's a great tool.

You're viewing a single thread.

206 comments

Does too much for one tool (against unix philosophy) and has poor interop with other tools (binary logfiles).
- That's not really true. systemd is split up into many different, independent binaries, and each of those does one job and does it well.
- Linux User when their program does more than IO text streams:
  
  Piping xz into tar is not text stream
- That's not really true. systemd is split up into many different, independent binaries, and each of those does one job and does it well.
  
  Does it really matter if you can't use those independent binaries with any other init system? If you want to use systemd, you pretty much have to take the whole ecosystem.
  
  If I remember correctly, there was a ton of pain configuring a minimal systemd. I am unaware if that has changed much in recent years.
  Here is an old thread talking about it: https://unix.stackexchange.com/questions/150975/what-is-needed-for-a-minimal-systemd-boot-to-launch-getty-on-a-virtual-console
  
  Your link describes setting up one file, the getty@.service.
  The .target unit files are built-in, and not part of configuration.
- Btw. The Linux kernel does more than one thing. But monolithic kernels are much better for small student projects that won't be relevant anymore, when Gnu Hurd comes out
  
  when Gnu Hurd comes out
  Any day now...
  
  Too thick
  
  Monolithic kernels are also generally more performant, compared to micro-kernels, it turns out. A bit counter-intuitive at first but, makes sense when you think about it.
  Micro-kernels in general-purpose OSes suffer from a death of a thousand cuts due to context switching. Something that would be a single callback to the kernel in a monolith turns into a mess of calls bouncing between kernel and user space. When using something like an RTOS where hardware is not likely intended for general-purpose computing, this is not an issue but, when you start adding all of the complexity of user-installable applications that need storage, graphics, inputs, etc, the number of calls gets huge.
- Binary log files is my only significant complaint
- Does too much for one tool (against unix philosophy)
  This tired, old argument needs to die already.
  Do you use browser extensions? That breaks unix philosophy too.
  
  You just compared a browser extension and an init system that takes proc id 1. The unix philosophy is about what runs as processes at the system level.
  
  The unix philosophy is about what runs as processes at the system level.
  I don't know what you mean by "system level" (cat is userspace) but I don't believe there is any clarification about what kind of applications should apply to the unix philosophy or not. It doesn't say that applications "should do one thing and do it well only if it is a system process or terminal based program built for purely shell environments."
  Also, if the argument was exclusively about OS processes, dbus should be in the firing line of everyone in the anti-systemd camp too. That never gets the same level of hate.
  The unix philosophy is old and, while nice to have, is insufficient to fully address the needs of the modern world. It's not as simple today as it was in the 1960s and 70s and we need to embrace change to progress.
  
  I’m honestly not sure what you’re talking about here. The unix philosophy is something informal that applies to compiled utilities that run usually in a bin/ directory. The philosophy isn’t attempting to apply to all software that exists and certainly doesn’t intend to apply to browsers or browser extensions.
  
  Dbus does only one thing: relays messages.
  as it was in the 1960s and 70s
  You will be surprised, but Turing machine was created during WW2, and we still say turing-complete today.
  
  Adblock does only one thing: blocks ads. Doesn't sound phylosophy-breaking.
  
  You just compared a browser extension and an init system that takes proc id 1. The unix philosophy is about what runs as processes at the system level.

206 comments