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

Show HN: Devbox – Easy, predictable shells and containers

github.com

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Show HN: Devbox – Easy, predictable shells and containers

#151

Post by ianpurton »

jitl wrote: post #15

Looks really good. A layer over Nix that makes it tolerable sounds like a godsend. I’ve had a TODO item for “somehow use Nix for our dev env” at Notion since 2019, but I keep kicking the can down the road because its better to tolerate a 500 line setup script than learn all the Nix stuff. Of course we could use Docker, but then on Mac our dev process would be 3x slower. Congrats to Daniel and the team! Excited to see…

> Of course we could use Docker, but then on Mac our dev process would be 3x slower.

Not in my experience.

If you set up volumes for node_modules or any folders where where dependencies are stored you get the same performance on Mac as anywhere else.

For rust, which I use, I'm able to get better performance on Mac under docker than using rust tools natively. See https://purton.tech/blog/faster-rust-incremental-builds/

Re: Show HN: Devbox – Easy, predictable shells and containers

#152

Post by thesuperbigfrog »

pmontra wrote: post #103
thesuperbigfrog wrote: post #44

Microsoft recently released a similarly named product called Dev Box: https://docs.microsoft.com/en-us/azure/dev-box/overview-what... I am not sure if they would send a cease-and-desist, but you might want to consider a new name for this tool.

Or Microsoft use a different name because this devbox predates MS's August 15 announcement. Devbox first commit was on August 4.

If life was fair then Microsoft would choose a different name.

However, Microsoft has a team of lawyers and have been known to go after other tech products to protect their trademarks and copyrights.

Devbox is an awesome tool. If it becomes popular enough, I would not be surprised if it attracts unwanted legal attention. (Sadly, it has happened to other tools and products.)

Re: Show HN: Devbox – Easy, predictable shells and containers

#154

Post by tasuki »

throwaway892238 wrote: post #47

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…

> some crazy interface that keeps their shell session alive even if their internet disconnects.

This is a solved problem, see eg mosh. Not so crazy.

But, I don't want my development environment running on the same box as other people's environments, it just doesn't make sense: people stepping on each other's toes, the whole box breaking... I really don't want that.

Give me an environment that's possible to build from scratch with a push of a button, and I'll be happy. Anyway in a larger project there needs to be a person/team responsible for keeping the dev env up - either they can keep the shared one up with whatever black magic, or they can make sure the button to create the environment will work for people wherever and whenever they want.

Re: Show HN: Devbox – Easy, predictable shells and containers

#155

Post by mejutoco »

throwaway892238 wrote: post #47

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…

The only advantage I can think of in this scenario is monitoring of employees.

As for disadvantages:

- no work offline

- no freedom for different OS, IDE, tools

- Single Point of Failure (that server goes down, connection drops and nobody can do any work).

IMO the cons are much worse than the pros. I am curious what other advantages you would see in this approach.

EDIT: grammar, format

Re: Show HN: Devbox – Easy, predictable shells and containers

#156

Post by rodrigodlu »

There are also some rough edges that you need to take care.

For instance, my nix installation `locale` was not `UTF-8` (after the first `devbox shell` run), but all my tools and code needs the locale to be UTF8. When you quick check `locale` after `devbox shell` it keeps returning to your host shell locale instead of the nix one, so you can easily be fooled by which layer you're really running. `which` command also loses its purpose.

Then you need an extra step to fix the locale: https://nixos.wiki/wiki/Locales

Then you find other similar issues that need to be taken care, like conflicts with `rbenv`, `poetry` and so on.

It's an awesome idea, but with `docker`, `podman` or fedora's `toolbox` I have some more certainty on what it's running.

With `docker` you can `docker inspect` or something like that. `devbox shell` tries to merge the nix layer with my own shell in a not predictable way.

Anyway, nice project indeed.

Re: Show HN: Devbox – Easy, predictable shells and containers

#157

Post by otabdeveloper4 »

xvector wrote: post #21
jitl wrote: post #15

Looks really good. A layer over Nix that makes it tolerable sounds like a godsend. I’ve had a TODO item for “somehow use Nix for our dev env” at Notion since 2019, but I keep kicking the can down the road because its better to tolerate a 500 line setup script than learn all the Nix stuff. Of course we could use Docker, but then on Mac our dev process would be 3x slower. Congrats to Daniel and the team! Excited to see…

Nix absolutely needed a wrapper like this to be used 'in the real world.' When you think about bringing it to production (eg getting dev teams to migrate to it), Nix goes from a genuinely interesting idea to an "oh, that's cute" experimental toy because no one is going to spend hours learning Nix's weird DSL. It's simply not approachable in its base form. I spent hours converting my devboxes to NixOS and managing my…

I think you're confusing Nix, nixpkgs and NixOs.

(Also Nix and Nix-flakes are two different things, like Javascript and React.)

Re: Show HN: Devbox – Easy, predictable shells and containers

#158

Post by justinsaccount »

throwaway892238 wrote: post #45
justinsaccount wrote: post #12

Earlier quoted context omitted.

This is a cool project and yay nix, but: > Inside a container the file system is very slow Because you are not using "a container". You are using a container that happens to be running in a linux VM on your OS X laptop. It's not the containers fault, it's the entire virtual machine that you are running because you're trying to run technology built on top of one operating system while running a completely different on…

Overlay copy-on-write filesystems are slow. I think most container runtimes use them.

It's not the COW filesystem that is slow, it's bind mounting the host filesystem into the VM. This ends up using something like 9p or sshfs.

Re: Show HN: Devbox – Easy, predictable shells and containers

#159

Post by justinsaccount »

baq wrote: post #143
throwaway892238 wrote: post #45

Earlier quoted context omitted.

Overlay copy-on-write filesystems are slow. I think most container runtimes use them.

compared to full-VMs-pretending-to-be-containers everything is fast. it seems like everybody here is using Macs for development to the point that if you don't say you aren't, you are assumed to be on a mac. Windows with WSL2 is actually pleasant to use, I can recommend trying it out. while WSL2 is a VM technically, the level of integration makes it basically native (if you use the VM disk for your workspace, which yo…

> if you use the VM disk for your workspace, which you should.

Yep, if you try to build something that is stored on /mnt/c you'll have the same horrible performance.

Re: Show HN: Devbox – Easy, predictable shells and containers

#160

Post by nitsky »

otabdeveloper4 wrote: post #157
xvector wrote: post #21

Earlier quoted context omitted.

Nix absolutely needed a wrapper like this to be used 'in the real world.' When you think about bringing it to production (eg getting dev teams to migrate to it), Nix goes from a genuinely interesting idea to an "oh, that's cute" experimental toy because no one is going to spend hours learning Nix's weird DSL. It's simply not approachable in its base form. I spent hours converting my devboxes to NixOS and managing my…

I think you're confusing Nix, nixpkgs and NixOs. (Also Nix and Nix-flakes are two different things, like Javascript and React.)

I think this attempt at clarification is just proving xvector’s point.
Post reply on HN