Path: utzoo!yunexus!unicus!yunexus!spectrix!John_M
From: John_M@spectrix.UUCP (John Macdonald)
Newsgroups: comp.sys.mac
Subject: Re: Init Manager, please
Summary: init ordering requirements are not neccessarily bugs
Message-ID: 
Date: 19 Dec 87 06:08:16 GMT
Article-I.D.: spectrix.I46
Posted: Sat Dec 19 01:08:16 1987
References: <338@spectrix.UUCP> <3184@batcomputer.tn.cornell.edu> <22163@ucbvax.BERKELEY.EDU> <977@pembina.UUCP> <8216@steinmetz.steinmetz.UUCP> <8203@steinmetz.steinmetz.UUCP> <3185@batcomputer.tn.cornell.edu> <7028@apple.UUCP> <2250@dasys1.UUCP> <2491@fluke.COM>
Reply-To: jmm@spectrix.UUCP (John Macdonald)
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada
Lines: 185

In <338@spectrix.UUCP>, I made a long posting asking for a way of
controlling inits, both the order that they were run, and which
ones would be run at all; with these alternatives being specified
either for permanent effect, or for a single boot only.  Judging
from the number and intensity of the responses, this is an important
matter.

A number of responses refer to Aask, an Init which provides much
of this capability, being developed by CE Software, with an early
version already available on various bulletin boards.  I will
certainly look into this, but I think that this is something that
is important enough for Apple to do - putting it into the System
itself (a new variant of INIT 31).  I will return to this point
later.

It has been pointed out that you can disable INITs by moving them
out of the System folder, and that you can control their order by
renaming them.  This is considered to be so simple that providing
any other mechanism makes it difficult for naive users to understand
what is happening.  I agree with this only partially.  It is very
easy for a naive user to add a new INIT to their system file to
try it out and to remove if he doesn't like it.  This simplicity
should not be interfered with.  It is not easy for a naive user
to install the latest system/finder/multifinder from Apple, have
it crash on startup, and then figure out which INIT is not compatible
with the new system.  It is not easy for a naive user to determine
which INIT is causing a conflict with a new INIT that he is trying
to install.  (It is not even very easy for a naive user to determine
what other INITs he has that might be conflicting.  He can easily not
notice an init sitting in the middle of a bunch of device drivers.
He can forget that something is an init)  It is not easy for some
naive users to rename a file that they didn't create. (They are
justified too, some programs stop working if you rename them.)

There was also some mention of the confusion that might result if
it were possible to have inits that were not in the system folder.
Considering the large number and variety of different files that
MUST be in the system folder, I don't fully agree.  This is one
of the things that I especially like about Suitcase - it adds files
to the system usage class that can be collected in a folder under
the system folder.  (I would like to see blessed sub folders, so
that you can have device drivers in one, inits in another, DA's
and their control files in another, etc.)  (Suitcase also brings
back the day where a "usable" system file could be copied to a
floppy.  If you haven't got Suitcase, look into it.  disclaimer:
I just a happy customer.)

If trying to determine what init causes a crash means that you
must reboot from floppy, move various inits in/out of your system
folder and retry and see if it crashes again, then it will take
a very long time (especially if you have many INITs).

Forexample, if I know that one of ten INITs causes a problem, I
would toss them all into a sub-folder, pull them back out two
or three at a time and reboot.  If it crashes, I reboot from
floppy and toss two of them back.  If it succeeds, I pull two
or three more.  If the proposed init manager existed, I would
simply reboot once, check all the INITs for loading, and check
the single-step box.  The manager would run the inits, one at a
time, telling me which one it was about to run as it went.
When it crashed, I would know which one (probably) caused the
trouble - next time I would uncheck that candidate and try to
load it all.  Thus, in two passes, I would find and eliminate
a single INIT that crashed with that system.  (Of course, it
would take longer to determine one that crashed after it started
or a combination that crashed together, but this type of problem
would still be easier to resolve with an init manager control.)
Note that a naive user would probably be able to use the second
method as efficiently as an expert user, it is simple.  However,
with the current setup, he would likely run add them one at a time
and require more reboots, or even worse, remove them one at a time,
and have more crash and reboot from floppy sequences, taking much
longer.  A naive user is also less likely than an expert developer
type user to be able to guess which init is the most likely to
have caused the problem, or which had definitely started running
before the crash.

To not reduce the current simplicity, I had expected (but not
stated in my posting) that new inits could still be added by
putting them into the system folder - I hadn't determined any
specific rule about how they would fit into the ordering.

I don't trust that all of the current and future init writers
will provide a mechanism that will allow boot-time choice of
inits - they already don't.  (If I depress shift-whatever and boot,
I get some inits that don't install themselves, some that put
up a box asking if I want them or not, and some that install
themselves regardless.  I might also get finder instead of multi-
finder, and some other Apple internal devices might change their
behaviour.)  An Apple-provided machanism would ensure that init
writers don't have to do the 'right' thing - a 'righter' mechanism
than they could possibly provide would already be there.

A number of followups made the assuption (or outright statement)
that inits that must be run in a specific order are "buggy".  I
think that this assumption may be already wrong, and is certainly
likely to be wrong in the future.  The Macintosh has already shown
that it is dangerous for a program to make assumptions about the
environment it is running in.  What is a fixed piece of hardware
on todays Mac may turn out to be one of the possible pieces of
hardware available on next years Mac, and may be dynamically
simulated to any of them (without rebooting after a switch) on
some other Mac.  (The specific example I am thinking of here is
screen size - we now have large, small and simulated (Stepping
Out) screens (I don't know whether Stepping Out allows the screen
size to change dynamically, but certainly the monitor cdev on a
Mac II allows the "screen" to change shape without rebooting.))
One of the means available for simulated hardware changes is inits.
(There is a shareware or public domain init called Big Screen which
simulates a large screen.  I don't know if Stepping Out is also
an init.)  This same principle of not making assumptions about
the underlying universe lead to the addition of the SysEnvirons
trap.  Anything that might change in the future should be determined
through software, even if it is fixed on all current hardware.

If an init provides a new or dramatically changed appearance to
the "machine" it might affect the way other inits should operate.
Imagine an init which creates a "spooling" process which watches
all serial ports for some sort of request (perhaps the Mac is
being used to provide LaserWriter access to a number of lesser
machines).  It would determine from the system how many serial
ports there were on the system, so that it doesn't just blindly
assume that will always be limited to two.  Now imagine a second
init, which interacts with the Ethernet board.  It sets up a process
to handle requests to act as if it were a serial port.  It even tells
the system that it is acting like a serial port and the system adds
it to its list.  Unless it runs first, the "spooler" init will
not notice it, and not be able to watch this "serial port".  I
don't think that there is anything that either init writer could
do to make them work together if the inits are run out of sequence
(at least not if the init writers did not know of each others work
while they were writing their init).  While this specific example is
flawed (I expect that these things would be better off as device
drivers instead of inits, although they still may have problems
getting amicably started up), I think that the principle holds.
I am sure that there could be inits that could benefit from each
other if run in the proper order, and be perfectly useful on their
own, but which could only work together sensibly if run in a certain
order.  This is what I hoped would be addressed with the extensions
- some way hohaving init that will work into the future with other
inits that change the basis of the machine out from under them.  Given
some method of specifying what system resources an init asked about and
used, and what resources it modified the appearance of, the computer
could do a lot of the work of ordering inits automatically.  That would
certainly be the least taxing demand on the naive user of all!

One final comment. One response said:
::Most INITs have the feature that if you hold down some combination of
::the chift, control and option keys while the machine is booting, the
::INIT will just return without doing anything. These shift-sequences
::are clearly documented in the manuals.

The "shift key disables 5 inits I want as well as the one I don't"
and the "the bad init doesn't allow for disabling" problems I mentioned
above make the manual-documented sequence not particularily useful.

In addition, I have started to regard looking something up in the manual
as a subtle hint that the user-interface may be lacking.  Having to look
something up in the manual of every init you have is a strong signal that
the user-interface is lacking.  (The fact that looking it up doesn't help
even more so.)

I have been lead more and more toward this opinion by the Macintosh.
(Before the Mac, I memorized manuals without complaint; I was not an
easy convert to this contrary view.  I strongly believed that any
serious program obviously would require a manual, and would require
studying the manual before one could become proficient at using such
a program.)

As an example, I tell most of our users that they should not use Microsoft
Word, but should use MacWrite.  The learning required for Word is too great,
most of our users do not do enough word processing to EVER become proficient
with Word, and its non-standard interface is too much of a barrier for casual
use.  We do have some Word experts, anyone who has a need for the advanced
capabilities of Word can still get them - by going to an expert.  With
MacWrite (soon to be WriteNow, I expect), they are already expert enough
to do most common word processing tasks without assistance.

I apologize for the length of this posting.  I hope I am explaining more
than I am burying with the length.
-- 
John Macdonald   UUCP:    {mnetor,utzoo}             !spectrix!jmm
                 UUCP:    {utecfb,ontmoh,spectrix}   !bml!jmm
(formerly of Spectrix, still using their computer for news)
Now working for Brown Manufacturing, Ltd. (soon to have their own feed)