What does an ideal init system look like - pid1 revisited (and/or deamontools)
by zeebra from LinuxQuestions.org on (#5P9PF)
Again I have been reading up on init systems to try to get some answers, and I'm a little bit st(r)uck. This is not about init x vs init y, but more of a thread to discuss what an ideal/optimal init would be like if it was to be designed today. All the init systems currently existing seem to have a variety of pros and cons.
Anyways. I will start listing some things that I think would be essential for a good init system in 2021:
- Minimalistic init (supporting all kind of systems)
- Security oriented (what's the point of all the kernel security and userland security if the init is not secure? aka x vs w type discussion)
- Generic (can be used in multiple Unix like systems, not only Linux)
- Generic (not creating unecessary dependencies)
- Written in C (most likely?)
- Easy for users to manage (rc.d easy)
- Easy for users to manage with commands
- Easy to modify (scriptable option as oppose to have to rewrite C code)
- Service aware but passing the task to its own or any other service manager
- Rock solid stable
- Easy migration path
- Procedural AND parallell support (user choice)
- Modular design (??) (added features possible but optional)
- Scalable/plugins (??)
- Some or mostly compatibility with other init systems/functions (??)
Gathered most of these from init comparisons and pros and cons from various places. Feel free to discuss pros and cons of these pros, or add your own pros of how a 2021 optimal init should look like and behave. But don't discuss existing init systems or pros and cons of those, or which one is better or worse.
This is about discussing how an ideal init to be made in 2021 onwards would look like to make a "perfect" init.
Feel free to discuss technical possibilities and viabilities of ALL together and individual features an optimal init should have, or how X or Y could be done. It's a fully open discussion about "init 2021", let's call it.
I was reading the manual of a GNU init, and some of the things that struck me about it was "service dependency and resolution", it seems like good point too, but then again, the cons of it being too automated, complex and possibly creating issues was too much for me to include it as a "good feature", but something similar would surely be a "must have feature", dynamically adding/removing/restarting daemons, maybe as an optional feature.
Anyways. I will start listing some things that I think would be essential for a good init system in 2021:
- Minimalistic init (supporting all kind of systems)
- Security oriented (what's the point of all the kernel security and userland security if the init is not secure? aka x vs w type discussion)
- Generic (can be used in multiple Unix like systems, not only Linux)
- Generic (not creating unecessary dependencies)
- Written in C (most likely?)
- Easy for users to manage (rc.d easy)
- Easy for users to manage with commands
- Easy to modify (scriptable option as oppose to have to rewrite C code)
- Service aware but passing the task to its own or any other service manager
- Rock solid stable
- Easy migration path
- Procedural AND parallell support (user choice)
- Modular design (??) (added features possible but optional)
- Scalable/plugins (??)
- Some or mostly compatibility with other init systems/functions (??)
Gathered most of these from init comparisons and pros and cons from various places. Feel free to discuss pros and cons of these pros, or add your own pros of how a 2021 optimal init should look like and behave. But don't discuss existing init systems or pros and cons of those, or which one is better or worse.
This is about discussing how an ideal init to be made in 2021 onwards would look like to make a "perfect" init.
Feel free to discuss technical possibilities and viabilities of ALL together and individual features an optimal init should have, or how X or Y could be done. It's a fully open discussion about "init 2021", let's call it.
I was reading the manual of a GNU init, and some of the things that struck me about it was "service dependency and resolution", it seems like good point too, but then again, the cons of it being too automated, complex and possibly creating issues was too much for me to include it as a "good feature", but something similar would surely be a "must have feature", dynamically adding/removing/restarting daemons, maybe as an optional feature.