Hacker News new | past | comments | ask | show | jobs | submit | yeck's comments login

Nix package manager's `nix-shell` is something I wish more people knew about. Nix is gaining some popularity, but people often think of using it has to be a really big commitment, like changing your Linux distro to NixOS or replacing your dotfiles with a Nix-based one (using the Nix package manager).

What I wish more people knew was that you don't need to do those things to get value from Nix. Create project specific dev shells that install the packages (at the correct versions) to work with that project can almost replace 90% of the docs for getting setup to work on a project.


Have you tried compiling software with a nix shell? It gets linked to the Nix store. Needless to say it was a frustrating revelation.


The missing link for me is nix-copy-closure, which I learned about from a post by mitchellh: https://mitchellh.com/writing/nix-with-dockerfiles

conceptually a game changer for me. In practice it's far from a silver bullet (because every language prefers its own package management so you still have to manage those), but when it works it's quite magical.


You can patchelf to link to the host system libraries instead, or some projects can statically compile (inc musl) with less drama than usual, since your cross compilation toolchain can be part of your nix-shell.


Isn't this what you want? You are reliably linking to the specific dynamic libraries you are compiling against.

Or was the issue that you expected them to be portable? Or use commonly known dynamic library locations?


It was just surprising, is all. When I use use <x> application from a nix shell, it pretty much always works the way I think. The compiler experience was very jarring, but yes I understand why it works the way it does.

I was more or less pointing out the UX issues with Nix that end up turning many people away.


There is definitely a learning investment in order to write good Nix expressions. But, if you write a good nix shell expression for your project, other devs should be able to jump in without really needing to understand those Nix expressions and still get a working environment.


Sometimes it matters, many times not.

For example I tried to run pip install yesterday on MemGPT on Nix.

It failed with a C++ error because they use miniconda.

I just created a nix shell with python, pip, etc and ran the pip install command.

Things work fine.


Oh God miniconda is a horrible piece of software on Nix.

I fell down the Nix rabbit hole, and miniconda was one of the worst things to get working. My first pass used an FHS environment, but eventually I just got the environment.yml file working in micromamba and used that instead. Except micromamba ships it's own linker that I had to override with SHAREDLD, or some random python c++ dependencies wouldn't compile correctly.

I love Nix, but my list of complaints is a mile long. If you want to do anything with opengl in nix, but not on nixos, just give up. NixGl just doesn't really work.

Good luck getting something like Poky (Reference project for Yocto) running in Nix. The only working example puts it in an FHS environment, which uses bubble wrap under the hood. But then because you're in a container with permissions dropped, you can't use a vm. The solution I see in the support forums is roll your own alternative FHS environment based on something else.

/Rant


Yes, this is where I am at. Used it for over a year in a DevOps role and have developed a huge distaste for it. Despite the language itself being one of the most complained about things, I didn't mind it so much. It was the mile-long stack traces, which were often wrong, and constantly fiddling with things I didn't want to fiddle with to get something working. Just ended up costing me way too much time.


Although I haven't really used it, jetpack.io's Devbox [0] is an abstraction over Nix for the usage you describe.

[0] https://www.jetpack.io/devbox


I've played around with it a little bit, but not enough to make any judgements on it. Something like devbox could be the sort of thing to make nix-shell accessible enough to see wider adoption.


Snap also has a way to open a shell inside the context of a snap package


It's good for a c or c++ project where libraries are very environment specific. But most modern languages have their own package/environment managers which makes Nix redundant.


Not really. I introduced it to our Python projects at work and it's been great. Partially because of poetry2nix, and partially because it makes it easy to include other stuff like a specific version of Redis for testing purposes. Everybody gets the exact same dev environment, reducing a ton of "works on my machine".


Presumably it also can fill the role of conda/mamba i.e. also managing C/C++ libraries in the same way in the nix environment, isolated from the system libraries?


Yep, it can lock down exact versions of those libraries as well, which is great for not mucking about with lib versions between even different Ubuntu versions, not to mention distros or macOS.


Except nix doesn't support Windows, which is best reason to use conda (having to support Windows).


virtualenv is the python way. For things like redis and other external web stuff, docker is the standard.


Sure, that works. Or I can have it all in a single shell.nix file that covers everything and is super simple to use. It's great for handing off to coworkers that don't usually use Python.


It's not simple. The nix programming language is like untyped ML. Most people aren't used to it and even if you are familiar with it it gets hella hard to read. Learning curve is huge.

One docker file and a poetry file works just as well. And is simpler. It's literally the same thing but using os primitives to manage the environment rather then shell tricks. Makes more sense to me to use a dedicated os primitive for the task it was designed to be used for.

Additionally docker-compose allows you to manage a constellation of environments simultaneously. This is nowhere near as straightforward with nix.

I love nix but being honest here. It's not definitively the best.

The biggest reason right now to avoid it is adoption. Most people won't know what to do with a shell.nix


> One docker file and a poetry file works just as well. And is simpler. It's literally the same thing but using os primitives to manage the environment rather then shell tricks. Makes more sense to me to use a dedicated os primitive for the task it was designed to be used for.

1) not just as well because docker is repeatable, not reproducible

2) not if you need GPU acceleration which is a headache in docker, but not Nix shells

> Additionally docker-compose allows you to manage a constellation of environments simultaneously. This is nowhere near as straightforward with nix.

- devenv.sh - arion - https://flakular.in/intro

> Most people won't know what to do with a shell.nix

The same was once true for Dockerfile


>1) not just as well because docker is repeatable, not reproducible

Not sure what you're saying here but most likely you're referring to some obscure pedantic difference. Effectively speaking docker and nix shell achieve similar objectives.

>2) not if you need GPU acceleration which is a headache in docker, but not Nix shells

This is true. But this is the only clear benefit I see.

>- devenv.sh - arion - https://flakular.in/intro

right. So? I said nowhere near as straightforward. This isn't straightforward. It's an obscure solution.

>The same was once true for Dockerfile

False. DockerFiles are much more intuitive because it's just a declarative config. With Nix shell it's mostly people who like haskell or OCaml who are into that style of syntax. I like it but clearly that syntax has not caught on for years and years and years. Quite likely Nix will never catch on to that level too.


I assume what they're getting at is that when you download a Docker image it'll always be the same (repeatable), but the image which is built from a Dockerfile may change even if the file does not (not reproducible).


Yes, exactly.


https://martinfowler.com/bliki/ReproducibleBuild.html and https://wiki.debian.org/ReproducibleBuilds and https://reproducible-builds.org/ says just because something is "repeatable", doesn't mean it is "reproducible".


byte for byte builds? I knew it was some pedantic thing. I'm sorry if some timestamp changes one byte of the build.


No, the biggest issue is you rebuild an image that has apt-update and 20 dependencies break.


>It's not simple.

Neither is using virtualenvs for Python packages with native extensions.


Yeah I know. I'm saying the nix language is not simple. With docker you don't need virtual envs.


nix is far simpler for consumption. My coworkers don't like fancy new things, and they haven't had any complaints. They don't have to dick around with half a dozen different commands to get everything set up, or bother with docker volumes/port mapping/etc. They just run nix-shell and it all works. That's all you have to do with a shell.nix file, it's very simple.

It is harder to write on average atm, but it's very much worth it to me when it comes to sharing code for development. Also, LLMs help quite a bit when writing nix.


It's the same thing for Docker. Just one command. The nix is much harder to deal with mainly because shell.nix is harder to read and write then a Docker file.

Additionally nix uses shell hacks to get everything working. Docker uses an os primitive DESIGNED for this very use case.

And additionally, because docker uses os primitives you can use docker-compose to manage multiple processes on multiple different environments simultaneously. Something that's much harder to do with nix shell.


You're seriously overestimating how hard this is, especially with poetry2nix. I like docker just fine and have used it in a development workflow and it's a pain in the ass and should never be used for that. It's great for packaging stuff up for prod, though.

Also, one man's "DESIGNED" is another man's hacks. I don't see anything wrong with how nix works. Potato/potato, I guess.


I'm not overestimating anything. it's not hard once the shell.nix is there, but everything to get to that point is waaay harder than docker. In the end once you're done you have two ways of doing the same thing with one command.

I think I know what you're getting at. nix-shell provides a fast way to get access to that specific shell environment which is a bit more annoying to do with docker. All docker needs to do is provide this interface by default and the only surface level differences between the two techniques is really just the configuration.

>Also, one man's "DESIGNED" is another man's hacks. I don't see anything wrong with how nix works. Potato/potato, I guess.

By any colloquial usage of the term "designed" in this context by any unbiased party, it's obvious Nix is more hacky by any charitable interpretation. NixOS is a layer on top of linux, containers are a linux feature. Thus creating a layer on top of linux to use existing features is the more hacky less elegant solution.

It can actually go in the other direction. Rather then use shell tricks Nix can also use containers under the hood. Overall though the API for docker is superior in terms of editing config files but not switching shells. Additionally the underlying implementation for docker is also superior.

Your main problem is with the API which is just opinionated.


Most language package/environment managers do not come close to giving you the guarantees that Nix does.


Two problems:

a) Unless you literally write everything in one language, you will have to deal with learning, supporting and fixing bugs in N different package/environment managers instead of just one.

b) If you have a project that uses several languages (say, a Python webapp with C++ extensions and frontend templates in Typescript), then Nix is the only solution that will integrate this mess under one umbrella.


a. Using nix in place of a package manager means dealing with libraries specific to that language. It's still managing different apis. And more potential for bugs and unforeseen problems in custom 3rd party APIs as opposed to the official one. Admit it, you hit tons of problems getting everything to work fine with python.

b. C++ is the only one that would benefit from nix here because C++ dependencies are usually installed externally. There's no folder with all the external sources in the project. Even so this can be achieved with docker. If you want you can have docker call some other scripting language to install everything if you want "one language" which is essentially what you're doing with nix.


a. you hit tons of problems getting everything to work fine with python - of course, but the maintenance burden is an order of magnitude lower than integrating all this manually.

b. No, docker is not a solution. Docker is another problem and a separate maintenance nightmare.

(Nix solves maintenance problems at scale, Docker explodes them exponentially. I would not ever recommend using Docker for anything except personal computing devices you don't care about.)


I agree.

There are many python packages that have other dependencies not managed by Python package management. The pain of figuring out what those implicit dependencies are is effectively removed for users when configured as a nix shell.


I had to use it for a c++ project and it was one of the biggest waste of time and frustrating moments of my computing career, there were constant breakages due to glibc mismatches, Nvidia drivers and whatnot, and getting an host IDE to have semantic understanding of the paths , etc... necessary for normal completions and stuff was nigh impossible.


Yeah but other than conan it's one of the few things where you can get a sort of "project package manager" experience like npm with C++. It's not nearly as user friendly as what they have for python or nodejs.


No way. Language specific managers are terrible at managing external dependencies. Trying to get python packages to link to system libraries is terrible. Nix makes it infinitely better.


I was using Nim for some of last years Advent of Code problems. I was mostly liking the syntax. Was a bit bother by the standard library have a snake case and camel case reference for each function (if I'm remember that correctly).

At the time nimble also required me to have NPM to install the the Nim package manager, Nimble. This was not ideal, but looking at [the nimble project install docs](https://github.com/nim-lang/nimble#installation) it seems like it is now package with the language.

Might try dusting it off for some AoC puzzles this year :)


I believe the whole language is "style insensitive" for variable names. So it's not just a feature of the stdlib.


Are you serious?


Yes. It’s so you can maintain a consistent style in your code base even if your dependencies use different styles. Nim has excellent C/C++ interop and it’s relatively common to interact with C or C++ symbols directly, and being able to do this without needing to adopt the dependency’s style or wrap everything is nice.

In python, for historical reasons the logging module uses camelCase while most other modules use snake_case, so it isn’t really possible to use the logging module and maintain a consistent style. This is a non-issue in Nim.


The downsides of this approach are unfortunately that it makes wrapping certain low-level libraries an absolute pain in the ass (especially anything to do with keyboards). But overall it's a non-issue, tooling recognizes both styles and you don't notice it.


Nim 2.0 changed the default to treating style mismatches as warnings.

E.g. it's something to check but not an error. You can easily set a config to make them an error or ignore them.


Cool, that definitely sounds like a welcome improvement.


There's also `atlas` that was released with Nim 2.0.

http://nim-lang.github.io/Nim/atlas.html


It seems hard to imagine a board member that is involved in another tech business not having a conceivable conflict of interests. LLMs are on a course to disrupt pretty much all forms of knowledge work after all. Also big implications for hardware manufacturing and supply chains.


> Separately, a person familiar with the matter told The Verge that the board never received a letter about such a breakthrough and that the company’s research progress didn’t play a role in Altman’s sudden firing.

This isn't a refute. All we can say now is that there are conflicting sources. There isn't a way to determine which one is correct based on this.


So we have sources claiming there is a letter, and another source claiming there is not. Feel like some people would need to start going on the record before anything might reasonably be determined from this.


This could just be a damage control attempt. Irrespective of whether the original report is true, the extra attention at the current stage is not very desirable.


Maybe we should have learned during the Trump years that the media puts no effort into vetting "anonymous sources" or is outright making them up to push lies.


And honestly normally I'd trust Reuters above The Verge.

But in either case, I think Reuters absolutely had someone on the inside to leak this. They have made mistakes in the past, sure, but they are also not a tabloid and they don't innovate.

To me, a sensible conclusion of this is simply that OpenAI is not ready or willing to discuss this. Stuff that are supposed to be kept internal but due to the emotional state over at OpenAI, things might have leaked, potentially even out of spite.


Where do you see it being rolled back?


If they actually have AGI, then being at the helm of could represent more power than any amount of money could. Money just gives you access to human labour, which would suddenly be massively devalued for those with access to AGI.


Sam even recently alluded to something that could have been a reference to this. "Witnessing he veil of ignorance being pulled back" or something like that.


Depends who gets onto the board. There are probably a lot of forces interested in ousting him now, so he'd need to do an amazing job vetting the new board members.

My guess is that he has less than a year, based on the my assumption that there will be constant pressure placed on the board to oust him.


He has his network and technical credibility, so I wouldn't underestimate him. Board composition remains hard to predict now.


What surprises me is how much regard the valley has for this guy. Doesn’t Quora suck terribly? I’m for sure its target demographic and I cannot for the life of me pull value from it. I have tried!


His claim to fame comes from scaling FB. Quora shows he has questionable product nous, but nobody questions his technical chops.


Quora is an embarrassment and died years ago when marketers took it over


I was about to say this. Only correct answer.


I don't see how - isn't he pretty against the commercialisation efforts[0]?

[0] https://www.bbc.co.uk/news/technology-65110030


Gollum wasn't a fan of anyone but him having the One Ring. Analogy doesn't not fit.


Elon was once "in possession" (influential investor and part of the board) of OpenAI, but it was since taken from him and he is evidently bitter about it.


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: