Get the top HN stories in your inbox every day.
throwaway894345
the_duke
I switched to NixOS about a year ago.
It's been amazing for me. Especially when combined with home-manager [1], which provides declarative user environments and flakes [2], which provide a even more declarative and more easily shareable package format.
Getting my exact setup on a new device - including lots of GUI and terminal app customization - takes a single `nixos-rebuild-switch`, and works every time. Everything is configured in a single config file, from hardware and system service setup, over window manager setup, all the way to installed Vim/VS Code/Chrome plugins and lots of application configs.
The ability to easily roll back to previous configurations and boot into old configs from the boot menu in case something breaks is also brilliant.
You can also just install and run pretty much all software on demand, similar to `npx`, without polluting the system. ( nix run some-app). Declarative, reproducible development environments for each project are the cherry on top.
That said, the onboarding experience is horrible. There are A LOT of things to learn, and the documentation is bad. I also agree that the language, while somewhat fine, is not great and very undiscoverable.
The Nix ecosystem is a diamond in the rough. Sadly it would take a lot of effort to simplify everything and make it more polished.
I'm afraid Nix will continue to remain very niche.
[1] https://github.com/nix-community/home-manager [2] https://nixos.wiki/wiki/Flakes
a9h74j
Low skill myself at installing Linux, but I found installing a Guix to disk relatively straightforward. Managed to easily add available builds. Apparently-good support for virtual machines as well.
throwaway894345
Even trying to get VS Code working with a couple of plugins (and the help of the good, experienced people on the Nix discord) was impossible (I was just using the package manager, not NixOS--apparently VS Code requires a different incantation depending on which platform you use, which is another problem.
> Sadly it would take a lot of effort to simplify everything and make it more polished.
Yes, and while it would take a lot of effort to make most things nicer (improving the language, etc), other things require effort that scales linearly with the number of packages in the universe. For example, making the package definitions in the first place, adding documentation for the packages, testing packages, etc. Other things are even worse: testing various combinations of dependencies at different versions.
> I'm afraid Nix will continue to remain very niche.
Unless it gets some serious corporate support, I'm afraid I'll agree. The Nix folks have done some impressive work, but I get the impression that they're more interested in making something cool for themselves and other like-minded people at the expense of others (and there's nothing wrong with that! it's just incompatible with growing out of a niche).
tinco
> Thanks for not going full-Haskell on us
It would have been so much better if they went full Haskell. Haskell is better designed as a language, it has types and could support all Nix features without modification as far as I can tell. On top of that it's a common language that most have used at least in university and has loads of friendly tutorials online.
Totally agree on the packaging of C/C++ projects is a drag of our entire industry and basically a complete embarrassment.
shepherdjerred
Haskell is a fantastic language, and it's becoming one of my favorites, but it is by no measure a friendly one. Nobody wants to have to learn a complex language for a task as essential as using their own computer.
Also, I think your claim that "most have used at least in university" is skewed to your experiences. I doubt the majority of programmers have any experience in Haskell whatsoever with even fewer having enough experience to be comfortable in it.
wyager
I don't really buy the "Haskell isn't friendly" thing - it's way more work and way less pleasant to become an expert in, say, C++, than to become an expert in Haskell.
It depends on what, precisely, you are measuring the difficulty of. Are you writing a quick script? A complex software project? Trying to master the language? Is it a beginner programmer? A narrowly focused coder who only knows one or two similar languages? An experienced programmer with a wide breadth of knowledge?
In pedagogical terms, I found learning Haskell much friendlier when I was contemporaneously learning Java, C++, Prolog, etc. in university.
SkyMarshal
I'm relatively new to NixOS but this is my sense of things too - it might have been better to use a subset of Haskell for the Nix package manager, instead of a new untyped language, for the reasons you give.
One simple thing I like about Haskell is its readability. Instead of cramming both type signature and function definition into the same line, Haskell splits those two into separate lines. Having the type signature in its own line, as the first line of every function, is so much more readable.
It's also interesting that you can outline/pseudo-code an entire program structure using only type signatures and no function definitions, check if the type signatures are all correct, and then fill in the function definitions later.
That said, I'm still new to Nix, and there are probably good reasons it was done this way, buried in past discussions, the creator's PhD thesis, etc. that I haven't read yet. And I hear that types are being looked into for future upgrades to Nix.
mikepurvis
I'm not a Haskell user, but my assumption has been that the Nix language being something of a DSL has meant that it's able to include certain kinds of convenient optimizations such as directly referring to files by their relative path.
Is this bogus, or would you imagine that a substantial number of additional wrapper/helper/noise functions would be needed to make a general-purpose language do what the Nix language does?
I guess Guix is probably an opportunity to look at a practical instance of this first-hand.
josteink
> have used at least in university
That’s showing a bit of bias.
Personally Ive been in the industry for roughly 20 years and I’ve yet to meet anyone IRL who has even dabbled in Haskell.
Basing your packaging-format on Haskell is a great way to alienate most Linux-users without a specialised university-education, and I’m wagering that’s a fairly big portion of desktop-Linux end-users.
nix23
>Personally Ive been in the industry for roughly 20 years and I’ve yet to meet anyone IRL who has even dabbled in Haskell.
See that's the bubble ;) If you work at a company who makes archival, language-detection and ocr you will see C/C++ Haskell and OCaml..well and perl in no time.
mikepurvis
I started on my Nix journey a few months ago, and in some ways, I've had the worst-possible experience— I had basically no ramp-in period of being just a "Nix user" before attempting to write my first package, but was instead thrust immediately into a massive project templating out generated definitions for 1000+ interlinked packages with a bunch of oddball requirements, funky build tools, etc. I've needed to manage version and patch overrides, obscure linker conflicts, stuff that broke at runtime due to unpropagated buildInputs. I'm also a functional programming novice, so that recursive combinator magic which makes the overlay system work— also something completely new that I've had to wrap my head around.
So yes, all this has been... somewhat harrowing. But overall I would say I'm quite pleased with the end result and impressed with what Nix has enabled. Despite its long evolutionary growth, many of the things that I've encountered feel thoughtfully considered and well made. The various ways that builds and binaries can be pushed around and shared is awesome, and I'm excited for the optimizations coming with the content-addressed store.
I don't think that making the Nix language or package definitions feel more conventional would necessarily be a good thing— I think there's a risk that those kinds of changes obscure the underlying realities and lead to expectation mismatches.
That said, one thing that I do feel is pretty unfortunate is the interplay between the shell and Nix in package definitions. Basically you pass a dict to mkDerivation, and all the stringy items in that dict become available to your build's environment as envvars. This means when writing out strings for your configurePhase, buildPhase, etc, you have to be hyper-aware that ${thing} will be templated by Nix in the Nix context, whereas $thing will be templated much later, by Bash. It's something that is learned quickly but my goodness is it ever a hell of a tripwire.
isr
This doesn't address the dynamic vs static typing issue you brought up, but for the rest, you may be interested in exploring guix.
Guix is essentially a reimplementation of nix packaging system using a pre-existing language - guile scheme.
Some may react adversely to them using a lisp (<s>well, enlightenment is not for all ... </s>), but leaving that aside, guix has continued to evolve in slightly different ways to nix, but still the core (and the guarantees it provides) remains essentially the same
maxdamantus
> 1. Add types to the Nix expression language
Interestingly, this was one of the first issues that Edolstra (creator of Nix) raised himself, but unfortunately he closed it again as unrealistic a number of years later [0].
[0] https://github.com/NixOS/nix/issues/14#issuecomment-37820190...
akavel
Thanks for linking this - reading through the thread made me discover a cool related project! -> https://github.com/tweag/nickel/
See esp.: https://github.com/tweag/nickel/#related-projects-and-inspir...
vnlwq
I'm not sure what kind of C/C++ projects you install, but most of them are still ./configure && make && make install.
Cmake can be worse, Meson versionitis can be annoying. It is also annoying to install Meson and Python in stage 1 in Linuxfromscratch now. Yuck!
The languages aren't fundamentally insecure, there are tons of reliable projects out there.
sa1
For the kind of reproducibility nix needs, ./configure && make && make install is not enough. It needs to track and manage the artefacts created by the build system, not just run a script.
iammisc
Except, most of a nixos system is built by simple Autoconf scripts and some env cars being set correctly.
I mean I built a whole nix distribution for embedded devices with runit as init and cross compiling and everything and nix made it easy and fun. And I learned that it's just Autoconf and shell all the way down. There's no magic to nix. The most voodoo non standard thing they do is patchelf stuff, but most of the nixos specific stuff is just setting paths to configure scripts or in the environment.
aidenn0
I think I might be misunderstanding you, but that's completely false. Nix sandboxes things and every single C project I've used with "./configure && make && make install" works with zero boilerplate.
seabrookmx
scons has entered the chat
ducktective
About point 3:
I don't think we should just ignore the immense technological knowledge encoded in C/C++ projects throughout the decades, only because they came from an era which having a package manager for every language was not fad of the day.
Let's see how those "memory safe" languages would fare 20 years down the line...but I predict there would be a cool_lang and people would advocate for rewriting every algorithm known to man, yet again
throwaway894345
I sympathize with this point, and I tried to be quite clear that I'm not suggesting we drop everything cavalierly today, but rather we decide that our aspiration is to deprecate C/C++ and we move our dependencies gradually from C-based to something else. Some dependencies will be more pernicious to move because they require a lot of specialty knowledge (e.g., Harfbuzz) or simply due to their size (e.g., Chromium) but many others could be moved more readily. It will be a long, hard road which is why we should start now.
> Let's see how those "memory safe" languages would fare 20 years down the line...but I predict there would be a cool_lang and people would advocate for rewriting every algorithm known to man, yet again
This just reads like you've taken personal offense. My argument is quite clearly not "C isn't cool enough" or "C isn't memory safe", it's "C lacks a standard, sane build system such that packaging C projects is a nightmare".
ducktective
I'm not experienced enough to take a side in language wars...It's just my personal opinion, as a non-CS, that deprecating working solutions because of non-theoretical problems (like difficulty of packaging) is not a sane engineering approach.
I mean, yeah, right now, Rust/Go have much better tooling than C/C++ for packaging and dependency resolution it's not even a debate but still one may argue that C/C++ library management is decentralized :) and maybe in future people converge to some unique method of dependency resolution that would deprecate Rust/Go way of doing things (like Nix/GuiX).
I came to this view because I see lots of cool projects in very specialized fields, that are practically abandoned and no one continues working on it on the sole reason of community thinking its not worth continue maintaining it in old lang/tech.
Again, consider I'm mainly a embedded guy...so idk, maybe a fresh re-write of every classical cs problem every 10 years is better in practice...
nix23
Not ignoring, but minimizing the surface, for example:
Should the default "webserver" really be written in c? Or maybe just the one for embedded or high performance?
ducktective
Yeah, best language for the task...but the parent was talking about not using a dependency just because it is written in C or C++
nix23
To your point 3, i don't think it's too controversial, some tools are absolutely ok being written in c like all the core-utils, but a monolithic kernel, written in c is probably the biggest problem:
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
robocat
Alyssa wrote some background behind the project:
https://alyssa.is/leaving-freeagent/
“When I had a call with [the project sponsor] NLnet recently, I was told ‘you work for the internet now’. And that evoked the most powerful feeling of purpose and drive I’ve ever felt in my life.”
“Although my funding is for Spectrum, I expect to be able to work on free software much more broadly over the next year. Certainly, a lot of my work will make its way into Nixpkgs, which I was very excited to receive commit access to some months ago due to my other work on it. And there are some further projects of my own to come as well. In addition to working on Spectrum, I’d like to diversify my funding. I hope to be able to take donations for my free software work on Spectrum and other projects, to make this important work truly sustainable for me. I couldn’t sensibly do this before, because I couldn’t guarantee that I’d have any time to spend working on what people would be giving me money for, but, in this new arrangement, I have a lot more freedom and capacity to choose how I spend my time. I don’t expect donation income to pay my bills, or even be significant, but I’d like to explore it, and until now I haven’t had the space to do that.”
outworlder
Glad to see that they are using Nix, was momentarily concerned about duplication of effort.
I've moved all my machines to NixOS, and even replaced Homebrew with Nix on my work OSX laptop(with home-manager). It's a rather refreshing system. Being able to use nix-shell and temporarily install one-off packages is also great.
The motivation behind this system sounds great.
lijogdfljk
This is interesting. One of my major complaints of Nix (of which i'm typing on, NixOS) is that my app states easily clobber each other. Ie moving between large nix changes can break, and even rolling back is broke, because the state is not managed in the same safe way that apps themselves are.
If this solves that problem i'd definitely be interested in trying it out. As the only thought i had was manage to put 100% of my state into my nix config which seems.. a nightmare.
SkyMarshal
As a (new) NixOS user too, I'd be interested to hear more about this.
Have you tried setups like "Erase Your Darlings" and "NixOS: tmpfs as root" to explicitly persist and manage state?
lijogdfljk
Nope, but that's exactly what i had in mind when i said "put everything in my nix config". Any setting for my desktop, browser, etc would need to be in that config. The tempfs would just help me practice it.
Big PITA though, imo. At least until i'm "better" at Nix.
SkyMarshal
I spent about 3-4 months learning Nix/OS this past spring/summer. After some trial and error and source code spelunking, I finally got my system working according to these two blog posts, with some tweaks [1]. It was a lot of work to ramp up that learning curve, but now that I have I don’t think I can ever go back to another standard Linux again. They all feel so messy and disorganized now by comparison.
[1]: Some things, notably containers like LXC/LXD, can’t work with tmpfs mounted to /var, /var has to be on disk, while the rest of / can be tmpfs.
nerdponx
For a non-Nix user, what do you mean by "app state"? Things like config files?
lijogdfljk
Correct. Though sometimes apps also store little files as local databases, effectively, and switching versions of the apps can jack with that file as well. Making rollbacks more difficult
isr
Could you elaborate a bit on this? Not arguing, genuinely interested ...
fouc
I'm surprised the app state isn't backed up so that rolling back restores it?
seniorivn
you can use fs snapshots and backups
ncmncm
What I miss most in QubesOS is ability to connect my GPU hardware to a specific VM (or app, or container) the way I do the mic, camera, and USB peripherals. I don't need it for rendering the browser GUI, where the CPU is wholly adequate, but it would be helpful for e.g. mpv, and as a back-end for OpenCL/OpenMP programs. This seems like it ought to be much easier than trying to share such a GPU with multiple VMs simultaneously.
The problem seems to be how to do it securely. You could imagine faking GPU hardware for the VM image to talk to. But maybe Vulkan would be a better API? Has any work been done on a wrapper forwarding calls that refer to VM-mapped addresses to a native Vulkan? (What happens in WSL2?)
I find Kompute ( https://github.com/KomputeProject/kompute , https://www.youtube.com/watch?v=Xz4fiQNmGSA ) that seems to be a serious attempt at building general computation infrastructure on top of Vulkan. Is exposing a Vulkan wrapper, and building compute kernels on top of that, a practical avenue?
This all seems like something someone must have throught through already, but I have not found anything published about it.
fsflover
> ability to connect my GPU hardware to a specific VM
You can do this if you have a second GPU: https://www.qubes-os.org/faq/#can-i-run-applications-like-ga...
https://forum.qubes-os.org/t/qubes-gpu-passthrough/661
https://forum.qubes-os.org/t/another-2-gpu-passthrough-post/...
ncmncm
Thanks, I do have. Actually, two, an Intel and an Nvidia, and not using either one.
pabs3
Connecting hardware to an app VM seems like a bad idea, better for the hardware to be managed in a specific VM, passing out an audio/video stream then individual audio/video/input streams sent to app VMs. On Linux pipewire is meant to do the audio/video part. I there are probably virtio protocols for GPU stuff, the Spectrum design page mentions one for Wayland.
ncmncm
But I'm not interested in video streams. I want computation.
1MachineElf
Latest update from the developer: https://spectrum-os.org/lists/archives/spectrum-devel/202108...
w0mbat
Anything called "Spectrum OS" should have something to do with the Sinclair ZX Spectrum. For people who grew up with Sir Clive's cuddly 8-bit masterpiece, the word "Spectrum" has too much history in the context of computers to be casually reused like that.
w0mbat
...and then Sir Clive died pretty much the next day. RIP my bearded friend.
ncmncm
Sorry, no. Rather, nothing should be named "Spectrum". There is a reason trademarks use unique spelling. Projects should use unique spelling. There is no shortage of spellings.
veltas
> nothing should be named Apple
ncmncm
Funny choice, considering the amount of litigation over that name. Unless you were serious.
When Apple started, they were sued by Apple Records, the Beatles' label, and settled with a pledge to never have any activity involving music distribution.
Come iPod, they turned around and sued Apple Records.
a-dub
this is actually a really interesting problem i've been pondering quite a bit recently. what would it actually take to get to actually secure computing assuming one was able to start with a clean slate? it seems like getting away from memory unsafe languages is a pre-requisite, but beyond that... how do you build a computer system with thousands of pieces of software authored by different people with thousands of inputs that are controlled by different entities that produces output you can really trust, and verify... like not tamper resistant, but actually tamper proof with verifiable outputs. and well, also not a huge step back in performance and usability.
in reality, maybe something like this that builds on existing primitives to get there may be the only real, feasible thing... but assuming you could start from scratch, what would it look like?
fsflover
> what would it actually take to get to actually secure computing assuming one was able to start with a clean slate?
> getting away from memory unsafe languages
How about secure virtualization and security through isolation instead? See Qubes OS.
a-dub
> How about secure virtualization and security through isolation instead? See Qubes OS.
yeah, that's kinda what i meant by "something like this that builds on existing primitives to get there may be the only real, feasible thing".
it looks like qubes uses vms as an existing (heavyweight) primitive to limit blast radii for existing software and systems. i wonder if you can do better if you start from scratch.
fsflover
> existing (heavyweight)
It's not exactly heavyweight, because Xen hardware virtualization eats up only additional 10% of CPU. However, GPU acceleration is switched off for security reasons.
yewenjie
Oh this is so interesting. I switched to NixOS (with Flakes) about a week ago and will really love to see more projects in the ecosystem.
mikepurvis
I'm a recent Nix convert who also loves flakes and nix-cli and would love to see them get out of unstable and the docs updated to direct users toward them.
SkyMarshal
My last understanding is that Flakes are slated to go into stable in the next NixOS version 21.11 this fall. Do you know if that's still the case? I'm still just using configuration.nix for everything, haven't migrated to Flakes yet.
lom
No. Flakes will be stabilized with nix version 3.0, while the current nix-unstable release is 2.4pre-something. See the roadmap here: https://discourse.nixos.org/t/nix-release-schedule-and-roadm...
mikepurvis
The main issue for me is that I'm working on packaging for a proprietary project where the ability to have an overlay flake and lock all my dependencies is critical. So I'm doing this with a flake and it works great, but I really didn't want to have to learn the old-and-busted way of doing it only to have to migrate later, particularly when the ergonomics of flakes is so great.
ncmncm
How can I send money?
I give to QubesOS every month, already. QubesOS uses OpenCollective to administer donations, which seems to work.
ilovetux
I have to say that their landing page is great. Short, sweet and to the point especially their `Development progress` and `Getting involved` sections.
I'm going to give it a try.
1vuio0pswjnm7
"ucspi-vsock UCSPI-1996 implementation for Linux AF_VSOCK sockets 6 months"
Neat!
I still use djb's ucspi all the time.
(stunnel or haproxy to add TLS support)
LargoLasskhyfv
I'm wondering if she's aware of http://skarnet.org/software/s6-networking/ ?
Get the top HN stories in your inbox every day.
> The host system and isolated environments will all be managed declaratively and reproducibly using Nix, a purely functional package manager
Nix seems cool, but all of my forays into it have been so unpleasant as to be unworkable. It seems to work well enough if all of your dependencies are already in the Nix store and have been thoroughly tested, but as soon as one has to start writing Nix packages themselves it's a train wreck: the peculiarities of the Nix expression language, the chaos and lack of documentation in nixpkgs, the immense understanding one must have of the common low-level libraries used to create Nix packages, and you'll still spend tons of time trying to package obscure C dependencies with their own bespoke build systems.
My constructive feedback is:
1. Add types to the Nix expression language so someone digging through the code can have some idea about what needs to be passed into various functions. This would probably help people traverse nixpkgs as well, since the client code will need to "import" the types of its arguments.
2. Make Nix more syntactically familiar. Familiarity here seems like it should be more important than innovating on programming language syntax. Thanks for not going full-Haskell on us, but it would be nice if looked more like JavaScript or Python or something that virtually any programmer could look at and recognize (I'm no great fan of either of those languages).
3. Very controversial, but the whole industry needs to minimize the number of C and C++ dependencies. Not only are these languages fundamentally insecure, but projects in these languages have their own bespoke build systems which assume dependencies are already installed at the correct versions and in the correct paths. Packaging these projects is painful, and it's largely the reason we have package maintainers who specialize not in building programs of a certain language, but in building certain dependencies.