24 ms·

I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx". https://github.com/89luca89/

I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx". https://github.com/89luca89/distrobox https://github.com/89luca89/distrobox https://containertoolbx.org/ https://containertoolbx.org/ It is sorta like Vagrant, but instead of using virtualbox virtual machines you use podman containers. This way you get to use OCI images for your "dev environment" that integrates directly into your desktop. https://podman.io/ https://podman.io/ There is some challenges related to usermode networking for non-root-managed controllers and desktop integration has some additional complications. But besides that it has almost no overhead and you can have unfettered access to things like GPUs. Also it is usually pretty easy to convert your normal docker or kubernetes containers over to something you can run on your desktop. Also it is possible to use things like Kubernetes pods definitions to deploy sets of containers with podman and manage it with systemd and such things. So you can have "clouds of containers" that your dev container needs access to locally. If there is a corporate need for window-specific applications then running Windows VMs or doing remote applications over RDP is a possible work around. If everything you are targeting as a deployment is going to be Linux-everything then it doesn't make a lot of sense to jump through a bunch of hoops and cause a bunch of headaches just to avoid having it as workstation OS.

trog 2y ago
If you're doing this, there are many cases where you might as well just spin up a decent Linux server and give your developers accounts on that? With some pretty basic setup everyone can just run their own stuff within their own user account. You'll run into occasional issues (e.g. if everyone is trying to run default node.js on default port) but with some basic guardrails it feels like it should be OK? I'm remembering back to when my old company ran a lot of PHP projects. Each user just had their own development environment and their own Apache vhost. They wrote their code and tested it in their own vhost. Then we'd merge to a single separate vhost for further testing. I am trying to remember anything about what was painful about it but it all basically Just Worked. Everyone had remote access via VPN; the worst case scenario for them was they'd have to work from home with a bit of extra latency.
- tored 2y ago
  The painful part of that setup is that all the tools you want to use on the source code must either run on the server itself, thus installed somehow, or some slow remote mounted filesystem, this severely limits the tools you may want to use.
  - trog 2y ago
    What tools don't run on Linux? Modern tooling almost assumes Linux in most cases now. As a Windows user I feel like I hit this wall way more often than any other.
    - tored 2y ago
      Running an IDE over ssh or samba is just an awful experience, but generally if I want a command line tool to be installed I need to be either root or I need to ask the administrator of the server to install it, on my own machine I can install whatever I want and I can run whatever operating system or distro I want. And if I'm traveling I can bring my laptop with me, can't do that with a server.
      - trog 2y ago
        Oh right sorry I did forget about that aspect. I haven't done that for a while with a big codebase with, say, VS Code, and not on anything that wasn't very low latency (sub 10ms, so local LAN). I am mostly editing directly on the server when I do it these days but that wouldn't fly for anything other than the light hacking I do.
        tored 2y ago
        These days with many working on remote location you also need to include the VPN latency.
h4ck_th3_pl4n3t 2y ago
This. Distrobox and podman are such a charm to use, and so easily integrated into dev environments and production environments. The intentional daemon free concept is so much easier to setup in practice, as there's no fiddly group management necessary anymore. Just a 5 line systemd service file and that's it. Easy as pie.

trog 2y ago

If you're doing this, there are many cases where you might as well just spin up a decent Linux server and give your developers accounts on that? With some pretty basic setup everyone can just run their own stuff within their own user account. You'll run into occasional issues (e.g. if everyone is trying to run default node.js on default port) but with some basic guardrails it feels like it should be OK? I'm remembering back to when my old company ran a lot of PHP projects. Each user just had their own development environment and their own Apache vhost. They wrote their code and tested it in their own vhost. Then we'd merge to a single separate vhost for further testing. I am trying to remember anything about what was painful about it but it all basically Just Worked. Everyone had remote access via VPN; the worst case scenario for them was they'd have to work from home with a bit of extra latency.

tored 2y ago
The painful part of that setup is that all the tools you want to use on the source code must either run on the server itself, thus installed somehow, or some slow remote mounted filesystem, this severely limits the tools you may want to use.
- trog 2y ago
  What tools don't run on Linux? Modern tooling almost assumes Linux in most cases now. As a Windows user I feel like I hit this wall way more often than any other.
  - tored 2y ago
    Running an IDE over ssh or samba is just an awful experience, but generally if I want a command line tool to be installed I need to be either root or I need to ask the administrator of the server to install it, on my own machine I can install whatever I want and I can run whatever operating system or distro I want. And if I'm traveling I can bring my laptop with me, can't do that with a server.
    - trog 2y ago
      Oh right sorry I did forget about that aspect. I haven't done that for a while with a big codebase with, say, VS Code, and not on anything that wasn't very low latency (sub 10ms, so local LAN). I am mostly editing directly on the server when I do it these days but that wouldn't fly for anything other than the light hacking I do.
      - tored 2y ago
        These days with many working on remote location you also need to include the VPN latency.

h4ck_th3_pl4n3t 2y ago

This. Distrobox and podman are such a charm to use, and so easily integrated into dev environments and production environments. The intentional daemon free concept is so much easier to setup in practice, as there's no fiddly group management necessary anymore. Just a 5 line systemd service file and that's it. Easy as pie.