• 0 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: March 17th, 2024

help-circle
  • We went from boring beige PC cases, that looked rather boring and were in dire need of some stylish upgrades, in the complete other direction and overshot the target by a mile. I find most modern PC stuff incredible ugly and impractical. Even just finding a tower that still has a 5.25" slot took effort, since most don’t even have them anymore. The whole idea of transparent windows on your case or putting your PC on the desk instead of below it, is complete nonsense, especially when you don’t even have room for swappable disk drives. The good old desktop PC at least went under your monitor, but modern PC cases don’t even do that.

    I am kind of surprised, despite all those decades of PC gaming, we still don’t have gaming PCs as compact as a Playstation/Xbox. They do exist, e.g. the old Alienware Steam Machine was tiny, but they are far from common place and often either underpowered or overpriced.


  • You can manage multiple machines with a single Nix configuration git repository and modularize the configuration as much as you want. You can have a config with a desktop environment that you skip on servers, override individual variables for a specific host or do whatever you want. You can even remote deploy it all with a simple nixos-rebuild build --target-host "user@host" and it works across different architectures too (e.g. build on your fast x86 machine and deploy to a slow RaspberryPi).



  • While some people love putting Lisp in everything, I really don’t get it. Guix is far uglier than Nix in the language department. Scheme is not a configuration language and thus has none of the nice things that Nix has (multi-line string handling, defaults, lazy evaluation, inline expression, etc.), instead you get multiple levels of macro spaghetti. Furthermore, Guix forces you to turn everything into Scheme, where you can just use plain Bash in your Nix build steps, in Guix that is all Scheme.

    I had spent a lot of years with Scheme before starting with Guix and then spend quite a few years with that, but even after all that switching to Nix just felt so much better instantly. Instead of trying to hack a DSL onto of Scheme you just get a language that’s actually build for the task.


  • Where are the source packages?

    It’s reproducible, so random updates are a no-no. You can however just dump the Git URL in your flake.nix inputs and then override the src of the package with that. The source gets updated when you do nix flake update next time. Something like this:

    inputs {
        ...
        mypackage_src.url = "github:myorg/mypackage";
        mypackage_src.flake = false;
        ...
    }
    
    pkgs.mypackage.overrideAttrs (oldAttrs: {
                  src = mypackage_src;
                  version = "nightly-${mypackage_src.shortRev or "src"}";
                })
    
    

  • The Nix language itself is the hardest part.

    Let me disagree there, the language is trivial. It’s just JSON-lookalike with expressions, with a lot of nice touches that make using it much easier than all the alternatives (e.g. sane multi-line string handling, lazy evaluation, default values, powerful key/value sets, etc.). The only real stumbling for me when first encountering it was realizing that functions can only take a single argument (which can be a key/value set) and that functions are literally just : (e.g. (a: a + 5) 6 => 11). That’s easily missed if you just look at a file without reading the documentation.

    The thing that makes it hard is just the complexity of the actual package collection, your configuration contains literally your whole system, and it’s not always obvious where to find the thing you need, since sometimes it’s a plain package, sometimes it is a services.foobar.enable = true and sometimes you have to fiddle with override or other package specific things. Knowing that https://search.nixos.org/ exists is half the battle here.

    There is also the lack of static typing that can lead to rather verbose error messages, but it’s not like many other configuration formats have that either.




  • Technically they are correct. None of the Open Source licenses really regulate what happens on the server. When it’s not you running the binary, all the licenses are basically useless. AGPL is one of the few that address this a little bit, but even there you only get the source code itself, when the value in most online services is in the databases and backend stuff that you still don’t get to access with AGPL.

    The Free Software world hasn’t figured out what to do with services running on computers you don’t own. GDPR is so far the only thing does something about the server side, but that’s EU law, not a license you can slap onto your software.


  • Actually, kind of not. FSF has a weird blindspot when it comes to backend stuff. They care about what runs on your computer, e.g. Javascript, but stuff running on a server that you don’t own they don’t really care about. The AGPL had to come from an outside third party, not the FSF themselves. The FSF has been pretty silent when it comes to making licenses to regulate the whole “cloud” space.

    It’s one of the big reason why the FSF has been slowly driving away into irrelevancy. The modern computing world is all about servers and data flowing between them. And the FSF is continuing doing licensing like it’s the 1980s. They are so far behind that politics got there first with the GDPR. There is still no “GNU GDPR” that you can slap on your software to give people outside Europe similar rights.