user-startup -- Really useful?

[cecilia]

this entire thread proves why Amiga OS is better than any other: everyone can make their system as they see fit and you don't have to be a major Tech-head to do it!

i like my user-startup just because it gives me a convenient list of programs that need assigns.

and, as my system starts up faster than windows or even linux, it's fast enough for me.

[adolescent]

Useful.  Sure, I could combine everything into one.  But, then the next BB comes out and overwrites it and I need to add everything back in again.   I don't see a valid reason to change.

[AmigaHeretic]

First of all I have to ask how you figure it's any faster having something run from WBStartup as opposed to the user-startup?

My user-startup is mostly filled with Assigns that programs need ie.  assign dpaint: dh1:dpaint

To me it's just a lot easier way to keep track of everything.  I actually prefer to have as few things as possible in the WB Startup drawer and move them into user-startup to keep everything in one place.   It would seem cluttered to me to have all the assigns and programs in the middle of the startup-sequence somewhere.

As doomy would say, "You don't know what you're talking about when it comes to User-Startup!"

[chris]

adolescent wrote:
Useful.  Sure, I could combine everything into one.  But, then the next BB comes out and overwrites it and I need to add everything back in again.   I don't see a valid reason to change.

And that's a very good reason for leaving the startup-sequence alone and only adding commands to user-startup, not to mention that Installer plays with user-startup by default (and can happily add and change sections relevant to particular installed applications), and you can add commands to user-statup with an "echo >>s:user-startup".

Obviously on occasion you need to add things before or immediately after Setpatch, but for most things user-startup works perfectly.

Chris

[AmigaHeretic]

Before it was very hard to determine which of the commands in the startup-sequences is executed first. (o.k., this is only a problem for those who are called in the startup-sequence after user-startup is started).

They're executed in the order that they are in the script.  How is elminating User-Startup going to change that?  And how exactly do you determine which programs are executed first in the WB Startup drawer now that you moved them there?

I had some troubles with this and only could avoid occasional gurus by inserting some wait commands at different places.

I have never had to nor have I ever heard of anyone having to add a bunch of wait commands in their startup-sequence to avoid a guru.  Even if you did have to, how would moving these programs out of User-Startup and into the Startup-Sequence fix it so that you didn't have to add these wait commands in anymore?

[Targhan]

The real answer, whether you wish to use the User-Starup or not is to maintain backups.  Personally, I prefer to have the user-startup as a seperate entity than the startup-sequence.

In fact, I've had and used (pre-gfx card Amigas) requestchoice from the startup-sequence to heavily modify things by using multiple user-startups.  A great Usage for this sort of thing on a native-gfx (or scandoubled) Amiga is the ability to make changes to the very look and feel of the OS.

For example: I used multiple user-startups to control:

def-icons (which icons got copied to env:)
preferences (have multiple default mui/reaction prefs)
backgrounds (more preference files that can be copied around).
Birdie prefs
Visual prefs
EVEN the location of the FONTS: assign was adjusted according to these "extra" user-startups.

I had everything from a bare-bones to a fully-custamized WB based on a request-choice in the startup-sequence controlling *which* user-startup to use.

:-)

[Kent]

There are several good reasons to keep a user-startup and startup-sequence seperate.  When I still had my A4KT I was switching back and forth between WarpOS and PowerUP not to mention changing the graphics install between CGX and P96.  I had it set up so that I could boot with PowerUP and CGX or PowerUP and P96 or go with WarpOS and P96 etc.  Also there were some programs that didn't like to work with each other so some environments were disabled on booting.  Custom scripts were written to replace the user-startup script for when I wanted to reboot the computer to play a hard drive installed game that required a few changes to the hardware via degrader.  I also had some custom user-startup scripts that I used to handle multiple environments for different users and such.  In all, I think I had a total of 340 someodd lines of hand written user-startup scripts.  Probably more, who knows.  Then there were the custom scripts that were written in arexx to handle the all the changes made to each of these scripts depending on the boot.  When I ran a hard drive installed game that required a reboot to run, it would copy back the startup-sequence and boot right back into workbench without a problem.  With all the components that I had and the custom amigados scripts and arexx scripts I had controlling how my Amiga booted, I couldn't use just 1 startup-sequence.

Oh yeah... plug for my friend Roj... I also had been testing something called IMACS which on a warm reset had me booted to workbench and connected to the internet in less than 4 seconds using a regular modem.  IMACS is the ultimate system controller for anything internet... from email to newsgroups to irc to web... you name it, it could do it.  The damn cool thing about IMACS, I think he's still developing it but it was never released for the public last I checked.

:pint:

[Mika]

If you don't need it, take it away.
If you need it, leave it there...

[scholle]

The programs in the WBStartup drawer are executed after opening up the Workbench, i.e. when "loadwb" is executed. Unfortunately I cannot determine the order of execution here. My problem was the starting of some commands in user-startup. As we now, the user-startup script is called by run, thus executed in background. So the execution of programs called by startup-sequence is not over yet. I never could determine which of these made me trouble but I guess it was some of those in WBStartup as loadwb is called shortly after user-startup normally.

[chris]

amigaguy wrote:
And how exactly do you determine which programs are executed first in the WB Startup drawer now that you moved them there?

There's a tooltype - STARTPRI I think - which sets the order the programs are launched in.  Under OS3.5 and up, there is a section under Icon => Information to set this without manually adding tooltypes.  Under normal circumstances it doesn't matter which order WBStartUp programs are launched in anyway.

Chris

[chris]

scholle wrote:
As we now, the user-startup script is called by run, thus executed in background. So the execution of programs called by startup-sequence is not over yet.

Not according to my default startup-sequence: user-startup is just executed.  It would be potentially dangerous to let it execute while startup-sequence is opening Workbench, and would also prevent the initial Shell from closing, making the bootup look a bit messy.

Chris

[scholle]

The speed aspect is obvious: When you have lots of programs in WBStartup AND a big user-startup, there's a good chance that they are executed in parallel which means lots of hard drive access back and forth. I prefer a single stream of program calls. Of course starting programs from WBStartup is not faster than starting from user-startup in general. The method you described would be the other side of solving my early problem. A matter of taste...

[Acill]

Well I allways liked having it. It doesnt seem to slow the system down all that much and using it is easy if you clean it up now and then.

[Karlos]

@Scholle

If your user-startup is being called by 'run' there is something badly wrong.

The speed aspect is obvious: When you have lots of programs in WBStartup AND a big user-startup, there's a good chance that they are executed in parallel which means lots of hard drive access back and forth

user-startup and wbstartup programs in parallel? Not on any system I have used.

A normal boot should be as follows

Commands in s:Startup-sequence are called sequentially (some are run, usually hacks/patches). Drivers are initialised, preferences are loaded etc.

If there is a user-startup, it is executed, again sequentially, causing the normal startup-sequence script to be suspended until it completes. It is not executed concurrently.

Workbench is then loaded, after any user-startup sequence has been processed.

Programs in WBStartup are launched in order of their start priority. Most use 'donotwait' which instructs workbench not to wait for the program to finish before continuing.

This is usually the busiest time, programs are being launched and workbench itself is being set up, images loaded etc. Your user-startup script should have long finished before this happens.

If you feel that you are getting too much strenuous activity at this point, add the 'delay' argument to loadwb, which causes workbench to wait for existing shell stuff to complete.

[scholle]

@Karlos: Damned, you are right, man! Only just I compared my old startup-sequence against a standard one. What the ####ing install program inserted the RUN >NIL: EXECUTE S:user-startup in my own startup-sequence instead of simply executing! I swear it was not me. It had caused me so much trouble and I always thought it had to be that way! THX!!!

[Karlos]

Man, that is really strange. I can see the thrashing that that would cause :-o

Hopefully removing the run >nil: part should help a great deal...