Date: Tue, 15 Jul 1997 10:01:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: syssgm@dtir.qld.gov.au (Stephen McKay) Cc: freebsd-hackers@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: multiple run-levels (was: Re: /etc/init.d/) Message-ID: <199707151701.KAA03654@phaeton.artisoft.com> In-Reply-To: <199707150416.OAA01561@ogre.dtir.qld.gov.au> from "Stephen McKay" at Jul 15, 97 02:16:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >As Terry mentioned, the concept of run-levels is sound, its just that the > >SysV implementation where '1' is single user and '2' can be something else > >and '3' is sometimes network level, etc, SUCKS > > I'm one of the (raving monster looney) objectors to the run level concept. > Even if you fix the crap that System V has, I still find the whole concept > intensely objectionable. There are reasons to have a maintenance mode, and > an operational mode, which we call single user mode and multi user mode. > There is no need for the other junk. Yes and no. IBCS2 compatability requires that the target system support run levels to correctly support IBCS2 compliant installation scripts for commercial shrink-wrapped products designed to be run on UNIX platforms. In an ideal world, everyone would share your vision (and mine) that BSD is the best OS, and they would create their software on BSD and port it to any other platform they wanted to sell it on. I think we can agree that that is not going to happen. The question becomes: "How can we take advantage of existing off-the-shelf UNIX applications". The answer is IBCS2 compliance, in the near term, and common UNIX standard, in the long term. > Terry described a complex way to use his mobile computer which boils down > to a desire to: > 1) add and remove network connections > 2) add and remove hardware > while continuing in multiuser mode. No more magic than that. This is true. I never claimed more magic was required. > Appearing and disappearing network connections can be dealt with using > some program similar to routed. No, they can't. If they can, I'd like a cookbook on how to make this happen. The problem is that there is no configuration monitor that can react to device arrival and departure events, assuming they occur in the first place. One easy conversion is from "plain old init" into "init plus some configuration management capabilities". > Adding and removing hardware will be more difficult, but won't be > handled by run states. It will have to be handled by device drivers. It's a lot easier, actually, to get arrival/departure events out of what are, essentially, plugable interfaces (docking port, PCMCIA, etc.). It can *not* be handled solely by the device drivers; a configuration monitor is required, as is a list of possible configurations, and what should occur as a result of leaving one configuration and entering another. Now it's quite possible to write a bunch of new code to handle configuration change events (including power management events). It may even be possible to do this such that you can preserve the anonymity of the NFS server from which you are mounting your presentation software package into the same place in your local FS hiearchy. By why go to this trouble when an init mechanism already exists? > Run levels suck, and I'm going to hold my breath until you all > forget about them. Fine; I never wanted run *levels* anyway. 8-). > Run states also suck, because they are too simplistic. Why consider the > presence of a network connection as different from the presence of my > window manager (say). Because ideally you'd use a single window manager so that you would not require retraining on other window managers. Window managers are also not a system configuration issue; in point of fact, they are not even a system service issue (ie: I want or don't want an HTTP service provided by my system to other systems, regardless of what the idiot user wants to run as a window manager). A network connection is different in that you don't care *how* you are connected, only that you *are* connected (hopefully by the most efficient method for a given set of possibilities). > I need different networking, I run the connect program. No. End users should not be expected to know about building and destroying network connections in order for their systems to be minimally usable. This type of thinking is why your market is small and Bill Gates market is large. > You can call these things different "states", but you don't > gain anything by coding all possible arrangements and wiring > them into a directory structure. I gain a user base, which gains me more products that I can personally run. There are good, selfish reasons for doing this as well as "bad" non-selfish reasons. 8-). > Fuzzy thinking here will just lumber us with more cruft. And a fuzzy control system will save us both more cruft and more pain. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707151701.KAA03654>