Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: scholle on October 24, 2003, 08:13:40 AM
-
I would like to discuss the question wether the user-startup script really is useful by now. I have discarded mine not only for speed purpose during boot time, but also for a better overview of the booting sequence. Anything that has to be started early or better/only as a shell command went into the primary startup-sequence, the rest resides in the WBStartup drawer. IMHO two places is enough for starting stuff. We will not go towards Linux with its chaos of booting structure, but me thinks we should beware of the beginnings...
What do you think? Has anyone gone the same direction with the boot process?
-
usefull
-
:-? I would be grateful if you were a bit more detailed...
-
I agree with you
As I understand it, the User Startup is there to edit by hand if you want/need to. The Startup Sequence is then to be left alone and only to be edited 'automatically' by softwareinstallation programs and such.
But, imo, if you are capable enough to edit the User Startup, you are also capable of editing the Startup Sequence, thus leaving the division of startupfiles into two parts rather useles (I never understood why there was both a config.sys and an autoexec.bat in DOS).
So I've also removed my User Startup. Works for me...
-
There are arguments either way with the user-startup.
The original idea with it was that the startup-sequence, which contained the important system booting stuff, was meant to be left alone. Any additional assigns or programs run on startup could be added to the user-startup.
If some kind of problem developed, you could disable the entire user-startup, thus narrowing the problem down to the startup-sequence or the user-startup.
I kind of use it in this fashion, but of course we all add extra stuff that has to be run early in the main startup-sequence.
A disadvantage is that it's harder to see what's going on during startup, as first you have the startup-sequence, then the user-startup, then the contents of the WBstartup drawer.
The bottom line is that the OS is flexible enough so that you can use user-startup/WBstartup if you want to, but if you don't like/need it, then don't use it.
Personally I use all 3, but I know it could be tidier, and slightly faster if I just use 1 startup-sequence.
Anhony.
-
usefull
It's extremely usefull when installing progs with assigns. The installer add lines only to the user-startup, wouldn't want any installer messing with my startup-sequence.
-
Hmmmm....it's easier for me to divide them in
two, and I think it makes sense from a design/
organization perspective to have both - one for
strict system oriented commands, and another
for extraneous user related commands.
But either way is ultimately the same effect,
so I'd say "whatever works best for you."
-
The logic intention to have one file for system and the other for user commands is clear but once you start finetunining your system or heading for speedups you have to fiddle around with the startup-sequence. Doing this long enough you can hardly divide between system and user commands. At some point it was enough for me already because of the number of commands. So I throw away my user-startup and reorganized the startup-sequence from the scratch. Now the chaos is banned and I am able to discover errors easily again. :-)
-
I hate installers cluttering up my systems with assigns anyway. :-D For this I try to avoid installers up to 95-98%.
All important assigns go into a list that is read by BatchAssign (Aminet), the rest is done by batch scripts when they are needed, i.e. before the corresponding executable is called in for action.
-
Whatever floats your boat.
I've gotten used to the idea of two of them, and it's pretty simple to figure out where a problem lies since you can temporarily rename the user-startup to check and see if something in it is what's causing a problem.
-
@scholle
I agree about avoiding installers, BUT why sacrifice the convinence of disabling the user-startup simply? What do you gain? 2 seconds on boot-up? For myself I'm with the original concept.
IF EXISTS USER-STARTUP, Execute that Bugga! :-D
-
Useless.
Be a man, use your hand!
-
JoNty
#AmigaIRC Xnet
#AmigaOne Undernet
#AmigaOne EFNet
-
The Installer program also makes automatic use of user-startup when you create assigns with install scripts. Moving user-startup might cause the script some problems. I will try tonight to see if not having a user-startup causes trouble or not.
-
@Steady
It doesn't.
If I really have to use an installer, I just move what's put in the newly created user-startup into the startup-sequence, and delete the user-startup.
-
JoNty
#AmigaIRC Xnet
#AmigaOne Undernet
#AmigaOne EFNet
-
I find the feature very useful. Its a place to stick all those startup slowing patches and additinal assigns without cluttering up the main startup.
The startup-sequence is prolly one of the most important filesonthe system and the less programs messing about with it the better. The user startup at least is an easy place to look for allthose nasty extra progs that get launched which can help finding issues i guess.
There is absolutly no speedup befit of any kind by merging the files. since they get joined into one big script and executed durring the startup anyway. (Usualy find it lurking in T:)
Its important this feature stays in os4 for 100% AOS Compatability anyway ;)
-
If I am not wrong the User-Startup wastes less memory and programs are started earlyer the in WB-Startup.
-
Actually I usually create a user-startup for my Harddisk:-partiton, and execute this script from my user-startup.
"Why?" i hear you rave. Because I use multiple OS:es. BetaOS4, Os3.9 and my own cd32-thingie.
The progs on HD has it's own startup-scripts.
Thus I can reinstall the OS without having to reinstall my progs.
And why not use the installer when it exists? They usually work, and it's a lot more convenient. (Ok, so you can acuse me of beeing irradical by doing my own startup-script in Harddisk:, which isn't very convenient, but, hey, it keeps me occupied ;-))
-
by JoNty on 2003/10/24 11:12:29
Useless.
Be a man, use your hand!
-
JoNty
If you are still using only hands, you aren't a "so called" man :-)
Ciao!
-
@Lo: If it's 2 seconds on boot-up I can gain, then I want to have them. Yes, I'm a speed-freak. :-)
But the biggest plus for me is: clearness. 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). I had some troubles with this and only could avoid occasional gurus by inserting some wait commands at different places. Alltogether it may be about 8-10 seconds I gained...
-
I got rid of mine ( but kept a backup ).
All the assigns that were in it were moved over to be handled by MCP.
Seemed to be faster boot.
-
Years ago I would have agreed with you.
Unix was always more complicated and fragmented in it's initialization than AmigaOS, DOS or MAC.
However now, once you get to know where things are (or are likely to be), Unix is a lot easier to deal with than Windows.
In Windows you have this vast monolithic thing called the registry which makes 'the matrix' look simple - maybe it IS the matrix - ####! I'm starting to sound like Tim Rue! :-D
Humm - I like the startup-sequence but in the modern day I think we need more scripts to make it more intuitive.
-
I find the idea of separating system-specific and application-specific startup commands useful. In my user-startup I have application assigns, my own assigns and a few other things. In my startup-sequence I add things like FastIPrefs, MCP, the Ram Disk icon etc.
-
It is useful. I've even cleaned it a bit up, putting only Assign and path instructions into the User-Startup, adding a new subscript called "ExtUser-Startup", where tool programs and patches are started and another script called "AfterExec",
that starts with a Wait 5, so the rest of the stuff is done after the Workbench has loaded. My startup-sequence has no similarity with the original one. My machine boots into workbench in about 15 seconds from a cold boot.
-
heh , ok..here is an example why i use a user-startup.
i install a dodgy patch/hack from aminet or anywhere else , it crash on boot.
IF i had removed my user-startup and it would have been in Startup-sequence , then i wouldnt know whats going on, because my gfx card drivers starts in the end of the startup process (startup-sequence) , so i would have to rig up a tv or whatever to see what went wrong , instead i just use user-startup :)
anyway if anything crash in userstartup then you could normally just break it and loadwb/endcli.
..
anyway i know why you wonder if its useless/should be removed because for new users or not so experienced ones will think of it as " A MESS" , anyway i really dont see how u an win boot time on removing user-startup , my userstartup is only a few lines , its not a big messy file, and its sorted well out and i would recomend everyone to do so, clean it up! , remove all reduant #### in it.
cheers
-
I have to admit, I find this discussion somewhat pointless. The user-startup file is completely optional and always has been.
If you don't think it's a good idea, don't use one, if you do, then do. To my mind, the existing concept of an 'if present then execute' script is fine and simply reflects the modular design of the OS as a whole.
Personally I haven't found any speed penalties as a result of executing the script compared to 'inlining' its contents into the startup-sequence. If you want to speed up assigns and what not, use a specific late-assignment tool or MCP.
-
Well, the main advantage I can think of with having a seperate user-startup is it removes clutter from the startup-sequence so you can see what you're doing...
But I'm agreeing with Karlos here, still a thread like this bumps the post-count, huh?
Says me ;-)
:lol:
-
It does indeed :-D
-
So do useless replies...
-
For some, they can get their StartUp with a coffee!
Irish Coffee is a even better StartUp! ;-)
-
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.
-
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.
-
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!"
-
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
-
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?
-
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.
:-)
-
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:
-
If you don't need it, take it away.
If you need it, leave it there...
-
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.
-
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
-
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
-
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...
-
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.
-
@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.
-
@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!!!
-
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...