5 ms·
Don't do development on your local machine. Full stop. Just don't. Do development, all of it, inside VMs or containers, either local or remote. Use ephemeral
by numbsafari 11mo ago
Don't do development on your local machine. Full stop. Just don't.
Do development, all of it, inside VMs or containers, either local or remote.
Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling.
This has the added benefit of not only sandboxing your code, but also making your dev environments repeatable.
If you are using GitHub, use codespaces. If you are using gitlab, workspaces. If you are using neither, check out tools like UTM or Vagrant.
- deleted 11mo ago[deleted]
- suck-my-spez 11mo agoAre people actually using UTM to do local development? Im genuinely curious because I casually looked into it so that i could work on some hobby stuff over lunch on my work machine. However I just assumed the performance wouldn't be too great. Would love to hear how people are setup…
- suchar 11mo agoWith remote development (vscode and remote extension in jetbrains with ssh to VM) performance is good with headless VM in UTM. Although it always (?) uses performance cores on Apple Silicon Macs, so battery drain is a problem
- rickstanley 11mo agoWhen I had a Macbook from work, I set up an Arch Linux VM using their basic VM image [1], and followed these steps (it may differ, since is quite old): https://www.youtube.com/watch?v=enF3zbyiNZA https://www.youtube.com/watch?v=enF3zbyiNZA Then, I removed the graphical settings, as I was aiming to use SSH instead of emulated TTY that comes ON by default with UTM (at that time). Finally, I set up some basic scripting to turn the machine on and SSH into it as soon as sshd.service was available, which I don't have now, but the script finished with this: (fish shell) while not ssh -p 2222 arch@localhost; sleep 2; end; Later it evolved in something like this: virsh start arch-linux_testing && virsh qemu-monitor-command --hmp arch-linux_testing 'hostfwd_add ::2222-:22' && while not ssh -p 2222 arch@localhost; sleep 2; end; I also removed some unnecessary services for local development: arch@archlinux ~> sudo systemctl mask systemd-time-wait-sync.service arch@archlinux ~> sudo systemctl disable systemd-time-wait-sync.service And done, performance was really good and I could develop on seamlessly. [1]: https://gitlab.archlinux.org/archlinux/arch-boxes/-/packages/2057 https://gitlab.archlinux.org/archlinux/arch-boxes/-/packages...
- hombre_fatal 11mo agoI started using UTM last week on my Macbook just to try out NixOS + sway and see if I could make environment that I liked using (inspired by the hype around Omarchy). Pretty soon I liked using the environment so much that I got my work running on it. And when I change the environment, I can sync it to my other machine. Though NixOS is particularly magical as a dev environment since you have a record of everything you've done. Every time I mess with postgres hb_conf or nginx or pcap or on my local machine, I think "welp, I'll never remember that I did that".
- ivankra 11mo agoIt works incredibly well with Linux VMs, my daily driver. I plug in a USB keyboard, external monitor and Can't Believe It's Not Linux. Only occasionally when I need to use the laptop screen/keyboard does macOS bother me and remind of it real self. There's around 10-15% performance penalty for VMs (assuming you use arm64 guests), but the whole system is just so much faster and well built than anything Intel-based to day, that it more than compensates. For Windows, it's lacking accelerated video drivers, but VMWare Fusion is an ok free alternative - I can totally play AAA games from last decade. Enjoy it until broadcom kills it.
- DyslexicAtheist 11mo ago[flagged]
- bigstrat2003 11mo agoThat's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.
- socalgal2 11mo agoYou are right, if it's a pain no one is going to do it. So the thing that needs to happen is to make it not a pain.
- numbsafari 11mo agoWake up and smell the codespaces/workspaces/vagrant/so many other tools that make this not a pain. Some of these tools have been around for AGES. Nowadays, with VSCode Remote, you can even use a "modern" IDE environment with a local fat client observing your remote runtime. Other folks do this quite happily, with tremendous tooling, using emacs or *vim.
- cutemonster 11mo agoIt is a realistic solution.
- zbentley 11mo agoTaking this more seriously than it perhaps deserves: if that’s true, why isn’t widespread adoption of this approach growing? Whether or not it’s a good idea, “realistic” implies practicality, which could presumably be measured by whether people find it worthwhile to do the thing.
- cutemonster 11mo agoI suppose it depends on what you're protecting, who's out there to get you, and how boring and time consuming it is to clean up after a breach (can't that take weeks or months), etc. Aren't you're a bit asking "When X transportation method isn't used by everyone, can it really be any good?" :-)
- hinkley 11mo agoI used to have a separate account on my box for doing code for other people, one for myself and another for surfing the web. Since I have an Apple TV hooked up to one of my monitors I don’t have a ton of reasons for hopping credentials between accounts so I think I’ll be going back to at least that. The fact I use nvm means a global install won’t cross accounts.