3 ms·

Read it through but hard to grasp all the details. One thing I'm sure is that for non-systemd "legacy" init systems I know what I'm doing, for systemd I most of

by ausjke 11y ago

Read it through but hard to grasp all the details. One thing I'm sure is that for non-systemd "legacy" init systems I know what I'm doing, for systemd I most of the time don't know what's going on there, it's still like a blind art after using it for a while, overly abstracted might be one reason for that.

kbenson 11y ago
I think part of the reason for this may be that some types of systems lend themselves to exploration and gradual learning through use, while others, being very tightly coupled, generally require a larger upfront investment in learning how they function as a whole, since any one subcomponent is only marginally useful without the rest. This is largely how I remembered studying for Microsoft certification back in the day to be. There was only so much you could easily learn from playing around with the system. At some point, well written technical documentation was, if not required, extremely helpful in making connections between how systems worked together, or explaining exactly what a component was or was not capable of. I don't think this is inherently worse or better, just different, and with its own advantages and disadvantages. For example, people who went through this training seemed to have a very high base-level of understanding of how to configure these systems, what they could or could not do, and how to troubleshoot them, but not necessarily how they functioned in every case. 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. The average person responsible for using these will have vastly different levels of skill and knowledge about them, but with that comes how it actually functions, because that's needed to troubleshoot problems, since it's so exposed. The feeling I get mostly when reading about systemd is that it's very much in the vein of MS products. Like I said, that isn't necessarily a bad thing, but it is very different than a lot of UNIX admins are used to.
- bgilroy26 11y ago
  >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!

by ausjke 11y ago

kbenson 11y ago

I think part of the reason for this may be that some types of systems lend themselves to exploration and gradual learning through use, while others, being very tightly coupled, generally require a larger upfront investment in learning how they function as a whole, since any one subcomponent is only marginally useful without the rest. This is largely how I remembered studying for Microsoft certification back in the day to be. There was only so much you could easily learn from playing around with the system. At some point, well written technical documentation was, if not required, extremely helpful in making connections between how systems worked together, or explaining exactly what a component was or was not capable of. I don't think this is inherently worse or better, just different, and with its own advantages and disadvantages. For example, people who went through this training seemed to have a very high base-level of understanding of how to configure these systems, what they could or could not do, and how to troubleshoot them, but not necessarily how they functioned in every case. 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. The average person responsible for using these will have vastly different levels of skill and knowledge about them, but with that comes how it actually functions, because that's needed to troubleshoot problems, since it's so exposed. The feeling I get mostly when reading about systemd is that it's very much in the vein of MS products. Like I said, that isn't necessarily a bad thing, but it is very different than a lot of UNIX admins are used to.

bgilroy26 11y ago
>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!