On Mon, Mar 19, 2012 at 12:35:26AM +0200, Alan McKinnon wrote > > systemd is like Captain Picard of STTNG (Start Trek The Next > > Generation) always saying "make it so". *HOW DO YOU "MAKE IT SO"? > > That intelligence has to be somewhere. So what alternative do you > > propose? A bash or ash script is more guaranteed to run than a > > binary. Shoving all that "intelligence" into the service itself, > > means that the service has to start up in order to determine whether > > it's safe for the service to start up. What's wrong with this > > picture? > > The intelligence goes in the init system's config file for that service > of course. I know I didn't clearly say so, but that's where it goes.
The config file can specify upper/lower limits, variables, settings, etc, etc. But in the end, some executable somewhere is going to have to parse the config file, check the actual environment, and decide whether or not to launch the service, and with what parameters. Note also that many open source programs are multiplatform. I.e. they run on FreeDOS with DJGPP, multiple flavours of Windows, multiple BSDs (including Apple), linux, and multiple commercial unix flavours. Do you really want to throw multiple platform-specific IFDEFs into the program code to allow the services to do the appropriate platform-specific initialization? Isn't it be easier to move the service setup out of the main service, and let the maintainers of the specific platforms figure it out? One last question. Let's go back in time 20 years, and assume that you're the maintainer for a program that runs as a service. A small handfull of end-users come along. They're running a "hobby OS" that fits on a couple floppies. Said "hobby OS" has been cobbled together by a university student. Would you... * download that university student's hobby OS, and install it * throw in a bunch of additional IFDEF initialization code in your program * test and debug the program to make sure it runs under that OS -- Walter Dnes <waltd...@waltdnes.org>
