55 ms·

My NixOS Desktop Flow

280 points by pcr910303 7y ago

kristopolous 7y ago
Nice layout. A fundamental reengagement with the concept of "formatted hypertext".
- snicker7 7y ago
  https://hackcss.egoist.moe/ https://hackcss.egoist.moe/
- nloomans 7y ago
  I agree! Showing a bit of the markdown in the rendered text really gives the page a nice hacky feel. I'm doing something similar on my website[1] but this blog looks a lot nicer then mine! The biggest problem on my version I think is that links aren't obvious enough in dark mode, but I like the links used here so I'll look into that. [1]: https://noahloomans.com/tutorials/makefile/ https://noahloomans.com/tutorials/makefile/ (The contents of this page is intended for the other students at my college and probably doesn't make a lot of sense standalone)
  - aaron-lebo 7y ago
    Noah, I love that menu. Nice work!
_ytji 7y ago
>> Nix and NixOS ruined me. It’s hard to go back. 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.
- k_bx 7y ago
  You can use Nix on your Linux (Ubuntu, maybe Gentoo) for the projects you want without going full NixOS.
  - danieldk 7y ago
    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.
    - k_bx 7y ago
      Right, sorry, forgot to mention macOS even though I’m using Nix there myself for our commercial project’s dependencies
    - asdf-asdf-asdf 7y ago
      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?
      - danieldk 7y ago
        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.
ylyn 7y ago
I think Nix/NixOS is a great idea. But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work. Since GCC isn't really meant to work with headers spread across a varying set of directories, you end up with this wrapper for every GCC invocation: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... And this just doesn't sit well with me: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
- jchw 7y ago
  I agree there’s a lot of hacks and maybe the current model of Nix as it is today won’t survive. However, I think several aspects of the Nix concept are highly novel and worth pursuing, and there’s no way to get there without large intermediary steps. NixOS and GuixSD represent, to me, some of the most exciting OS research not aimed squarely at security. It’s difficult to fully appreciate until you’ve really exploited it well. The hacks that are needed today, indeed, are a bit of a turn off, but I do still find a remarkable amount of stuff ends up working well in the model. As a personal example, NixOS not managing dotfiles feels like it would be a huge deal, but actually it isn’t as big of a deal because you can just manage system level configs; for example, my SwayWM config is stored at /etc/sway/config and so forth, and I can neatly provide Nix store paths in my config files through substitution, allowing me to keep my global namespace cleaner. (Various approaches for per user config can then be applied as needed, such as referencing global configs from dotfiles, or wrapper scripts that have logic.) My opinion is that it’s unlikely NixOS or Nix are the stable, hermetic utopia we’re looking for, but they or a successor may very well become it, and the exploration done today is an important part of the necessary research. I’m already excited by things you can do today that are not well documented, like cross compiling to other platforms almost seamlessly (for example, MinGW has worked quite well in my experience.)
  - mlinksva 7y ago
    There also is a NixOS derivative OS project "aimed squarely at security" https://spectrum-os.org/ https://spectrum-os.org/
IshKebab 7y ago
I really want to try NixOS but the Nix language is just so damn weird... Why didn't they use a syntax people wouldn't have to actually read a tutorial to learn. E.g. C-style or Python-style? This article has a whole paragraph explaining `with`, but it wouldn't have needed any explanation if they called it `using` or `import`. Same for the script parameters. I have absolutely no idea what this does { pkgs ? import <nixpkgs> { } }: Why not: function main(pkgs: Package = nixpkgs) { } Or something like that. My second issue is that the files clearly aren't machine-editable. There's no sensible way to make a GUI that can edit your hostname if the hostname is defined in some Turing complete functional program. But it definitely beats the design of any other package manager.
- therein 7y ago
  > My second issue is that the files clearly aren't machine-editable. There's no sensible way to make a GUI that can edit your hostname if the hostname is defined in some Turing complete functional program. I don't disagree with the overall argument you are making however on this point alone, they aren't meant to be machine-editable. They are functions, they take arguments. So you can make your module or system configuration or whatever, have unassigned variables and then have your function take them as parameters. Your GUI can invoke this function with arguments from the user input.
- lambdaba 7y ago
  I had a similar feeling for the language and I can assure you you do get used to it, and that it's probably not the syntax that's making it difficult but understanding the programming model. As for not being machine-editable, the nix language has a module system and it's easy to format a file with something that's whatever shape you want and have that machine-editable. Or use any other format and fromJSON etc. functions.
- arianvanp 7y ago
  Would be more like function main(pkgs: Map String Package = (import(sys.path("nixpkgs"))({}))){ } I'm not sure if it's better at this point...
  - 7y ago
alpaca128 7y ago
> I had been using a 2013 Mac Pro for at least 7 years. Assuming the 2013 Mac Pro came out in 2013 I'd say that's at most 7 years.
- rvz 7y ago
  Then you also have those who still use unsupported Mac Pros. I know a friend who was in this dilemma and I asked why they still use it. My friend replied that it still 'just works' and switching to something else isn't worth the effort. By then you can see why when I gave them the choice of either upgrading to the latest version of macOS + H/W upgrade or just installing either Ubuntu/Fedora/etc on a second partition in which both are long winded processes the decision was obvious and clear to them. They didn't care about either solution and rejected both suggestions to carry on with the status quo with great reason: 'If it ain't broke, don't fix it.' So until their favourite app requires a higher version and kills their productiviy, it is enough of a reason for them to upgrade it. A full blown switch to any Linux distro would be the worst decision for my friend, especially NixOS since even with this blogpost it gives little reason why they should bother switching.
YuukiRey 7y ago
Would be nice to mention that you're using home manager for user space package management, if I read your config files correctly. User space package management is a bit of a confusing topic especially since overlays supersede some of the former overrides but the documentation doesn't mention that prominently enough. Also great post and great blog <3
aeurielesn 7y ago
I just tried out Nix (not NixOS) earlier this week in the context of creating Docker images. Getting started with Nix is easy but getting the hang of the Nix language isn't so much (despite having a reference manual.) My best advice to get you started with the Nix language is looking at what's already available in <nixpkgs>[1]. Going fast-forward, my Docker image got a lot of unnecessary files in it (include headers, configuration files, /etc/passwd, /etc/group, etc.) I have to come back to it and see how I can improve this. P.S. On the other hand, I succeeded creating a minimal Docker image using magicpak[2]. [1]: https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/libraries https://github.com/NixOS/nixpkgs/tree/master/pkgs/developmen... [2]: https://github.com/coord-e/magicpak https://github.com/coord-e/magicpak
gigatexal 7y ago
The best part of Debian and Ubuntu is package maintainers do all the heavy lifting for you. So a simple apt get install package is all I need. This looks like having to write packages again and that’s the very reason I use a Debian based distribution is for apt
- eeh 7y ago
  I can see why the blog post gives the impression that packaging is involved, because the author is creating packages! However, what's novel is that the author is packaging their own software (a blog). A Debian and Ubuntu maintainer isn't going to package Joe Blogg's blog. NixOS also has package maintainers, which the author of this blog post relies on (see "nixos.graphviz"). Traditional distributions also allow you to package your own software. The difference between a traditional distribution and NixOS is that NixOS makes packaging your own software (and config) easily and safely enough to treat as first-class citizens along with the distro's own packages. So much so that I don't think of NixOS packages as "packages". Rather, I just see them as config/code.
  - xena 7y ago
    I mainly nix-ified my blog build to make a docker image that is as small as possible. Compare my super-optimised dockerfile results: $ docker images | grep xena xena/christinewebsite latest eb8c27a1a5d2 12 seconds ago 121MB To the naiive nix results: $ docker images | grep xena xena/christinewebsite latest b087ad7fb924 50 years ago 102MB This image ends up only including my blog (statically compiled), ca certificates (because of the patreon integration), time zone data files (because of the go time package), iana port numbers (something to do with the go net package) and mailcap (for some reason). It's puny!
    - asdf-asdf-asdf 7y ago
      so, what makes up the 19MB difference? (i assume it's not caused by the nix one being MUCH older :-) couldn't you simply do a multi-stage docker-image (in the not-nix situation),where you just copy over the go binary into the final docker-image, and add the needed files?
xena 7y ago
Author of the article here. Ask me anything!
- chakerb 7y ago
  Can you share the list of hardware you choose to build your tower?
  - xena 7y ago
    Something like this: https://ca.pcpartpicker.com/list/9jgTq3 https://ca.pcpartpicker.com/list/9jgTq3 The SATA SSD is for Windows.
  - dr3adward 7y ago
    Why? Do you for some reason assume that the author is an expert on hardware and authority on picking the best, most compatible parts? Do you not have your own specific requirements and use cases? It is better you do some research on your own end and learn to pick the parts that will best work for you. Ryzen CPUs run hot, the stock cooler is garbage. The tower is not silenced, and with the stock cooler you will have a lot of fan noise both from the CPU fan and chassis fans. Ryzen 3900 is a much better choice than the 3600, especially for CPU intensive work like compilation. The M2 disk is on the slow end. The motherboard supports 128 GB RAM, but now all 4 DIMM sockets are used for 64 GB. You should go with 2x32 GB, in case you have a need for more RAM later on. There are more issues here, but those are the worst.
    - chakerb 7y ago
      Simply to compare the author list to mine and check for compatibility issue if needed. Ryzen 3000 series CPUs are known to have issues with systemd while booting ( which affect nixos https://github.com/NixOS/nixpkgs/issues/64443 https://github.com/NixOS/nixpkgs/issues/64443). And the fact that it works for the author helps me deciding that 3700x suits my needs and budget without worrying that i will need to use old versions of NixOS. Also the suggestions that you gave are valid, but that doesn't mean I will go with them because as you said I'm doing my own research. For example I will stick with the stock cooler because it got good reviews and my budget won't allow another cooler for now.
offmycloud 7y ago
I gave NixOS a try recently, and generally liked it. I could get over the arcane packaging language and hit-or-miss documentation. The red flag for me was the inattention to software freedom. Most other distros like Debian or Fedora have source packages or SRPMs that include everything needed to rebuild a package from scratch. Nix pushes binary packages, and even stores them in S3, but with no matching source packages that I could find. They tout reproducible builds, but really haven't considered to how to deal with the "disapearing sources" problem, including vanishing git repositories. I grabbed some URLs that pointed to sources in the old Nix Tarball Cache and they all returned 404. Nix has no longer term plan to preserve package sources.
- dTal 7y ago
  I've noticed this seems to be a problem with F-Droid as well. Seemingly half the packages are marked "the source is no longer available", which renders them non-free in practical terms. It's great that they tell you, but why is it a problem at all?
  - est31 7y ago
    F-Droid packager here (gotten inactive though so maybe my knowledge is outdated, beware). F-Droid actually does store source code of the package. A tarball for each published version. Not like what debian's git mirrors have, but already some progress. "The source is no longer available" means that the upstream sources have vanished and no updates can be obtained. The tarballs are still available. The build that F-Droid executes comes in two phases: one to obtain source code, which then gets packaged, the second phase to execute the build. Note however that the build execution phase does have network access and many builds actually do use the network to download dependencies, so its certainly not as advanced as Debian. I'd put what F-Droid is doing to somewhere between Nix OS (which doesn't have source packages at all) and Debian (whose source packages are complete so that no internet is needed). For F-Droid, one could maybe think about running build twice: first with internet enabled but a recording proxy in between, and second with internet disabled but that proxy replaying the recorded file. That file is then published with the sources. There are formats for this, e.g. warc. It would be a partial improvement although it might still download binaries etc instead of source code and patching the source code would be also hard (tools would have to be developed to do this), hurting the FLOSS spirit.
mjhoy 7y ago
Nix is very cool, and I encourage anyone to at least install nix on their machine and try it out. I started using it on my Mac, mostly to set up a Haskell environment, which at the time meant quicker builds than using other tools, due to the binary cache. I now use it for python, scala, emacs and basically wherever else I can get away with not using Homebrew. I share the config [1] between my work and personal machine. This works really well: it's just a git pull, and a `nix-env -iA nixpkgs.devEnv` and my environment is updated (and I can easily roll back to the previous state if something goes wrong). It does take a lot of up-front investment, learning a new language and paradigm, but once things are working they tend to stay working. [1]: https://github.com/mjhoy/dotfiles/blob/master/nix/nixpkgs/config.nix https://github.com/mjhoy/dotfiles/blob/master/nix/nixpkgs/co...
k__ 7y ago
I tried to use NixOS a few years ago, and it was reallly hard. The Nix language didn't have good tutorials and I couldn't use any of my NPM skills with the Nix package manager. I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers. Did any of this happen? I really think NixOS and GuixSD are the next generation Linux distributions and want to use it.
- globular-toast 7y ago
  Maybe try Guix because there is a wealth of documentation out there for scheme. Since it's a real language you can also consider it an investment as it will make you a better programmer.
  - k__ 7y ago
    Yes, I read about that, but free software is always a bit of a struggle.
    - aijony 7y ago
      I suggest either using Nonguix [1], or installing Guix on top of Debian or any other binary distribution if the free software part or small ecosystem is going to prevent you from trying a very great piece of software. [1] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
- Shoue 7y ago
  > I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers. I'm guessing this is about `nix` and `nix-env` having poor interfaces and lacking e.g `nix install` – those aren't _really_ meant to do package management, because it's an imperative approach akin to Apt. I haven't touched `nix-env` for actual package management in over a year now. You should instead be writing your system-level package dependencies and services in your configuration.nix, your user-level package dependencies and services in home-manager's home.nix, and if you just need to use a package quickly, you should use `nix run nixpkgs.hello -c hello` or `nix-shell -p hello`, and if you're trying to set up a dev env for a project you should be using direnv or lorri. nix-env pollutes your environment and causes headaches when/if you add the same packages you have installed there to your declarative files. >I couldn't use any of my NPM skills with the Nix package manager. You can – look into direnv and lorri, they let you handle system-level dependencies while NPM handles its own libraries, on a per-project basis. This is IMO the best contemporary way to do a developer environment.
lidHanteyk 7y ago
For all the folks that can't get into Nix because they find it obtuse: Okay, fine, don't use it. Nobody is forcing you to adopt it, and moreover, we don't want an influx of folks who are only embracing the situation reluctantly and cannot respect the Nix way of doing things. The top complaints I've seen in this comment section so far are about the Nix expression language. It's not appealing, hard to learn, weird, etc. Okay, good. If learning a single simple DSL is completely off-putting, then we should probably keep the DSL for a while, since it seems to be effective at weeding out folks who aren't interested in learning about the theory of package management, while allowing the rest of us to get things done. The next top complaints I've seen are about how nixpkgs is hacky, lacking, or doesn't well-support traditional UNIX tools. Well, to the extent that we can force traditional UNIX tools to respect package-capability discipline, we're doing quite well. According to Repology [0][1], nixpkgs is amongst the top 5 repositories for number of packages, number of maintainers, number of fresh packages, and percentage of up-to-date packages. Seriously, before you downvote or reply, stop and look at [1]. Look at how nixpkgs is literally off the charts compared to almost any other distro. The only close contender is AUR, which doesn't have the reproducibility or less-insecure build model of Nix. [0] https://repology.org/ https://repology.org/ [1] https://repology.org/graph/map_repo_size_fresh.svg https://repology.org/graph/map_repo_size_fresh.svg
LockAndLol 7y ago
$ docker run --rm --name temp -it nixos/nix c343661ad923:/# nix search graphviz warning: using cached results; pass '-u' to update the cache error: no results for the given search term(s)! c343661ad923:/# nix search -u graphviz error: no results for the given search term(s)! Well... that's not off to a good start. I don't mind learning something new, but nix just seems super convoluted. In many other distros the package manager makes it pretty easy to get a graphical environment running or even to install and configure software. Not nix. Nix is far from easy to use or install https://invidio.us/watch?v=QujRHErFG4w https://invidio.us/watch?v=QujRHErFG4w
- carapace 7y ago
  That video is two years old, and the comments make it clear that dude didn't RTFM, so... YMMV.
skyfaller 7y ago
Does anyone know if Ansible works on NixOS? I understand that Ansible requires a working Linux system before it can operate, but it would be nice to use some of my existing Ansible playbooks rather than rewriting everything in Nix.
- majewsky 7y ago
  Ansible could theoretically be made to work with NixOS by having it manipulate the /etc/nixos/configuration.nix instead of touching files and starting services directly. But you're still going to run into so many incompatibilities between NixOS and other Linuxes (esp. because of the different filesystem layout) that it's probably not a path worth pursuing. It's always a recipe for disaster to have two configuration management systems competing for power on one system, and NixOS very much is a configuration management system.
- takeda 7y ago
  Ansible would work, but to use NixOS properly or would have to only modify /etc/nixos/configuration.nix and run nixos-rebuild switch after that. Any other changes are not recommend, unless it is home directory and you don't use home-manager. At that point you would correctly wonder why would you use ansible it is like running ansible to run saltstack. NixOS essentially makes these tools redundant. It is also more powerful. Imagine that you wanted to for example use libressl instead of openssl with python, because it is more secure, or maybe introduce your custom patch put use different configure option. With other tools like ansible, you would start with building custom package(s), then place that package in repo like artifactory. Then write your ansible definitions, you would add artifactory to the OS uninstall the old package install a new one (also worry that replacing your Python package with a custom version could break other stuff, you might end up installing your Python under a different path). If you want to revert it, removing these steps is not enough, you would need to write steps that would revert it. In Nix, you make change to the disk that is being installed. If nix won't find precompiled package in its repo it will automatically pull compiler and compile it. If you configure caching after finishing it it would populate the cache so other machines no longer would need to compile it. And if something else is using old Python version it won't be affected at all, it will continue using what it was using. If you remove your change nix will restore back the previous state, no need writing rules about restoring it. Another killer feature is that nix will never leave your packages in half state, everything is atomic. So if you incorporate many changes you either get all or nothing. It also guarantees that all machines using particular configuration are identical, I often seen rules working on one machine and not working in another (different OS version, maybe previous state was not applied everywhere or somebody made changes by hand).
Datenstrom 7y ago
I spent a lot of time setting up Nix and NixOS to replicate my current dotfile environment on Debian I've spent years developing and which I can deploy on a new machine with a one liner. I really like Nix and found their DSL fairly easy to pick up, I didn't keep it for my desktop, workstation, or servers though for a few reasons. 1) Package availability: this is by far the largest reason. I frequently need to use software or specific versions that are just not available and while I did create some packages myself it is just too much work when I need to get something done. 2) Language Documentation. 3) I still need to use cargo and pip anyway. 4) Even when packages were available they often lacked the configuration options I needed and I would have to fork and edit them anyway. I do think Nix is a lot better than current systems though.
- MarcScott 7y ago
  I use pip all the time in NixOS. I just run it in a nix-shell, and install from a requirements.txt when the Python package is not in the nix packages.
  - takeda 7y ago
    I created a template which to the extent that I used it completly replaces the need for virtualenv and integrates well with declarative setuptools: https://github.com/takeda/example_python_project https://github.com/takeda/example_python_project With direnv + lorri when you enter the directory, it is as if you enter virtualenv, your code behaves as if it is installed with pip -e, if you call nix build it takes care of all dependencies and the command created in bin/ behave like binaries, have all dependencies needed. I plan to update nixpkgs code that processes setup.cfg and make this less trivial example when I find some time.
globular-toast 7y ago
I would use Guix rather than NixOS, but I wonder if I would feel as in control as I do as a Gentoo user. I suppose I should set aside some time to try it in a VM.
- carapace 7y ago
  I tried them both last week. All I did was spin up a server, connect through ssh. NixOS was fine. Standard systemd (bleah!) commands to enable and then start sshd. (Because "enabling" and "starting" are two different things, yeah?) Guix required editing a file and rebuilding the OS. This wasn't well documented, and they had forgotten to include the file in the VM image. (The manual says edit /etc/config.scm (IIRC) but it's not there. There's a bug open for it.) I had to find a copy of the VM config and hack it up to work, but after that everything went smoothly. (Can you taste the irony on that last sentence? I am being sardonic. The experience was hugely demotivating.) Anyhoo, FWIW, Nix seems great but I don't like the language (and I don't like systemd, and no, I don't want to talk about it.) Guix seems like it will approach being a new kind of Lisp Machine, Guile lisp is fine, and integrated into other parts of the OS. (Shepard seems fine.) But having to edit a file and rebuild the OS to get ssh access was gnarly. All in all, something like NixOS or Guix seems to me to be the way of the future. Other build/package managers seem just stupid and dangerous in comparison (like operating a chainsaw without kevlar chaps. I have two legs thanks to kevlar chaps. Always wear your chaps kids!)
frabbit 7y ago
I don't understand the conjunction of the following two phrases in the article: > * Nix goes a step further by disallowing package* > * builds to access the internet. This allows Nix* > * packages to be a lot more reproducible;* and > * The src attribute tells Nix where the source * > * code of the package is stored. Sometimes this* > * can be a URL to a compressed archive on the* > * internet,
- tridentlead 7y ago
  The idea is that as long as the downloaded source file matches the hash all inputs are deterministic and so is the build overall.
  - scintill76 7y ago
    Right. More specifically, Nix itself can download files in this way, but the build scripts (in this case, the mkdir & cp part) are not allowed access so that the build is deterministic.
- takeda 7y ago
  First paragraph talks about build. The build by default happens in sandbox, with many things disabled to force reproducibility. It sometimes makes things annoying, for example there was one Ruby package that was downloading a file during build, so whomever was making a derivation needed to download it in advance) The second paragraph talks about fetching sources which nix does before build starts, each source is required to be provided with hash, this ensures that it is an identical file that author of the derivation used.
jancsika 7y ago
ergonomics oversight: /nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv should be /nix/store/gruvbox-css-c99n4ixraigf4jb0jfjxbkzicd79scpj.drv
- takeda 7y ago
  They actually answer that in FAQ: https://nixos.wiki/wiki/FAQ https://nixos.wiki/wiki/FAQ
avodonosov 7y ago
The functional package management sounds good and clean in theory, but when I tried nixos Firefox had terrible fonts. Because of some config files in /etc influencing it indirectly. So pograms in nixos influence each other via global configs, they are not isolated. I was unabne to fix that.
towb 7y ago
Used NixOS for a short bit, it was easy to get going with and most things works good out of the box with a pretty simple config. Didn't want to replace my linux knowledge with something this different though so moved back to something more normal for my desktop. Thinking about using NisOS on my home server though, already have the configuration.nix to get it up and running very fast which is nice obviously.
dimitar 7y ago
I tried Nixos but I found out it is really easy to setup a system but then it gets harder when you get off the beaten path by messing with npm or steam for example. I think a winning approach would be to manage the OS using nix, but let the user do more imperative stuff in his home directory. Here is an illustration of how one is supposed to use a package manager for a programming language (in this example npm) in Nixos: https://unix.stackexchange.com/a/381797 https://unix.stackexchange.com/a/381797 And here is an article about the hoops needed to run Steam games: https://nixos.wiki/wiki/Steam https://nixos.wiki/wiki/Steam
- takeda 7y ago
  That's how it works normally, but once you get to the point of having the system configured declaratively, people strive for more. The home-manager as far as I know is not official component, but a lot of people add it because they love the idea. I think anyone who is interested in Nix should start with Nix Pills[1] they are concentrating on just nix and nixpkgs, but I think it is minimum getting started. Once you are familiar how to build nix derivations, adding custom components is not that hard. [1] https://nixos.org/nixos/nix-pills/index.html https://nixos.org/nixos/nix-pills/index.html
- Shoue 7y ago
  Regarding NPM, you can do user-level "global" installs on NixOS, see toraritte's answer in the same Stackexchange question. NPM should work fine within a project, but if you need specific dynamic libraries that a Node package implicitly depends on, you can specify them using Nix, and this means you automate the process of installing system dependencies for anyone else who touches the project too. While you could use nix-shell, it is IMO a dated and very manual way, preferably you'd use direnv or lorri to automatically load a default.nix or shell.nix from your project root directory where libraries have been specified in `buildInputs`.
tbrock 7y ago
You know, for all the nerding out about how package managers do their work and how “correct” they are, they all still pale in comparison to how easy and intuitive homebrew is to use. I’m running Linux and pacman/yay are great but if something is screwed up I miss being able to run brew doctor to figure out what’s wrong or add a tap for some weird thing here or there. I know I’ll get crucified for saying it but usability counts for a lot and apt, dpkg, yum, dnf, and yes, even nix suck. All the correctness and perfection don’t matter if nobody uses or wants to use your software.
- NateEag 7y ago
  Yeah, UX matters, but reliability and robustness are part of UX, too. I've had innocuous-seeming brew commands foul up my working environment. I don't think Nix would do that in the same way. Specifically, updating a package in Homebrew can have unexpected knock-on effects due to updating dependencies. Left my working environment badly hosed at one point last year. Nix's design should ensure that all such updates leave everything else stable, as I understand it. I've been tempted to try it or Guix for years - I was delighted when I discovered Nix existed. I'd been thinking about the problems with existing package managers for years, and both Nix and Guix have most of what I felt was missing from the existing tools, along with some other really cool attributes I hadn't thought of at all.
- t0astbread 7y ago
  I haven't used a Mac so I don't know what UX breakthroughs I might be missing but I think even for beginners, apt and the like are fine, given how much assistance software and online help there is for them. It does take you a while to understand everything about it but that's always the case with power tools. You'll likely not need to dive into the guts of your package manager on day one anyways.
  - tbrock 7y ago
    No. apt-get install for installing and apt-cache search for searching? That’s... not discoverable to say the least: how about brew install and brew search? Didn’t know they were there? No problem you’ll see they are available commands when you run brew.
indigodaddy 7y ago
Christine, very attractive and minimal site. Well done. I see on your “new site” blogpost you mention “This content is markdown rendered by Purescript.” ..have you considered doing a write up with more detailed information as to how your site is generated or a howto? I think many might be interested. Thanks!

280 points by pcr910303 7y ago

kristopolous 7y ago

Nice layout. A fundamental reengagement with the concept of "formatted hypertext".

snicker7 7y ago
https://hackcss.egoist.moe/ https://hackcss.egoist.moe/
nloomans 7y ago
I agree! Showing a bit of the markdown in the rendered text really gives the page a nice hacky feel. I'm doing something similar on my website[1] but this blog looks a lot nicer then mine! The biggest problem on my version I think is that links aren't obvious enough in dark mode, but I like the links used here so I'll look into that. [1]: https://noahloomans.com/tutorials/makefile/ https://noahloomans.com/tutorials/makefile/ (The contents of this page is intended for the other students at my college and probably doesn't make a lot of sense standalone)
- aaron-lebo 7y ago
  Noah, I love that menu. Nice work!

_ytji 7y ago

>> Nix and NixOS ruined me. It’s hard to go back. 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.

k_bx 7y ago
You can use Nix on your Linux (Ubuntu, maybe Gentoo) for the projects you want without going full NixOS.
- danieldk 7y ago
  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.
  - k_bx 7y ago
    Right, sorry, forgot to mention macOS even though I’m using Nix there myself for our commercial project’s dependencies
  - asdf-asdf-asdf 7y ago
    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?
    - danieldk 7y ago
      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.

ylyn 7y ago

I think Nix/NixOS is a great idea. But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work. Since GCC isn't really meant to work with headers spread across a varying set of directories, you end up with this wrapper for every GCC invocation: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... And this just doesn't sit well with me: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

jchw 7y ago
I agree there’s a lot of hacks and maybe the current model of Nix as it is today won’t survive. However, I think several aspects of the Nix concept are highly novel and worth pursuing, and there’s no way to get there without large intermediary steps. NixOS and GuixSD represent, to me, some of the most exciting OS research not aimed squarely at security. It’s difficult to fully appreciate until you’ve really exploited it well. The hacks that are needed today, indeed, are a bit of a turn off, but I do still find a remarkable amount of stuff ends up working well in the model. As a personal example, NixOS not managing dotfiles feels like it would be a huge deal, but actually it isn’t as big of a deal because you can just manage system level configs; for example, my SwayWM config is stored at /etc/sway/config and so forth, and I can neatly provide Nix store paths in my config files through substitution, allowing me to keep my global namespace cleaner. (Various approaches for per user config can then be applied as needed, such as referencing global configs from dotfiles, or wrapper scripts that have logic.) My opinion is that it’s unlikely NixOS or Nix are the stable, hermetic utopia we’re looking for, but they or a successor may very well become it, and the exploration done today is an important part of the necessary research. I’m already excited by things you can do today that are not well documented, like cross compiling to other platforms almost seamlessly (for example, MinGW has worked quite well in my experience.)
- mlinksva 7y ago
  There also is a NixOS derivative OS project "aimed squarely at security" https://spectrum-os.org/ https://spectrum-os.org/

IshKebab 7y ago

I really want to try NixOS but the Nix language is just so damn weird... Why didn't they use a syntax people wouldn't have to actually read a tutorial to learn. E.g. C-style or Python-style? This article has a whole paragraph explaining `with`, but it wouldn't have needed any explanation if they called it `using` or `import`. Same for the script parameters. I have absolutely no idea what this does { pkgs ? import <nixpkgs> { } }: Why not: function main(pkgs: Package = nixpkgs) { } Or something like that. My second issue is that the files clearly aren't machine-editable. There's no sensible way to make a GUI that can edit your hostname if the hostname is defined in some Turing complete functional program. But it definitely beats the design of any other package manager.

therein 7y ago
> My second issue is that the files clearly aren't machine-editable. There's no sensible way to make a GUI that can edit your hostname if the hostname is defined in some Turing complete functional program. I don't disagree with the overall argument you are making however on this point alone, they aren't meant to be machine-editable. They are functions, they take arguments. So you can make your module or system configuration or whatever, have unassigned variables and then have your function take them as parameters. Your GUI can invoke this function with arguments from the user input.
lambdaba 7y ago
I had a similar feeling for the language and I can assure you you do get used to it, and that it's probably not the syntax that's making it difficult but understanding the programming model. As for not being machine-editable, the nix language has a module system and it's easy to format a file with something that's whatever shape you want and have that machine-editable. Or use any other format and fromJSON etc. functions.
arianvanp 7y ago
Would be more like function main(pkgs: Map String Package = (import(sys.path("nixpkgs"))({}))){ } I'm not sure if it's better at this point...
- 7y ago

alpaca128 7y ago

> I had been using a 2013 Mac Pro for at least 7 years. Assuming the 2013 Mac Pro came out in 2013 I'd say that's at most 7 years.

rvz 7y ago
Then you also have those who still use unsupported Mac Pros. I know a friend who was in this dilemma and I asked why they still use it. My friend replied that it still 'just works' and switching to something else isn't worth the effort. By then you can see why when I gave them the choice of either upgrading to the latest version of macOS + H/W upgrade or just installing either Ubuntu/Fedora/etc on a second partition in which both are long winded processes the decision was obvious and clear to them. They didn't care about either solution and rejected both suggestions to carry on with the status quo with great reason: 'If it ain't broke, don't fix it.' So until their favourite app requires a higher version and kills their productiviy, it is enough of a reason for them to upgrade it. A full blown switch to any Linux distro would be the worst decision for my friend, especially NixOS since even with this blogpost it gives little reason why they should bother switching.

YuukiRey 7y ago

Would be nice to mention that you're using home manager for user space package management, if I read your config files correctly. User space package management is a bit of a confusing topic especially since overlays supersede some of the former overrides but the documentation doesn't mention that prominently enough. Also great post and great blog <3

aeurielesn 7y ago

I just tried out Nix (not NixOS) earlier this week in the context of creating Docker images. Getting started with Nix is easy but getting the hang of the Nix language isn't so much (despite having a reference manual.) My best advice to get you started with the Nix language is looking at what's already available in <nixpkgs>[1]. Going fast-forward, my Docker image got a lot of unnecessary files in it (include headers, configuration files, /etc/passwd, /etc/group, etc.) I have to come back to it and see how I can improve this. P.S. On the other hand, I succeeded creating a minimal Docker image using magicpak[2]. [1]: https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/libraries https://github.com/NixOS/nixpkgs/tree/master/pkgs/developmen... [2]: https://github.com/coord-e/magicpak https://github.com/coord-e/magicpak

gigatexal 7y ago

The best part of Debian and Ubuntu is package maintainers do all the heavy lifting for you. So a simple apt get install package is all I need. This looks like having to write packages again and that’s the very reason I use a Debian based distribution is for apt

eeh 7y ago
I can see why the blog post gives the impression that packaging is involved, because the author is creating packages! However, what's novel is that the author is packaging their own software (a blog). A Debian and Ubuntu maintainer isn't going to package Joe Blogg's blog. NixOS also has package maintainers, which the author of this blog post relies on (see "nixos.graphviz"). Traditional distributions also allow you to package your own software. The difference between a traditional distribution and NixOS is that NixOS makes packaging your own software (and config) easily and safely enough to treat as first-class citizens along with the distro's own packages. So much so that I don't think of NixOS packages as "packages". Rather, I just see them as config/code.
- xena 7y ago
  I mainly nix-ified my blog build to make a docker image that is as small as possible. Compare my super-optimised dockerfile results: $ docker images | grep xena xena/christinewebsite latest eb8c27a1a5d2 12 seconds ago 121MB To the naiive nix results: $ docker images | grep xena xena/christinewebsite latest b087ad7fb924 50 years ago 102MB This image ends up only including my blog (statically compiled), ca certificates (because of the patreon integration), time zone data files (because of the go time package), iana port numbers (something to do with the go net package) and mailcap (for some reason). It's puny!
  - asdf-asdf-asdf 7y ago
    so, what makes up the 19MB difference? (i assume it's not caused by the nix one being MUCH older :-) couldn't you simply do a multi-stage docker-image (in the not-nix situation),where you just copy over the go binary into the final docker-image, and add the needed files?

xena 7y ago

Author of the article here. Ask me anything!

chakerb 7y ago
Can you share the list of hardware you choose to build your tower?
- xena 7y ago
  Something like this: https://ca.pcpartpicker.com/list/9jgTq3 https://ca.pcpartpicker.com/list/9jgTq3 The SATA SSD is for Windows.
- dr3adward 7y ago
  Why? Do you for some reason assume that the author is an expert on hardware and authority on picking the best, most compatible parts? Do you not have your own specific requirements and use cases? It is better you do some research on your own end and learn to pick the parts that will best work for you. Ryzen CPUs run hot, the stock cooler is garbage. The tower is not silenced, and with the stock cooler you will have a lot of fan noise both from the CPU fan and chassis fans. Ryzen 3900 is a much better choice than the 3600, especially for CPU intensive work like compilation. The M2 disk is on the slow end. The motherboard supports 128 GB RAM, but now all 4 DIMM sockets are used for 64 GB. You should go with 2x32 GB, in case you have a need for more RAM later on. There are more issues here, but those are the worst.
  - chakerb 7y ago
    Simply to compare the author list to mine and check for compatibility issue if needed. Ryzen 3000 series CPUs are known to have issues with systemd while booting ( which affect nixos https://github.com/NixOS/nixpkgs/issues/64443 https://github.com/NixOS/nixpkgs/issues/64443). And the fact that it works for the author helps me deciding that 3700x suits my needs and budget without worrying that i will need to use old versions of NixOS. Also the suggestions that you gave are valid, but that doesn't mean I will go with them because as you said I'm doing my own research. For example I will stick with the stock cooler because it got good reviews and my budget won't allow another cooler for now.

offmycloud 7y ago

I gave NixOS a try recently, and generally liked it. I could get over the arcane packaging language and hit-or-miss documentation. The red flag for me was the inattention to software freedom. Most other distros like Debian or Fedora have source packages or SRPMs that include everything needed to rebuild a package from scratch. Nix pushes binary packages, and even stores them in S3, but with no matching source packages that I could find. They tout reproducible builds, but really haven't considered to how to deal with the "disapearing sources" problem, including vanishing git repositories. I grabbed some URLs that pointed to sources in the old Nix Tarball Cache and they all returned 404. Nix has no longer term plan to preserve package sources.

dTal 7y ago
I've noticed this seems to be a problem with F-Droid as well. Seemingly half the packages are marked "the source is no longer available", which renders them non-free in practical terms. It's great that they tell you, but why is it a problem at all?
- est31 7y ago
  F-Droid packager here (gotten inactive though so maybe my knowledge is outdated, beware). F-Droid actually does store source code of the package. A tarball for each published version. Not like what debian's git mirrors have, but already some progress. "The source is no longer available" means that the upstream sources have vanished and no updates can be obtained. The tarballs are still available. The build that F-Droid executes comes in two phases: one to obtain source code, which then gets packaged, the second phase to execute the build. Note however that the build execution phase does have network access and many builds actually do use the network to download dependencies, so its certainly not as advanced as Debian. I'd put what F-Droid is doing to somewhere between Nix OS (which doesn't have source packages at all) and Debian (whose source packages are complete so that no internet is needed). For F-Droid, one could maybe think about running build twice: first with internet enabled but a recording proxy in between, and second with internet disabled but that proxy replaying the recorded file. That file is then published with the sources. There are formats for this, e.g. warc. It would be a partial improvement although it might still download binaries etc instead of source code and patching the source code would be also hard (tools would have to be developed to do this), hurting the FLOSS spirit.

mjhoy 7y ago

Nix is very cool, and I encourage anyone to at least install nix on their machine and try it out. I started using it on my Mac, mostly to set up a Haskell environment, which at the time meant quicker builds than using other tools, due to the binary cache. I now use it for python, scala, emacs and basically wherever else I can get away with not using Homebrew. I share the config [1] between my work and personal machine. This works really well: it's just a git pull, and a `nix-env -iA nixpkgs.devEnv` and my environment is updated (and I can easily roll back to the previous state if something goes wrong). It does take a lot of up-front investment, learning a new language and paradigm, but once things are working they tend to stay working. [1]: https://github.com/mjhoy/dotfiles/blob/master/nix/nixpkgs/config.nix https://github.com/mjhoy/dotfiles/blob/master/nix/nixpkgs/co...

k__ 7y ago

I tried to use NixOS a few years ago, and it was reallly hard. The Nix language didn't have good tutorials and I couldn't use any of my NPM skills with the Nix package manager. I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers. Did any of this happen? I really think NixOS and GuixSD are the next generation Linux distributions and want to use it.

globular-toast 7y ago
Maybe try Guix because there is a wealth of documentation out there for scheme. Since it's a real language you can also consider it an investment as it will make you a better programmer.
- k__ 7y ago
  Yes, I read about that, but free software is always a bit of a struggle.
  - aijony 7y ago
    I suggest either using Nonguix [1], or installing Guix on top of Debian or any other binary distribution if the free software part or small ecosystem is going to prevent you from trying a very great piece of software. [1] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
Shoue 7y ago
> I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers. I'm guessing this is about `nix` and `nix-env` having poor interfaces and lacking e.g `nix install` – those aren't _really_ meant to do package management, because it's an imperative approach akin to Apt. I haven't touched `nix-env` for actual package management in over a year now. You should instead be writing your system-level package dependencies and services in your configuration.nix, your user-level package dependencies and services in home-manager's home.nix, and if you just need to use a package quickly, you should use `nix run nixpkgs.hello -c hello` or `nix-shell -p hello`, and if you're trying to set up a dev env for a project you should be using direnv or lorri. nix-env pollutes your environment and causes headaches when/if you add the same packages you have installed there to your declarative files. >I couldn't use any of my NPM skills with the Nix package manager. You can – look into direnv and lorri, they let you handle system-level dependencies while NPM handles its own libraries, on a per-project basis. This is IMO the best contemporary way to do a developer environment.

lidHanteyk 7y ago

For all the folks that can't get into Nix because they find it obtuse: Okay, fine, don't use it. Nobody is forcing you to adopt it, and moreover, we don't want an influx of folks who are only embracing the situation reluctantly and cannot respect the Nix way of doing things. The top complaints I've seen in this comment section so far are about the Nix expression language. It's not appealing, hard to learn, weird, etc. Okay, good. If learning a single simple DSL is completely off-putting, then we should probably keep the DSL for a while, since it seems to be effective at weeding out folks who aren't interested in learning about the theory of package management, while allowing the rest of us to get things done. The next top complaints I've seen are about how nixpkgs is hacky, lacking, or doesn't well-support traditional UNIX tools. Well, to the extent that we can force traditional UNIX tools to respect package-capability discipline, we're doing quite well. According to Repology [0][1], nixpkgs is amongst the top 5 repositories for number of packages, number of maintainers, number of fresh packages, and percentage of up-to-date packages. Seriously, before you downvote or reply, stop and look at [1]. Look at how nixpkgs is literally off the charts compared to almost any other distro. The only close contender is AUR, which doesn't have the reproducibility or less-insecure build model of Nix. [0] https://repology.org/ https://repology.org/ [1] https://repology.org/graph/map_repo_size_fresh.svg https://repology.org/graph/map_repo_size_fresh.svg

LockAndLol 7y ago

$ docker run --rm --name temp -it nixos/nix c343661ad923:/# nix search graphviz warning: using cached results; pass '-u' to update the cache error: no results for the given search term(s)! c343661ad923:/# nix search -u graphviz error: no results for the given search term(s)! Well... that's not off to a good start. I don't mind learning something new, but nix just seems super convoluted. In many other distros the package manager makes it pretty easy to get a graphical environment running or even to install and configure software. Not nix. Nix is far from easy to use or install https://invidio.us/watch?v=QujRHErFG4w https://invidio.us/watch?v=QujRHErFG4w

carapace 7y ago
That video is two years old, and the comments make it clear that dude didn't RTFM, so... YMMV.

skyfaller 7y ago

Does anyone know if Ansible works on NixOS? I understand that Ansible requires a working Linux system before it can operate, but it would be nice to use some of my existing Ansible playbooks rather than rewriting everything in Nix.

majewsky 7y ago
Ansible could theoretically be made to work with NixOS by having it manipulate the /etc/nixos/configuration.nix instead of touching files and starting services directly. But you're still going to run into so many incompatibilities between NixOS and other Linuxes (esp. because of the different filesystem layout) that it's probably not a path worth pursuing. It's always a recipe for disaster to have two configuration management systems competing for power on one system, and NixOS very much is a configuration management system.
takeda 7y ago
Ansible would work, but to use NixOS properly or would have to only modify /etc/nixos/configuration.nix and run nixos-rebuild switch after that. Any other changes are not recommend, unless it is home directory and you don't use home-manager. At that point you would correctly wonder why would you use ansible it is like running ansible to run saltstack. NixOS essentially makes these tools redundant. It is also more powerful. Imagine that you wanted to for example use libressl instead of openssl with python, because it is more secure, or maybe introduce your custom patch put use different configure option. With other tools like ansible, you would start with building custom package(s), then place that package in repo like artifactory. Then write your ansible definitions, you would add artifactory to the OS uninstall the old package install a new one (also worry that replacing your Python package with a custom version could break other stuff, you might end up installing your Python under a different path). If you want to revert it, removing these steps is not enough, you would need to write steps that would revert it. In Nix, you make change to the disk that is being installed. If nix won't find precompiled package in its repo it will automatically pull compiler and compile it. If you configure caching after finishing it it would populate the cache so other machines no longer would need to compile it. And if something else is using old Python version it won't be affected at all, it will continue using what it was using. If you remove your change nix will restore back the previous state, no need writing rules about restoring it. Another killer feature is that nix will never leave your packages in half state, everything is atomic. So if you incorporate many changes you either get all or nothing. It also guarantees that all machines using particular configuration are identical, I often seen rules working on one machine and not working in another (different OS version, maybe previous state was not applied everywhere or somebody made changes by hand).

Datenstrom 7y ago

I spent a lot of time setting up Nix and NixOS to replicate my current dotfile environment on Debian I've spent years developing and which I can deploy on a new machine with a one liner. I really like Nix and found their DSL fairly easy to pick up, I didn't keep it for my desktop, workstation, or servers though for a few reasons. 1) Package availability: this is by far the largest reason. I frequently need to use software or specific versions that are just not available and while I did create some packages myself it is just too much work when I need to get something done. 2) Language Documentation. 3) I still need to use cargo and pip anyway. 4) Even when packages were available they often lacked the configuration options I needed and I would have to fork and edit them anyway. I do think Nix is a lot better than current systems though.

MarcScott 7y ago
I use pip all the time in NixOS. I just run it in a nix-shell, and install from a requirements.txt when the Python package is not in the nix packages.
- takeda 7y ago
  I created a template which to the extent that I used it completly replaces the need for virtualenv and integrates well with declarative setuptools: https://github.com/takeda/example_python_project https://github.com/takeda/example_python_project With direnv + lorri when you enter the directory, it is as if you enter virtualenv, your code behaves as if it is installed with pip -e, if you call nix build it takes care of all dependencies and the command created in bin/ behave like binaries, have all dependencies needed. I plan to update nixpkgs code that processes setup.cfg and make this less trivial example when I find some time.

globular-toast 7y ago

I would use Guix rather than NixOS, but I wonder if I would feel as in control as I do as a Gentoo user. I suppose I should set aside some time to try it in a VM.

carapace 7y ago
I tried them both last week. All I did was spin up a server, connect through ssh. NixOS was fine. Standard systemd (bleah!) commands to enable and then start sshd. (Because "enabling" and "starting" are two different things, yeah?) Guix required editing a file and rebuilding the OS. This wasn't well documented, and they had forgotten to include the file in the VM image. (The manual says edit /etc/config.scm (IIRC) but it's not there. There's a bug open for it.) I had to find a copy of the VM config and hack it up to work, but after that everything went smoothly. (Can you taste the irony on that last sentence? I am being sardonic. The experience was hugely demotivating.) Anyhoo, FWIW, Nix seems great but I don't like the language (and I don't like systemd, and no, I don't want to talk about it.) Guix seems like it will approach being a new kind of Lisp Machine, Guile lisp is fine, and integrated into other parts of the OS. (Shepard seems fine.) But having to edit a file and rebuild the OS to get ssh access was gnarly. All in all, something like NixOS or Guix seems to me to be the way of the future. Other build/package managers seem just stupid and dangerous in comparison (like operating a chainsaw without kevlar chaps. I have two legs thanks to kevlar chaps. Always wear your chaps kids!)

frabbit 7y ago

I don't understand the conjunction of the following two phrases in the article: > * Nix goes a step further by disallowing package* > * builds to access the internet. This allows Nix* > * packages to be a lot more reproducible;* and > * The src attribute tells Nix where the source * > * code of the package is stored. Sometimes this* > * can be a URL to a compressed archive on the* > * internet,

tridentlead 7y ago
The idea is that as long as the downloaded source file matches the hash all inputs are deterministic and so is the build overall.
- scintill76 7y ago
  Right. More specifically, Nix itself can download files in this way, but the build scripts (in this case, the mkdir & cp part) are not allowed access so that the build is deterministic.
takeda 7y ago
First paragraph talks about build. The build by default happens in sandbox, with many things disabled to force reproducibility. It sometimes makes things annoying, for example there was one Ruby package that was downloading a file during build, so whomever was making a derivation needed to download it in advance) The second paragraph talks about fetching sources which nix does before build starts, each source is required to be provided with hash, this ensures that it is an identical file that author of the derivation used.

jancsika 7y ago

ergonomics oversight: /nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv should be /nix/store/gruvbox-css-c99n4ixraigf4jb0jfjxbkzicd79scpj.drv

takeda 7y ago
They actually answer that in FAQ: https://nixos.wiki/wiki/FAQ https://nixos.wiki/wiki/FAQ

avodonosov 7y ago

The functional package management sounds good and clean in theory, but when I tried nixos Firefox had terrible fonts. Because of some config files in /etc influencing it indirectly. So pograms in nixos influence each other via global configs, they are not isolated. I was unabne to fix that.

towb 7y ago

Used NixOS for a short bit, it was easy to get going with and most things works good out of the box with a pretty simple config. Didn't want to replace my linux knowledge with something this different though so moved back to something more normal for my desktop. Thinking about using NisOS on my home server though, already have the configuration.nix to get it up and running very fast which is nice obviously.

dimitar 7y ago

I tried Nixos but I found out it is really easy to setup a system but then it gets harder when you get off the beaten path by messing with npm or steam for example. I think a winning approach would be to manage the OS using nix, but let the user do more imperative stuff in his home directory. Here is an illustration of how one is supposed to use a package manager for a programming language (in this example npm) in Nixos: https://unix.stackexchange.com/a/381797 https://unix.stackexchange.com/a/381797 And here is an article about the hoops needed to run Steam games: https://nixos.wiki/wiki/Steam https://nixos.wiki/wiki/Steam

takeda 7y ago
That's how it works normally, but once you get to the point of having the system configured declaratively, people strive for more. The home-manager as far as I know is not official component, but a lot of people add it because they love the idea. I think anyone who is interested in Nix should start with Nix Pills[1] they are concentrating on just nix and nixpkgs, but I think it is minimum getting started. Once you are familiar how to build nix derivations, adding custom components is not that hard. [1] https://nixos.org/nixos/nix-pills/index.html https://nixos.org/nixos/nix-pills/index.html
Shoue 7y ago
Regarding NPM, you can do user-level "global" installs on NixOS, see toraritte's answer in the same Stackexchange question. NPM should work fine within a project, but if you need specific dynamic libraries that a Node package implicitly depends on, you can specify them using Nix, and this means you automate the process of installing system dependencies for anyone else who touches the project too. While you could use nix-shell, it is IMO a dated and very manual way, preferably you'd use direnv or lorri to automatically load a default.nix or shell.nix from your project root directory where libraries have been specified in `buildInputs`.

tbrock 7y ago

You know, for all the nerding out about how package managers do their work and how “correct” they are, they all still pale in comparison to how easy and intuitive homebrew is to use. I’m running Linux and pacman/yay are great but if something is screwed up I miss being able to run brew doctor to figure out what’s wrong or add a tap for some weird thing here or there. I know I’ll get crucified for saying it but usability counts for a lot and apt, dpkg, yum, dnf, and yes, even nix suck. All the correctness and perfection don’t matter if nobody uses or wants to use your software.

NateEag 7y ago
Yeah, UX matters, but reliability and robustness are part of UX, too. I've had innocuous-seeming brew commands foul up my working environment. I don't think Nix would do that in the same way. Specifically, updating a package in Homebrew can have unexpected knock-on effects due to updating dependencies. Left my working environment badly hosed at one point last year. Nix's design should ensure that all such updates leave everything else stable, as I understand it. I've been tempted to try it or Guix for years - I was delighted when I discovered Nix existed. I'd been thinking about the problems with existing package managers for years, and both Nix and Guix have most of what I felt was missing from the existing tools, along with some other really cool attributes I hadn't thought of at all.
t0astbread 7y ago
I haven't used a Mac so I don't know what UX breakthroughs I might be missing but I think even for beginners, apt and the like are fine, given how much assistance software and online help there is for them. It does take you a while to understand everything about it but that's always the case with power tools. You'll likely not need to dive into the guts of your package manager on day one anyways.
- tbrock 7y ago
  No. apt-get install for installing and apt-cache search for searching? That’s... not discoverable to say the least: how about brew install and brew search? Didn’t know they were there? No problem you’ll see they are available commands when you run brew.

indigodaddy 7y ago

Christine, very attractive and minimal site. Well done. I see on your “new site” blogpost you mention “This content is markdown rendered by Purescript.” ..have you considered doing a write up with more detailed information as to how your site is generated or a howto? I think many might be interested. Thanks!