Skip Navigation

Posts
14
Comments
236
Joined
3 yr. ago

  • The default Gnome installation on NixOS uses Wayland. And GDM too - it's pretty much the same as other distros I've used. I'd guess the Plasma install option is also on Wayland.

    I do have some issues with screen sharing. It generally works fine in Firefox and Discord. But screen sharing in Slack crashes every time.

  • I've been using Wayland for a while, but I remember two factors that might have held me back in another universe:

    • lack of support from Xmonad (so group 3 from the article)
    • I used to make extensive use of keyboard remapping using xkb & xcape, and last I checked that doesn't work in native Wayland apps. (I think that would've put me in one of the niche groups.)

    I'm not sure if those restrictions still apply. Luckily for the simplicity of my life I switched to Gnome (partially for Wayland support, partially for a simpler setup), and I switched to doing keyboard reconfiguration in hardware.

  • Oh yeah, the need for parenthesis often has me scratching my head for a bit

  • rust-script looks like a neat way to use Rust for scripting. But I was coincidentally reflecting on how helpful Nix is for handling the same problem, where I want to write scripts in a compiled language, but managing builds is a lot to deal with in an ad-hoc setting. I can pair my script with a Nix expression that gets checked into either my project repo, or my Home Manager dot files, and then I don't have to think about rebuilding on changes or on new machines.

  • You might simplify it a bit with something like,

     
        
    let my-hello-scripts = [
      (writeShellApplication {
        name = "my-hello-1-script";
        text = "echo my hello world 1";
      })
      (writeShellApplication {
        name = "my-hello-2-script";
        text = "echo my hello world 2";
      })
    ];
    in
    {
      environment.systemPackages = 
        my-hello-scripts ++
        [ pkgs.whatever-else-you-want ];
    }
    
      
  • I have a recurring task called "rotate butter" scheduled once a month which seems about right to me.

  • When an ecosystem is new there is a lot of design space to explore. No one knows what the best ideas will be - the only way to find them is to try lots of things. After a while it becomes clearer what the good ideas are, and things settle down. That happened in Javascript when React and Vue became popular. You didn't see a new application framework every month anymore - at least not ones that got a lot of adoption. Exploration shifted to stuff like state-management libraries to use within React. Of course the search for better ideas never stops completely...

  • I can at least try to define the concepts I mentioned in my comment.

    • store path is a directory or file in /nix/store/. It has the format /nix/store/--. Every installed package gets a store path. There is other stuff too - if you use flakes each flake and each flake input are copied to a store path before being evaluated. IIUC certain directories within each store path are treated specially. For example if a store path has a bin/ directory, and that store path is included in your user "profile" of installed packages, then everything in that bin/ directory is automatically symlinked to your profile bin/ directory, which is in your $PATH. For example,

     sh
        
    $ which git
    /home/jesse/.nix-profile/bin/git
    $ ls -l $(which git)
    lrwxrwxrwx 62 root 31 Dec  1969 /home/jesse/.nix-profile/bin/git -> /nix/store/nqdyqplahmhdgz8pzzd5nip17zf3ijzx-git-2.40.1/bin/git
    
      

    • derivation is a value in the Nix language that represents one or more files that could potentially be written to a store path. Specifically a derivation is an attribute set (the Nix term for a dictionary/object) with certain special attributes/properties. A derivation contains all the information necessary to produce some files to go into a store path (often by downloading or compiling something), and also contains the specific path that those files will be written to. When you access a package in a Nix expression, such as nixpkgs.git, the value you get is a derivation. But you can also make derivations yourself using functions like stdenv.mkDerivation or writeShellApplication. I think you can even write an attribute set from scratch if you want to.

    To get from a Nix attribute set to a set of files there is a process called instantiation that is separate from evaluation of Nix expressions. (By "expressions" I mean Nix programs, anything in a .nix file.) Certain Nix programs will evaluate a Nix expression, read a derivation that the expression produces, and do the instantiation to actually create the files. As I mentioned the derivation includes all of the information necessary to do this. Part of this process actually serializes each derivation to a file in /nix/store/ - that's what the .drv files in there are. Those are very-specialized scripts that produce store paths.

    • package is I think a less-specific term for a derivation or a store path. Maybe there is an implication that a derivation that is a package comes from a software repository, or includes either executables or libraries. (Derivations don't necessarily have to provide executables or libraries - they can represent any file or directory of files.)
  • Yes, California, late 30s. I drove a manual transmission when I was a teenager. I was proud of how practiced I got with it. I don't drive manual anymore, but my dad recently switched back after some decades driving automatic. He found out he's out of practice lol

  • Yeah, it was quite a learning curve for me too. I found reading Nix Pills was helpful. I put it off too long even after seeing lots of recommendations. It turns out the recommendations are apt.

  • Yes, writeShellApplication is a good solution. But instead of altering your path, put the result right in the environment.systemPackages list, or in users.users.your-user.packages.

    writeShellApplication produces a derivation (a value that will be turned into a store path when it's "instantiated"). Basically it's already a package. You can use the derivation the same way you would use a package from nixpkgs.

    You're likely already aware, but when you get secrets from sops those are paths to files in /var/run/ generated at runtime; so your scripts will need to run with sufficient privileges to read the secrets files.

    Edit: Sorry, I meant "instantiated", not "realized"

  • I've had ls aliased to exa for a while. So it looks like eza is a fork of exa? The git feature looks interesting.

  • Ok, I'm seeing overwhelming recommendations for local credit unions. Thanks everyone!

  • What frustrates me most about "new Trek" is that the characters don't drive the story. Instead they have constant action, artificial tension, and over-the-top stakes. I love the characters on Discovery, but they're not allowed to exist as themselves. OTOH SNW is primarily character-driven, as good Trek always has been.

  • I agree, especially with respect to batteries. It's not about nuclear vs renewables, it's about nuclear vs batteries. We can probably scale up energy storage to meet the world's baseload needs - but we haven't done that before. It might take a long time, we might hit some dead ends, and it might not end up being as cheap as we hope. But we have seen nuclear power on a large scale so we know what it takes. To be certain we can get zero carbon as soon as possible we should pursue every promising avenue.

    Also note that the cost of, for example, solar energy has decreased 94% in the last 35 years because we have (rightly) put lots of resources into research and scaling up production. Meanwhile nuclear investment has been way down for decades. Maybe the cost of nuclear would come down with economies of scale, and newer designs.

  • Yes, I met someone who was allergic to basically everything, and said she had good results with hookworms

  • @linux any global mesh networks that could replace ISP's?

    Jump
  • Actually I'd like to add a note about how much I appreciate infrastructure. It would be great if we could all equally own and control the Internet. But when you get down to it, societies pooling their efforts can do things that small, independent groups can't, such as building tier 1 network backbones.

    Looking at it another way, if you did have a global mesh network it would be made up of electronics that take tremendous systems of supply chains and factories to build and distribute. That's sort of the same idea: large-scale infrastructure that small groups can't pull off.

    If I had my way I would keep the large-scale networks, but change the governance model to shift the primary organizational motivation from profit to human wellbeing.

  • @linux any global mesh networks that could replace ISP's?

    Jump
  • I remember reading about a "guerilla wifi" mesh network in NYC, and I did a bit of research on connecting to that several years ago. It turned out I was too far away from Manhattan to be in range. But also from what I read a series of small-scale peer-to-peer connections don't give you the low-latency or throughput of a good backbone.

  • The NixOS ideal is that every detail of the system is configured through Nix expressions so that the system is completely reproducible. But in practice there are some details you might want to configure directly.

    With users.mutableUsers = false you are in the "ideal" declarative mode where users and groups are supposed to be fully represented in configuration.nix including passwords (or hashed passwords). In this mode the Nix config overrides everything in /etc/passwd. If the Nix config doesn't specify passwords I think the default is to leave the account without a password, disabling login for that account.

    With users.mutableUsers = true NixOS respects changes to user and group accounts made outside of configuration.nix. Accounts configured through Nix will be added to /etc/password if they aren't already there. But NixOS won't remove accounts, and won't modify or unset passwords. In this mode the default of leaving the password unset makes sense because you're expected to set a password by running passwd. This is the typical choice because there are security problems with putting passwords in configuration.nix.

    You can set passwords in the Nix config using the password, passwordFile, hashedPassword, or initialPassword options. If mutableUsers is true these options only set the password the first time the user account is created. I checked to see if there are any options that implicitly disable mutable users, but I didn't find any.