4 ms·

> Systemd OTOH makes almost all possible sins against the unix philosophy Is this supposed to be a bad thing? Because I don't find it obvious. In fact, I don't

by pkkm 3y ago

> Systemd OTOH makes almost all possible sins against the unix philosophy Is this supposed to be a bad thing? Because I don't find it obvious. In fact, I don't get why many people have this mystical reverence for the "unix philosophy", as if having a large number of small processes that communicate via plain text was some kind of divine commandment rather than just one of many ways to design software (and not necessarily that good for tasks other than slicing and dicing text). I'm guessing that you do your image editing in a program like GIMP or Photoshop rather than with a bash shell, pipes, and a hundred tiny programs that input and output text. The "unix philosophy" simply isn't a good fit there. Having used both sysvinit and systemd when doing server administration, I find systemd so much better that to me, it's evidence that maybe the "unix philosophy" isn't the best choice here either.

imtringued 3y ago
systemd is a hundred tiny programs packaged as one big package by your distro. People don't seem to understand that.
jampekka 3y ago
The core idea is "do one thing and do it well". Implicated here is that these tools should have interoperable interfaces. These are very basic principles for good design in any programming. Unix implementation of this is cli programs, streams and files. The systemd ideology, and in general declarative or pointy-clicky-ad-hoc like in Windoes and MacOS, dumb down computers into appliancies. I don't want my computer, especially the very core of the userspace, to be an appliance. For most image editing I use bash and imagemagic. I guess you e.g. resize a batch of images by repeating the same clicky-click routine for each image? Clicky-click has it's uses, but e.g. in Blender I much rather use nodes instead of having thousands of buttons for all connection permutations. Nodes are quite unixy in their UI philosophy. Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. I'd love a modern and retought implementation of the unix philosophy.
- kaba0 3y ago
  cli programs are not interoperable. Binary streams are not an interface, it's the lack of one. I can't goddamn pipe the CPU temperature into my display manager's status bar without 3 different tools unmaintainable, easy-to-break invocations, that will break from something as innocuous as changing the locale. It's as much of an interface as randomly reading into the memory of another process.
  - jampekka 3y ago
    That you can do it with 3 different tools means that they are interoperable. That you can do this without hacking into some huge codebase or waiting someone to implement this specific feature. /sys/class/thermal/thermal_zone0/temp gives you the temperature in ASCII. It's about as simple and interoperable as an interface gets. I like that I can check it in terminal with cat /sys/class/thermal/thermal_zone0/temp when needed. I really like that I can check a remote computer's CPU temperature by doing ssh some.remote.host -C cat /sys/class/thermal/thermal_zone0/temp. If you have the commands to show that in your status bar, you can easily extend a local one to a remote one. You prefer to wait for remotehosttemperaturetostatusbarctl to appear in the AppStore? Or write and debug thousand lines of dbus juggling in C? I do agree that cli programs should be more interoperable in general. E.g. have more structured inputs and outputs akin to JSON or something, conform better to e.g. the GNU command line parameter spec and read stdin and write stdout and log to stderr by default.
- funcDropShadow 3y ago
  > The systemd ideology, ... , dumb down computers into appliancies. > Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. Why are you sure, you're perceived limitations of systemd compared to sysvinit are based on systemd's shortcommings instead of yours? I don't want to attack you personally, but I've had this conversation lot's of times before. Most of the time, people just had no clue how systemd works. In my experience it simplified lots of use-cases. And I have yet to find a use-case that was possible with sysvinit, but is not with systemd.

by pkkm 3y ago

imtringued 3y ago

systemd is a hundred tiny programs packaged as one big package by your distro. People don't seem to understand that.

jampekka 3y ago

The core idea is "do one thing and do it well". Implicated here is that these tools should have interoperable interfaces. These are very basic principles for good design in any programming. Unix implementation of this is cli programs, streams and files. The systemd ideology, and in general declarative or pointy-clicky-ad-hoc like in Windoes and MacOS, dumb down computers into appliancies. I don't want my computer, especially the very core of the userspace, to be an appliance. For most image editing I use bash and imagemagic. I guess you e.g. resize a batch of images by repeating the same clicky-click routine for each image? Clicky-click has it's uses, but e.g. in Blender I much rather use nodes instead of having thousands of buttons for all connection permutations. Nodes are quite unixy in their UI philosophy. Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. I'd love a modern and retought implementation of the unix philosophy.

kaba0 3y ago
cli programs are not interoperable. Binary streams are not an interface, it's the lack of one. I can't goddamn pipe the CPU temperature into my display manager's status bar without 3 different tools unmaintainable, easy-to-break invocations, that will break from something as innocuous as changing the locale. It's as much of an interface as randomly reading into the memory of another process.
- jampekka 3y ago
  That you can do it with 3 different tools means that they are interoperable. That you can do this without hacking into some huge codebase or waiting someone to implement this specific feature. /sys/class/thermal/thermal_zone0/temp gives you the temperature in ASCII. It's about as simple and interoperable as an interface gets. I like that I can check it in terminal with cat /sys/class/thermal/thermal_zone0/temp when needed. I really like that I can check a remote computer's CPU temperature by doing ssh some.remote.host -C cat /sys/class/thermal/thermal_zone0/temp. If you have the commands to show that in your status bar, you can easily extend a local one to a remote one. You prefer to wait for remotehosttemperaturetostatusbarctl to appear in the AppStore? Or write and debug thousand lines of dbus juggling in C? I do agree that cli programs should be more interoperable in general. E.g. have more structured inputs and outputs akin to JSON or something, conform better to e.g. the GNU command line parameter spec and read stdin and write stdout and log to stderr by default.
funcDropShadow 3y ago
> The systemd ideology, ... , dumb down computers into appliancies. > Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. Why are you sure, you're perceived limitations of systemd compared to sysvinit are based on systemd's shortcommings instead of yours? I don't want to attack you personally, but I've had this conversation lot's of times before. Most of the time, people just had no clue how systemd works. In my experience it simplified lots of use-cases. And I have yet to find a use-case that was possible with sysvinit, but is not with systemd.