Default Hard Disc Structure

I was wondering whether other users would prefer RISC OS to have to a more structured Hard Disc by default?

At the moment, the disc image has many different folders; Apps, Diversions, Printing, Public, Utilities etc..

Would it not perhaps be better to offer a more succinct folder layout? A possible alternative might be;

!Boot
Software
Documents
Media

Each folder above would of course have it’s own sub folders.

What’s everyone’s thoughts on this? I personally think the less populated the top level disc structure the less confusing it is, especially for new users.

A folder named “Software” is meaningless.

I think many people would like to see a simpler structure to !Boot, but I suspect that would break a lot of apps.

Navigating a folder structure has a lot in common with navigating a menu structure. It’s easier to have wider levels and less of them, than to have lots of narrow levels.

So I really can’t take much issue with the present layout – comments about !Boot notwithstanding.

Default filing system structure is a tricky one. Look how long Unix has been going and what they have ended up with. Width is easier than depth, especially when commandlines use fixed buffers rather than more sophisticated datatypes for their implementation.

I usually have a top level directory “Work” for my own stuff as opposed to other people’s. Perhaps we should think more about how to slice up the filing system:

#Ownership:
!Boot belongs to ROOL, except for Choices.
My documents, my work in progress, my letters, my URLs.

#Code:
Applications and scripts versus passive documents.

#Permanence:
Temporary stuff magpied from the internet.
Abandoned projects that I cannot bear to jettison.

#Utility:
Really useful, needed all the time.
Kept for extraordinary circumstances.
Kept because the documentation or code may be worth studying.
Fish-garters.

#Topic:
Graphics
Archiving
Internet

So maybe we need a more general database structure for storing
files. The only reason we use a tree structure is the historic, or accidental one, that a single character for directory separator is all that is required for pathnames to be represented as strings. It would be more honest to use a labelled record for naming files. Thus I might describe a file as

File {
Owner = me; Code = PDF; Topic = “Ancient Languages”;
Utility = Fish-garters; Permanence = ?;
Date = 2013/09/10; Leafname = “Split Ergativity”;
}

Files have to have a canonical name if we are to be able to test them for equality. So maybe the tree-structured hierarchy is the most practical, but a more general user-defined notion of file-attribute is what we need. How best to present such attributes graphically?

I usually have a top level directory “Work” for my own stuff as opposed to other people’s. Perhaps we should think more about how to slice up the filing system:
#Ownership:
!Boot belongs to ROOL, except for Choices.
My documents, my work in progress, my letters, my URLs.

Hmmm, and why exactly should a set of USER choices sit in a system boot heirarchy?
Choices is a classic for having two components, the system component which is in the system boot protected against general user alteration and the user component out in a user directory (which can be per user) – which if you think about it is where the ROL changes were heading.

As to DH’s comment about it breaking software – why would it? The choices are refered to by the choices path variables so they can exist pretty much anywhere including on a network share. If the application doesn’t use that scheme it is already broken.

Steve:

Hmmm, and why exactly should a set of USER choices sit in a system boot heirarchy?

To my mind, burying this in !Boot is the best approach. Power users will know where to find the choices files, and non power users really ought not be messing around in there. Perhaps this is part of the reason Acorn decided to shift everything into BootResources$Dir – to reduce the likelihood of things getting messed up by “fiddling”?

Dave:

A folder named “Software” is meaningless.

Technically we already have this. It is called “Apps”. It has side effects.

I think many people would like to see a simpler structure to !Boot,

Been there, tried it. I don’t like the xxxHook thing because it seems to me to be messy. I have, as yet, completely failed to think of something better that can isolate the possibility of needing different versions of the same module for different versions of RISC OS.

but I suspect that would break a lot of apps.

Why do you suspect that? User settings work according to Choices: and Choices$Write; boot resources via BootResources:. Modules loaded by pointing to System:Modules.blah and so on. There is really no need to make any assumptions about how !Boot is laid out internally – and anything that does so – as Steve points out – is by definition broken.

Steve:
Hmmm, and why exactly should a set of USER choices sit in a system boot heirarchy?

To my mind, burying this in !Boot is the best approach. Power users will know where to find the choices files, and non power users really ought not be messing around in there. Perhaps this is part of the reason Acorn decided to shift everything into BootResources$Dir – to reduce the likelihood of things getting messed up by “fiddling”?

I did suggest that a system and user choices model was a decent idea, with global settings resident in the system side and the user specific in a userchoices.
I appreciate that some people have a single user only machine but there are a fair number of computer users that use and expect their own view on things. The wife for example would think a shade of purple all over the desktop was wonderful. Making a setup that changes look and feel swiftly, at log on, would please her no end and far more so than my use of plain colours.

PS. Anyone else running the 2013-12-16 ROM?
I have it on RPCEmu (always my first test) and recalling Jeffreys comments about this and the screen configure, I tried the screen configure – just slightly broken in visible terms so I won’t save anything from that. The iconbar display change still works perfectly. The configure utility seems to be making a pigs ear of reading the MDFs.
Switch back to the previous ROM and the resolution selection displays just fine.

I’d much prefer Choices outside !boot. I’d like !Boot only for the OS.

Yes, I would agree. In these days with quite rapid development of the OS and a lot of us sticking with very recent versions it would be much easier to revert to a clean boot (or indeed upgrade the !Boot structure) if it contained only OS essential stuff. It is not just user choices as such, it is the PreDesk and Tasks directories which can have all sorts of third party and user stuff put in them. How often have we heard of ‘less geeky’ users getting into a situation of the machine not booting correctly because of some misbehaving file dumped into one of these directories, and having no confidence to get in there and sort things out.

At the moment, the disc image has many different folders

I’m not sure by any counting method that 7 could be classed as “many” (being Boot/Apps/Diversions/Documents/Printing/Public/Utilities) or 6 if you don’t share anything so don’t need ‘Public’.

The problem in any arrangement is different people’s minds are wired differently. When I go to a supermarket is cheese opposite the milk, or opposite the cooked meat?

Boot is actually pretty well thought out , but it can be daunting, which is why the configure plugins allow you to merge them automatically. If you change the internal structure of Boot then all the handy pre-prepared mergeable !Boot updates out there will do all sorts of strange things.

I don’t like the xxxHook thing because it seems to me to be messy. I have, as yet, completely failed to think of something better that can isolate the possibility of needing different versions of the same module for different versions of RISC OS.

I think you’re confusing !System there – don’t put your modules in xxxHook.

why exactly should a set of USER choices sit in a system boot heirarchy

I think that might be to do with FSLock allowing you to write them on an otherwise locked disc, and when the bulk of !Boot is on a fileserver except for the machine local choices. That’s not to say with some care that Choices can’t be moved – as noted elsewhere they should only ever be referred to indirectly through system variables, certainly even Acorn had trouble understanding that Choices$Write is not where to go reading from .

or indeed upgrade the !Boot structure

The plan, now everyone’s been good and followed the 5.20 upgrade procedure, is that future !Boot upgrades can be supplied as deltas and merged automatically using the oft-overlooked “Installer” module.

The plan, now everyone’s been good and followed the 5.20 upgrade procedure, is that future !Boot upgrades can be supplied as deltas and merged automatically using the oft-overlooked “Installer” module.

All RO users using an automated update tool that puts things where it wants?

Coo, can I see your cat herding certificate? :-)

Colin:

I’d much prefer Choices outside !boot. I’d like !Boot only for the OS.

You know !Scrap is in there too? ;-)
In fact, all the nuts’n’bolts stuff is probably lurking somewhere inside !Boot.

Question is – if not there, then where?

I’ll give you a hint – if you stick it anywhere in $, the first thing I would do is move it somewhere else and tweak the paths to point to the new location; thus risking every automated update re-breaking my setup. At least in !Boot, it is all self-contained and mostly hidden.
I mean, the DOS partition probably shouldn’t be there either. But it is, and I know where it is if I need it. If it was someplace else, perhaps some place more visible, what’s the betting somebody might have thought “mmm, this is big and unnecessary” and deleted it?

and having no confidence to get in there and sort things out.

I’m not sure changing the directory location would help much. It might mean one or two less levels to traverse, but it will still be complicated and scary.

When I go to a supermarket is cheese opposite the milk, or opposite the cooked meat?

Neither. It is beside the butter, which is beside the yoghurt, which is distantly beside the milk.

[or, if you are Jewish, just begin screaming at the idea of meat and milk together]

I think you’re confusing !System there – don’t put your modules in xxxHook.

I’m not putting my modules there¹. I’m just saying it seems like a messy arrangement until you understand what it is actually doing.

¹ My modules usually reside within the app in question, unless it is likely to be a shared resource. I don’t dump stuff in !System as a matter of course…

Rick.

Scrap can be removed as well – choices was only an example. Scrap is user data and in my world doesn’t belong in !boot.

I realise !boot is virtually unchangable for the same reason you can’t get rid of windows folders like documents, video etc. – There’s always some program hard wired to them, but I don’t have to like it and consider it the worst feature of RISC OS.

Sprow.

Does boot merge now cope with the !boot merge directory containing !System ie does it now automatically do a sysmerge? I haven’t been keeping up to date with !boot changes it may have done this for a long time.

future !Boot upgrades can be supplied as deltas and merged automatically using the oft-overlooked “Installer” module.

S’pose that means I have to find another hobby.

The best way to understand why !boot is how it is is to open a task window and type show then check how many pages of info that you would need to setup every time you start using your computer. This is OK for long time users but a nightmare for new users i have noticed that most of the people that posted are long time users.
At least it not hidden away like other systems where you don’t know where to even start to look.

*show shows data from !application.!boot not the !boot application. It’s the application I dislike. In risc os we have directories, application directories and files. We tell new users about application directories and how wonderful they are because they hide program files. We tell them there is no need to look inside them but you can if you want. And what do we do? The very first application on the disc you don’t even give the user time to settle down to the delights of movable applications and you tell them get your shift finger out and rummage around in !boot if you want access your choices . In one fell swoop you’ve just destroyed any credibility you had trying to explain what’s good about riscos.

With user files hidden in !boot the advent of package managers it is no different to windows it is only your experience of the system that makes it seem different.

Hello all
if there is a serious intent to muck about with the current !Boot structure then this one ‘old time’ user that would want
instructions to restore the !Boot back to its current form.
I’m not against worthwhile change but I like it the way it is.

The problem in any arrangement is different people’s minds are wired differently.

Absolutely agree with you there. And I know 7 folders may not be that many, but it does seem a lot considering they only contain a few applications in each of them.
Was just wondering to see if there was any appetite to ‘tidy’ things up for future and current users.

As for changing the !Boot structure, I think if this was ever to happen in the future, that it might be good to get rid of the hundreds of different files spread across different folders and just go with a few files that do everything. Surely a much quicker approach to loading data. However, not being too technical I have no idea how feasible that actually is for RISC OS.

I’m with Colin on this one. I’ve long since thought it would be nice if !Boot was system-only, and other things like user choices, !Scrap, were somewhere else. Obviously there’s a problem figuring out exactly what is “system-only” – many things overlap slightly.

!Boot would end up quite a bit smaller, and easier to backup. If it had no private user data in there, people could comfortably email it to others for troubleshooting, etc.

Horse for courses. On the subject of root-level directories, I’m also in favour of more rather than less (to a sensible degree, obviously). I don’t like it when directory levels get too deep – makes for a lot of clicking!

I’m not against worthwhile change but I like it the way it is.

There you go Sprow, your cat herding skills are needed already :)

and

I don’t like it when directory levels get too deep – makes for a lot of clicking!

Where the other viewpoint is that having fewer directories with more in tends to lead to more scrolling and RSI

All RO users using an automated update tool that puts things where it wants?
Coo, can I see your cat herding certificate? :-)

Sure – it’s just over here in my drawer, next to the jar of hen’s teeth, guarded by my pet unicorn.

Scrap is user data and in my world doesn’t belong in !boot.

You can already move it, it just needs to be somewhere “seen” by the filer – harking back to the days when it was on your work floppy disc.

Does boot merge now cope with the !boot merge directory containing !System ie does it now automatically do a sysmerge?

No, both !System and !Fonts are skipped I think, they would be supplied seperately still.

it might be good to get rid of the hundreds of different files spread across different folders and just go with a few files that do everything.

If anyone knows what the 25224 files inside C:\Windows do please raise their hand.
Part of the reason why they’re split out within !Boot is that they’re managed by different configure plugins, so while you could mash them all into one really long obey file, each of the plugins would then need to understand how to edit that obey file without affecting any of the other areas (or ordering) of things it doesn’t know about. The layout of !Boot encodes both the actions needed to boot and the order in which those actions are performed, both of which are important.

future !Boot upgrades can be supplied as deltas and merged automatically using the oft-overlooked “Installer” module.

S’pose that means I have to find another hobby.

Don’t worry – that’s only planned as a convenience for those uncomfortable upgrading. The full fat disc contents aren’t going away, so you can do it manually too if you prefer.

If anyone knows what the 25224 files inside C:\Windows do please raise their hand.

Me! me! me!

They clog up your hard disc.

On Colin’s point of needing to shift-double-click to ‘get at’ choices… would a simple solution be some sort of ‘choices plugin’ in Configure?

The plan, now everyone’s been good and followed the 5.20 upgrade procedure, is that future !Boot upgrades can be supplied as deltas and merged automatically using the oft-overlooked “Installer” module.

I’ve also been considering for a long while the possibility of putting a copy of all the disc image components in a package repository so they could be individually updated when they changed by PackMan. As well as the stable releases, it could then also include a testing repository so individual components could be installed for testing in between releases.

My latest attempt at this is using a simple database with the package details that would then generate the files for the repository from a HardDisc4 zip file. I’m looking at other things at the moment, but if it’s of any interest I could have a fresh look at it in the new year.

On Colin’s point of needing to shift-double-click to ‘get at’ choices… would a simple solution be some sort of ‘choices plugin’ in Configure?

Isn’t this a power user problem? Surely less experienced users should use the app’s UI for editing the settings, rather than poking around in choices?

Or, to put it another way – why are those wanting to access choices wanting to access it?

would a simple solution be some sort of ‘choices plugin’ in Configure?

Not sure what you mean here. The ‘OS’ choices are managed by the Boot-configure plug ins. Each of the plugins knows how to interpret its own data. I see no need for change.

User application choices must be managed by the application surely. Application choices files can be text or ‘binary’ in content, there is no ‘api’ for how applications write their choices. A generic choices plugin can have no means of knowing what the choices file(s) content is and how it should be interpreted.