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

Phil! Really good to hear from you :-) Thanks very much for your work 
and support on this topic in that past, and hopefully we can find ways 
to make some more progress.

Tim, minor details aside I agree very much with what you said. You are 
probably aware (but others may not be) that Phil has done some important 
work on making opensmalltalk-vm and squeakvm be consistent with *nix 
standards and conventions, and our goal was (is?) to be able to support 
the rather stringent requirements of the Debian project (which in turn 
is the basis for many other derivative Linux distros). Vanessa was an 
important contributor as well.

Many of the necessary pieces are already in place, but not well 
advertised. For example, if you are building opensmalltalk-vm for your 
Raspberry Pi, try doing a "sudo make install" right after you run the 
"mvm" the build directory. You will see /usr/local/bin/spur64 installed 
and pointing to a quite reasonable library location for the VM itself. I 
should put together some notes on the various pieces like this that are 
already sorted out, maybe next week because I'll need to dust off some 
old notes and tired memory cells.

Dave

On 2026-06-16 14:40, Phil B wrote:

> I almost included a bit talking more about commercial software but 
> decided I was already going on long enough. ;-)  Yes, commercial 
> software definitely uses it mainly because that's the way they've 
> always done it (i.e. the holdover from the commercial Unix days part)  
> But for open source applications running on open source operating 
> systems, it's never really been a thing. (compare the two dozen vendors 
> using your /opt directories against the thousands of applications 
> installed on a typical Linux box... that's the point I was trying to 
> make: it would appear quite bizarre for a project like Squeak to start 
> using /opt)
> 
> On Tue, Jun 16, 2026 at 1:44 PM Tobias Pape via Squeak-dev 
> <[email protected]> wrote:
> 
>>> On 16. Jun 2026, at 18:44, tim Rowledge <[email protected]> wrote:
>>> 
>>> 
>>> 
>>>> On Jun 15, 2026, at 8:55 PM, Phil B <[email protected]> wrote:
>>>> 
>>>> The /opt tree is a historical artifact of the commercial Unix 
>>>> days... it hasn't been widely used on Linux and is even less used by 
>>>> (open source) applications on Linux.
>>> 
>>> Really? Dang. I wish people would maybe update purported Serious 
>>> Documents On Standards sometimes. It would be so useful for users 
>>> trying to find out The Proper Way!
>> 
>> /opt is still extremely popular, in particular on enterprise stuff.
>> 
>> Look at that:
>> 
>> srv1# ls -1 /opt
>> filepath
>> fujitsu
>> ibm
>> IBM
>> knem-1.1.4.90mlnx1
>> mellanox
>> QLogic_Corporation
>> tivoli
>> xcat
>> Xilinx
>> 
>> Or that:
>> 
>> srv2# ls -1 /opt
>> MegaRAID
>> amsd
>> hpe
>> 
>> Or that:
>> 
>> srv67# ls -1 /opt
>> at14.0
>> at15.0
>> ibm
>> IBM
>> nvidia
>> oc-utils
>> 
>> Just saying.
>> -t
>> 
>>> 
>>> 
>>>> For a directory-tree based install like Squeak, the options are 
>>>> generally to package it up for a given distro (which would spray 
>>>> files across the file system... another historical artifact and 
>>>> increasingly out of fashion for GUI apps) or distribute a tarball 
>>>> and let the user decide where to put it.
>>> 
>>> The latter is kind of how we are doing it right now and I claim it 
>>> leaves a mess. Hence the suggestion to Not Do That. We also have the 
>>> problem that there seem to be at least three different structures 
>>> used for the vm file depending upon where you download from. Looks 
>>> like a bad idea to me.
>>> 
>>> 
>>>> The 'modern' Linux approach to dealing with this is one of the 
>>>> packaged app formats (I like AppImage personally) which behave a lot 
>>>> more like OS X applications in that they hide the directory tree in 
>>>> an archive file that gets extracted transparently at runtime out of 
>>>> view of the user.
>>> 
>>> 
>>> Oh, so they finally realized that the Acorn RISC OS application 
>>> directory approach from *1985* was a good idea. Cool. I can certainly 
>>> get behind that. Somewhere out there we could possibly find the 
>>> Smalltalk code I wrote back then-ish for BrouHaHa to save 
>>> images/changes as an application directory complete with suitable 
>>> startup scripts etc.  40 year old ideas to the rescue :-)
>>> 
>>> Another approach someone suggested is dockerising things to make easy 
>>> to handle packages. I kinda like that idea from my limited experience 
>>> of Docker, but it may have problems I've not yet encountered?
>>> 
>>> tim
>>> --
>>> tim Rowledge; [email protected]; http://www.rowledge.org/tim
>>> A)bort, R)etry, I)gnore, V)alium?
>>> 
>>> 
>>> Squeak-dev mailing list -- [email protected]
>>> To unsubscribe send an email to 
>>> [email protected]
>> 
>> Squeak-dev mailing list -- [email protected]
>> To unsubscribe send an email to 
>> [email protected]
> 
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to 
> [email protected]

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