https://forum.elivelinux.org/t/how-to-install-nix-packages-o...
I'm giving it a go now in the easily undoable single-user "no-daemon" mode.
Super excited how approachable this makes Nix, I've put this off for many years due to what turned out to be an incorrect assumption about the level of commitment!
- Nix: build system and package manager (available on Linux and macOS)
- Nix: language used to define how to build packages
- nixpkgs: Nix package monorepo
- NixOS: Linux distro that is fully managed using Nix (language), has Nix (package manager) built-in, and is defined as part of nixpkgs
https://kagi.com/proxy/images?c=_m3km2RjA3G0qleowsZXHZb9NEn0...
(Also, I tend to think it's better to view NixOS as a tool for producing a linux distribution, which in many cases just happens to have an installbase of 1 - but that's not necessarily the case, and you could build your images with NixOS and deploy a dozen of them to aws.)
[1]: this was meant to be a joke, but it occurs to me that a person might think I missed that they had divided "Nix" up into two, the buildsystem and the language. But a language is not a command and doesn't do anything, so it can't possibly be an interpreter as well - and there could be and to some degree is multiple nix interpreters. So it is the first of the divisions of Nix that I sliced in two, and you end up with three Nixes: the buildsystem/sandbox; the main language interpreter; and the language.
It's a bit more involved than homebrew, but you end up with a very precise definition of what your project depends on. This prevents all kinds of headaches re: Linux and Mac users depending on subtly different versions of grep or sed. Plus you can recreate the same environment in CI and Prod without having to define those dependencies separately.
Or you could, if your team was bought in. That's the hard part.
I always see these type of arguments for why nix is so great but it’s never been a pain point for me in 10+ languages and 20 years of development experience. I see your example of bash scripts but this can’t be all for writing scripts.
We should promote this more :)
I use arch, btw, because its a solid rolling release and the AUR. Its the absolute best distro for a developer, theres really no competition.
There is nixgl which you can wrap around any executable to make it work and it's got support in home-manager (https://nix-community.github.io/home-manager/options.xhtml#o...) but it's a huge annoyance having to wrap `config.lib.nixGL.wrap <package>` around everything you want to install.
The determinate systems installer for Nix is honestly a really great example of a great command line tool. It very transparently tells you "this is what we're going to be doing. Will you allow me to do all of these things?" and it tells you what when it is doing them. Then they bundle the uninstaller.
- Normally, just deleting /nix gets you 95% of the way back to normal.
- If you want a bulletproof removal, the determinate systems Nix installer saves a file with a list of all the operations it made during installation so that it can be cleanly removed.
- If you want to stop home-manager from hooking into your shell without completely removing Nix, there's a separate uninstall command for that.
Given that package management on the Deck is traditionally handled with Flatpak, Nix seems like a great alternative for power users with storage to spare.
Every few months I have to rerun an install script though, if I choose to upgrade to their latest release, since I don't want to risk doing that upgrade with the overlay in place.
But otherwise it's been working well for a couple of years.
Long story short, it would be faster to go check the computer physically. But it was more fun this way, even though I didn't have the time to play the game in the end.
RetroDeck bundles everything into a single flatpak and seems a lot saner, but is a lot newer.
We generally mean an asterisk as a glob wildcard, and *nix definitely doesn't match Linux. There are vanishingly few operating systems whose names match this glob, and all of the ones I'm aware of are either true UNIXes or Unix-likes.
One of my favorite examples of this precision-be-damned absurdity is from the wiki page for Unix-like (https://en.wikipedia.org/wiki/Unix-like):
> Other parties frequently treat "Unix" as a genericized trademark. Some add a wildcard character to the name to make an abbreviation like "Un*x"[2] or "*nix", since Unix-like systems often have Unix-like names such as AIX, A/UX, HP-UX, IRIX, Linux, Minix, Ultrix, Xenix, and XNU.
Of these, zero match `Un*x` and only "Minix" and "Xenix" match `*nix`.
If we want to talk about the category of OS that includes both UNIXes and Linux, I wish we'd just call them Unix-like :)
The asterisk character in this context/usage is not used as a wildcard/glob but as a censoring device[3], in a manner similar to: "Don't censor f*ck on HN."
In the case of "Un*x" the motivation is not one of propriety but of proprietary--it was motivated by matters of legality (real or imagined) in relation to trademarks.
AIUI at the time UNIX(TM) was a trademark and it was thought by some that in order to avoid potential legal issues it was required to always include the TM superscript in order to avoid the wrath of the trademark owners for trademark infringement/generic-ism.
But as "Un*x" is not "UNIX"[4], the reasoning went, no trademark attribution was required.
Anyway, that's why when referring to "***/L*nux" I’ve (very) recently taken to calling it "***/L*nux", not wanting to infringe on Linus's trademark and all...
----
[0] The Wikipedia text doesn't really fully represent/match the text of the cited reference[1][2]:
"Used to refer to the Unix operating system [...] in writing, but avoiding the need for the ugly ™ typography [...] lawyers now say that the requirement for the trademark postfix has no legal force [...]"
[1] https://en.wikipedia.org/wiki/Unix-like#cite_note-jargonfile...
[2] http://catb.org/jargon/html/U/UN-asterisk-X.html
[3] https://en.wikipedia.org/wiki/Asterisk#Censorship
[4] Coincidentally, GNU is also Not Unix: https://en.wikipedia.org/wiki/GNU#Name
I've actually been using NixOS on my Legion Go to give me the SteamOS experience while I wait for the official image from Valve [1].
I knew that Valve had whitelisted /nix, but seeing how the author explicitly loads Nix in Bash:
.nix-profile/etc/profile.d/nix.sh
What are the boundaries between things that work everywhere, things that only work after you've loaded a bash profile (e.g. from a terminal), and things that only work in NixOS? What if a package wants to run at login? What if it uses its own systemd rules?
Not sure if I'm misunderstanding what you mean by systemd rules, but from what I understand, enabling a systemd service (either at the system or user level) is the most reliable way to make sure that something starts up in game mode as well as desktop mode. Because I find it useful to ssh into my Steam deck for a lot of things rather than trying to do it all via desktop mode (e.g. managing config files for Baldur's Gate 3 mods that aren't from the in-game mod installer), and I always turn off wifi on it whenever I leave my apartment with it to save battery, I enabled the sshd systemd service, and it's available even if I boot up directly into game mode. I haven't actually been able to find any other way outside of an enabled systemd service to make things start up automatically in game mode, which ended up being an issue for me when I wanted to autostart something through Wine that didn't have an option to avoid trying (and failing) to open a window.
I really want to get game developers using Nix. That is a large reason why I am working on the Windows port!
https://nixos.wiki/wiki/RetroArch https://nixos.wiki/wiki/Playstation2
I'm able to run steam games and have had no issues at all. Im using Lutris as the launcher, but you could easily use the official steam launcher (programs.steam.enable = true).
So you could technically get yourself a full gaming experience just with nix, without relying on the shipped steam client in SteamOS.
>nix-channel --add https://nixos.org/channels/nixos-24.11 nixpkgs
>This command sets your nixpkgs channel to the latest stable version (in this example, 24.11). In the future, check the current stable version on the NixOS homepage.
Any particular reason for not having a "latest" that will automatically detect the latest release instead of forcing each user to manually check and set the latest stable release every time?