Hm,

it seems I have to correct myself -- cat'ing together the rc.d
scripts together with glue from the current rc file isn't really
going to significantly reduce the number of processes started during
the boot process, due to the following snippet from rc.subr, from
run_rc_script, called from run_rc_command which is again called from
/etc/rc itself:

...
        case "$_file" in
        *.sh)                           # run in current shell
                set $_arg ; . $_file
                ;;
        *)                              # run in subshell
                ( set $_arg ; . $_file )
                ;;
        esac
...

And of course no distributed rc.d scripts have the .sh extension,
causing the shell to fork at least once for each startup script.  This
does of course provide for more robustness, but as several of you have
observed, at a price.

I see that the general issue of the startup system present in 1.5 has
once again surfaced.  I'll try to not fan the flames, but I can't help
but note that I see many already-voiced opinions (what a surprise!).
What you do "in the privacy of your own vax system" when you merge or
upgrade your etc installation set when moving to 1.5 is entirely up to
you, but note that what is "supported" is what's shipped as part of the
system.  Please realize that several tradeoffs were made between the
various factors relevant to the design, and IMHO the tradeoffs made were
all quite reasonable for normal use.

I don't know enough about the innards of the vax port to comment on what
might be causing the perceived slowdown of process forking in 1.5
compared to earlier releases.  Perhaps some others in this discussion
have something to contribute here?  Of course, if that is indeed what's
happening, it will hit the vax port even harder in terms of slowness in
the startup scripts.

Perhaps someone could at least run a benchmark to measure this
effect on two otherwise identical systems with two different OS
releases installed, say 1.4.3 vs. 1.5?

As already noted, I don't understand why the speed of the boot-up
process is such a major issue.  I would have guessed that under normal
usage these sort of machines are not booted several times a day?!?  Of
course, the more general problem of speed of process forking is rather
more serious, but also more difficult to tackle.

Best regards,

- H=E5vard