swapping between vesa and nvidia, what do the gurus use?

[Misalf]

I think you're right but would't that slow down the boot process (a little bit) an comsume more RAM?
The NVidia drivers at least are pretty big (on TC 4.7 I made myelf even bigger extensions from latest drivers via scripts by Rich).
Also I want to be able to specifically choose Xvesa because, at least on my home PC which has a NVidia graphics card, the nv and nouveau drivers seem to be unusable (very poor display performance).

[gerald_clark]

Only the modules actually loaded will be in RAM.  The extensions will be loop mounted, and reside on flash/disk.

[coreplayer2]

Your list above indicates all Xorg drivers (which are the most basic of drivers),  the additional few Kb they consume is a moot point  IMO   

I find the way to reduce boot times with xf86 drivers is intelligently selecting only those which are required for all systems, like xf86-input-xxx .
The other nv, nouveau, etc etc drivers (not likely to support modern hardware anyhow) are all unnecessary when loading up proprietary Nvidia drivers. 

When you bring in real proprietary Nvidia and ATI drivers into the mix, this changes perspective somewhat.  But I would argue that a few Mb of memory unnecessarily used against several Gb of available memory and the few extra milliseconds it takes to load or mount is  almost negligible in today's systems, the upside of this is functionality across many systems.    If you are still thinking  lst files based on configuration, by now we're down to maybe only two lst options, which is much more manageable  Xorg + Nvidia or Xorg + ATI lst files. 

Striving for a balance of minimal drivers to support the most hardware configurations is always challenging, but can be done

[Misalf]

Oh, yes. It's mounted but not loaded into RAM. Silly me..
--
True, I might ignore and not even notice any very little extra boot time or a few KB of RAM (if even used).
Though, my main intention is to get rid of additional .lst files (and the need to remember their names) which have basically the same contents (exept graphics drivers). Furthermore, if I want/need to have an alternate onboot.lst containg a totally different setup of extensions, I might have to create dublicates of all my current .lst files.
Could there be any downside by loading extensions from inside bootsync.sh?

[curaga]

Could there be any downside by loading extensions from inside bootsync.sh?

The only downside is that it's slower than when done via onboot.lst (as all lib/module/desktop updates are done for each extension, instead of deferred and done once).

[Lee]

If you feel like you got something worth sharing whenever you're 'done', I'd be glad to learn a little bit from your scripts.

'Done' seems like too strong of a word, as this project is kind of on-going.  But last night even "started' would be too strong of a word... I had forgotten (but remembered in the nick of time) that it was my mothers' birthday, so I never did get any geekery done.

Maybe tomorrow evening, if the real world doesn't somehow intrude.

[Misalf]

slower than when done via onboot.lst

Hmm, I indeed noticed booting has slowed down a little bit (3 or 4 sec.) by looking at the uptime value that Conky shows me but I didn't yet tryed to figure out what was causing this. bummer.
Maybe I should edit /etc/init.d/tc-config then and repack core.gz which is totally update unfriendly though.
--

, as this project is kind of on-going.

I guessed so. (: