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

Howdy, 



If you have the time and inclination...



Do you run your squeak instances headless? 



If so, how do you handle crashes/freezes etc..?



Typical *nix tools?





Regarding the "The thing born of Markhov that shall not be named",  I have found that  keeping a Webserver running and running blocks into that is very, very productive and fast...





stuff like this... 



cat > /tmp/postB_state.st <<'EOF'

[| out |

out := WriteStream on: String new.

out nextPutAll: 'CScanner superclass: '; nextPutAll: CScanner superclass name asString; nextPut: Character lf.

out nextPutAll: 'CParser  superclass: '; nextPutAll: CParser superclass name asString; nextPut: Character lf.

out nextPutAll: 'CScanner allIvars: '; print: CScanner allInstVarNames size; nextPut: Character lf.

out nextPutAll: 'CParser inherits commentStart: '; print: (CParser allInstVarNames includes: 'commentStart'); nextPut: Character lf.

out nextPutAll: 'CParser own commentStart: '; print: (CParser instVarNames includes: 'commentStart'); nextPut: Character lf.

out contents]

  on: Error do: [:e | 'PROBE ERROR: ', e class name asString, ' :: ', (e messageText ifNil: ['(no message)'])]

EOF



tr '\n' '\r' < /tmp/postB_state.st | curl -s --max-time 30 --data-binary @- http://127.0.0.1:8082/eval  | tr '\r' '\n'



lightning fast, no MCP needed...



It would be nice if we could "attach" to a running image and "attach" to the debuggers that come up from the command line, but that does not exist to my knowledge...(Unless, the image is compiled as debugable and you launch it from gdb. but I have never deployed an image this way)





I ask because back in my former career as a mid-tier web developer (good at SQL get me in demand), the sys admins I knew would never use a gui interface on a server, but would always xterm /ssh into them.







thank you for your time.



t




























From: Tobias Pape via Squeak-dev <[email protected]>
To: "The general-purpose Squeak developers list"<[email protected]>
Cc: "Tobias Pape"<[email protected]>
Date: Wed, 17 Jun 2026 09:32:44 -0400
Subject: [squeak-dev] Re: File locations for linux (and mostly other *nix too)



Hi 
 
> On 17. Jun 2026, at 02:38, gettimothy via Squeak-dev < mailto:[email protected] > wrote: 
> 
> srvX# ls -1 
> 
> 
> Enterprise noob here...what is srvX#  ? is it a cloud thing? or do you have your own sever farm? 
 
This is the root shell on the server, named srv1 and so on. 
The actual names are different ;) 
 
best regards 
    -Tobias 
 
> 
> cordially 
> 
> 
> 
> 
> From: Tobias Pape via Squeak-dev < mailto:[email protected] > 
> To: "The general-purpose Squeak developers list"< mailto:[email protected] > 
> Cc: "Tobias Pape"< mailto:[email protected] > 
> Date: Tue, 16 Jun 2026 13:43:02 -0400 
> Subject: [squeak-dev] Re: File locations for linux (and mostly other *nix too) 
> 
> 
> 
> > On 16. Jun 2026, at 18:44, tim Rowledge < mailto:[email protected] > wrote: 
> > 
> > 
> > 
> >> On Jun 15, 2026, at 8:55 PM, Phil B < mailto:[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; mailto:[email protected] ; http://www.rowledge.org/tim  
> > A)bort, R)etry, I)gnore, V)alium? 
> > 
> > 
> > Squeak-dev mailing list -- mailto:[email protected]  
> > To unsubscribe send an email to mailto:[email protected]  
> 
> 
> Squeak-dev mailing list -- mailto:[email protected]  
> To unsubscribe send an email to mailto:[email protected]  
> 
> 
> Squeak-dev mailing list -- mailto:[email protected]  
> To unsubscribe send an email to mailto:[email protected]  
 
 
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]