18 ms·
I might want to try some new Linux distribution so I wonder: what doesn't work in nix? What are its weaknesses? What about devices with non-free firmware?
by codedokode 4y ago
I might want to try some new Linux distribution so I wonder: what doesn't work in nix? What are its weaknesses? What about devices with non-free firmware?
- justoreply 4y agoyou can't run binaries built for other distributions, without patching them
- bfrog 4y agoSort of true, you can but it require a fhs environment setup
- Filligree 4y agosteam-run usually. That gives you a Ubuntu-like environment.
- throwup 4y agoI wonder why Nix doesn't give every package a FHS env by default. In 2022 chroot and overlayfs should be available everywhere. Wouldn't that solve a ton of problems?
- chriswarbo 4y agoNix has no concept of "package". Applications are defined as derivations, but so is everything else (I wouldn't want an entire FHS directory structure for, e.g., a single text file). If you want an FHS, you can get one using a function like buildFHSUserEnv (that's defined in the Nixpkgs project; Nix itself doesn't know or care what FHS is; indeed, Nix will happily run on non-Linux platforms)
- SuperSandro2000 4y agoA FHS adds slight overhead to a package and to launch times. It also shadows part of the file system. For example /lib would probably be different for every other program which would be even more confusing.
- rnhmjoj 4y agoNot true: there are many tools that allows directly running any binary, like nix-autobahn [1]. [1]: https://github.com/Lassulus/nix-autobahn https://github.com/Lassulus/nix-autobahn
- SuperSandro2000 4y agoor https://github.com/Mic92/nix-ld https://github.com/Mic92/nix-ld or a FHS. There are many projects to help with this.
- 331c8c71 4y agoHaha, sometimes it goes the other way round. The vpn client at work wasn't available for the latest ubuntu and the old version did not work due to changes in some libs. Wrapping it with nix providing the right libs was way easier and much more replicable than manually building the required stuff. Did in on my machine and than 3 mins to do the same for a colleague.
- _piif 4y ago- You will have to learn both the nix language and working with nixpkgs. Learning nix is pretty trivial IMO (great resources are nix-1p[0] and Nix Pills[1]) but the documentation, while vast, is pretty shallow at the moment. You will likely have to resort to reading random blog posts, nix configs published by others and the source code of nixpkgs itself. - As mentioned by another commenter you will not be able to run random binaries by default. You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS environment for the binary. - It is significantly more bandwidth- / rebuild-heavy. If an input for a derivation changes it will trigger a rebuild, which means either a redownload from the binary cache or a recompilation. [0] https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p [1] https://nixos.org/guides/nix-pills https://nixos.org/guides/nix-pills [2] https://github.com/thiagokokada/nix-alien https://github.com/thiagokokada/nix-alien
- codedokode 4y ago> learn both the nix language That seems weird to me. I don't have to learn package configuration language in other distributions. I thought that one could just install packages with a package manager. > You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS shell for the binary. That's actually fine. I want to put closed source software into a chroot anyway.
- preisschild 4y ago> That seems weird to me. I don't have to learn package configuration language in other distributions. I thought that one could just install packages with a package manager. NixOS is more like a distro bundled with Ansible, so you can describe your entire system as code.
- SuperSandro2000 4y agobut in contrast to ansible it uses a real programming language and not turing complete yaml
- troad 4y agoI would expect something like Steam gaming on my dual-GPU laptop might be one deep mineshaft of "nope" on NixOS.
- Filligree 4y agoNo, that works fine. As well as it ever does.
- troad 4y agoReally? I'm curious to read more. It works very well for me under Ubuntu these days, but if I can get it working equivalently well on NixOS I may legitimately consider switching.
- Jhsto 4y agoPlugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix https://github.com/jhvst/nix-config/blob/main/nvidia.nix First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config https://github.com/jhvst/nix-config (however, kexec will not likely work, read more how to run it later) Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way. Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs. If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750 https://github.com/NixOS/nixpkgs/pull/203750 For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.md https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m... However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy. To get iPXE, the easy option is to go along with https://netboot.xyz https://netboot.xyz. You will find the `iPXE shell` option here to which to write the boot option from the previous paragraph. I also added AMD to the iPXE menu for whomever decides to test it. Sway is launched by writing `sway`. Steam should be started with `AMD_VULKAN_ICD="RADV" VK_ICD_FILENAMES="/run/opengl/driver/share/vulkan/icd.d/radeon_icd.x86_64.json" steam` to use the faster RADV driver.
- stingraycharles 4y agoFrom my experience, any binary is going to need patching before it runs, because shared libraries are in weird paths. I especially had issues running Steam, but this was about 8 years ago — maybe the situation has improved now.
- iopq 4y agoSteam still needs to be configured https://nixos.wiki/wiki/Steam https://nixos.wiki/wiki/Steam but it's just a few lines in your config and then it works
- SuperSandro2000 4y agoThat page is missing the opengl drivers which you also most likely want in the 32 bit variant.
- Filligree 4y agoSetting programs.steam.enable also enables 32-bit opengl, last I checked.
- SuperSandro2000 4y agoYes, that's correct and then you need to tell it which driver you need for your hardware. For example like: hardware.opengl = { extraPackages = with pkgs; [ intel-compute-runtime # OpenCL library intel-media-driver # video encoding/decoding hardware accerlation ]; extraPackages32 = with pkgs.pkgsi686Linux; [ intel-media-driver # video encoding/decoding hardware accerlation ]; };
- SuperSandro2000 4y agoYes, you cannot just download any random binary from the internet unless you use a FHS because those libraries are compiled for Distros using a default file system layout.
- aliqot 4y agoIf you just want someone to shoot you straight: Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and people will say I'm wrong, but I'm 100% right. Go see yourself, it's bad. Language is called Nix, OS is actually called Nix, package manager is called Nix, just the whole thing seems like it was written in 1 week by a squirrel with 12 hands and a sack of ritalin. That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it.
- bsnnkv 4y agoThat last sentence is so true. I'm all in on Nix and I couldn't elevator pitch it if my life depended on it.
- kadoban 4y ago"A completely repeatable setup all the way down."
- tomrod 4y agoCompletely repeatable setup. Like Docker, but works.
- SuperSandro2000 4y agoDocker is not repeatable. If I try to build the same Dockerfile in 12 months then I likely do not get the same output and it wouldn't be surprising if it does not build at all.
- tomrod 4y agoCorrect and agreed, hence my "but works" portion of the comment! The notion of portability is Docker's bread and butter. With proper version pinning you _might_ get lucky with repeatability too. Most people anticipate repeatability to be part of portability, but it really is a distinct notion.
- 4y ago
- speed_spread 4y agoIf Nix is too much but you still want an immutable distro, look into Fedora Silverblue (or Kinoite). It offers some of the advantages of Nix in a more approachable fashion.
- AnIdiotOnTheNet 4y agoSeconding this. I ran Silverblue until recently due to some bugs in Kinoite but switched as soon as possible because GNOME sucks. Its the first distro I've used in 20 years that doesn't feel like a stiff wind could cause the whole thing to collapse and catch fire in an unrecoverable way, while still allowing me to run any software I want instead of just what is in some limited curated repo. And unlike Nix, I didn't need to learn a new language to use it.
- smoldesu 4y agoDoes Silverblue still support traditional package managers? An immutable OS seems nice and I like Bubblewrap's isolation, but I would never switch full-time to an all-Flatpak distro...
- enticeing 4y agoYou can install all the usual software from the Fedora repos, but you need to do a reboot before you can use it. See the Package Layering section here: https://docs.fedoraproject.org/en-US/fedora-silverblue/getting-started/ https://docs.fedoraproject.org/en-US/fedora-silverblue/getti...
- speed_spread 4y ago(for other readers) This is only required for packages that require low-level integration - services, virtualization, drivers. The Silverblue big idea is that you should make maximum use of flatpaks and "toolbox" containerized environments, all which "float" over the base OS. Once everything's been "layered" to your liking, you rarely touch the base OS anymore except for updates.
- 4y ago
- SuperSandro2000 4y agoNixOS has a steep learning curve but if you start to climb it, it is probably the strongest distro right now especially if you want to customize things and have it reproducible.
- mamcx 4y ago> What are its weaknesses? I think is easier to see this with what is their main strength: A declarative/reproducible OS setup. Is AMAZING for server deployment (like what you put in a docker file but that not mutate after it). But I don't think will be so nice for day to day use. That is where a mutation OS is easier.
- SuperSandro2000 4y agoAs soon as you have multiple machines with shared configs it gets really attractive again.
- funcDropShadow 4y agoMy desktop development workstation is running on NixOS. I am always updating it as soon as possible because I know I can revert everything. That is damn nice.
- aidenn0 4y agoI don't agree. NixOS has many weaknesses, but a server/desktop divide is not one of them. Fwiw the best summary of "should I use NixOS" is https://news.ycombinator.com/item?id=33679621 https://news.ycombinator.com/item?id=33679621
- JamesSwift 4y agoThe biggest weakness is the built-in expectations it has on how packages install/operate. There are some patterns that will not fit into the box easily (e.g. native-compiled gems/node packages). Also since things are declarative, that means things like e.g. updating bash aliases has additional friction vs the traditional way of editing the file directly.
- kaba0 4y ago> updating bash aliases has additional friction vs the traditional way of editing the file directly Additional friction (not much imo), but you will actually be able to move that bash plugin that does that thing you didn’t even realize were not available in a vanilla shell.
- staunch 4y agoNix feels to me like a cool but somewhat hacky v1 of a really great idea. I'm hoping someone creates a much more elegant successor. If Nix is CVS or even Subversion, I'm hoping for Git.
- thomastjeffery 4y agoThe neat thing about the functional design of Nix is that you don't have to reinvent the wheel: just make better steering. Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.
- pxc 4y ago> Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest. Tweaking a few NixOS modules it replacing a package is easy, but neither the Nix codebase nor Nixpkgs is characterized by perfect modularity or uniform layering.
- JamesSwift 4y agoWhat? Have you used the old nix cli? It absolutely dominates Git in the frequency of "how do I do that again?" /s
- chriswarbo 4y agoMaybe take a look at Guix? (I don't use it, but it sounds like what you describe)
- aidenn0 4y agoI'm just going to link to the best HN comment I've seen on this topic https://news.ycombinator.com/item?id=33679621 https://news.ycombinator.com/item?id=33679621
- mindslight 4y agoNo mention of the fucky /nix/store paths for everything? I haven't used a lot of other distros, especially recent ones (my list: Slackware, Redhat, Ubuntu, Debian), but Nix is a drastic departure from the standard FHS and Linux conventions. Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring, and if we want converts we have to manage expectations properly!
- pxc 4y agoThat's true! Whenever I demo Nix for someone in person, the first trick I do is > Look ma, no /usr/lib and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve. I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glorious Nix symlink forest under /nix/var/nix/profiles for the first time. :)
- mindslight 4y agoMy personal administration involved a lot of digging through installed software's FHS to figure out how things worked. Especially coming up through Slackware. It's probably a learning style thing. Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere). A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program. So I see that departure as a pretty huge one, that will affect someone learning Linux on NixOS for many years, as they need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs. Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else. As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity". (Also, that sounds like a great approach to explaining NixOS!)