Live data from Hacker News

Show HN: Devbox – Easy, predictable shells and containers

github.com

191–196 of 196 posts

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

#191
After trying to find out how this works I am not the wiser.

How does this guarantee consistency across Docker, Kubernetes and the local environment?

How are base images selected? Where do the packages come from? Are the packages all Alpine/x86_64 or from Nix directly? Who builds them? Who signs them? Who deploys them?

Following the demo makes this seem more unlikely to be made with reproducable builds in mind, because it shows go's version to be darwin on the host system, which probably isn't going to be used on Docker!?

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

#192

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…

This. Put another way: it's slow only because you're on macOS and not on Linux.

That's why Linux needs more love.

I find it sad that many people use Docker, but the majority of them run Linux in a VM inside an expensive proprietary platform to do so, sometimes without even realizing it.

Meanwhile, the Linux desktop ecosystem is deteriorating and should be used more and receive more financial support.

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

#193
post #129

Earlier quoted context omitted.

> 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?

Docker on Mac and Windows runs in a VM, not natively.

3x slower is not regular VM overhead range.

Using the dodgy file share volume mounting, maybe for particular file access patterns.

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

#194

Earlier quoted context omitted.

> 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 Why is this desirable?

Lightweight terminals with days of battery life while a juggernaut handles the real work.

[deleted]

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

#195

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…

Working in a remote forest is actually pretty pleasant. Offline matters.

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

#196
post #160

Earlier quoted context omitted.

I think this attempt at clarification is just proving xvector’s point.

It's not an attempt at clarification. It's best if you start with the problem you're trying to solve, then work backwards towards a solution. "Nix" isn't really a thing, no more than "Linux" is. It's a collection of tools and languages and frameworks people use to solve various very different problems.

See, this is why I would like to use a wrapper.
Post reply on HN