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

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]