!Boot in ResourceFS
Pages: 1 2
Glenn R (2369) 125 posts |
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. |
David Feugey (2125) 2709 posts |
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 :) |
Chris Evans (457) 1614 posts |
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. |
Steve Revill (20) 1361 posts |
We put the entire disc image into ResourceFS once – take a look at the OMAP3Live build here, and here. |
Jess Hampshire (158) 865 posts |
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). |
Glenn R (2369) 125 posts |
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. |
Steve Revill (20) 1361 posts |
Or ShinkWrap would probably do the trick. |
John Sandgrounder (1650) 574 posts |
RISCOS is advertsed as “An easily customised operating system for ARM devices”. How would putting !Boot is ROM help with that aim? |
Jeffrey Lee (213) 6048 posts |
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. |
John Sandgrounder (1650) 574 posts |
I regard myself as a user. Surely I am not alone with a customised !boot. |
Glenn R (2369) 125 posts |
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!) |
John Sandgrounder (1650) 574 posts |
My view is still “No”. Leave !Boot where it is. |
Glenn R (2369) 125 posts |
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). |
David Feugey (2125) 2709 posts |
!Boot yes, but perhaps to put !Configure in ROM could be a good idea. |
Michael Emerton (483) 136 posts |
“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”? :@) |
Steve Revill (20) 1361 posts |
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. |
Chris Evans (457) 1614 posts |
If the boot system is to be changed how about basing it on Rick’s Harinezumi or something similar? |
Steve Drain (222) 1620 posts |
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. |
Steffen Huber (91) 1953 posts |
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”. |
Dave Higton (1515) 3526 posts |
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? |
Steve Revill (20) 1361 posts |
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. |
Chris Johnson (125) 825 posts |
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. |
Dave Higton (1515) 3526 posts |
I think that’s the killer reason to do it. |
Martin Avison (27) 1494 posts |
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! |
Rick Murray (539) 13840 posts |
What is actually needed to be in ROM? Serious question. I’m looking at my !Boot and…
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.
The aim being to be just enough to format media1 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 image2 (probably writing into a Dynamic Area as the standard RAMdisc maxes out at 128MB) and to unzip it directly to an SD card3 (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? 1 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. 2 For those systems where an SD image exists. 3 Which means we’d either need a Squash version of the image, or some sort of zip decompressor in ROM… |
Pages: 1 2