[janeway]

Yes, I spend a majority of my professional life on similar systems writing code in vim and running massive jobs via slurm. Required for processing TBs of data on secured environments with seamless command line access. I hate web-based connections or vscode type system. Although open to any improvements, this works best to me. It’s like a world inside one’s head with a text-based interface.

Graphical data exploration and stats with R, python, etc is a beautiful challenge at that scale.

[sevensor]

Aside from how slow and user hostile it is compared to a text editor, my biggest complaint about vs code is the load it puts on the login node. You get 40 people each running multiple vs code servers and it brings the poor computer to its knees.

[mattpallissard]

Every job on an HPC cluster should have a memory and CPU limit. Nearly every job should have a time limit as well. I/O throttling is a much trickier problem.

I wound up having a script for users on a jump host that would submit an sbatch job that ran sshd as the user on a random high level port and stored the port in the output. The output was available over NFS so the script parsed the port number and displayed the connection info to the user.

The user could then run a vscode server over ssh within the bounds of CPU/memory/time limits.

[teekert]

I know indeed that our sys-admins also don't like it.

[mattpallissard]

> It’s like a world inside one’s head with a text-based interface.

I had a co-worker describe it as a giant Linux playground.

Another as ETL nirvana.