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

101–110 of 196 posts

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

#101

Post by gaocegege »

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…

Remote development will be popular? Yes.

But developing in a monolithic machine may be not. The development environment should be clean and isolated, and products like gitpod and coder is promising.

Besides this, maybe you can have a look at https://github.com/tensorchord/envd and https://github.com/okteto/okteto

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

#102

Post by x0rg »

pxc wrote: post #93
x0rg wrote: post #85

This is shelling out to nix-shell ( https://github.com/jetpack-io/devbox/blob/97c19c370287e203bb... ) which means that it will only support bash AFAIK. I've seen a lot of discussions around using nix-shell for dev environments, but read somewhere that is not really made for this purpose originally, rather for just building packages, bash being only one of the limitations. I tried to experiment myself with nix-shell,…

Even with old `nix-shell`, you could always use `nix-shell ... --command fish` or whatever it is to launch a different shell. Historically other `nix-shell` wrappers, like `direnv`' Nix integration, have also supported non-bash shells well. > [I] read somewhere that [nix-shell]'s not really made for this purpose originally, rather for just building packages, bash being only one of the limitations. Yeah, nix-shell was…

This all makes sense to me, thanks for the comment. I am aware of the --command option, but I didn't manage to do everything I wanted with it, but honestly that was a while ago. I was discouraged by people telling me that this wasn't the "right way" because tons of things in nix-shell assume bash, but honestly I don't know the details and I should try again.

> But the purpose of shells like this isn't to protect you from running `rm -rf /`, if that's what you're after. It doesn't protect you from dogecoin miners in your `npm install` hooks, if you're just using Nix to provide `nodejs` and then running `npm install` as usual.

This is absolutely fair. I was mostly saying what I wish I could have: isolation (as in can't write outside of the current directory) together with the ease of getting packaged without installing them that nix-shell provides, without the overhead of docker or a vm. I don't think it's impossible to build although I appreciate that it may be out of scope for this particular project.

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

#103

Post by pmontra »

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.

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

#104

Post by xvector »

minitech wrote: post #52
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…

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

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

#105

Post by legulere »

xvector wrote: post #104
minitech wrote: post #52

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.

But we already have notebooks with battery life for 2 work days which have very good performance like the M2 macbook air. And I highly doubt that it's the cpu that is the limiting factor for battery life and not the screen.

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

#106

Post by kkkrist »

x0rg wrote: post #85

This is shelling out to nix-shell ( https://github.com/jetpack-io/devbox/blob/97c19c370287e203bb... ) which means that it will only support bash AFAIK. I've seen a lot of discussions around using nix-shell for dev environments, but read somewhere that is not really made for this purpose originally, rather for just building packages, bash being only one of the limitations. I tried to experiment myself with nix-shell,…

This. One of the reasons I use docker dev environments is to keep all my sensitive stuff separate from dangerous bugs and malicious external packages/modules in my projects.

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

#108

Post by swyx »

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…

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.

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

#109

Post by kreetx »

TekMol wrote: 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.

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

#110

Post by myuzio »

setheron wrote: post #76

Love the idea and we are all thinking Nix needs the Docker treatment. I believe though that something has restart from scratch rather than rely on Nix. Nix ushered the idea but needs a new face. Building on top of it may be too problematic long term.

My first thought was this is exactly what I'm looking for, ah it needs installing Nix package manager on my Mac, I'll pass for now.
Post reply on HN