4 ms·

>Conversely, the loosely coupled individual components of traditional UNIX service handlers (sysvinit, inetd) promoted people learning how the actually work, an

>Conversely, the loosely coupled individual components of traditional UNIX service handlers (sysvinit, inetd) promoted people learning how the actually work, and what they do, but with scattered and not entirely comprehensive documentation on how they worked. Can you tease out this distinction a bit more? It reads like you are saying, due to their nature, people learned how to use Unix service handlers, without a good understanding of how they were designed. It could also mean that people learned how Unix service handlers worked by using them, through trial and error, because the documentation was scattered and not entirely comprehensive.

kbenson 11y ago
The second interpretation. The documentation is not entirely comprehensive because interface between components is not only a grey area of accountability, but also continuously changing. When the system is composed of multiple distinct sub-programs with their own development teams, update cycles and planned feature sets, what is possible at any one point in time is largely a matter of which versions of those sub-programs you are using, as well as what the root program (e.g.sysvinit) allows in it's version. There is no one set of features, nor one set of bugs, nor one set of directions. The best you can get in this regard is whatever your distro put together for the combination they chose, or alternatively to read the docs for every sub-program and intuit what new capabilities may exist in how they interact. I think the clearest example of this would be everything that makes up the core Linux environment, compared OpenBSD. OpenBSD has amazing documentation, and the systems are all designed to work with eachother because they were all designed and developed as a working whole. Linux, on the other hand, often exposes interfaces through the kernel, and some other set of developers (or multiple set of developers) create systems to interface with it. As such, the documentation can be haphazard or near non-existent. That's not to say the Linux methodology doesn't have it's advantages. For example, I think there's a better feedback loop in Linux in determining what is needed from the kernel, and what can be done from it in userspace. It's a more market-like system, and sees rapid advancement.
- bgilroy26 11y ago
  Thank you!

kbenson 11y ago

The second interpretation. The documentation is not entirely comprehensive because interface between components is not only a grey area of accountability, but also continuously changing. When the system is composed of multiple distinct sub-programs with their own development teams, update cycles and planned feature sets, what is possible at any one point in time is largely a matter of which versions of those sub-programs you are using, as well as what the root program (e.g.sysvinit) allows in it's version. There is no one set of features, nor one set of bugs, nor one set of directions. The best you can get in this regard is whatever your distro put together for the combination they chose, or alternatively to read the docs for every sub-program and intuit what new capabilities may exist in how they interact. I think the clearest example of this would be everything that makes up the core Linux environment, compared OpenBSD. OpenBSD has amazing documentation, and the systems are all designed to work with eachother because they were all designed and developed as a working whole. Linux, on the other hand, often exposes interfaces through the kernel, and some other set of developers (or multiple set of developers) create systems to interface with it. As such, the documentation can be haphazard or near non-existent. That's not to say the Linux methodology doesn't have it's advantages. For example, I think there's a better feedback loop in Linux in determining what is needed from the kernel, and what can be done from it in userspace. It's a more market-like system, and sees rapid advancement.

bgilroy26 11y ago
Thank you!