File locations for linux (and mostly other *nix too)

For far too long (eh, like 30 years) the directory layout we are using for the various flavours of *nix have annoyed me. This is a fixable problem.

There is an actual standard that people are supposed to adhere to; it’s the "Filesystem Hierarchy Standard” as per https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

My understanding of this standard suggests that we should be installing all the ’static’ parts  (the VM, the .sources, any default config files, arguably the initial release .image & .changes) in the /opt tree (per https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html) under a ’squeak’ subdirectory. For the VM I would suggest making use of the multiple version trick used by the development make system whereby the base VM directory has more than one lib/squeak/{complicated name release/version thing}, and a modestly clever shell script that finds the right one to use for the image being fired up. I think we have a suitable script somewhere that Dave L has kept alive?

We would need to modify the SmalltalkImage>>#sourcesFilePaths code to add the ‘proper’ location, which I suggest would be /opt/squeak/shared. I could swear we used to have a primitive that helped work out the appropriate platform places to look at, but maybe I’m misremembering? I *don’t think* that the vm path is a good place in general, and I suspect that the old related code that fusses about misusing aliases (in SmalltalkImage>>#openSourcesAndChanges:forImage:) is now out of date.

Related but applicable to most platforms, it seems to me that the behaviour of the assorted all-in-one & platform specific packages is not just wrong but dangerous when using them to start a new default image. The default image is after all effectively the ‘default template’ that many creative applications use for a first start or ‘New File’ option. That file should be read-only and the startup script should make a copy of it in a more user-visible directory, not use the initial one and let naive users corrupt it by playing with it and saving a damaged version. This could perhaps be managed with the config wizard for example, which would provide an opportunity to explain why this is done. 

Anyone want to argue otherwise?

tim
--
tim Rowledge; [email protected]; http://www.rowledge.org/tim
"How many Motie Warriors does it take to change a lightbulb?” 
"None. One of the dead ones will do it."



Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]