7 ms·

It's not like systemd is written in deliberately obfuscated C or something inscrutable altogether like Brainfuck. A monorepo containing well-organized boring C

It's not like systemd is written in deliberately obfuscated C or something inscrutable altogether like Brainfuck. A monorepo containing well-organized boring C, developed on github of all places, is the polar opposite of raising the barrier to contributing vs. what was replaced. Full-disclosure: I contribute to systemd.

ReactiveJelly 5y ago
There is a difference between the best C, and scripts that you can modify in-place. But, like some other comments have said, I was young enough to dodge the drama. I basically grew up with systemd and I don't feel like I'm missing anything. The biggest problem I have is that Ubuntu Server defaults (or used to default) to having the system wait on network interfaces, which is annoying when I want to build a desktop off of it. And sometimes on shutdown it waits for some daemon I don't care about to quit. Which is probably just a bug in the daemon.
- eternityforest 5y ago
  The transition period of any new tech is usually horrid. But now that things aren't buggy, being unable to modify them in place is a good thing. It sets a clear boundary that this is not how you do things on a modern system, so you can always expect systemd to be the same, consistent, non customized thing it always is.
  - a-dub 5y ago
    just like pentalobe screws! i'm not going to argue it's a bad thing, i actually really like macs and think they hide a lot of details making time and space for other pursuits, although since you cede user serviceability it's important to purchase a service plan and that you don't try anything that wasn't provided for in the design. maybe simple composable parts are past their prime. i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. but i suppose that's given way to large monolithic daemons these days. personally though, i always thought the simplicity and the composability of unix philosophy was what bred systems that outperformed their competition in terms of security and extensibility. so many commercial systems reflected apparent power grabs within the corporate structures that produced them... i suppose that when you see foss monoliths like this, it's the same game playing out on a different field.
    - shawnz 5y ago
      > i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. You could achieve the same thing with systemd socket activation :)
      - hanselot 5y ago
      - a-dub 5y ago
        > Which one would you trust to take you into space? neither. last i checked, linux, even with rt_preempt, was unsuitable for realtime control applications. even hollywood gets that, didn't you see the end of "don't look up"?
- kaba0 5y ago
  You can configure systemd to kill lingering applications, it was defaulted to false because some old UNIX tools liked to linger in the background forever.
Blikkentrekker 5y ago
Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script. To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file can contain anything the system administrator wills, from a simple script that does nothing more than `systemctl sleep` to whatever complex task he could desire. The last time I checked the situation, logind had replaced this powerful, and simple mechanism with a configuration that offers nine options to execute when the lid is pressed, none of which involve executing a simple file. Of course I can edit the source code and recompile to allow it to do what I want it to, but I would far rather simply quickly alter a simple shell script to do so. And luckily I can, because I do not use logind but acpid, but that does not change the ire I experience when dealing with many Redhat and Freedesktop people who make it very clear that I should be using logind, that it's better, and that they create artificial dependencies on it to as Poettering calls it “gently puh” me in that direction.
- vanviegen 5y ago
  Although I like the acpid approach, the logind way is probably safer to abstract behind a user friendly GUI. That's what most people will be using. :-/
  - Blikkentrekker 5y ago
    And that is probably the motivation for this design philosophy of limiting options that Redhat and Freedesktop champion where more and more, simple, clean, turing complete solutions are replaced by a discrete list of simple options. But it does not change at all why I dislike it, and why I am annoyed by Freedesktop's pushing and insistence that many keep to these more custoizable solutions supposedly simply because they are “stuck in their ways” and that their philosophy is the future and “modern”, whereas all I see is more hurdles that stop me from effectively being the master of my own machine.
    - 5y ago

ReactiveJelly 5y ago

There is a difference between the best C, and scripts that you can modify in-place. But, like some other comments have said, I was young enough to dodge the drama. I basically grew up with systemd and I don't feel like I'm missing anything. The biggest problem I have is that Ubuntu Server defaults (or used to default) to having the system wait on network interfaces, which is annoying when I want to build a desktop off of it. And sometimes on shutdown it waits for some daemon I don't care about to quit. Which is probably just a bug in the daemon.

eternityforest 5y ago
The transition period of any new tech is usually horrid. But now that things aren't buggy, being unable to modify them in place is a good thing. It sets a clear boundary that this is not how you do things on a modern system, so you can always expect systemd to be the same, consistent, non customized thing it always is.
- a-dub 5y ago
  just like pentalobe screws! i'm not going to argue it's a bad thing, i actually really like macs and think they hide a lot of details making time and space for other pursuits, although since you cede user serviceability it's important to purchase a service plan and that you don't try anything that wasn't provided for in the design. maybe simple composable parts are past their prime. i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. but i suppose that's given way to large monolithic daemons these days. personally though, i always thought the simplicity and the composability of unix philosophy was what bred systems that outperformed their competition in terms of security and extensibility. so many commercial systems reflected apparent power grabs within the corporate structures that produced them... i suppose that when you see foss monoliths like this, it's the same game playing out on a different field.
  - shawnz 5y ago
    > i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. You could achieve the same thing with systemd socket activation :)
    - hanselot 5y ago
    - a-dub 5y ago
      > Which one would you trust to take you into space? neither. last i checked, linux, even with rt_preempt, was unsuitable for realtime control applications. even hollywood gets that, didn't you see the end of "don't look up"?
kaba0 5y ago
You can configure systemd to kill lingering applications, it was defaulted to false because some old UNIX tools liked to linger in the background forever.

Blikkentrekker 5y ago

Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script. To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file can contain anything the system administrator wills, from a simple script that does nothing more than `systemctl sleep` to whatever complex task he could desire. The last time I checked the situation, logind had replaced this powerful, and simple mechanism with a configuration that offers nine options to execute when the lid is pressed, none of which involve executing a simple file. Of course I can edit the source code and recompile to allow it to do what I want it to, but I would far rather simply quickly alter a simple shell script to do so. And luckily I can, because I do not use logind but acpid, but that does not change the ire I experience when dealing with many Redhat and Freedesktop people who make it very clear that I should be using logind, that it's better, and that they create artificial dependencies on it to as Poettering calls it “gently puh” me in that direction.

vanviegen 5y ago
Although I like the acpid approach, the logind way is probably safer to abstract behind a user friendly GUI. That's what most people will be using. :-/
- Blikkentrekker 5y ago
  And that is probably the motivation for this design philosophy of limiting options that Redhat and Freedesktop champion where more and more, simple, clean, turing complete solutions are replaced by a discrete list of simple options. But it does not change at all why I dislike it, and why I am annoyed by Freedesktop's pushing and insistence that many keep to these more custoizable solutions supposedly simply because they are “stuck in their ways” and that their philosophy is the future and “modern”, whereas all I see is more hurdles that stop me from effectively being the master of my own machine.
  - 5y ago