From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
I found these interesting Nix OS articles series for users that want to try it and learn first things, have a good reading!
#nixos #linux #tutorial #guide
everyone here will hate me for bringing this up, but i tried to install nixos on hyperv, but wasn't able to.
YOU BASTARD
Since I'm already a NixOS user, I thought to check out Series 4. One of the steps was "install flatpak"
My disappointment is immeasurable and my day is ruined.
My disappointment is immutable
“install flatpak”
why would someone do that in NixOS? nix has a lot of packages and using flatpaks imperatively would lead to less reproducibility
My usecase is that I want to build a rock-solid workstation laptop for my non-tech-savvy family member.
I configure all the basics in .nix files, and then from there, they can install Flatpak from the software center, like they are used to doing.
Then I can just do a rebuild switch when I see them, make sure it's all working, and then trust that they probably won't break the system in-between.
Edit: to be clear, in my own config, if it's not reproducible, I'm actively working to fix that.
I thought about doing that but updating nixos confuses me. Does nixos-rebuild switch pull new packages? To my understanding there is a file that saves all currently installed versions of packages and switch only adds new things but wouldn't update packages.
Like, if I want to update Google Chrome. Doing switch wouldn't change anything if the config hasn't changed, right?
I believe that's correct -- if nothing has changed from your last generation, then the new generation will be identical. But if something has changed, it will do a bunch of duplicating and remapping symlinks in the Nix store to ensure that everything plays nicely together and that you can rollback to a previous generation if needed.
So if you do a rebuild switch regularly, you will end up with gigs worth of old "copies" of things that aren't being referenced in your current generation.
That's what nix-collect-garbage handles -- once you know your current generation is working well, you collect the garbage and recover that space, at the expense of not being able to roll back.
That's why I think building a core system with NixOS and then having user software come from Flatpak is a nice combo for simple workstation that won't update and bork itself, leaving my grandpa without a laptop until I can come take a look.
Edit: To clarify, nixos-rebuild-switch won't update your Flatpaks at all -- just the Flatpak service
That makes a lot of sense. I can setup their computer with nixos and stuff that needs to be updated regularly (like a web browser) can be flatpak which should be more stable too.
Then flatpak update would get them updated without rebuilding the whole OS.
My grandparents have been rocking Linux Mint for a few years. I have managed Chrome through Flatpak since I discovered that was possible on Mint. I've been flirting with the idea of having NixOS instead so I don't have to remember what I've configured in the past. I'm not 100% sure now though :-P
Exactly right. Throw in Plymouth and set the bootloader timeout to 0 and you've got a noob-friendly workstation.
Plymouth?
It's a graphical boot screen.
Just helps eliminate all the bootloader noise you see when booting up or powering off that make scare off less tech-savvy folks
Oh cool. My grandparents don't have any idea that scrolling text isn't normal on startup. Neat project though!
I mean why would you be fully against flatpak? I use NixOS without it and always packaged natively on Arch, but especially when upstream offers flatpak, it makes sense to enable it. Keeps the user-facing programs up to date and somewhat sandboxed while you can have a stable release beneath it. Especially if the system's actual users aren't that tech-savvy.
Stuff on unstable tends to break, especially electron-dependent derivations. Stable doesn't always have the latest and greatest. Flatpak seems like a good compromise for desktop applications in some cases.
Well the only real reason when it comes to Nix is that they aren't declarative. For a lot of Nix users, the ability to describe every bit of software and all their settings in one giant config file is the draw. Not necessarily anything against Flatpaks themselves.
But I agree, I like being able to mix the two where it makes sense.
NixOS itself by default isn't fully declarative anyways, nix-env for example is imperative and very comparable to flatpak regarding applications.
I welcome the efforts to move away from all imperative bits in NixOS though. My point was rather not to dismiss an article on NixOS for mentioning flatpaks.
Flakes takes care of a lot of the imperative bits, but some people are wary of them since they're marked experimental.
I don't think flakes can do much more declarative than "legacy" nix, rather they increase reproducibility and purity. Also their tooling doesn't offer imperative stuff by default, but I'm not sure they cover use cases previously solved imperatively. E.g. I don't think you can install user software through a flake. Sure you can create shells with software available, but that is also possible without flakes.
Maybe my understanding here is wrong though.
They cover a few things -- most notably they replace channels, which are imperative.
Unless I'm way off, you can also install user software through flakes if you add them as inputs. That's what I'm doing with Musnix.
You can also pull a repo and 'nix run .#software' from the command-line, without entering a shell. That's how I'm using NixifiedAI.
They cover a few things -- most notably they replace channels, which are imperative.
True. I never considered channels imperative, but rather a purity issue. But I guess this is a matter of perspective.
Unless I'm way off, you can also install user software through flakes if you add them as inputs.
I don't know about this, but that doesn't mean anything.
You can also pull a repo and 'nix run .#software' from the command-line, without entering a shell.
True, though this by default only runs the default binary, and you're probably in a shell anyways, so it doesn't save that much. Also that output is, to my knowledge, not protected by garbage collection. But my knowledge of any imperative stuff is minimal, so I don't know if that's the case there.
I don't know about this, but that doesn't mean anything.
Why doesn't it mean anything? You add the flake as an input (declarative) and then add the software to your config (also declarative).
I'm not arguing that it's better, or saves time, just that it takes things that were done imperatively, and makes them declarative.
I meant that just because I don't know about it doesn't mean that it isn't possible.
Oh gotcha, sorry.
For what it's worth, I'm still reasonably new to NixOS (but not Linux) so it's entirely possible I'm way off base.
Ahh, itsfoss.com. they had some article on "being a supercharged Joplin user" or some nonsense and suggestion 3 or 4 was "Create a notebook".... Really being a power user when you're utilizing the most basic functionality the app was created for....
What's up with the ux design of nix? I get it's made for advanced users but still. I'm reading through this guide and man it's convoluted.
The different ways of installing packages. Either through editing the configuration.nix or running a command.
The weird inconsistency of nix commands. nix-env -iA to install and nix-env --uninstall to uninstall. Then updating uses nix-channel --update but upgrade uses nixos-rebuild switch --upgrade. All this to use the package manager. Also haven't even mentioned flakes or home manager.
It's a cool OS, but the UX really needs work imo.
[Edit] I do wanna add something else too because I feel like my point isn't getting across.
It's okay to have a complicated ui. Especially if your target audience are tech-savvy. But even tech-savvy people have to start as new users. A tech-savvy new user isn't going to know what the best practices are. Being able to anticipate the steps for installing a package is important for ux. If the commands for installing packages isn't cohesive/intuitive, then the user has to spend more time looking for guides and learning how to use the software.
People also mentioned a new command in the works. This is great! However, these current commands are being recommended through blogs and nix. New users won't know about this new command.
After trying out Nix as a package manager I realized I have a pretty different world view than the makers of Nix. I agree with the end goal but how they are trying achieve it is just alien to me. The nix command line is just downright user hostile.
I am personally hoping that someone else takes a stab at the Nix concept but have accepted Nix isn’t for me.
I've read so many things that try to explain what flakes are, and for the life of me I still don't understand what they are or what they're for lol.
They're not that different from the classic nix files. Their main difference is that their inputs are always well-defined (as opposed to a channels registry, i.e. you can get totally different systems by reapplying a configuration when you change channels which doesn't change your nix file at all). A configuration is always exactly described by a flake.nix and flake.lock.
I mean there is more to it, but this is the primary motivation. What you would normally put into use case specific nix files goes into a flake's output section. The stuff in your input sections is what you can use in there.
The errors are also pretty terrible, usually the thing that interests you is buried under a lot of text that makes troubleshooting a real pain.
oof, yeah.
i had a syntax error in my dotfiles that took me two hours to solve.
it was a missing semicolon that was wayyy above where the error said it was. it didn't even say missing semicolon, instead saying unexpected '}' on line ...
Yep, today I had a typo in a package name, and it cascaded into a syntax error. The syntax was absolutely fine.
Yeah because when you make an error it causes a snowball affect and it shows you too little information but when you look at the trace its a wall of errors.
There is controversy in the nix world because nix flakes were (some say) merged without proper vetting first. OG nix diehards don't want to taint nix documentation with 'experimental' flakes. But probably the majority of nix users are all in on flakes. So you have documentation from the OG camp that doesn't include flakes, and you have innumerable unofficial guides for the flakes way. This on top of the quirkiness of nix the language and the multiple ways to do things. Unfortunate.
IMO nix-env was a mistake. It feels like an imperative package manager which may be comfortable to new users who are used to apt or similar. But really what you should be doing on nix is maintaining *.nix files which document/specify your system setup, and nixos-rebuild to update your system to that configuration. Similarly, nix channels are an imperative holdover, which can be done away with if you use flakes, which results in your current nixpkgs version being documented in a system level flake.lock file.
I think both nix-env and flakes are designed with making package management easier. Nix-env tries to make it intuitive and familiar for new users. Flakes improve package management by simplifying the configuration.
Personally I would love to see syntax highlighting, language server, code completion. Maybe all in a dedicated application which is configured to give the easiest experience for new users. If nix is intended to be managed through config files, then the experience of writing a config should be as easy as possible.
The intent of nix-env was to make it easier, but the effect was to push some of your system state into a shadowy 'env' realm that is not managed by your *nix files. Same with channels - its state that isn't in your configuration.nix.
To me the whole point is to have all your state in some files you can check in to version control, and use to reproduce your system.
Agree it would be cool to have a way to edit nix files that would give you all the args to functions, code completion etc. You do get some of that with the nix repl. Would be nice to even have a GUI for selecting packages for those that don't "do" text editing.
I'm using nixd for a nix language server, but haven't seen a lot of benefit so far to be honest. I think part of the reason is nixpkgs isn't pulled in until runtime, so most things are undefined as far as the lsp is concerned. Haven't put a lot of time into it, there may be ways to make it more useful.
Syntax highlighting, LSP and code formatting work flawlessly for me using Helix, and therefore should on any editor that implemented LSP
I do think it's important to emphasize the difference between installing software in user environments and system wide, which is why the tool is named nix-env. System packages must be installed via the nixos configuration file and a rebuild.
To me the biggest missing piece for new users is a tool to help manage your system configuration and reduce the frustration of having to constantly look up nix syntax or nixpkgs quirks. Maybe thinking of it as a nixos/nix IDE? Also a polished distribution built on nixos would be a good starting point (and easy to do, I didn't realize I could just copy someone else's configuration until well after I had my system working well enough)
The other thing that got me starting out is the need to garbage collect old packages. It's not strictly necessary if you have a large enough disk, but it took me several iterations of filling my root partition before I figured out how to properly clean up old generations.
Have a good guide on cleanup? 👀
I think ultimately
Sudo nix-collect-garbage --delete-old
Is my go-to command. For a while I was looking at generations manually, but now I just wait a while (days, a few reboots, or until I need more space) to run this after changing things in case the new stuff is broken.
I think running this as my normal user cleans out old env generations... But I'm not 100% sure.
Here's an example of a tutorial that uses flakes and the new cli. You might glance through here to see how the syntax compares: https://zero-to-nix.com/start
Imho I wouldn't bother with nix-env or nix profile. It just creates a secondary list of packages that needs to be maintained and it's cumbersome to do so. There's nix-shell or nix shell if you need a package temporarily and there's your configuration.nix or flake for everything else.
Side note: nix profile at least has consistent commands: install/remove/upgrade
They have resolved this exact problem. There is an "experimental" cli tool that fixes a lot of your complaints about nix-env, nix-channel, etc. Itcs wrapped together with "flakes". This newer feature is a little different, and working with or without flakes segments the community AND the types of articles about nix, like this one.
As far as I know though, nixos related thing still have a bizarre set of commands, and even with flakes "nixos-rebuild switch --upgrade" is still how you switch configs.
And as far as installation goes, using nix-env -iA really is a bad practice. Thats installing something ad hoc like you would in any other package manager. That defeats the point of nixos, where your configuration file explicitly defines all the packages you need installed, and nothing else. Nix will remove any packages you didnt specify.
What is this experimental tool called so I can read more about it?
Add this to your nix.conf: experimental-features = nix-command flakes
Then check out nix --help.
Oh that's good that they are addressing those issues with a new command. Hopefully it gets into stable soon.
Might be that nix-env -iA is bad practice! I'm strictly talking about ux design here and nix-env -iA is being recommend by blogs and nix themselves. (Nixpkgs tells you how to install using nix-env -iA)
A new user isn't going to know what bad practice is.
It actually recommends using nix-env -i, which is even worse because with that command it searches the whole repository instead of just getting the correct attribute on nixpkgs. It takes half a minute to run the command, it's insane.