Setting up my new laptop: Nix style
bmcgee.ie
bmcgee.ie
1. How often did you update your Nixpkgs channel/flake input/etc? 2. What branch (nixos-XX.XX or unstable) were you using? 3. Were you using Chromium or Google Chrome?
Chrom{e,ium} gets updated pretty quickly, but depending on a lot of factors, it may take time to make it into a channel. It should really never take 2 weeks though, which is why I ask the first question.
You can also always track HEAD (or even a bump PR!) as the other commenter mentioned, though you might not want to do this if you're not using Google Chrome, as you probably don't want to build the browser ;)
I'm sure I could have found a way if I persevered and ramped up properly. I just don't have that kind of time. Maybe after I retire I can pick up where I left off. I do suspect there's a big opportunity to build a shallower ramp onto nixos.
For instance, personally I have everything gaming related set up inside an Arch container so I can trivially follow upstream (or the master branch for Mesa) without any friction and it works wonderfully.
That, or simply using pkgsrc.
It also provides versioning and decoupling from the system, but also has the benefits of working on any Unix and to be predictably updated. It's also far more KISS than any aforementioned solution.
The only real downside is the build time, as pkgsrc is more or less a managed federation of Makefiles. Installing software can take more time than would solutions based on binary packages, but it's totally worth it for the technical simplicity it brings to reproducible userlands.
I always install Pkgsrc via Joyent's installers¹, and use `pkgin` to perform package installs. Most packagws thsn install from binaries. Seema to work pretty well!
I still mostly stick to Nix, but I highly recommend Pkgsrc over Homebrew/Linuxbrew. It plays nice with other package managers and is generally well-behaved. Not a bad escape hatch for Nix if you feel like you need one.
--
You can follow -unstable for a select choice of package, that's what I'm doing e.g. for the TeamSpeak client.
I don't bother with building a custom ISO.
The way I do it:
* Boot with the default ISO
* Format the disk
* Git clone my dotfiles repo with all the configs
* Generate the hardware config and extend my flake.nix with the new machine.
* Install with my dotfiles config
* Reboot (aka profit!)
I can complete the whole process in about 10 minutes (on a fast CPU and with a good network).
Customizing the config up front, building the custom ISO , and writing it to a USB stick takes up way more time than just doing the above.
1. Use netboot.xyz to boot Nixos 2. Copy over nix configurations. I use nix flakes, so I can pre-build all my packages on another machine and debug the config in a more comfortable environment. 3. Run nixos-install (and generate a hardware config if needed). 4. Reboot
- I have two M1 Macs, running MacOS
- I have a Ryzen desktop that dual-boots Windows 11 and NixOS 22.11
I would like to have one dotfiles repo with all my configs and home-manager setup, as well as the system / hardware config for the bare-metal NixOS installations.
I have gotten these working independently, but I still can't quite make the leap in a single repo to:
- Having some config be machine-specific
- Having other config be OS-specific
- On a particular machine (same OS - macOS), having some slightly different config, because it's a work machine vs personal (e.g. different .gitconfig setups).
Can all of the above be addressed with Nix?
There seems to be an assumption either you have gone all-in using NixOS (e.g. in a VM inside host OS, or bare-metal), or you are just using the package manager (+ a subset of home-manager), e.g. macOS or WSL inside Windows.
But on the whole, 80% of what I want to set up and configure is machine-agnostic (NeoVIM, fish shell, basic CLI utilities, etc), and I use direnv/shell.nix in individual project folders to load the tooling for that project.
Then you can have multiple system and home configs that import the common files and then add your own config.
You can also pass options in with suecialArgs / extraSpecialArgs to the nixos/hm modiles.
I gave up after a short while using Nix and switched to Windows. It's not perfectly tuned like a minimal Linux install might be, but all of the hardware features work as expected and it has a pretty good battery life.
If someone can find a way to do something like Nix, but simple, I'll be interested. Even if it's just a on-rails version of Nix.
I doubt it's possible to substantially simplify Nix and still cover all the use and edge cases it does. Maybe GUIX since it had the benefit of learning from Nix and uses a more familiar (for HN anyway) Scheme, but I haven't looked at closely.
It seems that if Nix/OS works for you, it works really well, but if there are use/edge cases where it doesn't then it can be a lot of added effort to wrangle it.
In general, I think there's always going to be a long tail of things which will be relatively difficult to achieve with Nix.
But, I think it would be possible to make many cases much simpler, or have more common developer use cases well-trodden so that its rough edges get ironed out.
I’d be glad if sb could give a rough outline of the similarities and differences between Guix and NixOS for me who is not familiar with both of these systems but would like to learn more about them. I have a gut feeling that having reproducible builds/installations gives 90% of the benefits Docker provides.
> I have a gut feeling that having reproducible builds/installations gives 90% of the benefits Docker provides.
I'd argue that both tools provide more benefits than Docker, at the cost of the extreme convenience Docker offers in allowing you to use completely arbitrary (even non-reproducible!) steps to produce a container image. If you're already using either tool, you can achieve anything Docker can, including deploying against the Docker runtime. See the docs for the `guix pack` and `nix bundle` commands for info on how either tool can automatically produce OCI images out of arbitrary packages for you.
(To compare the two tools, I recommend just installing both Nix and Guix (via their own usual installers) on some desktop Linux VM and playing with them.)
That was my experience as well.
On top of that, getting something like nVidia's latest drivers working with everything else on Nix seems daunting, so you become fully reliant on the community (which may be lagging behind wrt the newest versions).
I don't think what Nix does in its most general strokes can really be made much simpler, unless you're willing to throw away a lot of what it does today (be it some of the package set, some extra features it offers, platform support, whatever.) The complex things it handles, that inherent complexity, is where all value really is. And that's where the huge and vibrant community comes from, because it does so much for everyone. It isn't easy, though.
For an on-rails version of Nix, you might enjoy something like Devbox. I can't personally vouch for it (I just use Nix itself, but I'm "an expert" with sunk costs), but I like the idea. One of the cool parts of Nix being "An API" is that you can build things like this on top: https://www.jetpack.io/devbox/
Why not an established distribution like Fedora, Arch, Debian or Ubuntu?
Nowadays so much is just some USB device that even on laptops so much ends up working out of the box
I have yet to get the camera color balance working remotely well in artificial lighting, though.
Only recently (November) did the webcam start working reliably on Windows 11. Also, out of the box, you get no touchpad / trackpoint during install.
On linux you might have to fiddle with configuration, and get unacceptable behavior like black screen and needing a restart after wakeup, until you get it working. But at least you can do something about it.
Only macs seem to get it right out of the box.
It’s improving and I’m sure in a few years it’ll be working well but these are issues that have been reoccurring for me. I’ve never had a Linux laptop where the fingerprint scanner worked.
Right.
In many ways, Nix is almost like a layer on top of Linux. If anything goes wrong, you'll need to understand both the Linux stuff, as well as how Nix works, and how Nix is making use of what's going on.
The most exciting thing I've seen with Nix recently is http://devenv.sh/ which offers both YAML/Nix declaration of a development environment.
Currently it works on a "per-project" basis, but we're planning to add support to use it as your primary package manager for global installs as well.
Specifically, i've noticed battery performance leaves lots to be desired and your mileage will vary by distros.
Mine specifically, started with Zorin but noticed it didnt do well with idle power usage. Switched to PopOs as its my desktop daily driver, but kept getting random freezes. Gave up and went with stock ubuntu.
Pretty much stable now, and perfect for a desktop but really not happy that a 2022 laptop only lasts 2 - 3 hours in usage. Not sure if its a linux issue but if Windows does solve it, wouldnt blame you for making that choice
https://kevincox.ca/2021/05/06/workstation-install-with-nixo...
I think the really cool thing about NixOS is that once you have any sort of base system installed it is just one `nixos-rebuild` away from any other system. This means that once you have your config the amount of futzing around on a system that isn't set up the way you like it.
[1]:the only risk is that once in a blue moon, a major version Nix upgrade will change Nix's database schema, and be incompatible with prior builds of lower versions, so you can't roll back to a lower version build after such an update. But afaik that's only happened a few times in Nix's history, is not a surprise, and is communicated well in advance.
Much worse, nix does not do any actual package management, i.e., dependency management. There is no way to derive a common-denominator configuration for a dependency shared between two dependent packages, each with their own configuration requirements (a la portage). Nix style is to install the dependency twice. It achieves that wonderfully, which is essential for development environments, but it should permit the shared dependency model for the "base system".
I've never used Portage; what did you mean by this? If you recompiled a library with different flags then you'd expect it to produce a different result. To use the exact same library in multiple packages, change their `buildInputs` by overriding their argument attrsets (`aPkg.override { aLib = aLibModified; }`). To replace it in every consuming package, use an overlay `final: prev: { aLib = prev.aLib.overrideAttrs { ... }; }`.
Nix does not. Nix seems great for deploying VMs and other kinds of managed images, where the cost of manually managing dependencies is amortized. But it is not useful for a development machine. That is a shame, because the other thing that Nix ought to be good at is creating development environments.
I wish that Portage's abilities (or any other comparable software; e.g. Cargo does much the same kind of resolution but on a different scale) were explicitly considered and designed into Nix (-the-package-manager), because the features would complement each other incredibly well. Portage's biggest drawback is that, although USE flags are managed declaratively, the system as a whole is, shall we say, aggressively stateful - every problem I've ever had with it is when it fails to find a path from the state it's in to the state I'm requesting.
You can do the same thing in Nix (e.g. you can package software with a bunch of options and pull in required dependencies based on the options selected by the user), but you're right that Nix doesn't have a standardized API for doing this like Portage does. I think it would be a nice thing to have. Maybe it takes a lot of work for maintainers to pre-package every possible build option like they do in Gentoo. Instead, Nix focuses more on providing a unified interface (the Nix language) for end users to modify anything about any package. nixpkgs is also pretty flexible, allowing maintainers to use packaging approaches that aren't "standard practice", and those approaches are all exposed to the end user if they need to make changes. This usually means reading the Nix package source to see what's going on if you want to make changes to a given package. For example some packages like vim do provide a nice interface for users to choose pre-packaged build options [4], similar to USE in Portage. Since Nix is lazy-evaluated, you just have to reference the dependency in the code somewhere (search for ${python3} in the linked example), and then that dependency will only get installed if that bit of code gets executed (e.g. if the pythonSupport option gets passed).
I think that's a big part of what makes Nix a pain, the fact that end users can make almost any change they can think of to any attribute on the entire system. But that's also what makes it very powerful. Right now most people use overlays, as people described above. So you can modify the "buildInputs" attribute (the set of build-time dependencies), or the "buildPhase" to pass some different CMake flags, or any install phase you like, for any package in nixpkgs (see [5] for all bajillion phases). Nix flakes might make it easier to compose custom set of packages, but I'm not sure how yet.
Oh and one more random tangent - this whole time I've been talking about build dependencies in Nix as opposed to runtime dependencies. That's because runtime dependencies are loaded automatically based on whether they get referenced in the final output of the build. Since every package has a unique hash, Nix literally greps the final build for package hashes, and if it finds any it loads them in as runtime dependencies. This is different from something like Portage where runtime dependencies are explicitly specified in RDEPEND.
[1] https://devmanual.gentoo.org/general-concepts/dependencies/#... [2] https://gitweb.gentoo.org/repo/gentoo.git/tree/app-office/gn... [3] https://gitweb.gentoo.org/repo/gentoo.git/tree/app-editors/v... [4] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... [5] https://nixos.org/manual/nixpkgs/stable/#ssec-controlling-ph...
That said, if I understand you correctly, I think nix does let you do what you're describing. You can make an overlay, which is a way to modify a set of packages by reaching in and changing build instructions or add packages to the set. So, you can make an overlay of nixpkgs and add a modified libgcc called mylibgcc to the set. In the same overlay, you can modify package A and package B that depend on libgcc, and change their build instructions, including making them use mylibgcc as a build dependency. If you do this for then both packages will use mylibgcc as a single shared dependency without duplicating it.
Im on mobile but could try to send a working example if you need one, lmk.
Some references:
... And all that stuff you did via SSH after grabbing the IP address?
$ uname
Linux
$ uname -a
Linux phi-nixos 6.0.7 #1-NixOS SMP PREEMPT_DYNAMIC Thu Nov 3 15:00:35 UTC 2022 x86_64 GNU/LinuxSounds great, isn't. A lot of magical thinking going on in that group.
If you know anything about computers, you know for them to operate deterministically, uniqueness of the next potential state is an important characteristic. They use hashes (galois fields) that aren't unique to ID packages (by definition), and as far as I have been told (when asking about this), they don't do anything to check for collisions.
Yes the probability is extremely remote, but probability isn't likelihood. What happens when a collision does occur, maybe the software won't work. So how critical is the software? Will it break the system? Can the system clean it up and recover (no, because its non-deterministic, more time).
These are questions anyone worth their salt would ask when they value stability and many Linux systems run for months of uptime or more.
They have two fundamental problems, they violate determinism, but that failure doesn't hit until there is a package collision, and its non-deterministic which means its not easily characterized (you spend a lot of time), and you need some form of mutability for package security updates, and configurations. If you can't adjust your software easily its stealing your time.
Barring a catastrophic break, there will never be a collision witnessed across the full lifespan of humanity.
You've made some significant assumptions, one of those assumptions is that the brute force way is the most efficient way or put another way there is no optimal way to calculate collisions better than brute force.
That line of thinking is very flawed. Has shown to be flawed many times in the past several decades, and shouldn't even be up for debate given the evidence and deprecation of various cryptographic functions (as vulnerabilities become known publicly). We all know vulnerabilities were known before the deprecation because detection is a lagging process.
Also note, as far as the respondents of the project I've spoken with have said, they do not even check for existing collisions. So if a collision did occur, you wouldn't even know it without specialized knowledge.
You can never have something compromised injected onto your computer this way either because nix requires signed builds to download from a remote repository. If you trust a malicious repository... that's on you. By default, only nixpkgs is trusted with the default hydra.
As a thought experiment, say a collision is found for libc or the standard library, thanks to all that research on primes that's been released recently, assume a more efficient search is found.
What would the failure domains be for those two libraries if, a) the library was non-functional suddenly, or b) the library remained functional but malicious.
Would Nix detect the collision, or would Nix simply recreate the dependency graph overwriting the old but secure with this new malicious software.
Almost all of the security primitives are implemented at domain edges, which means local access, or remote exploitation would have equal effect, and a watering hole/supply chain attack may not even be necessary.
I really don't get your point.
That's just trolling. Primes have nothing to do with sha256 beyond the initial value. It's just bitwise operations and additions.
As for automating the identity hash generation so it is perfectly deterministic, its not possible so long as you map onto Galois Fields due to their finite field length (and inherent non-unique solutions).
I'm not aware of any mathematical alternative for cryptography, to finite fields, and a hash is a cryptographic function.
Strictly speaking, you have a tradeoff in terms of stability as well as additional cost from the language complexity, and non-deterministic behavior is the fallback when discrete time invariance or determinism is violated.
Many people like Nix, but many people also don't understand how it works, and thus it will work until it doesn't, and then you'll be stuck.
Its not like there is tooling to check determinism, and if time invariance fails because of say a cache (memory property), then you can't even troubleshoot because everything we do to troubleshoot relies on those fundamental system properties with exception to Guess and Check which to be successful requires the highest specialization and understanding of the system.
Until what doesn't work? The base system is verified continuously, so there's no chance some two packages are linked against each other causing a boot problem.
If there's really a problem ever, then you just find the old system and start it on boot to one that doesn't include that package. This is straightforwards because most nix users have multiple nixos versions installed at once. Then, you update the offending package to not hash to the same thing (add a comment to a build script).
The system works so long as its deterministic, this is a requirement for computation to do work.
Then it stops working or doing work when its no longer deterministic. It does this in unknowable ways, unplannable ways, and you often won't know why something failed or even if it did fail. The only concrete characterization non-determinism has is the result was not expected.
Troubleshooting and repeatability doesn't work, you get different results each attempt.
Many things can happen non-deterministically including data corruption.
Its not nearly as simply or safe as you make it out to be.
You are making light and minimizing non-deterministic issues.
The infantesimal chance that a collision could cause a few hours (at most!) of hassle seems to me to be a far better trade-off in terms of stability and ease of applying and undoing changes compared to pretty much any package managemer that I've used.
I've heard the exact same argument almost verbatim from a C-level exec who got fired after an outage. It was regarding backups and the infantesimal chance that we would have a power outage.
It fundamentally assumes a lot of critical things that you can't control. If you follow your own advice, you will eventually be wrong, and pay more for it than you would have otherwise.
As for undoing or applying changes, I've had nothing but praise for rpm, its pretty rock solid with the right setup, and better, because it is maintainable and supportable.
I don't see why you get so fixated on Nix rather than preaching about anything else using sha256.
> infantesimal chance that we would have a power outage.
Power outages are experienced every day in every country; sha256 collisions are still to be found. That's not the same magnitude of ‶infinitesimal″ at all.
In that sense, I alone have lost more time to rpm than the entire world has with nix sha256 collisions.
You are way overstating the importance of this. This is not a fundamental design flaw in the nix ecosystem. If there's actually no check it's because most people realize this is not a problem worth spending a lot of time on. But the time required here is a few minutes at most.
Hashes don't really map onto finite fields. They purposefully try to not preserve any algebra.
There are existing issues from this not being the case. Uniqueness of names can only be guaranteed in a single repository and this causes many problems for people pulling from multiple enterprise repos (because everyone packages their own ruby for example). Then they start using omnibus packages instead with their own libraries up to libc, which... it's basically half of poor-mans nix-store.
> Many people like Nix, but many people also don't understand how it works, and thus it will work until it doesn't, and then you'll be stuck.
Considering git still uses sha1 and just about all of web cryptography uses sha1 or sha256 for signatures, block deduplication uses typically 128b hashes, etc., we'll have other problems way before this becomes a problem for nix.
Basically you're worried about a collision in nix, when the whole stack of 10 different things leading to you even reading an article about nix already relies on no collisions.
This will not be an accidental issue within multiples of our lifetimes, and malicious actors will not 0day some nix package in public.
As for cryptography, its all based on primes, and have you been watching what papers are being published regarding more efficient methods and searches for primes?
Ethical people would publish, unethical people would sell it to everyone elses detriment.
You are making a lot of over-general assumptions in your posts.
Unless you are suddenly trying to shift gears to muddy the water for some other purpose and apply what I said to 'all cryptography', it was pretty clear what we were talking about prior to this response.
Perhaps you should do a bit more research into the origin of those magic constants that get used to initialize those functions.
Where do you think they come from... yes you could change them but then you wouldn't be following the specification, and you can't legitimately call it the same thing.
AFAIK, they are all in some form related to primes, whether that's a truncation of a floating point representation of a prime or some other operation like a square root of a sequence of primes, because evidence has shown that the chaotic nature of primes works best and this is a property we want in cryptographic systems.
No. They aren’t. Not elliptic curves, not any hash functions, not AES, not ChaCha20, and not any of the post-quantum stuff NIST is tossing about.
RSA is. That’s about it. And RSA is being rapidly phased out.
That's plain wrong. Primes are being phased out in crypto, elliptic curves are decades old at this point, and lattices are everywhere in recent research.
For others interested, the magic constants are normally truncated binary of a known constant like e or pi, derived from famous texts, roots of small primes, etc. But the reasoning is that these are common, simple to reproduce numbers that can't be chosen to produce desired results. A.k.a "nothing up my sleeve" https://en.m.wikipedia.org/wiki/Nothing-up-my-sleeve_number
Sha256 is using some prime, but other hashes and systems don't and it doesn't matter at all in this context. They just needed a simple random initial value. I'm half convinced op is trying to use cleverly worded half truths to troll us.
You're not the one taking huge karmic hits for taking an unpopular opinion, and a lot of kids are using bots to try to de-amp that, like that even matters. So many people these days (if they aren't bots) regularly commit acts of true evil without even realizing it.
You know what I find really sad. No one can talk about anything because people use voting as a way to punish people based on their shallow feelings rather than the content, if they are even real people at all. Most of the time their bots controlled by a small group of people.
Its sad because to think and express real intelligent thought one must risk being offensive, and to learn one must risk being offended. If you don't allow that, you're stripping people of voice or the ability to become more intelligent which is a true evil.
When those that don't think outnumber those that do, why should any intelligent person try to solve the unintelligent majority's problems? :: shakes head, so shortsighted::
I hope you have a happy holiday despite all the negativity. I blame HN for switching their banner to red, it always brings out the absolute worst in people.
first: i know some folks who use nix and it works very well for them.
next: but not me tho. the experience:
To be clear, I had a laptop with Nixos as daily driver for about 9 months and it was total hell. The thing that finally forced me to switch to ubuntu (yes, that. at that time i needed working software for 7hours already. studying another five A3 pages of what could have hypothetically go wrong and how to maybe fix it was far beyond the scope what i needed to do.) was some component needed by pyqt4 and pyqt5 and nix could not handle it in any way. i've reported the issue which was subsequently fixed about 8 months later. thanks but not again.
the nix language itself is a hard no. 3 days worth of figuring out stuff instead of having it done in 15 minutes is a usability joke.
then there is guix that has the very same problems you mentioned, because the re-used that hashing nonsense from nix.
looking into /nix/store makes me want to cry every time. i just cant believe the current state (implementation) could be taken seriously by anyone. i have a strong feeling that after 19 years of development nix got into stage when it needs complete redesign and rethink way of doing stuff.
Yea, tell that Nix is good to admins. They might appreciate. Desktop? No way. Devs? Not even remote. I'd give it 2 out of 10.
Huh? What do hashes like Sha256 have to do with Galois fields?
You have a set field size as you go over it, it loops and so output fields are never unique, you have a 1:infinite relationship. That property to determinism, there are problems computers cannot solve but we can. A computer requires determinism to do work, which in effect is that 1:1 state->next state mapping on the state graph. There's a lot of computer science theory and literature on this if you want to dig deeper. MIT has an OCW course in signals and systems.
Anywhere you see modulus math happening, its working with finite fields.
Just because there exists a finite field of size 2^n doesn't mean that any length-n-bit-string that is the output of a hash function lives in a finite field of size 2^n.
Adding and multiplying hashes doesn't make any sense. If it does then you have a very weird hash function. Not one of the standard cryptographic hashes. So saying that a hash function maps onto a finite field sounds pretty confused to me.