!Boot in ResourceFS

Just a thought, but I’ve always thought it would have made sense (memory permitting) to have the main part of !Boot in ROM, and run from ResourceFS.

Given that the only things that generally need changing are stuff in Resources and Choices, why not move Boot:Resources into System:Resources (with a path alias set up so nothing breaks) and Choices$Write could point to System:Choices, with !System obviously stored on a local or network disk.

I’m thinking back to the days of booting diskless over AUN/ShareFS, so I know it’s possible for !Boot to be on a read-only file system.

Obviously it would still be possible to do “*configure filesystem adfs” instead of “resourcefs” and boot the “old” way.

Just a random thought.

I agree. To have a system that can boots from ROM, but – in fact – that is not useable with only the ROM, is not very logical. Even configure add-ons can be add to an existing Boot placed in ROM. Only problem: room available in ROM :)

RISC OS 4.39 can boot from a variety of FS’s including CDROMFS and a network. I can’t recall what FS on a network.

We put the entire disc image into ResourceFS once – take a look at the OMAP3Live build here, and here.

This would be an excellent idea, it would be even better if there was a boot priority system.

Perhaps 3 paths, (complete path meaning the name wouldn’t have to be !boot)

The system would check for the presence of the first location, and boot from it if it exists, if not try the second, etc.

If it boots of resources fs, any subsequent entries are used in a similar manner to continue the boot sequence, after the built in one is finished.

It would also be nice if ResourceFS also contained the formatting utility and packman.

Would it also be possible to use archives, so that otherwise unsuitable filesystems could be used? (e.g. use !boot.zip on a fat32 system).

Would also like to see SparkFS in ROM (if it isn’t already in the image?). One could then make !Boot into an archive stored in ResourceFS.

There doesn’t seem to be much of a performance hit with decompression even on old systems, it’s only writes to a Sparkive on a slow FS (add a file to a Sparkive stored on a floppy disk to see what I mean!).

Again, thinking back to my Econet/AUN days, I found it considerably quicker to make applications into archives and ensure SparkFS (even if not the filer) was loaded on boot.

Would also like to see SparkFS in ROM (if it isn’t already in the image?). One could then make !Boot into an archive stored in ResourceFS.

Or ShinkWrap would probably do the trick.

RISCOS is advertsed as “An easily customised operating system for ARM devices”.

How would putting !Boot is ROM help with that aim?

I think that quote is referring to customisation from a system designer’s point of view, rather than from a user’s point of view. I.e. it’s easy for a designer to make their own custom ROM image containing just the modules they require for their product. In which case the ability to include !Boot (or any other arbitrary software) in ROM would be a major plus point if they wanted to avoid the extra cost/hassle of building a product which relies on flash memory or a hard disc for storing the system software.

I regard myself as a user. Surely I am not alone with a customised !boot.

Like I said, if you want a customised Boot then “*configure filesystem adfs” and run the existing Boot application.

For 95% of “normal” users, a ROM-based Boot (from ResourceFS) with choices written back to a writeable file system would increase resiliance, and on IOMD machines would probably speed things up (PIO mode 0 disks are SLOW by modern standards!)

My view is still “No”. Leave !Boot where it is.

Fair enough, although I personally can’t see any drawback to this if you’re using the standard Boot. If you want a customised one then just configure the file system to be ADFS (or SCSIFS, or SDFS as applicable).

My view is still “No”. Leave !Boot where it is.

!Boot yes, but perhaps to put !Configure in ROM could be a good idea.

“My view is still “No”. Leave !Boot where it is.”

Maybe it would be better to have ‘standard’ !Boot stuff in ROM, nothing more annoying than having to setup a !Boot structure on a disc after formatting, in an environment that’s ‘unbooted’

No reason why *con. ROMBoot 1 (and equivalent in !Configure) can’t be used surely?

Isn’t that the whole point of your “easily customised operating system”? :@)

There’s something to be said for having the core boot sequence in ROM and a shell !Boot (with Choices, Resources, etc) on disc, especially now that ROM updates are relatively pain-free. It’d make rolling-out updates a great deal easier (for ROOL) to not have to worry about trampling on the various hacks and tweaks end users make to what is – or should really be – a core OS component.

If the boot system is to be changed how about basing it on Rick’s Harinezumi or something similar?

There’s something to be said for having the core boot sequence in ROM and a shell !Boot (with Choices, Resources, etc) on disc,

The wheel may have turned a full circle. ;-)

Back in the day, I was one of those who thought the univeral Boot was overdoing things. I remember Matthias Sieffert fighting a worthy rearguard action against it. We would much rather have kept those resource directories, now in !Boot.Resources, out in the open as with RISC OS 3. My opinion was set when that infamous DrawFile of the !Boot structure was published.

As has been mentioned here, before the universal !Boot we school network managers cooked up our own !Boot arrangements to allow just enough user flexibility, with most of it write protected from the server. This would be equivalent to keeping it in Rom now.

Times have changed. In the old days, ROM space was very limited, and upgrading the ROM was done seldomly. Even then, many fell into the trap of not updating their boot structure accordingly.

Nowadays, for the standard distribution of many “new generation” machines, putting a ready-to-boot !Boot into the ROM would be a good thing, especially in the light of the inevitable intertwining between core OS and stuff in !Boot – the ROOL forum has many postings where strange errors happened because people forgot to update the !Boot after changing the “ROM”.

I also think that having a “universal Boot” is not really valuable. The days of having a large amount of diskless machines booting from a central server are long gone (and, as Steve Drain pointed out, the networking guys didn’t use the plain vanilla universal Boot anyway), and I think we should focus on making it as easy as possible for the “average user”.

The change to 5.20 required users to update their !Boot systems. The procedure was time-consuming and error-prone. Many users are still too afraid to do it, so they remain on an out of date version of RISC OS, which doesn’t allow them to run USB audio devices, for example.

If !Boot were in ROM, would we avoid such problems?

If !Boot were in ROM, would we avoid such problems?

Essentially. If the (notionally) read-only parts of !Boot were in ResourceFS, with another !Boot on disc that contained the writeable stuff – all the paths in the boot sequence would already support this (nearly) – then any update from ROOL would be able to ignore the on-disc bit and 99% of the time that would be enough.

The main problem with !Boot as it is at the moment, is that there is no simple way of knowing what has changed at any particular time. Time stamps are no good because a lot of the files are stamped with the time of the nightly build.

I installed completely clean boots on all my machines when required for 5.20. However, after that, every month or so, I did a ‘boot merge’ with the latest !Boot at the time. At some point something changed, or something was then left in !Boot that shouldn’t have been, because I was driven crazy with a number of apps suddenly failing to run (and Iyo, BB, PB, RPi behaved differently). The long and the short of it was to once again do a clean reinstall of !Boot, then add back in everything that was required for a full working system. One doesn’t want to have to keep doing that.

Essentially.

I think that’s the killer reason to do it.

Some way has to be found so that users (both experienced and new) are not put off upgrading to a newer ROM because of problems (real or imagined) with the !Boot files. Ideally there would be a clear distinction between ‘standard’ items and ‘user changed’ items – and all users change !Boot in some way, even if it is just in Choices.

Having a standard !Boot in ROM seems a very good idea to me, if it will resolve these problems … as long as there is still the ability to modify add to (or subtract from) it!

What is actually needed to be in ROM?

Serious question.

I’m looking at my !Boot and…

• Choices – none of that can go in a ROM, for obvious reasons
• Library – could be ROMed if you don’t mind screwing up Run$Path even more and/or fixing it so there are two places that % can point to. Let’s say I have added numerous things to mine.
• Loader – cannot be in ROM (and is like 10x the size of the ROM anyway)
• Resources – here’s the rub. Some stuff (!Internet? !Unicode?) could be baked into a ROM. But is it better to have a “Resources” folder where resources live, or is it better to mess it all up with things all everywhere? Mine has !Ghostscr and !DCDRes and !ZapFonts to name a few. Oh, and some additional fonts. I’d say keep it together on disc.
• ROxxxHook – the ones pertaining to older versions of RISC OS could perhaps be added to ROM so long as there was a mechanism to construct a disc-based one as well for modules that work on more than just the latest version of RISC OS (such as the MP3 player module). The ability to update these plus the absolute balls-up it would make of System$Path are two very good reasons to keep this on disc.
• ROxxxHook.Res.Configure – an ideal candidate for being ROMed. Just know that I have replaced !WindSetup with my own one (allows additional options to be set). I believe Paul Vigay wrote a does-extra-stuff configuration tool, and maybe other people too.
• Utils – I’m surprised HOn and HOff are not built into BootUtils these days. People will kill you if you hardcode the BootRun and DeskRun files – that’s one of the places to tweak startup.

RISC OS is fairly unique these days in that if the boot media is junk, the machine can still boot and you can access the command line, basic UI, text/file editor, etc.

So, with that in mind – when you say you want !Boot in ROM, exactly what do you expect to be ROMed?

Now for my suggestion.

• We need a “hidden” directory, something like Resources:$.Recovery that contains at least:
  • HForm
  • IfConfig
  • InetStat
  • Ping
  • Route
  • ShowStat

The aim being to be just enough to format media¹ and get internet running.

What would be cool is if it would be possible to create a “wizard” to attempt to set up networking, to download a RISC OS SD card image² (probably writing into a Dynamic Area as the standard RAMdisc maxes out at 128MB) and to unzip it directly to an SD card³ (as we don’t have 2GB RAM kicking around). In this way, there can be a built-in tool that can try to get you going from within RISC OS. Maybe RISC OS itself could autostart such a tool if it can’t find a valid boot at startup?

¹ Note that this means FileCore only. The mixed-format (FileCore+FAT) style is whole different kettle of fish. Which is why the auto-install wizard idea might be nice.

² For those systems where an SD image exists.

³ Which means we’d either need a Squash version of the image, or some sort of zip decompressor in ROM…