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.
Show HN: Devbox – Easy, predictable shells and containers
141–150 of 196 posts
Re: Show HN: Devbox – Easy, predictable shells and containers
#142Extremely, 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…
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
#143Earlier 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 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
#144Looks 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.
What changed?
Re: Show HN: Devbox – Easy, predictable shells and containers
#145Earlier 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
Re: Show HN: Devbox – Easy, predictable shells and containers
#146A 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.
Re: Show HN: Devbox – Easy, predictable shells and containers
#147Earlier 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)
Re: Show HN: Devbox – Easy, predictable shells and containers
#148Extremely, 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…
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
#149Extremely, 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…