4 ms·

Is there some high-level document or blog post somewhere that outlines the vision of the systemd developers and why they are building these systems? So far I se

by api 11y ago

Is there some high-level document or blog post somewhere that outlines the vision of the systemd developers and why they are building these systems? So far I see a variety of projects (of IMHO varying quality) but no attempt at articulating a vision to tie it all together. What's the goal? What problem is all this stuff solving?

CaptSpify 11y ago
> What problem is all this stuff solving? RH's lack of having their hands in everything (only kinda kidding)
viraptor 11y ago
Have a look at systemd.conf presentations (and videos https://www.youtube.com/channel/UCvq_RgZp3kljp9X8Io9Z1DA https://www.youtube.com/channel/UCvq_RgZp3kljp9X8Io9Z1DA). There are various goals there. My interpretation would be: universal, global interfaces for all system things. Which is not a bad goal in itself.
- vezzy-fnord 11y ago
  Which is not a bad goal in itself. It's worse than a bad goal. "Universal, global interfaces for all system things" is a goal that is cognitively meaningless.
  - viraptor 11y ago
    Not sure why cognitively meaningless. To some extent syscalls are a global, universal interface for all system things. They're just very low level, so they carry very little information. Dbus is an abstraction that allows actions with rich information and context, and makes it possible to define simple interfaces to potentially complex sets of actions. Systemd and related services fulfill those interfaces. Why do you think that's a bad goal?
    - vezzy-fnord 11y ago
      "All system things" is a meaningless statement. Syscalls can actually carry quite a lot of information (just look at signal semantics) and they're not "very low level". The second paragraph is more wind. I don't think it's a bad goal. You haven't even specified a goal.
      - viraptor 11y ago
        I see what you mean, but I think it's a technicality. There's no good definition that I know of that wouldn't be called either insufficient or scope creep. Can you come up with one that includes interface to date/time, connected devices (with access control), virtual-or-physical screen resolution, packages, system and user services, etc. ? They're not even all administration actions. My best description here is "all system things" even if it's poorly defined - simply because I don't have a better one. As for syscalls - they can carry a lot of data. That doesn't make it rich, structured information. Sure, everything is just writing/reading bytes at the end of the day. But there's a reason we've got open() function and don't use syscalls directly - rich interfaces are nice. Syscalls are definitely low level (they're defined in the cpu specs, how much more low-level can you get?).
        vezzy-fnord 11y ago
        I wouldn't describe it as a technicality, but more of a carte blanche vacuity. What comprises "the system"? Just about everything. Hence "all system things" is really "all everything things". Such underspecified weasel wording is a chief reason for systemd's status at large. Even your list involves diverse interfaces ranging from real-time kernel primitives to end-user archives (packages), so again, "system things" is more of a justification for perpetual consumption than anything resembling a mission statement or goal. (Things that merely wrap syscalls would probably be part of a utilities package anyway, a la util-linux.)
        viraptor 11y ago
        Yes, it does include diverse interfaces. And you keep saying the idea of common interface to all (system or everything) things is a bad idea, but not why. So again, why is it bad idea to want a common bus that can talk to all of those things and have interfaces that actually describe high-level, meaningful actions on them? I can agree systemd situation is bad, but I don't think it's because of technical reasons. Leaving systemd out of it, what's bad about the idea that distributions, backend services, and client applications start using a common bus that has an interface for action "The system timezone is now XXX"? (and similar actions for network configuration, printers, sessions, and "all everything things")
emmelaich 11y ago
You should at least read "Rethinking PID 1" from 2010 http://0pointer.de/blog/projects/systemd.html Lennart has written an enormous amount of excellent articles about systemd.

by api 11y ago

CaptSpify 11y ago

> What problem is all this stuff solving? RH's lack of having their hands in everything (only kinda kidding)

viraptor 11y ago

Have a look at systemd.conf presentations (and videos https://www.youtube.com/channel/UCvq_RgZp3kljp9X8Io9Z1DA https://www.youtube.com/channel/UCvq_RgZp3kljp9X8Io9Z1DA). There are various goals there. My interpretation would be: universal, global interfaces for all system things. Which is not a bad goal in itself.

vezzy-fnord 11y ago
Which is not a bad goal in itself. It's worse than a bad goal. "Universal, global interfaces for all system things" is a goal that is cognitively meaningless.
- viraptor 11y ago
  Not sure why cognitively meaningless. To some extent syscalls are a global, universal interface for all system things. They're just very low level, so they carry very little information. Dbus is an abstraction that allows actions with rich information and context, and makes it possible to define simple interfaces to potentially complex sets of actions. Systemd and related services fulfill those interfaces. Why do you think that's a bad goal?
  - vezzy-fnord 11y ago
    "All system things" is a meaningless statement. Syscalls can actually carry quite a lot of information (just look at signal semantics) and they're not "very low level". The second paragraph is more wind. I don't think it's a bad goal. You haven't even specified a goal.
    - viraptor 11y ago
      I see what you mean, but I think it's a technicality. There's no good definition that I know of that wouldn't be called either insufficient or scope creep. Can you come up with one that includes interface to date/time, connected devices (with access control), virtual-or-physical screen resolution, packages, system and user services, etc. ? They're not even all administration actions. My best description here is "all system things" even if it's poorly defined - simply because I don't have a better one. As for syscalls - they can carry a lot of data. That doesn't make it rich, structured information. Sure, everything is just writing/reading bytes at the end of the day. But there's a reason we've got open() function and don't use syscalls directly - rich interfaces are nice. Syscalls are definitely low level (they're defined in the cpu specs, how much more low-level can you get?).
      - vezzy-fnord 11y ago
        I wouldn't describe it as a technicality, but more of a carte blanche vacuity. What comprises "the system"? Just about everything. Hence "all system things" is really "all everything things". Such underspecified weasel wording is a chief reason for systemd's status at large. Even your list involves diverse interfaces ranging from real-time kernel primitives to end-user archives (packages), so again, "system things" is more of a justification for perpetual consumption than anything resembling a mission statement or goal. (Things that merely wrap syscalls would probably be part of a utilities package anyway, a la util-linux.)
        viraptor 11y ago
        Yes, it does include diverse interfaces. And you keep saying the idea of common interface to all (system or everything) things is a bad idea, but not why. So again, why is it bad idea to want a common bus that can talk to all of those things and have interfaces that actually describe high-level, meaningful actions on them? I can agree systemd situation is bad, but I don't think it's because of technical reasons. Leaving systemd out of it, what's bad about the idea that distributions, backend services, and client applications start using a common bus that has an interface for action "The system timezone is now XXX"? (and similar actions for network configuration, printers, sessions, and "all everything things")

emmelaich 11y ago

You should at least read "Rethinking PID 1" from 2010 http://0pointer.de/blog/projects/systemd.html Lennart has written an enormous amount of excellent articles about systemd.