Live data from Hacker News

Show HN: Devbox – Easy, predictable shells and containers

github.com

141–150 of 196 posts

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

#141
post #56

I want to love this, and it looks amazing, but it doesn't work for me: 05:01:13 $ devbox add python2 Error: Package python2 not found. Really bad first-run experience when the demo command doesn't work, sadly.

This error happens because you didn't spawn a new shell after installing nix and devbox. I think README could make it more obvious, as I stumbled upon this as well.

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

#142

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…

I used to work on remote servers, when the laptops were not powerful enough to sustain a full dev environment and at the same time renting dedicated servers wouldn't break a bank.

Today, getting a server more performant than my laptop (M1 MB PRO) is not economically viable.

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

#143

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.

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 you should.)

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

#144
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…

I just set up a docker dev environment on Mac and I would not call it slow anymore. If you were referring to volume mounts, they are 10x faster now. Definitely fast enough for our work.

> they are 10x faster now

What changed?

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

#145

Earlier quoted context omitted.

No, it uses native Nix directly on your machine - Linux, Mac, or Windows. Its integration with Docker is that it can _build_ Docker images from the Nix packages in your "devbox".

I'm assuming for windows it only works in WSL2? cause last time I checked nix wasn't compatible with native windows development, sadly

Yeah I assume so too, but I'm not sure.

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

#146
post #109
post #99

A consistent shell for everyone on the team Declare the list of tools needed by your project via a devbox.json file and run devbox shell. Everyone working on the project gets a shell environment with the exact same version of those tools. Why not just use a Dockerfile?

Dockerfiles are repeatable but they are not reproducible - they don't give you the same version of everything every time you run them.

One can absolutely lock versions in their Dockerfile. I can see that the design principle of DevBox is to pin the versions. At the end of the day we all need to consider versioning (i.e., the image version) the versions (i.e., package versions) anyway.

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

#147
post #127
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…

My theory is that we need better learning resources (that’s why I’m working on https://mimoo.github.io/nixbyexample/ ), better tooling (debugging or starting a project from scratch is hard), better integration with rust/js/etc. projects based on convention (and not configuration: I shouldn’t have to point to more than a Cargo.toml or package.json and nix should do the rest)

The problem is boundless complexity. Learning resources won’t help anyone to learn and manage boundless complexity.

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

#148

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…

It is expensive though. Can get some nice local hardware for those cloud costs and then there is the latency.

A cool option is give everyone the same laptop and set them up from a disk image. Keep data you want to keep on another partition. Reimage every so often with the latest required tooling. New starters will be thankful.

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

#149
post #77

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…

> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time Single repository, yes. Single development environment, no. Development environments should be isolated, so developers don't step on each other's toes... Also, centralised cloud development machines are by definition, a single point of failur…

And tools like the one that spawned this HN discussion are going to help homogenise things and make it easier to go local.

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

#150

Earlier quoted context omitted.

I just set up a docker dev environment on Mac and I would not call it slow anymore. If you were referring to volume mounts, they are 10x faster now. Definitely fast enough for our work.

> they are 10x faster now What changed?

Virtiofs
Post reply on HN