Live data from Hacker News

Show HN: Devbox – Easy, predictable shells and containers

github.com

181–190 of 196 posts

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

#181

Earlier quoted context omitted.

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.

not to mention, horsepower is hardly ever the choke these days. I would say that the greatest limiting factor here is the lack of screen space, because now your dev must context switch to read documentation etc

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

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

there are more reasons that this take is bunkum than that article seems to be aware of.

- security. the most common vector of attack is through dev boxes. centralizing creates a single point of failure.

- vendor capture. right now, it's cheap to "do a dev". if you put everything in the cloud, the FAANG that be can start charging rent.

- vscode or (insert cloud IDE here) might work great for some, but my local emacs is better. fight me.

- the longer the distance between your devs and the metal, the dumber they get. you learn best by working with visibility into what your code is doing. many of the efficiencies mentioned will lead to educational drift, which is bad.

- connection speed. he gets real hand wavy about "developing on a plane" but even developing on a satellite connection makes latency-dependant tasks super slow. try running Ansible from your star link and get back at me.

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

#183
post #43

I think we’ve all been wanting something along those lines for a while. I hope this is it. Docker is only lightweight in Linux.

I paid the ~cost of learning Nix mainly to get out of needing VMs for daily dev work on macOS. I won't sugar-coat those costs, but I'm glad I did.

I keep thinking of rolling a simpler solution with chroot + something something, but if someone is able to hide the complexity of Nix well enough, sign me up. Those abstractions tend to be leaky though.

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

#184
post #127

Earlier quoted context omitted.

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)

This looks great. As someone who started learning Nix in the last few weeks this is definitely needed and will prove invaluable to future learners. I'm still completely lost on a lot of things but if I work something out that isn't covered on your site I'll try and put together a PR for it.

That’d be great!

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

#185
post #110

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.

I agree (although I use Linux, not macOS). I tried to use nixpkgs in an existing Slackware installation and... it worked but has a bunch of warts, especially GUI applications don't respect my desktop settings

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

#187
post #160

Earlier quoted context omitted.

I think you're confusing Nix, nixpkgs and NixOs. (Also Nix and Nix-flakes are two different things, like Javascript and React.)

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.

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

#190

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…

I’m sat in a plane right now and am able to code with a high latency, low bandwidth internet link without issue. If I were using something from this dystopian vision of yours I’d not be able to do that. It doesn’t matter how much “courage” may be involved, frankly.
Post reply on HN