[davrosthedalek]

I am the "analysis software coordinator" for a nuclear physics experiment (MUSE). The software framework we use was originally developed by me, on a macbook pro, mainly, targeting both MacOS and Linux. We have to onboard new students regularly, and it's quite a software stack to compile (Geant4, root, helper libs, our framework). 5-10 years ago, I was happy if a new student was on Mac. Slap homebrew on it, install the dependencies, install the software. Pretty straight forward. But now, it get more and more brittle. New xcode? Better start downloading new versions and recompile everything, and pray that it works. Now I am actually happy if somebody brings a windows laptop. Slap on WSL, install ubuntu, just works. The number of students we had who used linux already on their laptop I can count on one hand with no fingers :(, but our new postdoc directly ran into an opengl problem on AMD which makes the gpu restart.... So from that perspective, Windows+WSL, with all its warts, comes closest to usable.

[ssivark]

On a tangent -- You might want to look into Guix (at least just the package manager, if not the whole system/distribution); it seems quite popular for similar use cases. See, eg: https://hpc.guix.info/about/

Also, with regards to linux, what stops you from making that the default that students onboard to? I would imagine that something like this becomes quite easy if you have a culture where group members help onboard the new ones into the ways of doing things.

[davrosthedalek]

They typically have one laptop, and a) they are not happy if I tell them that they need to switch to linux (and no word, less games...) b) it's often cheaper laptops with questionable linux support.

It's not like we can buy them a work laptop. At least not for each undergrad.

[noughtme]

Docker? After attemping to install dependencies and build GIS tools originating in the 90´s, I am so thankful for people who have published docker images of obscure software.

[davrosthedalek]

The students have to develop software using the framework, not just use the final program. I always found docker as a dev environment rather painful. Maybe I have to revisit.

[imron]

> I always found docker as a dev environment rather painful.

I’ve found the following to work quite well:

Have a docker compose file setup that runs a container with all the necessary build tools and anything else.

Map home directories, /opt and anything else you want to persist as named volumes.

Run docker compose up -d

Use the remote development extension of vscode to connect to the container and develop almost as if it was local.

[davrosthedalek]

vscode's remote dev is indeed god-tier. I love vscode.

[imron]

I’m not a huge fan of vscode (speaking as a c++ dev), but remote dev is a killer feature so I use it over other alternatives.

[MathMonkeyMan]

This is a neat idea.

[snoopy_telex]

Maybe https://www.vagrantup.com would be a better solution then vanilla docker