I don't know. Not much about all this setup feels appealing. The apparent learning curve for nix looks...steep. I've been using linux for a pretty long time (I think kernel 2.1 was fresh when I started). I've done the slackwares and debians and redhats and arches and gentoos etc. And I have zero desire to put such effort into having a working system.
I realize the post is prefaced with a warning that it's over-engineered. I guess my question is- can I use nix without going so hard down the rabbit hole? I don't think I have the time to invest like my gentoo (read: teenage) years.
I'm pretty satisfied with doing a minimal install of fedora, setting up i3 and firefox and calling it a day. Maybe I'm just older and more crotchety than I thought.
So with NixOS your process would look like this. Open up your editor on one of your devices thats already running. Write up a nix config that sets up i3 and firefox, could be just a couple of lines. Save it on a usb drive along with nix itself. Boot your new pc off the USB drive and your set.
And thats just the first time you use nix. Next time you just reuse that thumbdrive, or redownload it, and get your config from a git repo you are tracking your config in.
I have a git repo that has configuration for three types of devices I run in my personal setup (desktop, nas, webserver). They all inherit from my base configuration which has stuff like the user configuration and maybe my vim how I like it. The server adds docker and runs the docker containers that it should. The nas mounts the raid array etc.
If I want to know how I configured my nas three years ago, all I have to do is read the nix file I checked onto github. Thats powerful.
> Write up a nix config that sets up i3 and firefox, could be just a couple of lines
You forget the step "find out what to write in the nix config file". Might take anywhere from less than a minute to forever, depending on experience, google-fu, and documentation.
Well obviously, I'm just pointing out why you would want to spend some time figuring it out. NixOS isn't just another linux distro, it's the next generation of operating systems.
I don't know, the "benefits" have been well preached for years, and I don't see NixOS gaining popularity (though, I tend to focus on the linux community news, so might be missing the visibility). To me, NixOS is a cool concept, but I think it solves a problem that not a lot of people have. I mean, how often are people "redoing their systems from scratch," deploying to new machines, etc? That's like a once-every-four-year thing for me, and it's way easier to just dump a list of packages.
People mostly don't have the problem because Ansible et al solve it for them. It's the classic situation of a good-enough solution existing, making the superior solution irrelevant.
Agree, what is going for Nix is that is a valuable tool and is very versatile. NixOS is just one application.
From OS point of view you no longer need:
- Kickstart
- Ansible, Saltstack et.al.
- Custom package repo for custom packages (if you need to customize something)
There are other areas too:
- create common developent environment, makes sure every developer has exactly the same tools installed with exactly same versions, so no more "it doesn't work on my machine"
- build system
- CI/CD
- packaging (as mentioned, you no longer need artifactory, instead you can have nix cache)
- there is also potential to use it for IaC, there's NixOps, but currently this is maybe the weakest part of Nix, it only covers deploying a box, but if you want to do something more complex, like autoscaled service it gets in the way. It is great for developing a new image though. There are terraform integrations, I didn't try them yet, might work better.
- you can configure local developer machine to use build system for local builds as well. If caching is configured, then once code is deployed it will already cache good build so it doesn't need to redo it
- for personal use with things like home-manager it can replace dot files as do more, you can have the same environment each time. Let say you change job and get a new laptop you can have it quickly set up the way you want it
https://nixos.org/nixos/options.html massively helps. Sure, some things you have to build for yourself and that may take some time, but a surprising amount of stuff has been done already and you just need to flip one of these options to activate it.
What's the value proposition over something like Debian where it Just Works(tm)?
Maybe if I was a sysadmin managing a herd of boxen I would like this, but for a guy with only two Linux systems (plus my mac, plus my windows boxes, plus my openbsd pcengines etc.), it seems like a lot of fuckery with text files for little to no actual improvement in my UX.
It's the same as with git. Some people don't use git when they're working on a project solo. I don't get that at all, NixOS is a fundamentally improved way of managing your operating system. The only real reason not to use it is because you're in a company and your business needs to avoid risks like sysadmins not getting your tech stack, or some component not working because there's a bug in a less battle-hardened setup.
When you're solo there's no such restrictions, you can just use the nicest tech that's out there. I've been amateur-adminning debian/arch/ubuntu machines for 15 years now, NixOS is such a relief to be rid of that mess.
I can actually remember what's installed on my system and how it's configured in a centralised place, even when I don't touch the configuration for a few months. It's actually better for "boring" systems that I don't touch the config of much - "why is that set up like that" is a question I can easily answer. Additionally, when I do want to play with new stuff, the various tools I'm given usually let me do that and go back to a clean slate if I'm not interested, without having to deal with heavyweight containers/VMs/etc.
All your state is in one place - packages and configuration. On a typical system there is tons of hidden state - some little option you had to change but didn't document, some package you forgot you installed ... that's not that easy to reproduce or change-track without backing up the whole system. You could use Ansible to do it, but that's another can of overhead.
I am sorry but that is fanfiction that nix people want to believe. There are numerous reasons not to use nix, a few:
- Incredibly smaller community
- Incredibly smaller support from community and enterprise
- Yet another programming language - that is difficult to grok
Those alone can kill any technically sound project, but there are lots of others. Such as slow installs, storage requirements etc.
The main value proposition is this:
With a single file, you describe the desired state of your system. That file is configuration.nix.
You put in there what packages you want installed, what users, what SSH keys, what services systemd manages.
Then, you run `nixos-rebuild` and then you switch your system to that configuration. The old state of your system stays around until you run garbage collect. So you can rollback to it, if you want.
>Then, you run `nixos-rebuild` and then you switch your system to that configuration. The old state of your system stays around until you run garbage collect. So you can rollback to it, if you want.
How often are people doing this, though? I get a machine set up pretty quickly (install list of packages, systemctl enable <foo bar baz>, reboot), and I'm set for several years.
It is as often as you change things. Also configuration.nix isn't just a list of packages to install and services to enable, it's also a configuration of various system components.
I'm quite new to NixOS and recently tried home manager, which basically manages your home, primarily all dot files, but goes as far as preinstalling favorite extensions on Firefox for example.
Kickstart is just RedHat equivalent of unattended install. NixOS goes way beyond that it also takes over CMS (ansible, saltstack, etc). You can for example modify one of packages (use different configuration option, or maybe sorry patch) and if binary version is not available in the cache it will compile new one. With home manager, it can also take care of your home directory, all configurations so called dot files, down to what extensions you want to have installed on Firefox.
Honestly, I find it infinitely easier to just do everything in in docker containers. Then the OS doesn't matter except for installing docker, and running docker-compose up.
Docker is for containing the environment of your apps. NixOS is for configuring your operating system. I use NixOS to define which Docker apps run on my machine, as well as monitoring and administration tools, firewall setup, that sort of thing.
If all you do is apt-get install docker, that doesn't feel like a very complete set up to me.
I'm saying if you run all your apps in containers, there really isn't much left to configure on the OS. Using Ansible for those few things seems like an easier solution.
But Ansible is an incomplete and extra part of software just to make your operating system behave like you want it to. Why not just pick an operating system that behaves like you want it to from the ground up?
Yeah, that argument is weird. If we are taking about state the difference between those two is that docker is just storing a snapshot of a state (BTW Dockerfile by itself is not reproducible and is comparable to a bash script) while Nix is storing information how to get to a given state.
That makes it far more versatile. It is what Docker promised to be, but ended up being an overglorified zip file. Depending on your needs, that might be all you actually want. If you want to make small adjustments to existing state (let say applying a patch, in docker you pretty much have to rebuild from scratch and with non-deterministic Dockerfile you might change more than that), or maybe compose something new from existing components, Nix gives you far greater control to do that.
Yes, the Dockerfile has serious shortcomings and makes it totally miss the mark on what it was promising, but based on some comments about how nix is hard, it probably helped with adaptation.
Seems like it comes much easier to most people to issue series of (often nondeterministic) commands that mutate state rather than learning a new language that allows describing dependencies and have it figure out steps needed.
Yes obviously docker is primitive and people prefered that, just like they prefered php4/wordpress, it was the right match for a nascent space/market.
The issue to me is that it's mostly a regression and that when showed nix/guix people would squint saying it's horrible.. when in fact docker way is horrible, it's just nicer to them.
>> If I want to know how I configured my nas three years ago, all I have to do is read the nix file I checked onto github. Thats powerful.
Have you had to deal with breaking changes in the config language? (Does this ever happen? Are there versions/specs of the language that can be pinned?)
I don't remember any changes in the language, but I did encounter packages that had their configuration renamed or changed in a way that broke my config.
Basically you pin to a version of NixOS, and opting into the next version is fully optional. So if you change your NixOS version, and you run nixos-rebuild, and stuff doesn't work, then you can just undo your change. NixOS even keeps a backup of itself ready, so say for some reason you update but your new version doesn't boot, you can simply boot into your previous working version.
So nix has ability to pin to specific version and you can get exact same system.
With an OS there is a problem, because most of the time you don't want to do that, you want to get security patches and erratas. For this purpose channels are used. They promise to not break anything within release channels. This is very similar to how other OSes, you need to trust them to not break thighs. There is also option to subscribe to a rolling release, so similarly to other OSes there are more opportunities for things to break (living on the edge and all), but the stuff below still applies.
On top of that there is also variable in your configuration.nix it is set to the version of NixOS that you first installed. That version is version of the configuration file and supposed to guarantee compatibility. The compatibility they mentions are things like for example default version of PostgreSQL that they use if you choose default one you don't want on system upgrade to automatically force you to upgrade your database. Another obvious change is change of defaults, perhaps they decided that service that was previously enabled by default should be now disabled etc.
You can bump the version in that file, but then you have to go through changelog and adapt your config to these changes.
I am relatively new NixOS user, but just did uphrade from 19.09 to 20.03 and it went smooth as if it was just update within the same release.
Ran out of disk space, want to run another service, want to check if there's any software updates.. I don't know, in my case I had it in a moving box for 1.5 years and I was pleasantly surprised it even booted and immediately started serving up stuff to my TV.
I had a machine that I let run with an old (private) certificate for years because I didn't remember the how and the what of renewing that specific certificate.
I had another machine that had a hardware failure, and I spent an enormous amount of time recreating it.
I have been running a personal server (FreeBSD) for close to 20 years now, and upgrading in place since 4.6. And once some hardware components fails (especially disk) I spend extra time figuring once again how I did it then. Having everything described in a configuration would take less time to do such fixes.
As a keen NixOS user/contributor, if your only needs are i3 and Firefox, then I do not recommend NixOS to you. ~Any distribution can meet your needs.
NixOS is great for:
* shortening the divide between the user and upstream: not just release lag, but also the ability to contribute to upstream. NixOS makes it trivial to write a patch and deploy it your system, something I wouldn't usually bother with Debian, for example, because the same process was so frictionful.
> As a keen NixOS user/contributor, if your only needs are i3 and Firefox, then I do not recommend NixOS to you. ~Any distribution can meet your needs.
I really disagree with this. NixOS is also great for simple use cases like this because it's robust. I know a lot of people who switched to Linux, need to get something to work, follow some online tutorial/directions blindly, and just break shit pretty badly.
This isn't contrived: even seemingly-inoculous commands like "pacman -Sy" on Manjaro/Arch can fuck your shit up (it basically amounts to a partial upgrade).
NixOS doesn't let you break shit like this. (Literally, upgrades are atomic and packages can never have missing dependencies.) And, even if somehow you did, you then have a nice configuration.nix to quickly get back up to speed.
I tried to setup a simple NixOS machine this week. From this experience I couldn't manage to install any GNOME extensions via the browser plugin because of some Firefox manifest location that conflicts with the way the NixOS store handles it - there is some workaround in some tickets, but it made me wonder how many other applications are in need for specific workarounds. I then enabled flatpak via the OS configuration, but the first installed app couldn't launch because of some obscure error with gstreamer. I changed to fedora and could setup anything without any of those issues.
I really want to like NixOS (I still do), but I now consider it more for a server environment than a casual desktop environment.
You can use NixOS on the desktop -- it has a lot of benefit (including atomic upgrades/rollbacks). But it only really works well if you manage everything through Nix. Other mechanisms such as the ones that you mention tend to break very often.
I just gave up using Flatpaks with NixOS and install GNOME extensions through Nix.
Sure, but Debian/Ubuntu/Fedora all provide great experiences for "I just want some packages installed".
Fedora nowadays has btrfs-level rollbacks, which although this doesn't interact well with cfgmgmt (unlike NixOS's excellent rollback support), it's perfectly fine for an end user.
This is a benefit, but other distributions are catching up. For example, Fedora Silverblue has an immutable root filesystem and provides atomic upgrades/rollbacks through OSTree. Ubuntu 20.04 supports making ZFS snapshots as an APT pre-installation hook and thus also support rollbacks.
And don't forget OpenSUSE, which has been making btrfs snapshots before and after every upgrade for years(?) now. OpenSUSE doesn't seem to ever get the recognition it deserves.
The steps in that blog post aren't difficult, but it doesn't include all the steps and assumptions:
* how do you roll that dpkg out to your fleet? Now you need a deb archive?
* "For Debian the tool is called reportbug". Note that reportbug is a CLI tool to send an email to Debian's bug tracker, whose status/tags are then also controlled by control emails. It has a notoriously difficult learning curve.
* Many Debian packages expect patches via email, rather than the more familiar git-based approaches. Some Debian packages do accept patches via git, I'm aware. Hopefully the package you're filing a patch against does.
* The blog post also misses out the work the Debian package maintainer has to do: use their own approach (and there are multiple) for doing a package release/signing. NixOS? It's a PR that's built by CI. Like how we usually handle software systems.
* You've patched a single version. What happens when a new package is released but your patch didn't make it in?
IME, after years of using Debian I made a few but barely any patches against Debian because of the frictions involved. The frictionless experience of NixOS has made me more active.
Let's say your patch doesn't get in in time for Terminator 0.96 (following the same example), or it's not relevant for upstreaming. Now you need to go through the same process again to upgrade. So much for `apt-get upgrade`. And it gets even worse if your change breaks binary compatibility: now you need to find and rebuild all packages that depend on it too!
The beauty of NixOS here is that you patch the "repository" instead, so will get applied on top of the current version as long as the patch applies cleanly. And all of Nix's usual logic applies for rebuilding dependendees as required.
I've used NixOS, it's a great project and has some benefits that can't be overstated, however if you're going to give it a try completely you kind of have to go down the rabbit hole. You will basically be learning a programming language that will let you configure your system. It took quite a bit of getting used to to understand how the language nix works, as it wasn't familiar to something I had used before. One might not have as much difficulty getting used to it as I did if they are experienced with functional programming, which I've only dipped my hands into before.
I'd recommend giving it a try if you have some time on your hands to get used to it, but you shouldn't be expecting a quick switch.
I disagree. While to be a power user you might have to learn all the syntax of the OS, I have been using NixOS for a couple of years, and have my configuration set up by borrowing other configs from the Web.
Additionally I'm a heavy Emacs user, and couldn't type a single line of elisp. I get that I'd be better in Emacs if I knew elsip, but that doesn't stop me configuring my text editor by borrowing code from others.
I've been able to achieve that same end goal, having deterministic/reproducible/reverting/history/etc with Ubuntu. Essentially, I boot Docker images on bare metal.
I have the same exact images, bit-for-bit, running on 3 different machines. I have a zshrc alias that allows me to sync my current machine with my work image that I have stored on Docker Hub.
There is no guarantee that you will get exactly the same Go version when rebuilding an image. And all the scripts seem like that: ad-hoc wget and apt command, where package versions, how they are built, etc. can change between runs.
This is only a very weak notion of reproducibility: if the scripts run, you will get an image with the same packages. Nix/Guix guarantee that you get exactly the same versions, built in exactly the same way, from your own package down to transitive dependencies such as glibc or zlib.
(I am not criticizing the project, it may be great, but it is just not reproducible/deterministic.)
Sure, it's not bit-for-bit like Nix and friends, but it's as predictable as you'd expect "docker pull ubuntu:bionic" to be, which is perfectly reasonable/comfortable for desktop scenarios.
1. Temporary boots. You can "sudo rm -rf /", reboot, and all is well. You can play around with "apt-get install" without having to commit to your changes being persistent.
2. Checkpoints. Each "bash script that you call on first boot" is versioned and you can easily revert back to any image at any point, as simple as running either "docker run ubuntu:bionic" or "docker run ubuntu:focal".
That is a complicated way to achieve the same thing Darch does. I'd prefer to not learn a new DSL. Packages and products are more widely supported on Ubuntu/Debian. In the end, I just want to work and play, not learn a new DSL, while having everything in the article you shared.
No, it's really not the same thing.
You have a very weak reproducibility which relies on Docker's implementation details and a lot of impurities.
In contrary, NixOS has very fine-grained reproducibility (and is not perfect of course) but get us very far [1]
A lot of potential users will probably react similarly and think the project is not maintained anymore. Maybe you could clarify that by mentioning in the README that this project is basically done, but still maintained should a problem arise.
You must have been really confused when React moved to 16.X ;)
My scenario is similar. The current version is 100%. However, I'm going to be refactoring a bit, moving some pieces around, to support some new features. The only breaking changes that user's will notice is that ```darch recipes build``` will be moving to ```docker build .```. I've already converted my personal recipes to use it.
I'm no Linux expert. I used Ubuntu for a few years and then switched to NixOS a couple of years ago. Setup is no more difficult to Arch, and certainly a lot easier than Gentoo.
For me the fact that I can replicate my machines with a couple of config files is the major driver. That and the ability to install a package in a shell, use it, then exit the shell and not have it installed globally is amazing.
Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
> That and the ability to install a package in a shell, use it, then exit the shell and not have it installed globally is amazing.
I can't even count the number of packages I have installed because I needed them once. I have an entire Node.js ecosystem installed because I needed to run a frontend from another team for 20 minutes. Could I have done all that in a single shell, then had it automatically cleaned up when I was done? My current solution is to spin up a container, but that becomes a pain and I end up getting lazy and just globally installing everything again.
> Could I have done all that in a single shell, then had it automatically cleaned up when I was done?
Yes, that is a pretty standard workflow for most nix users. You either set up a shell.nix for your project with all of its dependencies, or if you need a certain tool once you just write for example: ‘nix shell -p iotop’ to enter a shell where iotop is in the path.
Certainly. You'd be just a `nix-shell -p nodejs` away from being in a shell with NPM. And a C^D away from not having it installed, with a caveat that it would be cleaned up periodically and not immediately after exiting the shell. But I think there's an option for immediately removing after use as well.
Yeah, you can just have a couple of config files and spin up a shell that auto-installs everything. The packages are all on your system, so the next time you start the shell, nothing has to be downloaded, but they're not installed globally, and a you can do a garbage collection command at any time to clean up everything.
When I first started using NixOS I had a huge list of globally installed packages, but that has become smaller and smaller over time. For instance, my main browser is Firefox, which is installed globally, but if I need to use Chrome, then it gets fired up in a temporary shell.
I haven't used it in a while but Vagrant used to be great for "setting this up with apt and the language's package manager would be straightforward, but containerizing it would be a pain" one-offs, to keep it off your base system. And didn't require you to keep an entire image around to do it again, just the vagrant config file.
>> ... and not have it installed globally is amazing.
Yah, the more I think about it this is the biggest selling point to me.
>> Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
I actually never thought deeply into nix NOT on nixos (I've probably been conflating the two). As an infra/devops-y person I can think of a lot of cool use cases off the bat in the server-space (theoretically anyways, I've a feeling the details would be quite the devil). But, except for the case of developing for such a system, I'm struggling to see a use case that warrants it in the desktop realm. (I need to meditate on this one..!)
There is a learning curve to NixOS, but it has saved me huge amounts of time over the last 6+ years. I wrote a configuration.nix file describing my ideal Linux install once and I've been using it largely unchanged for years. Upgrading and migrating to a new machine has been painless. I can also easily change any part of my setup with minimal effort (e.g. to switch from connman to network manager is a one-line change).
The NixOS configuration language is a unifying layer of abstraction and allows people to more easily re-use the work of others (compare with pasting commands from a how-to blog post).
> I wrote a configuration.ni x file describing my ideal Linux install once and I've been using it largely unchanged for years.
I use custom install and configuration scripts for various Linux distros and Windows installs, this is not a feature unique to NixOS, just a different implementation. I use a shell script for Linux and a PowerShell script for Windows.
> The apparent learning curve for nix looks...steep.
It looks like so, indeed the manual is fairly extensive yet it probably lacks a hands-on approach. That's what I'm aiming to solve by writing a couple of articles explaining pragmatically how to use Nix (not NixOS, I'm not quite there yet), starting as a Homebrew replacement.
And really, at the end of the day the new language is not really harder than having to learn Ruby and the Formula DSL, or ABS idioms and its shell idiosyncrasies in PKGBUILDs.
I went down the same path as you and now run NixOS. The biggest advantage is that all the tweaks you have to do every time you install are now just a couple of lines in a file you only write once. It's very hard to break the system because you can always boot a previous configuration. Everything is customizable like Gentoo but if you don't modify a package its binary will be fetched from a central server so installation is very fast.
I think the Nix/NixOS debate gets confused by two separate goals:
* A workstation machine where you do everything from development to watching netflix
* A server (whether VM, Metal, Container)
The former wants convenience and flexibility. I agree with you - I also use Fedora because (particularly with Lenovo hardware), you install it and you're done. Everything works. I don't want to have to go and write nix expressions because I want to run a not-very-obscure thing that isn't packaged. It's ok for me that my workstation is a 'pet' and I blow it away every 6 months to a year.
The latter case is more interesting and has some specific requirements on it. We all know about configuration drift. The idea of getting completely deterministic setups, and unifying how you do that across VMs, native and containers is great.
I agree. Or at least I used to! I set up a server a few years ago running NixOS and it required a steep learning curve, but it seemed worthwhile at the time. Fast forward to today and I want to add a new service on the server and I've completely forgotten everything I learned about Nix and I'm considering switching back to debian.
I think there are more nuanced value conflicts around the workstation case. There's nothing wrong with the values you're working from, but they've slipped down my list over the past few years.
Nix can certainly be limiting in some ways. But everything can--we just habituate.
It's possible to find interesting tools that aren't at all cross-platform, or that require hours of DIY spelunking to get compiling, or that are only in some other repository. It's possible to find something you want to use that either isn't packaged for or is broken in every package manager.
I use Nix (on macOS and NixOS) for roughly the same reasons: convenience and flexibility. But from a different angle, I guess. It is freeing to know that everything I need to make forward progress on all of my personal and professional projects is specified. I have the flexibility to resume work on the projects I care about with almost no friction beyond securing new hardware.
I am finding that the Nix package manager on top of Fedora works nicely as a middle ground:
You can use it to set up a per-project nix-shell that gives you an experience a little like docker (in terms of speed), but more convenient because your normal machine is available on the PATH (or not, if you run --pure).
I can then use that same Nix config in my CI - just use the base Nix docker image and then apply the nix-env as a pre-script.
"The former wants convenience and flexibility." Thanks but no thanks, if those were my priorities I'd just use my chromebook. Or a mac if I had to run locally hosted stuff old school style.
This NixOS stuff is very interesting, feels like living in the future. Turning it into Windows10 is exactly what would repel me from enjoying it.
To some extent my chromebook is completely deterministic in that there is no setup other than my wifi credentials and google login. Its weird and fun to compare.
Nix can be approached incrementally by starting with the package manager on your current machine. Perhaps use home-manager to build out a user environment or nix-shell for custom local development environments.
Yes you absolutely can just install nix[1] it should work on any Linux, I used it in OS X myself and some things are slightly less smooth than Linux, but it still works well. I also highly suggest to start with Nix Pills[2] it goes so by step how to create derivations and conventions in nixpkgs.
Once you get familiar, you can see how you can make a reproducible dev environment, the author has a blog how to do it for rust[3] but many things still apply, I for example did a template for python [4], I eventually plan to put a less trivial app with unit tests once I get some free time.
we had to setup a simple linux for the purpose of diplsaying some stats on the attached screen. choices were: debian and nixos. debian would take approx half day to setup (given other project tasks). nix os was chosen and it took 2 weeks and now it is rather hard for non-nix user to fix anything.
To be fair, at one point that was the general Linux experience: half a day on Windows, a week on Linux and then “nobody else can fix it”.
I’m not arguing for Nix (had a look and it seemed more complex than I can bear at the moment), just that new tech in general needs time before it can be properly compared.
Well, sure, anything that's unfamiliar to you is hard to fix. For me it would be exactly the other way around, because I'm quite familiar with NixOS and mostly unfamiliar with Debian.
The most complex thing you'll need to do is learn is whatever something like this (taken from my laptop's config, enables acpid, openssh, tlp, sddm, and make plasma5 and E available as sessions):
and then after the OS is install firefox to your local user profile:
nix-env -iA nixos.firefox-bin
You will also need to partition your harddrive, but the install/live USB includes the KDE partition manager, so you don't even need to use the commnd-line for that.
You might get more mileage from Fedora Silverblue. Toolbox (a regular Fedora ran via podman) gives a disposable container for running dev stuff. The rpm-ostree package manager allows for fearless upgrades as you can always boot into an earlier version of the core OS.
There is small learning curve for getting to know rpm-ostree and toolbox tends to be a hindrance if you want IDE integration. Also you have to reboot after installing packages to the core OS, that's mainly why they recommend using flatpaks, but it's optional.
Note that it's still beta but pretty reliable as you can always downgrade and wait till they fix stuff that may be broken after an upgrade.
When it comes to actual setup needed it's not much different than a regular distro. No language to learn, no additional setup required.
Initially I played around with toolbox, wrote a 30 line bash script for initial setup for it and eventually ditched using it.
You can still use RPM Fusion and install regular .rpm's.
One thing to note is that they recommend to use the default partition layout as custom ones can (and do) break.
> I don't know. Not much about all this setup feels appealing.
Exactly. While reading the post all I could think of were flashbacks of dependency hell and not one thing I was reading appeared to be helpful in eliminating it. But now I have to put up with the crazy cryptic language that I've never seen before.
LOL, you've must not paid attention or have some weird definition of dependency hell [1], because the way nix operates makes it nearly impossible (I mean you can technically write an app that requires incompatible versions of the same library, that can't work together, but then that app wouldn't work anywhere else as well, not just with nix)
You can absolutely use NixOS without understanding what the article goes through. For example, I use NixOS and I don't know any of this (but I'm looking forward to learning it).
For example, on other *Nixes, you install and uninstall packages, maybe configure them, but you're not BUILDING packages. All of the complexity of this article is in the superset of what you'd normally do.
For the most part, just add things to systemPackages in configuration and `nix-rebuild switch` or install via `nix-env -i` if you want user scoped installs.
And macOS! Catalina's read-only system volume has made the installation a bit more difficult. But once you have set it up, you get many of the same benefits (per-project virtual environments, home-manager, etc.).
We use NixOS on three machines around the house, but I use Nix + home-manager on my MacBook, and various Ubuntu servers at work. It's nice that I can largely use the same configuration across all machines. Just a home-manager switch and I am in my native environment.
i was planning to try out Nix on MacOS, because i always wanted to try out Nix and i use MacOS, but then Catalina happened,a and suddenly there were problems with Nix on Catalina.
last time i checked the install-instructions on Catalina, you had to create an unencrypted volume to store the nix-things, which i'd prefer not to do (i understand those files are probably non-personal, so no need to encrypt them, but i don't want to have to remember that half of my hard-drive is unencrypted)
is that still required or is there a simpler approach now?
The separate volume is still required. As far as I understand if you use an encrypted volume, it does not mount early enough in the login process and you have resort to more hacks to make it work.
Ideally the Nix store would be in some non-root location. But that requires a completely new binary cache among other things (since /nix store paths are hardcoded in binaries, scripts, etc).
Also making /nix a symlink doesn't really work in some cases, since realpath reports the actual path and that may break builds/applications.
It used to work so nicely out of the box :(, but I can also understand why Apple wants to enforce read-only system volumes, since it blocks nastier rootkits, etc.
I don't have any OSX boxes, but wouldn't bind-mounting the real the /some/where/nix to /nix solve the realpath problem? No need to write to / either (as you would have to do with the symlink approach).
If it is possible, then I think it should work. I believe this might be the way they are planning to go, because someone mentioned about a separate partition.
Honestly, I think they should just relocate it to a different location that can be persisted and rebuild the packages. I don't think people care about the location as long as they don't have to recompile every single thing. This could also be useful to catch all bugs where /nix was assumed.
I, too, have no desire to put so much work into having a working system (but I guess, there’s no way around nix for me, if I want to use haskell and ghcjs). Unfortunately from my own recent personal experience it does indeed have a steep learning curve .
I really like the general idea of nix, I think it’s going in the right direction and I am very grateful for all the people doing amazing work there and I wanted to give it a try for a long time, now.
But my recent experience with nix on MacOs has mostly just been incredibly frustrating. I started using nix one or two weeks ago, because I needed it for a project with haskell-miso (which I very much like, by the way).
As long as I just stuck to using the default.nix provided by Miso, everything worked fine, more or less, but as soon as I tried to go beyond that to customize things for the needs of my own project, the problems started to accumulate.
I needed to google for and apply manual fixes for some very basic things, because nix did not play well with neither macOS Catalina (nix needs access to /nix) nor with fish.
Some haskell packages I need like constructible were broken in the default channel and I had no idea how to fix those packages. In the end I ended up switching to a “stable” version. I do not understand why nixpgs-unstable is the default channel, by the way.
Sometimes things seem easy in some guides and I thought I understood them, but then when I tried them they just won’t work. For example I was hoping that
nix-shell -p 'haskell.packages.ghcjs.ghcWithPackages (pkgs: with pkgs; [ miso ])’
would give me a shell with the ghcjs compiler and the package miso, but that resulted in an error (after waiting for the result for quite some time and a lot of text scrolling by).
I tried following guides and didn’t try to do anything especially crazy, but somehow I ended up fucking up my haskell build environment so much, that I couldn’t do anything Haskell-related anymore. Still don’t how I managed to do that.
I tried rolling things back through
nix-env -G 1
but that didn’t work. Somehow the only think that helped me was deleting everything nix-related and trying again. I then switched away from the unstable channel in the very beginning and now things seem to somewhat work, more or less.
When I was 15 years younger I really enjoyed playing around with the configuration of my computer, trying different window managers and editors etc., but nowadays I have work I care about and limited time and I want my computer to just work and not get in the way. Nix really, really got in the way. It’s been incredibly frustrating the last few days, when I wanted to work on my project, but spent several days fighting with nix instead.
Sorry for the rant, again, I very much like the project and I really hope it succeeds, I just wanted to share my own experience with it, as a beginner.
I really dislike Nix/NixOS, but I think it's kind of unreasonable to claim something is unappealing because of a learning curve. Pretty much everything on the planet has a learning curve; if a project is genuinely innovative or aiming for a paradigm shift, and you find the benefits of it worthwhile, there's probably always going to be a learning curve.
That said, are we really reading the same post? What's presented here is...really simple, and you should be pretty much familiar with most of it if you actually set up Gentoo and Arch in the past; pretty much everything directly translates that requires user interaction in this, and the package format is pretty similar to write & read, too.
> it's kind of unreasonable to claim something is unappealing because of a learning curve.
It's not unreasonable at all. It all depends who is claiming that. Consider Mac OS and compare it to any Linux in terms of the learning curve. Can my mother say that Linux is unappealing because it's to hard to learn it? Of course.
Even among engineers there are people to prefer just getting the stuff done without spending hours or weeks on configuring their environment (even if it could pay off).
The appealing features of whatever it is are still appealing despite the learning curve. To highlight what I object to, because I feel I may have come across ambiguously:
Not much about all this setup feels appealing.
The good features about, say, OS X, are not made less appealing because of the rest of OS X. They're still appealing properties.
I think you're missing a variable: point of view.
Give positive points to any feature you find appealing.
Give negative points to any feature you find unappealing.
If you have the person you're speaking to go through the same process, you might find you've assigned points differently. And the net sum might be closer to zero for them. That's what makes going through the entire process unappealing for them.
That doesn't really answer much, can you be more specific?
Why is it poorly implemented, what are the problems?
Who is the competitor, and why is it better? (Guix?)
What are the philosophical issues?
How is the community toxic and obnoxius?
Personally there are a few things that annoy me about Nix, mostly implementation and documentation wise. Also, the language is pretty odd and the CLI UX is somewhat messy.
But the community (IRC / Discourse) has been pretty helpful for me thus far.
I'd prefer not to be more specific, actually; at least on most points. Complaining about popular new things in threads about them is a trend I find irritating, and using a thread about how someone finds something cool to give reasoning as to why it's distasteful is completely off-topic and kind of rude, anyhow.
However, I will note that I listed two competitors, not one, and while I think both have more merit, I only think the best is worth using out of all three. I'll point out that it's not Guix, and that it's older than Nix, but I don't think advertising alternatives is a particularly nice thing to do in a thread about any given piece of free software.
>Complaining about popular new things in threads about them is a trend I find irritating
It's a little too late for that. Complaining in a vague way across several comments and then not elaborating further is, I think, definitely more rude than making some concrete complaint (like the original comment's complaint about learning something new)
I didn't complain, and I didn't even criticize it in "several" comments; the only comment with anything resembling criticism is the second one I wrote, and it's just a single comment!
I said I didn't like something as a way of making it clear that I'm not trying to brigade for Nix and don't really have any incentive to defend it, and I gave an argument on why I believe the initial comment was being unfairly negative to Nix.
I was then asked why I disliked Nix. I made no complaints, I just listed my opinions. When I was asked to go into actual complaints implying fact rather than personal opinions, I said I'd prefer not to.
> I don't think advertising alternatives is a particularly nice thing to do in a thread about any given piece of free software
I don't think throwing unsubstantiated claims around is a particularly nice thing to do. I don't mind you having these opinions. But if you're not ready to properly argue them, it's probably better to just abstain from the discussion entirely. That's how I handle my own opinions as well.
I was asked why I dislike something. I answered. "Unsubstantiated" is a really weird thing to use in the context of opinion. An unsubstantiated claim exclusively applies to fact, while I was very clearly giving my opinion. None of the things listed can be objectively measured.
I'd be perfectly happy to argue for them, but I don't think this is the right place to do it. Frankly, I don't care about how you handle your own opinions. When I am asked about my own, I'll tell them. I won't try and sell them as factual to anyone else, though, which is what going into more detail would require me doing in this particular instance.
Fair enough, although I don't see how mentioning the names of competitors and giving well-reasoned comparison is somehow worse than calling a project "poorly implemented", "lacking merit", and having a "toxic and obnoxious community" without providing any verifiable arguments.
All three of those can be easily written off by anyone who likes the project. Claim that 4chan is toxic; people who like 4chan will think you're an idiot, but it won't really ruin their mood. Point out specific examples of their favorite board criticizing something they love, however, and they probably will feel upset for one reason or another.
But in a public forum such as this, calling a community toxic can, and will, keep people from looking in to to the associated project any further. If you have specifics, you should say them - public spaces are the right place to out toxic communities. But, people on the internet throwing around words like "toxic" without substantiation can be really damaging to communities by preventing growth.
Please substantiate - I'm not involved in the Nix community much but whenever I've been in the #nixos IRC channel, they've been super helpful.
Could you at least, at some point, when the comments have died down, share what this third alternative is? I'm really very curious - everyone replying to you is.
- It can't be GoboLinux, because that post-dates Nix (by a small amount)
- I've never heard anyone suggest environment modules have more technical merit than Nix, though they do predate Nix
- Could it be portage, which has some of the same features as Nix? Nix explicitly cited portage as a predecessor, and IMO it surpasses it, so that would be surprising...
I really don't know anything other than Nix or Guix that follows Nix's philosophy. I'm really interested to know what you're referring to!
I don't know. Not much about all this setup feels appealing. The apparent learning curve for nix looks...steep. I've been using linux for a pretty long time (I think kernel 2.1 was fresh when I started). I've done the slackwares and debians and redhats and arches and gentoos etc. And I have zero desire to put such effort into having a working system.
I realize the post is prefaced with a warning that it's over-engineered. I guess my question is- can I use nix without going so hard down the rabbit hole? I don't think I have the time to invest like my gentoo (read: teenage) years.
I'm pretty satisfied with doing a minimal install of fedora, setting up i3 and firefox and calling it a day. Maybe I'm just older and more crotchety than I thought.