4 ms·

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")
        vezzy-fnord 11y ago
        I can agree systemd situation is bad, but I don't think it's because of technical reasons It is: http://blog.darknedgy.net/technology/2015/10/11/0/ http://blog.darknedgy.net/technology/2015/10/11/0/ The context of this comment section was about systemd in general, not the BUS1 concept specifically. It's too early to comment on the latter when it's still just a red-black tree with some stub functions.
      - pzone 11y ago
        Can't a project have fuzzy boundaries yet not be an abomination? Systemd got started when trying to write a new init system and daemon manager that took advantage of Linux's new cgroups features. The implementers and users of systemd decided that it made sense to implement some other things in it, to support and make those functions convenient. I think a reasonable definition of systemd's goals is "init + service manager, and then anything else which is helpful in supporting that." Yes it's a fuzzy definition, but it's not saying that it's supposed to increase in scope without bounds. For example, systemd doesn't need to provide an http daemon, because it's not helpful to other services to provide that functionality. There's httpd already. But systemd does naturally provide some date and time functions. That's because the system log functionality needs to throw time stamps on everything, and starting processes at regular intervals also relies on knowing the system time, so it naturally fits in as part of what a process management daemon should provide.

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")
      - vezzy-fnord 11y ago
        I can agree systemd situation is bad, but I don't think it's because of technical reasons It is: http://blog.darknedgy.net/technology/2015/10/11/0/ http://blog.darknedgy.net/technology/2015/10/11/0/ The context of this comment section was about systemd in general, not the BUS1 concept specifically. It's too early to comment on the latter when it's still just a red-black tree with some stub functions.
    - pzone 11y ago
      Can't a project have fuzzy boundaries yet not be an abomination? Systemd got started when trying to write a new init system and daemon manager that took advantage of Linux's new cgroups features. The implementers and users of systemd decided that it made sense to implement some other things in it, to support and make those functions convenient. I think a reasonable definition of systemd's goals is "init + service manager, and then anything else which is helpful in supporting that." Yes it's a fuzzy definition, but it's not saying that it's supposed to increase in scope without bounds. For example, systemd doesn't need to provide an http daemon, because it's not helpful to other services to provide that functionality. There's httpd already. But systemd does naturally provide some date and time functions. That's because the system log functionality needs to throw time stamps on everything, and starting processes at regular intervals also relies on knowing the system time, so it naturally fits in as part of what a process management daemon should provide.