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

Not to argue, but to broaden things..I have recently learned and am using a .local directory  for stuff I use,  independent of the system (Slackware Linux 64)

(base) bash-5.1$ ls .local/

bin  emacs-30  emacs-30.1  glibc-2.39  glibc-2.39.tar.xz  include  lib  lib64  share  state

(base) bash-5.1$ ls .local/bin/

claude  corepack  duckdb  emacs-30  mcp-server-filesystem  mcp-server-filesystem-wrapper  node  npm  npx  pandoc  pandoc-lua  pandoc-server  squeak-wrapper-7.0-cog64

(base) bash-5.1$





I find it useful, but I am no expert...





Another thing that I kind of slid into is something called miniconda...if you look at the bash terminal output above, you see a (base) as part of the bash prompt.

Currently I do not use anything but the standard (base) but from what I feebly understand, it provides "virtual(?)" environments....I have no clue how it works...



I do not know if this could be done, but imagine a (squeak64)  environment or a (squeak32) environment...





my apologies for the lack of precision, but you may find that exploring these paths useful.



cordially,



t




From: tim Rowledge <[email protected]>
To: "The general-purpose Squeak developers list"<[email protected]>
Date: Mon, 15 Jun 2026 18:58:15 -0400
Subject: [squeak-dev] 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; mailto:[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 -- mailto:[email protected] 
To unsubscribe send an email to mailto:[email protected]

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