No more available space?

find whatever creates Choices: and Choices$Write (BootVars?) and tweak it.

Not BootVars, close. It’s SetChoices (in !Boot.Utils). Usefully written in BASIC so it can be tweaked. ;-)

They would barely make a tiny pock mark, never mind an actual dent.

In terms of actual numbers of files, yes. But conceptually, moving things like Configure would help to clarify what !Boot should actually do, and what it shouldn’t.

Create !Choices, give it a pretty icon, then find whatever creates Choices: and Choices$Write (BootVars?) and tweak it.

That’ll work for all the app-generated choices settings, but my thought is that !Choices should capture all the various user settings that are currently sprinkled across the !Boot labyrinth (like the screen size, wimp visual flags, Pinboard, etc). Not necessarily difficult to implement, I’d imagine, but lots of stuff to pull together, and thought needed on how it might work (ie what happens if !Boot is present but !Choices isn’t, and vice versa, etc).

It’s theoretically possible to go from 5.23 RC15 to 5.24 by using the InSituBootUpdate file in the 5.24 HardDisc archive, then copying the 5.24 ROM and firmware to !Boot.Loader, but no guarantees are offered.

OK, I tried that and it worked on the top one – the one whose SD card is just about accessible in case I had a problem.

The only oddity is that after I ran the inplaceupdate, info on the switcher reported it was 5.24, before I had replaced the rom image.

Thanks for the help. I’ll do the others tomorrow.

It’s SetChoices (in !Boot.Utils). Usefully written in BASIC so it can be tweaked. ;-)

Don’t do this…

There’s an official !Choices out there somewhere, which Acorn produced in the days of the RiscPC (so when they introduced !Boot in its current form), to allow local choices when !Boot itself was stored centrally on a fileserver.

None of this is new, people. It’s how the system was designed to work from the start, when circumstances required it.

There’s an official !Choices out there somewhere

Link?

Just rummaged around a mirror of the old Acorn FTP site, nothing stands out.

to allow local choices when !Boot itself was stored centrally on a fileserver.

I thought that was automatic?

Link?

No idea; I know it was on an old AU cover disc, so I guess Acorn distributed it some time in the mid-1990s. Looking at Chris’s Acorns, I’d suggest that it’s in one of the missing Application Notes.

I thought that was automatic?

There were several similar schemes, I think. !ArmBoot stored the files centrally, in folders named by the machines; this was for systems that had local hard discs, and perhaps single users, I suspect.

My point was more that people shouldn’t be “tweaking” files in !Boot to make their own home-brew versions; we should be following a standard approach that has been in place for 20+ years. Otherwise we just get into the situation that Gavin’s in: where he’s hacked around in system files to get a set-up that’s unique to him, and which then doesn’t play well with updates.

Line 4 of PreDesktop (!Boot 0.72) comments | When modifying the file by adding a section of lines … , which does not give quite the same message.

The key point is the use of |Start and |End bracketing with valid parameters afterwards; if the online copies are correct, even the PRMs from the 1990s note that you should only edit the file in line with these conventions.

In fact the user-modifiability of RISC OS now presents a problem, which has grown over the years without receiving sufficient attention, IMHO. In theory all the stuff belonging to the distributor, which the user should not touch, should be confined to !Boot, leaving the rest of the filing system to the whims of the user. Practice is rather different from theory, as the heat and smoke following the emergence of !Packman attested. There is a gamut of possible practice, between leaving the user completely free (thanks to the Obey$Dir mechanism) and tying the user down to specific names and directory structures, as Unixes do (though every distribution seems to make its own choices). Users come in different sizes – those who want complete freedom and those who could never use it – the technophiles and technophobes respectively.

You contradict yourself here… If the distribution stuff goes in !Boot, and nothing else, why are you hand-editing PreDesktop to add aliases essential to your boot sequence?

!Boot has grown to a massive size, and I think it needs more thought and modularity, so that the user can more easily understand what its components do. RISC OS, being a child of its era, tends to prefer things flat (arrays rather than trees); witness modules, system variables, how SWIs expect data. Now that I have used Raspbian a bit, I have come to appreciate how sophisticated Debian’s package management system is. In my view RISC OS does not need all that complexity. It is !Boot.Resources that contains all the bloat. Stuff gets put in there by the distributor that may never get used.

Again, why are you hand-editing PreDesktop in this case?

Over the years, I’ve actively minimised what I put into core !Boot files. If things go into PreDesktop and Desktop, it’s done via the Configure GUI and not by hand. And unless it’s essential to go into the PreDesk or Tasks folders, booted modules and apps go into a $.ThirdParty.Desktop folder and get actioned via the Look At and Run sections of Configure.

With the regularity of OS updates these days, leave the folders contained in the HardDisc downloads from ROOL as they come. That way, you can upgrade things easily.

As more applications come along compiled with gcc more shared object libraries will be stuffed into SharedLibs,

Really? All of my apps are compiled with GCC, and none of them put files into SharedLibs. They all link to the SCL at run time using conventional stubs.

without any means of removing them when applications are deleted. Some mechanism of recording dependencies is needed.

I think you mean package management. Isn’t that what Packman does?

I apologize if these remarks bring groans from ROD, ROOL and others. But I do think some clear thinking is needed about ownership of files, names, system variables, .. in a single user system like RISC OS, without going to the multi-user complexities of Unix.

Personally, as a developer, I think we need to move on from the “Oh, but it worked OK on Arthur” viewpoint, and accept that modern systems are more complex and need more shared resources. And that these need to be stored in a standard way across systems.

Also, disc space isn’t really an issue. Paring things down to the bare minimum needed to boot your machine isn’t necessarily the right option, when what we need is a system that will work reliably when installed by a newcomer on their own Pi or whatever.

Just rummaged around a mirror of the old Acorn FTP site, nothing stands out.

There’s a copy of !Choices included with !Printers 1.64a here

I think you mean package management. Isn’t that what Packman does?

If it lets you uninstall packages, yes. It means that resources will need to be reference-counted.

Really? All of my apps are compiled with GCC, and none of them put files into SharedLibs. They all link to the SCL at run time using conventional stubs.

How come my !SharedLibs.lib.abi-2/0 directory has nearly two hundred files in it? I would love to clear it out but dare not.

Steve will be relieved to hear that in my current RISC OS (5.24) I am leaving PreDesktop alone. I am belatedly learning the lesson not to tweak, and I take onboard all that Steve says. I do have stuff in PreDesk and Tasks. Moving Choices outside !Boot strikes me as a good idea, as it would be a step in the direction of a clean separation between distributor/user real estate.

Being able to uninstall an application simply by deleting it is one of the agreeable simplifications that RISC OS offers. But it cannot work if some resources are shared. In that case a reference count is needed, incremented by an application’s installation, decremented by an application’s deletion, and attempts to delete a resource should bring up a warning of which applications still need it. Reference counting also interacts with version numbers – another thorny issue.

Deletion of applications becomes more complicated. But in RISC OS the !Boot mechanism can be seen as a side-effect, admittedly dangerous, triggered by the opening of a directory. A reference-count-decrementing delete-mechanism should be seen as something that complements that. The close-bracket that complements the open-bracket, if you see what I mean. It would be triggered whenever the filer is about to delete an application. Applications need a generalization of RMensure that applies not only to modules but to resources of any kind, which serve as pointers for the delete-mechanism. Delete would need an option: whether to delete not only the application but also any resources whose reference-counts would become zero in consequence, or whether to leave zero-referenced resources alone.

Presumably this kind of thing is old hat to package-managers.

I really wish the Apps pseudo filing system supported directories so things could be better organised than “everything all lumped in together”.

Would be cool.

If it lets you uninstall packages, yes.

The User Guide suggests that it does, and that it can track packages installed automatically due to dependencies.

Can I just clarify: is your concern based on current behaviour that you’ve experienced first hand?

How come my !SharedLibs.lib.abi-2/0 directory has nearly two hundred files in it?

You’ve got some apps installed which used shared libraries. This is an option with GCC, but it isn’t a requirement; you can also statically link or, as I’ve already noted, link to the SCL Stubs if you just need standard C99.

[stuff… ] Presumably this kind of thing is old hat to package-managers.

As far as I’m aware, this kind of thing is already taken care of by Packman. Also, Packman is happy for you to move your apps around your hard disc after it has installed them, so long as you do it via Packman, so that it knows where they are. The idea that it tells you where to put apps is a little out of date.

The location of system resources, whether it’s modules in !System.Modules or shared libraries, has always been dictated by RISC OS. They must go in the correct places relative to system variables which identify where they are, else things break. This was the case on RISC OS 2, too.

Sure, there’s no requirement for them to live in !Boot.Resources, but they need to live somewhere – and a location where they are picked up automatically at an appropriate stage of the boot sequence seems sensible. It also simplifies things for developers, as they can then supply dummy !Boot.Resources folders to users for the install.

I don’t really follow this requirement for !Boot to be lean. Clearly minimising the things that are automatically loaded in Boot:Choices is wise (don’t put all of your desktop utilities and module here, folks; put them in $.ThirdParty and link them from Loot at and Run in Configure), but in the end !Boot is just a folder on your disc where things that the system needs and you don’t care about are stored.

And if you do wish to move certain discretionary things like NewsDir outside of !Boot.Resources, to simplify backups, then that’s easy to do if you just add them to Look at in Configure. Don’t do this for things that the system needs, of course.

Would be cool.

It already does. What doesn’t is the bit of the boot sequence which adds apps to ResourceFS at startup.

There’s a utility on my website somewhere dating from my student days (so late 1990s) which took advantage of this to have a nice hierarchy in Apps; I’ve not used it in years, though…

Soemwhwat off topic for this thread, but while RISC OS is a single user system, years ago I did a simple thing to let you have serval different ‘users’, and it would set the Choices paths appropriately. It meant different people could have their own setups on the same machine.

I can’t remember if it gave you a “home” disc on the iconbar. Perhaps it used TinyDirs to give you a quick access to your files. Of course being RISC OS there was nothing stopping you going and looking at someone elses files, but the point was to allow different people have the machine run as they wanted it.

An (improved) version of it made it into Select at some point.

My point was more that people shouldn’t be “tweaking” files in !Boot to make their own home-brew versions;

We shouldn’t be, but it happens. Everybody has an excuse, a reason, whatever. I guess it depends what was tweaked, whether it is a “configurable” part of not.

I think my mods (other than Harinezumi) are in user parts rather than scattered around Boot.

How come my !SharedLibs.lib.abi-2/0 directory has nearly two hundred files in it?

Because there are a lot of shared libraries.
I don’t mean to sound flippant, but a modern browser (as the ones that use the libraries are) need a lot of resources.

I would love to clear it out but dare not.

No, because that would be akin to opening up a body and yanking out random things.

But it cannot work if some resources are shared.

We’re just going to have to accept that some applications require resources that can be shared. Ironically, just like CLib (nobody links to ansilib any more).

It is also useful in that one can run both Otter and the other one (I forget it’s name) and it takes a huge amount of memory for the libraries but only once…because they are shared…

In that case a reference count is needed, incremented by an application’s installation, decremented by an application’s deletion,

Can I veto this in the strongest possible way?
Microsoft cannot get this reliably right (the infamous DLL use count).

There’s a copy of !Choices included with !Printers 1.64a here

I should point out that my suggestion to hack SetChoices was for a proof of concept, not advice to the world.
If somebody moves choices into its own app off of $ and tweaks the variables to point to it (rather then assuming it’s in Boot) and nothing falls over, then we could look to making it a viable option.
In theory nothing should mess up as it ought to be using Choices paths, but….. ;-)

There’s a utility on my website somewhere dating from my student days (so late 1990s) which took advantage of this to have a nice hierarchy in Apps

Found it! http://www.stevefryatt.org.uk/software/utils/resfsapps110.zip (or on the site, software → desktop apps)

I’ll have a play with this soon, it might well answer one of my biggest annoyances with RISC OS!

It already does. What doesn’t is the bit of the boot sequence which adds apps to ResourceFS at startup.

I wonder how much time would be needed, from your code, to get a recursive+directory compliant version of AddApp.

You have to be careful though. Like others I expect, I put some things in sub-directories off Utilities (and other auto-scanned locations) so they are there and available, but I don’t want them seen/run in normal circumstances.

One nice thing about !Apps is that, apart from the ROM-based apps, they appear in alphabetical order. I have the filer set to display in date order normally, so this difference is significant for me.

If you want to add arbitrary files to Apps sub-directories you can use my RFSFiles module with something like:

*RFSAdd <MyApp$Dir>.ThisFile Apps.Utilities.ThisFile

I have done this for the dummy files for !Boot, !Help and !Run that AddApp creates, using command aliases, but it is not very slick. If there is not a satisfactory alternative I could knock up a BASIC utility to do this in no time.

At one time I wrote commands to remove ROM apps from Apps, so in combination with the above you could move Paint and Draw into sub-directories, too. However, they were tied to specific OS versions and I am not sure I could pull the same trick with the latest. I would try if it became desirable.

ResourceFS was useful in antiquity when we had an Econet of Archimedes for teaching purposes. Each machine would boot up from the server and provide readonly stuff in ResourceFS according to the needs of the hour and the class. But for the single user it would be little hardship to dispense with ResourceFS altogether.

But for the single user it would be little hardship to dispense with ResourceFS altogether.

Methinks you don’t know what ResourceFS is.

Hint – go to Apps (on the iconbar), click Menu. Choose “Open $”. Then understand that it providing an easy way to access some applications is a mere side effect at best as to what it’s really there for.

Just my 2p, but I think Steve F. has it spot on.

No-one needs to go messing about inside Boot. Treat it like a black box. Anyone worrying about disk space or clutter just needs to get a grip.

I adopt the same approach of not fiddling with anything delivered in HardDisc4, and it is therefore really easy to update to the latest nightly every so often.

I know that many of us here are pre-1994, when everyone rolled their own disk structure and boot sequence. But that was over quarter of a century ago. It is less relevant than a cassette interface.

From what I have seen of the ROOL Boot over the last few years, it has got cleaner and slicker, and remember it is good back to OS 3.1!

No-one needs to go messing about inside Boot.

You’re a quarter century too late for that advice. ;-)

Anyone worrying about disk space or clutter just needs to get a grip.

Anyone worrying about disc space needs to get Martin Würthner’s DiscSpace to see what is taking up all the space. My Boot is 1153MiB, roughly broken down as follows:

• 32MiB in Choices, most of that being Qt5.cache – why isn’t that in Scrap?
• 50MiB is Loader, the FAT partition magic.
• 90MiB is Packages cache. I can probably nuke that if I need space (I don’t).
• 136MiB is SharedLibs.
• 698MiB is Scrap, of which about 620MiB is Manga’s cache. ;-)

My Apps take up 504MiB, of which the majority of that are the mp3s supplied with AmCog’s games (they’re high quality recordings).

My “Coding” directory is 2.7GiB. 566MiB is RISC OS plus tar files etc. 1625MiB is MangaLib. ;-)

I have 211MiB free (critical on Windows, severe on Android, no big deal on RISC OS). I think I ought to get a decent USB key and shift my manga onto that. I’d instantly gain a big chunk of disc space back.
Probably likewise if I use a key to shift off some of the things that I use less frequently. I have many random files around that are useful to have access to, but don’t need to be right there always.

Thinking about it, I wonder how much bother it would be to stick a larger SD into the old Pi1 and get it going with ShareFS to be storage for the “less essential” things? That should free up some space too.

There are always options that don’t involve trying to delete stuff from !Boot (though an auto clearing Scrap might be useful?).

Anyone worrying about […] clutter just needs to get a grip.

Yup. If you don’t open Boot, you won’t see it!

It is less relevant than a cassette interface.

Can we please apply that logic to FPEmulator and dump it once and for all so our programs can begin to make use of the infinitely faster on-board hardware floating point (that’s been a part of everything post-Iyonix)?

But for the single user it would be little hardship to dispense with ResourceFS altogether.

Try it, and watch large chunks of the OS fall apart.

The primary purpose of ResourceFS is to allow modules to present data contained within them as files, which can then be accessed via a filing system in the usual way. Generally this is so that data (such as Messages files) can be easily replaced without rebuilding the underlying components.

Large chunks of the OS do this, and third-party things do too. I’ve got a folder’s namespace allocated to one of my modules, for example: it stores a file of default number-to-name mappings there which a user might wish to edit and replace with an “enhanced” version. The module then loads the data from file, instead of accessing it directly from within its own memory space. Since the default data is all held inside the module, a user without a need to extend the mappings never need know about the file’s existence.

If there is not a satisfactory alternative I could knock up a BASIC utility to do this [copy apps into subdirectories] in no time.

And it is done.

At one time I wrote commands to remove ROM apps from Apps, so in combination with the above you could move Paint and Draw into sub-directories, too. However, they were tied to specific OS versions and I am not sure I could pull the same trick with the latest.

I have done it, but with the proviso that it depends on how the ROM is compiled.

I have uploaded AppUtils, which is a collection of four small utilities written in BASIC to manipulate the Resources Apps.

*CopyApp copies an existing app in Apps to a subdirectory.
*RemoveApp removes an app added by *AddApp and recovers the memory.
*KillRomApps removes all the ROM apps from Apps.
*InitRomApps puts the ROM apps back.