Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developing inside a virtual machine

blog.disintegrator.dev

Post reply on HN
Print view View original

101–110 of 147 posts

Re: Developing inside a virtual machine

#101

Post by quectophoton »

skydhash wrote: post #52
jeswin wrote: post #43

Earlier quoted context omitted.

> VM seems like a good way to add some protection. Yeah, but someone should try to fix this anyway. It's not a nodejs-specific problem, but it's badly needed in node. Any of the 100s of authors whose packages I depend on might have made a typo, or just been careless. Software development requires a scary level of trust. I am also increasingly moving to VMs. I want tools (such as VSCode) to run on the main machine, bu…

The one trick I found that work well is to move everything in the VM. I usually opt for either emacs or vim, and if I need an IDE, I install i3. It just takes a moment to copy my dotfiles over.

I'm doing something similar.

My development environment for work is defined in a Dockerfile, and I have a small shell script whose only purpose is to call `docker run` with that image, mount a few volumes for caching, mount the CWD in "/workspace", and start a shell in there. Development is done with nvim.

If I need Docker Compose, I run it from the host. For projects that I find unpleasant to work with in this way, I use GitHub Codespaces. I hadn't thought about using a GUI IDE from within a VM, so thanks to your comment (EDIT: and also the submitted article) I now have something new to try!

Re: Developing inside a virtual machine

#102

Post by MaKey »

vladvasiliu wrote: post #100
daghamm wrote: post #67

Earlier quoted context omitted.

You would be surprised how much of corporate cybersecurity is done like this. It has not in anyway improved sine crowdstrike, on the contrary EDR shenanigans has probably grow 100% since last year. These security companies must have really good salesmen. Or maybe IT departments are always ran by clueless fools, who knows?

> Or maybe IT departments are always ran by clueless fools, who knows? I think IT has its fair share of clueless fools, but what I've noticed is that when the "security department" is separate, people there tend to have no idea what they're talking about and rely on checklists. Plus, "everybody uses X, that means we're missing out".

Corporate IT security seems to be mainly about checklists and compliance, not about actual security.

Re: Developing inside a virtual machine

#103

Post by screcth »

daghamm wrote: post #67
bitwize wrote: post #53

Earlier quoted context omitted.

You'd think last year's Clownstrike incident would put the lie to the efficacy of the fucking-for-virginity approach to endpoint security favored by organizations but no. At the enterprise level, security isn't really about security, it's about having an audit trail so bad actors can be caught after the fact.

You would be surprised how much of corporate cybersecurity is done like this. It has not in anyway improved sine crowdstrike, on the contrary EDR shenanigans has probably grow 100% since last year. These security companies must have really good salesmen. Or maybe IT departments are always ran by clueless fools, who knows?

The security team cares about minimizing risks to the company and to their own careers.

Deviating from what everybody else is doing makes it so that the burden of proving that your policies are sane is on you and if anything bad happens your head is the first to roll.

You use CrowdStrike and the company lost millions of dollars due to the outage? That's not your problem, you applied industry standard practices.

You don't use CrowdStrike and the company got hacked? You will have to explain to the executives and the board why you didn't apply industry standard practices and you will be fired.

Re: Developing inside a virtual machine

#104

Post by throw5959 »

apt-apt-apt-apt wrote: post #36

I accidentally typed 'npm install axioss' (extra s typo) this morning. When it successfully installed, it was terrifying to think that all source code, private files were instantly shared with malicious actors. Not only that, there was the prospect of having to somehow wipe and ensure all files were clean, reinstall the OS, and the possibility of some bootloader remnant still lurking. In this case, it seems that a se…

Bun package manager (compatible with NPM) doesn't execute any code during package installation.

Re: Developing inside a virtual machine

#105

Post by gruez »

rawgabbit wrote: post #42
UltraSane wrote: post #41

Earlier quoted context omitted.

I worked at a government agency that used Zscaler to perform TLS MITM inspection. You have to create a tunnel to a Zcaler datacenter and send all your traffic to them encrypted with a certificate they provide so they can decrypt it. Then they encrypt it again and send it on its way. It can detect things that otherwise could not but you are putting a LOT of trust into Zscaler security because anyone who hacks them can…

I knew Zscaler did MITM. But I thought it only inspected hashes or summaries to detect malicious content. I didn’t know it would encrypt again.

>I didn’t know it would encrypt again.

"encrypt it again" in this case means establishing a new TLS connection to the original host and forwarding the decrypted contents in this new connection. This is obviously required if the original host only had a https endpoint, and (more importantly) so the traffic isn't exposed on the wider internet.

Re: Developing inside a virtual machine

#106

Post by gruez »

bitwize wrote: post #53
UltraSane wrote: post #41

Earlier quoted context omitted.

I worked at a government agency that used Zscaler to perform TLS MITM inspection. You have to create a tunnel to a Zcaler datacenter and send all your traffic to them encrypted with a certificate they provide so they can decrypt it. Then they encrypt it again and send it on its way. It can detect things that otherwise could not but you are putting a LOT of trust into Zscaler security because anyone who hacks them can…

You'd think last year's Clownstrike incident would put the lie to the efficacy of the fucking-for-virginity approach to endpoint security favored by organizations but no. At the enterprise level, security isn't really about security, it's about having an audit trail so bad actors can be caught after the fact.

>the fucking-for-virginity approach to endpoint security

???

Re: Developing inside a virtual machine

#107

Post by bluehatbrit »

lizknope wrote: post #90

Are most companies this flexible in allowing developers to install whatever they want? > My physical machine is a 2023 MacBook Pro with M2 Pro CPU > I’m using VMWare Fusion Pro > Quite often I’ve found developers frowning up Ubuntu and preaching for folks to use NixOS, Arch, Debian or other distros. The reality for me was Ubuntu was the fastest way to get set up and now I'm in integrated circuit / semiconductor desig…

I work mostly in web / server side development, it's not really a problem I've had for a number of years now. Some of my colleagues use various linux distros, others macos. No one is using Windows that I know of.

Each project we have requires a specific tool chain version (python, elixir, ...) and specific versions of things like postgres. All dependencies are listed with some kind dependency definition file (pyproject.toml, package.json, mix.exs). If you bump a package it's done in the definition file as part of your changes and goes through CI for packaging and releasing. The rest of the team will get the new package version as soon as they pull your changes and run `just deps` or whatever. CI is the ultimate determining factor of whether your code actually "works".

We also package and deploy with containers, but this isn't the real determining factor for any of the above.

Re: Developing inside a virtual machine

#108

Post by bluehatbrit »

disintegrator wrote: post #95
urronglol wrote: post #93

Devcontainers running as non root. Trivial t set up. Don’t need to fanny around with a Vm

I've tried devcontainers in the past and the performance compared to my current setup was pretty bad. This was a few years ago when it was known that filesystem-heavy workloads on Docker for Mac were sub-optimal. I remember having to define several bind mounts which improved the overall performance. I do intend to revisit this solution next time I need to set up a dev environment but rest assured there was nothing su…

I use it at the moment and don't really find any noticable difference between running directly on my host, and in a dev container. If I were to measure the performance I'm sure there would be something, but it's not noticable in my development cycle.

They also seem to be pushing it beyond vscode and into something which is editor agnostic. It's not quite there yet on that front, but I'm excited for it as I've been dabbling with other editors recently which don't support devcontainers directly and it always pulls me back to vscode.

It's on a journey for sure, but I've had no performance issues when using it straight out of the box over the past year.

Re: Developing inside a virtual machine

#109

Post by disintegrator »

StreakyCobra wrote: post #86
disintegrator wrote: post #25

Author here. Thank you for all the tips. I especially like the idea of using ssh from guest to host to enable pbcopy/pbpaste and open. Now I know what all the WSL users experience seamlessly with their setups. Glad I have something that comes close.

Thanks for the post, an interesting read! Side note: I checked out your other blog post, and it resonates with my own first post, which I wrote just two days ago: https://fabiendubosson.com/blog/overcoming-perfectionism/ . You’re definitely not alone in battling anxiety, perfectionism, and procrastination when it comes to blogging. Keep writing! :)

Thanks! Really appreciate your comment :)

Re: Developing inside a virtual machine

#110

Post by bitwize »

gruez wrote: post #106
bitwize wrote: post #53

Earlier quoted context omitted.

You'd think last year's Clownstrike incident would put the lie to the efficacy of the fucking-for-virginity approach to endpoint security favored by organizations but no. At the enterprise level, security isn't really about security, it's about having an audit trail so bad actors can be caught after the fact.

>the fucking-for-virginity approach to endpoint security ???

Compelling users to have software indistinguishable in its operation from malware running on their machines for security purposes is, as the expression goes, like fucking for virginity.
Post reply on HN