Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Flox 1.0 – Open-source dev env as code with Nix

github.com

Post reply on HN
Print view View original

161–170 of 201 posts

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#161

Post by jahsome »

bitvoid wrote: post #160
jahsome wrote: post #152

Earlier quoted context omitted.

The line suggests the opposite yes. That's why I take issue with it. There's nothing easy about nix. Maybe flox makes it easier, but I am so burned out by screwing around for countless hours with nix I'm not even going to try to figure out if it's true.

I'm confused here. That quote clearly says that Flox makes Nix easier for newcomers, not that Nix is easy. What exactly do you take issue with?

The fact that my experience with nix has historically been _so_ difficult, I fear even something that claims to make it "easier" will not be able to deliver -- my aversion has everything to do with nix, and little do with any product which claims to improve it. Consider it guilt by association.

For me, it doesn't simply need to be easier, it needs to be usable. I lack confidence a product which is an abstraction layer is going to solve that for me, because I have a personal inability to understand the underlying system.

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#162

Post by sandGorgon »

ivan_burazin wrote: post #79
sandGorgon wrote: post #26

https://news.ycombinator.com/item?id=39616709 a few days back daytona was also released. any thoughts on how it differs ?

Happy to take this one, as I am one of the cofounder of Daytona. Daytona solves all the automation and provisioning of the dev environment, actually wrote an article here laying out exactly what we do: https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m... Daytona currently supports only the dev container ( https://containers.dev/ ) "dev env infrastructure as code" standard, but are looking to support others…

ahh interesting - so there's a split on the dev format. why did you choose dev containers vs nix ? genuine question - asking because replit makes a big deal of nix, so it seemed to me as a very popular choice.

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#163

Post by emptysongglass »

jahsome wrote: post #161
bitvoid wrote: post #160

Earlier quoted context omitted.

I'm confused here. That quote clearly says that Flox makes Nix easier for newcomers, not that Nix is easy. What exactly do you take issue with?

The fact that my experience with nix has historically been _so_ difficult, I fear even something that claims to make it "easier" will not be able to deliver -- my aversion has everything to do with nix, and little do with any product which claims to improve it. Consider it guilt by association. For me, it doesn't simply need to be easier, it needs to be usable. I lack confidence a product which is an abstraction laye…

Maybe you need to try it out rather than casting doubts about a product you haven't tried yet? Pre-emptively doubting claims based on your past experience with a tool Flox claims to solve seems like a poor way to go here.

For what it's worth, there are a number of options in the Nix space that really do solve for its complexity like Devbox and now Flox.

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#164

Post by anonzzzies »

soraminazuki wrote: post #113
anonzzzies wrote: post #8

Earlier quoted context omitted.

Ah! The modern hell of choice. Can’t these peeps just work together and make one great thing instead of fragmenting over and over? I think I know the answers but have to ask anyway, hope to learn.

That’s equivalent to demanding the Python community to abolish PyPI in favor of making the “one great” standard library. Nix is a language after all. It’s meant to have tools that build on it.

Well, I wonder about all language communities why they don’t coordinate efforts indeed. I see monthly arrivals of new ‘js runtimes’ and package managers as well. And that eco system is a lot larger than nix. If these talented people would band together, wouldn’t we get a better endresult as a whole? If it’s commercial products then that doesn’t work, but this is all nice open source under good licenses, so outside ego, what’s the benefit of 50000 things that do the same thing except 499XX*n hours of life wasted?

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#166

Post by Qwertious »

amarshall wrote: post #139
ildjarn wrote: post #124

Last I tried to use Nix there was lots of confusion over flakes - some tutorials suggested using them and others saying they are still in development. Has the situation improved?

I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else. There are certain scenarios where the performance can be problematic, but there are workarounds and permanent solutions are being worked on. Nevertheless, using flakes extensively at home and work.

>I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.

"Experimental" traditionally means "if you use it and it breaks, then that's your fault". This is because if did break, the entire internet would dogpile on any complainers with "IT WAS LABELLED EXPERIMENTAL WHAT WERE YOU EXPECTING."

It's the same as ignoring Kickstarter warnings; if a project gives you a warning then tell you to ignore that same warning, don't; if things go to shit then everyone will say "YOU WERE WARNED WHAT WERE YOU EXPECTING." They cannot un-warn you, that's not how this social situation works. I'm not claiming this is fair, I'm just claiming this is how it plays out in practice.

The only safe response to this is to assume that anything labelled "experimental" is exactly what it says. And to be clear, that means the only safe response is to ignore any claims that the thing labelled "experimental" is safe.

Or to put it another way: if you don't mean it's experimental and do recommend it to the average user, then don't use the term "experimental".

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#167

Post by nkko »

sandGorgon wrote: post #162
ivan_burazin wrote: post #79

Earlier quoted context omitted.

Happy to take this one, as I am one of the cofounder of Daytona. Daytona solves all the automation and provisioning of the dev environment, actually wrote an article here laying out exactly what we do: https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m... Daytona currently supports only the dev container ( https://containers.dev/ ) "dev env infrastructure as code" standard, but are looking to support others…

ahh interesting - so there's a split on the dev format. why did you choose dev containers vs nix ? genuine question - asking because replit makes a big deal of nix, so it seemed to me as a very popular choice.

Dev containers provide a robust standard that is seamlessly integrated into VS Code, which makes workflow smooth end-to-end. Thanks to the Daytona plugin architecture and Apache license, it is relatively easy to bring in more standards. Cause, you know: https://xkcd.com/927/

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#168

Post by OJFord »

aidenn0 wrote: post #92
xyzzy_plugh wrote: post #60

Earlier quoted context omitted.

As opposed to Docker, or Bazel? Conversely I have never had this problem with Nix. It tells you plainly how to clean up garbage. It's easy to interrogate to find out what's hanging around, and why. The reason it's not on by default is that, like any garbage collector, it can be disruptive -- there is no "one size fits all" policy. Ultimately if you have too many gc roots you have to make some decisions.

The problem (especially pre-flakes) with nix (and Docker too; haven't used Bazel) is that if you GC, you can't recreate your previous environment (which version of nixpkgs were you using when you built it/which day did you run apt-get update in your Dockerfile). It appears that Flox uses flakes and versions the flake.lock file, so it should be possible to readily reproduce anything that hasn't completely disappeared…

Can't you just pin pkgs to particular commit, so everything will have the version it did as of that commit?

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#169

Post by elbear »

IshKebab wrote: post #88
ronef wrote: post #20

Earlier quoted context omitted.

Appreciate the call out. Regarding pricing, bringing forward what you saw today for free and open source, was a major part of why I started Flox, with much more to come into it. What we released today will be free forever (both the open source client and the FloxHub services for sharing environments). We plan on expanding the offering to include a more robust private software catalogs that layers on top of the OOTB F…

Good luck! My experience of Nix, and similar "robust engineering" solutions like Bazel is that there are a handful of people that get it, and see the benefits. But there are hoards more that think you should just write hacky shell scripts and bugs don't really matter anyway.

There are also the people who get it and see the benefits, but don't want to put up with the work required to have your system or environment managed with Nix. If this tool simplifies things, it could get traction.

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#170

Post by ivan_burazin »

sandGorgon wrote: post #162
ivan_burazin wrote: post #79

Earlier quoted context omitted.

Happy to take this one, as I am one of the cofounder of Daytona. Daytona solves all the automation and provisioning of the dev environment, actually wrote an article here laying out exactly what we do: https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m... Daytona currently supports only the dev container ( https://containers.dev/ ) "dev env infrastructure as code" standard, but are looking to support others…

ahh interesting - so there's a split on the dev format. why did you choose dev containers vs nix ? genuine question - asking because replit makes a big deal of nix, so it seemed to me as a very popular choice.

You only have so many things you can do at once.

From our perspective dev container seemed to be what our target audience was already using; as its supported by VS code natively and also as almost all OSS projects are hosted on Github, and their product Codespaces support it as well - it seemed like the logical first standard.

But as mentioned devfile, nix and flox are on the roadmap.

Post reply on HN