Live data from Hacker News

Show HN: Devbox – Easy, predictable shells and containers

github.com

121–130 of 196 posts

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

#123
post #109

Earlier quoted context omitted.

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

You're right, but it depends on workflow. IMO they should be pulling the docker image itself and not building the container from the Dockerfile.

It depends on other external circumstances, but other benefits for nix would be: - they could pull less data (nix configuration is smaller than docker binary blob), - nix is entirely deterministic (docker depends on whenever that image was built), - nix implicitly its components for if there are many of these dev shells, and also with your main system. Yes, Dockerfiles can also be chained but if the later levels of these are rebuilt, the the earlier ones better have new enough versions installed (i.e it's a can of worms and the entire chain needs to be rebuilt anyway)

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

#124
So essentially this seems like another implementation of what toolbox and distrobox is implementing.

https://github.com/containers/toolbox/

https://github.com/89luca89/distrobox

With the downside of not having the option to select a Linux distro and being locked to the nixpkgs repositories?

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

#125

So essentially this seems like another implementation of what toolbox and distrobox is implementing. https://github.com/containers/toolbox/ https://github.com/89luca89/distrobox With the downside of not having the option to select a Linux distro and being locked to the nixpkgs repositories?

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".

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

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

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

#128
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.

Depends how much memory your container needs to build…

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

#129
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

Out of interest, what in your dev process makes using containers so impactful?

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

#130
post #108

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…

agree: I compiled a list of supporting facts and dissenting opinions here https://dx.tips/the-end-of-localhost this is of course extremely hated on HN, which understandably loves independence and self reliance.

Speaking as a person who does have a strong gut reaction against cloud development, I think a lot of the justifications like 'what if I'm on a train' do mask a real desire to say it just feels bad. Public reason.

Is it logically consistent with other things I don't own? Like Chrome, within which all my apps run?

No. But is there something that feels right about having all my code running on the CPU on my lap? Unaccountably, yes.

Post reply on HN