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

Will Nix Overtake Docker?

blog.replit.com

Post reply on HN
Print view View original

241–250 of 259 posts

Re: Will Nix Overtake Docker?

#241

Post by rgoulter »

carlmr wrote: post #192
eitland wrote: post #122

Earlier quoted context omitted.

> It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the c…

Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.

I found this website useful for helping me understand what was going on with git. https://learngitbranching.js.org/

GUI vs CLI shouldn't be about which is a less confusing way of using git.

(Though, yes, magit is excellent, and there are very few tools which come close).

Re: Will Nix Overtake Docker?

#242

Post by kaladin-jasnah »

pxc wrote: post #240
kaladin-jasnah wrote: post #239

Earlier quoted context omitted.

I truly hope not as well. I spent an extensive period of time trying to learn Nix and integrate it into my homelab. Granted, it's not an enterprise environment, but it is the most painful, unstable, broken, buggy, bloated, hard-to-use, poorly-documented mess I've ever tried. I hope no one touches Nix with a ten-foot pole. That's not to say it's not a great idea. It's just a huge pain to get to work, and the cost of t…

> did I mention the interpreter took forever and sometimes failed on errors in files that had NOTHING to do with yours, leaving you to manually debug each line? This is a common (and horrible) issue with dynamic languages that pass functions or blocks of code around. There have been some major improvements to Nix error messages which were included in the last release, and there's also ongoing work to address this thr…

> There have been some major improvements to Nix error messages which were included in the last release

That's good to hear (and I think I heard about it before). The problem is, there are still lingering issues with Nix, like how long it takes to figure out how to compile a new program, (exceptionally) poor documentation, packages being unmaintained, the nixpkgs repository being a gigantic blackhole that takes forever to eval, etc.

Don't get me wrong. I really like the idea behind Nix. Even with this fix though, I'm still not sure I would enjoy using Nix (since many, many other problems) or giving it another shot because of my emotional response to it that's been caused by burnout trying to wrangle with it.

Re: Will Nix Overtake Docker?

#243

Post by throwaway894345 »

vineyardmike wrote: post #221
throwaway894345 wrote: post #76

Earlier quoted context omitted.

This mirrors my experience as a developer in an org that used Nix. If you want the dev team to have a strong dependency on the devops team for every little (often unpredictable) aspect of their workflow, Nix is the tool for the job. Don’t get me wrong, I’m completely bought in on the vision of reproducible builds but there’s a long ways to go before it’s usable in real organizations. I’ve heard that some orgs manage…

Many orgs get reproducible builds by using different build tools and abstractions. Eg Amazon gets it via their Brazil tool.

I was talking about Nix in particular, but yes, if you’re an enormous and highly lucrative tech company you can pay a team of engineers to build your own reproducible build tool. If the same team is very talented they can probably even get Bazel working. ;) But I don’t think any large orgs at all use Nix, presumably because it doesn’t scale beyond a small number of (enthusiastic) developers.

Re: Will Nix Overtake Docker?

#244

Post by peanball »

carlmr wrote: post #192
eitland wrote: post #122

Earlier quoted context omitted.

> It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the c…

Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.

Fork, hands down. https://fork.dev

Re: Will Nix Overtake Docker?

#245

Post by pxc »

kaladin-jasnah wrote: post #242
pxc wrote: post #240

Earlier quoted context omitted.

> did I mention the interpreter took forever and sometimes failed on errors in files that had NOTHING to do with yours, leaving you to manually debug each line? This is a common (and horrible) issue with dynamic languages that pass functions or blocks of code around. There have been some major improvements to Nix error messages which were included in the last release, and there's also ongoing work to address this thr…

> There have been some major improvements to Nix error messages which were included in the last release That's good to hear (and I think I heard about it before). The problem is, there are still lingering issues with Nix, like how long it takes to figure out how to compile a new program, (exceptionally) poor documentation, packages being unmaintained, the nixpkgs repository being a gigantic blackhole that takes forev…

> I'm still not sure I would enjoy using Nix (since many, many other problems) or giving it another shot because of my emotional response to it that's been caused by burnout trying to wrangle with it.

I'm not sure you would, either, and I won't ask you to give it another shot right now. I understand the feeling. Maybe it's something to revisit after more time than has already passed.

Re: Will Nix Overtake Docker?

#246

Post by lilyball »

bjtitus wrote: post #93
lilyball wrote: post #22

Earlier quoted context omitted.

I recommend also using direnv, with nix-direnv (home-manager has a setting to trivially enable nix-direnv). This lets you integrate your shell.nix environment into your existing shell without having to run `nix-shell` or use bash.

Oh wow, this is fantastic! Thanks for the tip and I'd like to thank you for all of the work you do on nix + Darwin. I'm using your `nix-env.fish` package and it's made things much easier than when I tried this setup a few years ago.

I'm glad to hear it! Though these days I don't actually use it at all, I finally switched to using nix-darwin[1] which means I get a NixOS-like fish initialization. Also prior to that I got the fish package updated with a new override option fishEnvPreInit that lets you write an overlay like

  self: super {
    fish = super.fish.override {
      fishEnvPreinit = sourceBash: sourceBash "${self.nix}/etc/profile.d/nix-daemon.sh";
    ];
  }
This would source the given bash script (using fenv IIRC) at the same point that NixOS fish would load its environment, thus producing the same behavior (notably, setting up all of the various directories prior to running any user code, unlike nix-env.fish that has to try and patch things up after the fact). The downside is that it means you have to recompile fish.

[1] https://github.com/LnL7/nix-darwin

Re: Will Nix Overtake Docker?

#247

Post by lproven »

KronisLV wrote: post #202
eximius wrote: post #106

Earlier quoted context omitted.

That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".

> That is extremely concerning, then, that it is so difficult to use after all that time. > I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years". I feel much the same way about wanting to run something like FreeBSD and having it just work, as opposed to running into weirdness because of the driver situation, with which GNU/Linux seems to be getting better at (even thou…

My suspicion is that the HURD folk seized on new shiny that was not finished enough, and it's dogged the project ever since. Periodically the already-inadequate number of people have got diverted by investigating L4, then CoyotOS, then Viengoos.

I also submit that to understand why that happened, one needs to consider the context at the time that the decision was made:

http://www.h-online.com/open/features/GNU-HURD-Altered-visio...

http://www.groklaw.net/article.php?story=20050727225542530

« RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today.

RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.

So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint.

This was all way before Linux; we're talking 1991 or so. » -- Friar Thomas Bushnell

They looked at BSD. The BSD people were not sure, so RMS decided on another path.

If GNU had picked the BSD kernel, there could have been a working Free xNix before Linux and things would have been very different.

Secondly, I think it's important when discussing microkernels and microkernel OSes to consider more than the most famous one: Mac OS X.

Xnu is based on Mach, but it's not a pure microkernel: its Xnu kernel contains a large, in-kernel "Unix server" derived from BSD code. This was done for performance reasons – remember, macOS is Mac OS X is NeXTstep, written for a 25MHz 68040 in around 1987-1988.

There are better examples. QNX is probably the best: a working, true-microkernel, Unix-like OS, dating from 1982. At one point shared-source but not any longer.

There is also Minix 3, which is a different OS from Minix 1 & 2, the OS that inspired Linux and upon which Linux was initially bootstrapped.

Minix 3 is still quite limited: no SMP, some missing APIs etc. But QNX proves that a true microkernel, on generic hardware such as x86 and ARM, can support SMP and so on.

Re: Will Nix Overtake Docker?

#248

Post by temptemptemp111 »

svenhy wrote: post #168
exdsq wrote: post #44

Earlier quoted context omitted.

Nix can do everything and that's an issue - suddenly the CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments, and more are all written in Nix packages. You need to write nix bindings. You need to add nix caching. And, as is fitting with a functional language, it can be beautifully (read: painfully) abstract. Some of the guys on the team were contributors to Ni…

No, Nix can't do everything, it can do the one thing it does, mainly it maintains immutable paths and allows to define derivations of any number of those paths using namespaced execution of build scripts. All this is controlled using expression in the Nix language, which is well suited for the intended purpose. It is in important aspect the opposite of Haskell. Nix does so well what it does, that it is easy to use it…

"CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments, and more are..." - Why can't any distro do this? They already do... People want to be lazy, but if they weren't they would stop adding more abstraction layers. Alpine (host & guest/container) + podman/docker + k8s/nomad + your custom software... Why the need for anything else? And each piece is replaceable in the event of failure/deprecation.

Re: Will Nix Overtake Docker?

#249

Post by dnautics »

mst wrote: post #160
dnautics wrote: post #94

Earlier quoted context omitted.

I really wish something like singularity containers had taken over -- that was literally just shell commands.

Possibly https://buildah.io/ would be of interest.

I do use podman, not really stoked about buildah because it's still a bunch of buildah commands in a shell-driven DSL, which I suppose is better than a dockerfile. Singularity was literally a build file that was a shell script divided into sections that denoted phases.
Post reply on HN