You are not logged in.
Pages: 1
Why a shell (by interpreting a sysadm's script) couldnt do what a service manager does ?
Devuan(Chimaera)(Daedalus) DS+WM: XorgX11server+StumpVM
Offline
It could.
Online
So.. if it could .. wouldnt a shell by being more flexible and powerfull be more good at it ?
Devuan(Chimaera)(Daedalus) DS+WM: XorgX11server+StumpVM
Offline
I think service supervision should be repeatable and robust while flexible. Therefore it's an advantage to use shell scripts. Which is how sysvinit was designed.
Of course, a system that is open and flexible entices and empowers a large number of people to have a go at adjusting scripts and making new ones, and slowly the aggregate system will start to lose it's coherence as well as any original overarching design ideas. And with less and less coherence, newcomers more and more easily get confused and misdirected, so they more or less inadvertently continue exploiting the inherent openness and flexibility to make the aggregate system even less coherent.
To adopt and pursue an original intent would take "unproductive" effort to find such original intent purposefully documented and to digest and assimilate it. This often demands additional layers of learning that typically are well to the side of the immediate objective which most often merely is "to have something working for me right now".
Online
^^^Great post, you're a pretty erudite dude RRQ.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
ralph.ronnquist i should study more sysvinit and runit i guess. My idea was that by using a scripted service-system supervisor you make the system less complex (in comparison to having a another -hardcoded- supervisor). But you argue that shell-scripted control leads to less coherence due to more offered flexibility. So as a metaphore ,the system's services supervisor should be a brick to hold the userspace and not a quicksand ?
Devuan(Chimaera)(Daedalus) DS+WM: XorgX11server+StumpVM
Offline
Interestingly reading about the various service depedency models and what is supported by each system it reminds me of similar discussions regarding apt dependencies. A package A depends on B. So B is installed with A. Now A is gone, what apt should do with B ?
I guess the answer could be fuzzy and elusive.
Which makes me think. Is APT scripted or not? And maybe then my initial question could be better rephrased as : Should a service manager be implemented in a certain programming language or in a scripted (interpreted) language? And a similar question : Is BASH (a shell) a specialized interpreter suited for that kind of job (service-system supervisor) or another interpreter could be better suited ?
Devuan(Chimaera)(Daedalus) DS+WM: XorgX11server+StumpVM
Offline
writing an init (or parts of an init), service supervision suite/system, or even an init-like daemon with it's client sounds like a good idea, shell even allows you to do some of the needed tasks trivially like gathering the pid of a process started with &, however once you face some of the less trivial and more complex tasks you start to stumble upon walls that you could not have seen purely from having a naive initial design/architecture for the driving daemon and then enter the refactoring purgatory where you can't just simply start refactoring code and changing program architecture but have to plan out every refactor and change so that later down the line when it is finally time to implement the feature no new roadblock will appear from thin air...
Offline
No, service management should not be a brick because it needs openness and flexibility. In my mind, my words were rather an attempt to explain why one might raise the questions you raised; my view is that a service management system needs to be open and flexible in order to be useful in a multitude of circumstances.
Are you seeking answers really, or are you seeking questions? Don't you wish to come to conclusions about those questions you ask, or do you prefer to side step and ask similar or new questions about other sub systems? Why don't you focus on individual functions. such as partitioning or file manager or keyboard mapping?
Online
Pages: 1