From owner-freebsd-hackers Mon Sep 25 15:01:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA23913 for hackers-outgoing; Mon, 25 Sep 1995 15:01:58 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA23888 for ; Mon, 25 Sep 1995 15:01:32 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id RAA13404; Mon, 25 Sep 1995 17:27:36 -0400 Date: Mon, 25 Sep 1995 17:27:36 -0400 From: Coranth Gryphon Message-Id: <199509252127.RAA13404@healer.com> To: patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert >>> Ah, but can you guarantee that the install script that inserts a >>> few new lines is putting them in the right place? > >+> Can you guarantee that the install script is going to get the numbering >+> right if we go with implicit order based upon script name? > Yes, actually. By using a sparse numeric order designator at the front > of the name to enforce ordering by strict lexical (numeric) order. Like > numbering your lines by 10 or 100 in a BASIC program. Like it adds to the end of the file. Or adds to the first (or fourth or ...) line after its dependancy. > +> Or worse, is every install going to check to make sure that no other > +> scripts exists which use that order number? > No. Because the number is not the only designator. By definition, > collisions in order designation are "don't care". This is because if Again, you can always append to the file if it is a "don't care", unless we are allowing additions that MUST come before other things that already exist in the startup sequence. I can think of it happening, though I'd like to see ANY automated sequence deal gracefully with it. And if it does, the same logic can be applied to the file edit. It really boils down to perference of style, and... > +> I think these are a LOT more dangerous. File order is explicit and simple. > +> Anything else is headaches. > You are not expected to manually edit the data. If you want to, fine: > you deserve headaches. The point is to make it easy for the tools, not It always comes down to a person trying to figure it out when something is wrong. I'd rather spend a little more time making the tools smarter, so that a person has an easier time of it, than making the tools stupid, and hoping the person is smart enought to work around that. That's the whole point of everything we're doing. Give the average person on the street a system that they can understand and maintain. Personally, I'd rather me (the designer/programmer) spend the time to make their lives easier, since that generates a larger customer/user base. Make things so that only long-time sys-admins with a serious understanding of OS concepts can debug this, and such free OS's will die. > +> If you want, put it as "mumble.daily" in /etc/bin and it will be run > +> automatically. > I have a problem with this. My problem is that I want finer control > over the granularity as part of the administrative range granted me There is no mechanism for doing this now. Either modify the current one with a few additional granularity levels, or let people do it by hand (which they have to do now anyway). I really can't see that there will be that many things that cannot conform into the "hourly, daily, weekly, monthly" framework we are currently using. > +> Yes, this relies upon implicit order (whatever "find" returns), which I > +> really don't like. But I couldn't see any other option, and if you > fairly simple: pick a number after the number of the packages you depend > on, but low enough that other packages may depend on you without overflowing > the lexical name space. I'd suggest 3 digits rather than 2 as a guard Or use file order, in which case your numbering limit is maximum number of lines in the file. Again, it quickly becomes a religious battle of which people prefer - numbered scripts or a control file. Personally, I like the control file. I can print it out, and know exactly what will run in what order. You like numbered scripts, you can print out a directory listing, and know exactly what will run in what order. Functionally, they are the same. Issues for the automation are similar in most cases (getting the ordering right, dependancies, collisions). You way requires sym-linked sub-dirs to control the order, mine still holds to the same master file. The danger of mine is that packages need to modify the master file, the danger of yours is that packages need to make sure they put the right files and links in the right places. > The feature we are considering is the ability to drop in add on components > as if they were system components and provide a unified administrative ... > It's possible to write one, but it'd be a kludge, and we all know it. We're in agreement here. It's just a matter of seeing different ways to implement similar concepts (gee, programmers never suffer this problem do they :-) > valid idea is a valid idea no matter where it comes from (I feel like Granted. A hundered times over :-) > The second best concept [SysV] had was run levels/states to allow staged > "run-up" and "run-down". I still like linear run-levels, rather than arbitrary states (and think the former would be a LOT easier to implement). > If you think you can present a unified view of all system > components without seperate scripts, fine, I'd like to see a set of > libraries for dealing with components. Is this a tangent, or missed interpretation? I have always been in favor of seperate scripts for each sub-system/component/package. I just want to put them in one place and have them run from a master file, rather than sym-links to state-based subdirectories. And yes, I'd be very happy a combined mechanism that includes startup of the various levels, plus the regularly scheduled daily/weekly stuff. > I already have a GUI library that will put out the right thing from the > same program on DOS, Windows, Mac, UNIX Text, Vanilla X, Motif, and Great. Given a simple GUI library, I'll even do the GUI's for both parts. > I'll give out the termcap/X/Motif libraries. Though I'd prefer a GUI > based Drag-N-Drop interface, like the Mac System folder concept, I'm > willing to throw the (IMO) less powerful paradigm out the door to get Drag-and-Drop I really think would be frosting. If you have the libraries for the standard GUI cake, let's go with what we have. We can always do a different GUI later. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa...