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

81–90 of 196 posts

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

#81

Post by [deleted] »

maxbond wrote: post #65
maxbond wrote: post #57

Earlier quoted context omitted.

That sounds like a problem that can be solved with a CI/CD system and Docker Compose. Perhaps there is more going on here institutionally that stops this problem from being solved. It sounds like something really frustrating is going on though, and I hope it works out.

Hey I'd like to expand on this a little bit. I hope I'm not presuming too much but as someone who recently had to leave their job due to burnout, I feel like I'm seeing signs of burnout here, and wanted to bring them to your attention. You sound really frustrated because you're being asked to do things that you feel aren't or shouldn't be part of your job, and perhaps it's taking time from your other responsibilities…

[deleted]

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

#82

Post by bigtunacan »

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…

It's unpopular because it's a terrible idea. Just because it's easy ssh'ing into the box, doesn't mean you should. Twenty years ago we didn't have the tools to do anything better. And while I miss some of the simplicity of those times I don't miss when someone ssh'ed into the server and fucked something up and left us in a lurch. If you really think this is the best approach today I really hope you aren't working on any critical systems.

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

#83

Post by [deleted] »

maxbond wrote: post #57
throwaway892238 wrote: post #54

Earlier quoted context omitted.

I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environment…

That sounds like a problem that can be solved with a CI/CD system and Docker Compose. Perhaps there is more going on here institutionally that stops this problem from being solved. It sounds like something really frustrating is going on though, and I hope it works out.

[deleted]

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

#84

Post by zufallsheld »

We use something similar at our company, although maybe with not such a nice UX: https://github.com/T-Systems-MMS/docker-management-container

This installs certain tools like helm, terraform or kubectl in the specified version as well as python dependencies or ansible roles and collections in a container to use on your laptop or in cicd-pipelines.

Another nice addition for this is https://github.com/upciti/wakemeops, that provides apt-repository for many tools from the Cloud landscape.

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

#85

Post by x0rg »

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, but I think it doesn't provide separation on the machine on which you run, it's not a chroot nor a docker container. If you are interested in some level of separation to make sure that a dev environment is "safe" to run on your machine without making side effects to things external to the project, then I'm not sure nix-shell would be able to help, but I would be happy to learn there is an option to do otherwise.

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

#86

Post by pxc »

mrich wrote: post #42
xvector wrote: 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…

When there are issues with debugging breakages of such environments, will a wrapper be sufficient? Does devbox have extra handling for such scenarios?

The opacity of Nix errors is largely (entirely?) constrained to the module systems (notably NixOS, Nix-Darwin, and Home Manager). (This is unfortunate, because these are actually some of the best parts of the Nix ecosystem.)

The issue is essentially that configuration options all get merged into a global namespace, but there are no facilities to track where they came from. So when configuration mismatches of certain kinds occur, you get an error in some library code that's trying to merge or coerce two incompatible values, and nothing pointing you to the two places where the conflicting values are originally set.

(This kind of error, the most common mostly-useless error message, is typically easily debugged by searching for the relevant options in your configuration and in the source code of that collection of modules. But that is still backwards and a chore, and deserves a real solution.)

Anyway, the package definitions and builds in Nixpkgs don't use any such module system in any way. So this tool is not wrapping the functionality that is associated with opaque error messages. :)

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

#87

Post by zie »

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,…

Nix can build Docker containers, VM's, ISO images, etc.

I build ISO's from nix all the time to run special compute nodes. The machines boot from the ISO, so every boot they get the same, sane environment.

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

#88

Post by x0rg »

zie wrote: post #87
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,…

Nix can build Docker containers, VM's, ISO images, etc. I build ISO's from nix all the time to run special compute nodes. The machines boot from the ISO, so every boot they get the same, sane environment.

Yeah I know, my whole comment was about nix-shell and about this project posted here, not generally on nix.

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

#89

Post by pmontra »

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…

That is how I and everybody else were developing software at my university around 1990. A few HP servers, character terminals or X11 servers. Then everybody got a Windows desktop at home powerful enough to work as on those X servers and it was game over.

I never saw a company developing on a shared server. Do you work for one doing that?

In that environment I expect developers to need separate environments not to stop all the team in case of mistakes. Let's say: docker containers running on the server instead of pulling an image locally. I don't see much of a gain.

Personally I could use my emacs to edit files of the server, my terminal to ssh on the server and my browser getting pages from there. For people using IDEs, those IDEs should either work in a different way or be in a remote connection (RDP, VNC, X11.) I remember Citrix thin terminals but I don't remember developers using them. They were for end users.

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

#90

Post by ithrow »

bigtunacan wrote: post #82
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…

It's unpopular because it's a terrible idea. Just because it's easy ssh'ing into the box, doesn't mean you should. Twenty years ago we didn't have the tools to do anything better. And while I miss some of the simplicity of those times I don't miss when someone ssh'ed into the server and fucked something up and left us in a lurch. If you really think this is the best approach today I really hope you aren't working on…

It's for dev systems not production.
Post reply on HN