Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!gatech!gtss!chas
From: chas@gtss.gatech.edu (Charles Cleveland)
Newsgroups: comp.sys.amiga
Subject: Re: More 1.4 whishes (and sw-installation procedure)
Message-ID: <342@gtss.gatech.edu>
Date: 4 Mar 89 01:09:38 GMT
References: <5442@abo.fi> <413@antares.UUCP> <5899@abo.fi> <5970@abo.fi>
Reply-To: chas@gtss.UUCP (Charles Cleveland)
Organization: Georgia Tech School of Physics
Lines: 72

Do all the following nested responses confuse you?  They sure as hell confuse
me.

In article <5970@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes:
)In article <5899@abo.fi>, vinsci@abo.fi (Leonard Norrgard) writes:
)> In article <413@antares.UUCP>, jms@antares.UUCP (Joe Smith) writes:
)>> In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes:
)>>>- An autoexec-directory: execute all programs and scripts in this
)>>>  drawer on startup. Then I would only have to drag icons into this
)>>>  directory to make them part of my startup.
)>> 
)>> If this is implemented, make sure it doesn't have the same problems as the
)>> AUTO folder on the Atari ST.  Several initialization programs will not work
)>> unless they are executed in a particular order.
)>>...
)>   So what would the directives look like? Well, how about:
)> 
)>      ANYTIME   --  Execute me at any point relative to the other startup
)> 		   scripts in this directory, except for the FIRST script
)> 		   which will always be the first. If no other type is
)> 		   specified, ANYTIME is the default.

        Other directives omitted for space.
)
)This is one possibe approach. Another simpler would be that the arrangement
)of icons would determine the order of execution. Arrange the icons in pretty
)rows and columns. Then execute first on first row,secons on first row...
)first on second row... and so on. This scheme obviously has some problems
)connected to it: how do we determine if an icon is on the same row or the
)row under it or above. A single pixel could make the difference. Is there
)a reasonable solution? Another would be a special program to set startup
)priorities. 
   ^
   |-------All we need is this program.  It will probably never be written.


The rest is not the problem.  The problem is that the poor (possibly naive)
user is responsible for determining the order of execution because he
determines the arrangement of the icons.  If he knows enough to do this,
he can probably write his own startup-sequence anyway and will probably
be much more comfortable doing so.

The directive approach might be one that the vendor could use to set up
his startup stuff so that it would work in the absence of any enlightenment
on the part of the user.  But even then, if he thinks his sequence should
execute after Mount_HD and the user has a Mount_Supra instead (or a
Mount_Rushmore -- he could name it anything), then he's in real trouble.
A system using names is hopeless without standardization of those names.
In general the names can be arbitrary.  Imagine trying to produce a makefile
(we are taking about producing a makefile, aren't we?) when you don't know
what the names of the units will be.

A priority system might be more useful, but priorities are linear and the
dependencies between various pieces of hardware and software aren't, but
can be quite complex, requiring intelligence to sort out.  There may 
conceivably be configurations where it is necessary to mount two systems
*simultaneously* (though I don't expect either to reach market).  I suspect
that it can be shown that there is no set of priorities which works in all
situations.

Actually, I like the makefile analogy.  I think it might be useful to think
about how a makefile describing the dependencies of various system units
could be constructed and how it might have to be changed when a new unit
is introduced.  Instead of $(OBJECTS) one might have $(HARD-DISKS).  But
I think that the organization must be centralized and that it cannot be
in general captured merely by associating attributes with particular files
such as Mount_HD, without regard to what other files may be in the picture.
-- 
-  It is better for civilization to be going down the drain than to be  -
-  coming up it.                                        -- Henry Allen  -
Charles Cleveland  Georgia Tech School of Physics  Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas                INTERNET:  chas@gtss.gatech.edu