Programmer in NYC

  • 1 Post
  • 59 Comments
Joined 1 year ago
cake
Cake day: May 7th, 2023

help-circle
  • I think you can mount an ISO image under your running system and make changes. I found a couple of guides that might be helpful:

    How to Mount an ISO File on Linux

    Edit and repack .iso bootable image

    I haven’t done this before, but I think you can chroot into the mount directory, and run package manager commands in the mounted image to install another package.

    Or I have an alternative suggestion that might or might not be easier. I’ve been hearing a lot about immutable/atomic distros, and people designing their own images. You could make your own ublue image, for example, with whatever you want on it.

    A promising looking starting point is github:ublue-os/startingpoint. Ignore the “Installation” instructions, and follow the “ISO” instructions instead.

    Or I saw recently an announcement of a new way to build atomic images that is supposed to be easier than ever, BlueBuild


  • Well you’re really feeding my Nix confirmation bias here. I used to use Ansible with my dot files to configure my personal computers to make it easy to get set up on a new machine or server shell account. But it wasn’t great because I would have to remember to update my Ansible config whenever I installed stuff with my OS package manager (and usually I did not remember). Then along came Nix and Home Manager which combined package management and configuration management in exactly the way I wanted. Now my config stays in sync because editing it is how I install stuff.

    Nix with either Home Manager or NixOps checks all of the benefits you listed, except arguably using a “known” programming language. What are you waiting for?


  • Well ok, they both use symlinks but in different ways. I think what I was trying to say is that in NixOS it’s symlinks all the way down.

    IIUC on Fedora Atomic you have an ostree image, and some directories in the image are actually symlinks to the mutable filesystem on /var. Files that are not symlinks to /var (and that are not inside those symlinked directories), are hard links to files in the ostree object store. (Basically like checked-out files in a git repository?)

    On NixOS this is what happens if examine what’s in my path:

    $ which curl
    /run/current-system/sw/bin/curl
    
    $ ls -l /run | grep current-system
    /run/current-system -> /nix/store/p92xzjwwykjj1ak0q6lcq7pr9psjzf6w-nixos-system-yu-23.11.20231231.32f6357
    
    $ ls -l /run/current-system/sw/bin/curl
    /run/current-system/sw/bin/curl -> /nix/store/r304lglsa9i2jy5hpbdz48z3j3x2n4a6-curl-8.4.0-bin/bin/curl
    

    If I select a previous configuration when I boot I would get a different symlink target for /run/current-system. And what makes updates atomic is the last step is to switch the /run/current-system symlink which switches over all installed packages at once.

    I can temporarily load up the version of curl from NixOS Unstable in a shell and see a different result,

    $ nix shell nixpkgs-unstable#curl  # this works because I added nixpkgs-unstable to my flake registry
    $ which curl
    /nix/store/0mjq6w6cx1k9907vxm0k5pk7pm1ifib3-curl-8.4.0-bin/bin/curl  # note the hash is different
    

    I could have a different version curl installed in my user profile than the one installed system-wide. In that case I’d see this:

    $ which curl
    /home/jesse/.nix-profile/bin/curl
    
    $ ls -la /home/jesse | grep .nix-profile
    .nix-profile -> /nix/var/nix/profiles/per-user/jesse/profile
    
    $ ls -l /nix/var/nix/profiles/per-user/jesse
    profile -> profile-133-link
    profile-130-link -> /nix/store/ylysfs90018zc9k0p0dg7x6wvzqcq68j-user-environment
    profile-131-link -> /nix/store/9hjiznbaii7a8aa36i8zah4c0xcd8w6d-user-environment
    profile-132-link -> /nix/store/h4kkw1m5q6zdhr6mlwr26n638vdbbm2c-user-environment
    profile-133-link -> /nix/store/jgxhrhqiagvhd6g42d17h4jhfpgxsk3n-user-environment
    

    Basically symlinks upon symlinks everywhere you look. (And environment variables.)

    So I guess at the end everything is symlinks on NixOS, and everything is hard links plus a set of mount paths on Fedora Atomic.





  • hallettj@beehaw.orgtoLinux@lemmy.mlNixOS - edit system files
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    8 months ago

    I did some digging around in the manual, and I tested this option which seems to work:

    security.pam.services.doas.fprintAuth = true;
    

    On my machine that adds this line to /etc/pam.d/doas:

    auth sufficient /nix/store/fq4vbhdk8dqywxirg3wb99zidfss7sbi-fprintd-1.94.2/lib/security/pam_fprintd.so # fprintd (order 11400)
    

    Edit: Note that the NixOS option puts in the full path to pam_fprintd.so. That’s necessary because NixOS doesn’t put so files in search paths.

    Without doing more research I don’t know how to add arbitrary options to pam files in case you run into something that isn’t mapped to a NixOS option yet. The implementation for the pam options is here; there might be something in there that would work.



  • Wayland replaces the older X protocol. It doesn’t have to operate with older protocols. You might be thinking of XWayland which is a proxy that receives X API calls from apps written for X, and translates those to the Wayland API so that those apps can run under Wayland implementations. Window managers can optionally run XWayland, and many do. But as more apps are updated to work natively with Wayland, XWayland becomes less important, and might fade away someday.

    PipeWire replaces PulseAudio (the most popular sound server before PipeWire). Systems running PipeWire often run pipewire-pulse which does basically the same thing that XWayland does - it translates from the PulseAudio API to the PipeWire API. It’s a technically optional, but realistically necessary compatibility layer that may become less relevant over time if apps tend to update to work with PipeWire natively.

    So no, both Wayland and PipeWire are capable of operating independently of other protocols.


  • hallettj@beehaw.orgtoLinux@lemmy.mlNixOS is better because...
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    9 months ago

    NixOS puts your full system configuration in a portable set of files. You can easily reproduce the same configuration on another machine. I also like that instead of accumulating a growing list of packages that I don’t remember why I installed I have package lists specified in files with comments, and split into modules that I can enable or disable.

    IMO NixOS works best when you also use Home Manager to apply the same benefits to your user app configurations and such. (OTOH you can use Home Manager to get those benefits without NixOS. But I like that I get consistency between the OS-level and user-level configurations, and that both use the same set of packages.) I use Home Manager to manage my list of installed packages, my dot files, Gnome settings, Firefox about:config settings, and so on.

    You might be installing packages imperatively with nix profile install or with nix env -i. If that’s the case you’re not going to see the full benefits of a declarative system in my opinion. I prefer to install packages by editing my Home Manager configuration and running home-manager switch.

    I like that NixOS + Home Manager automates stuff that I used to do by hand. A couple of the things that I do or have done are to,

    • test an experimental window manager, Niri
    • use Neovide (a GUI frontend for Neovim) with a custom patch to tweak font rendering

    Now I have that kind of stuff automated:

    • Since there was no packaging for Niri when I started trying it I wrote my own in my NixOS config with a NixOS module to set up a systemd unit to run it. Because Nix packages are effectively build scripts, whenever I update Nix automatically pulls the latest version of Niri and compiles it without me having to think about it anymore.
    • I use the Neovide package from nixpkgs with an override to compile with my custom patch. Like with Niri my configuration automatically gets the latest Neovide version and builds it with my patch when I update, and I don’t have to think about it anymore. I use this overlay to do that:
    modifications = final: prev: {
      neovide = final.neovide.overrideAttrs (oldAttrs: {
        patches = (oldAttrs.patches or [ ]) ++ [ ./neovide-font-customization.patch ];
      });
    };
    

    You can see that I compile some things from source. That’s fine on my desktop, but takes a while on my travel laptop. But I don’t need to compile on my laptop because I can use Nix’s binary cache feature. I push my NixOS and Home Manager configurations to Github, and I have Garnix build everything that I push. Garnix stores everything it builds in a binary cache. So when I pull my latest configuration version on my laptop it downloads binaries from that cache.



  • I’m also a PaperWM fan. For switching I mostly use spatial window-switching controls: Meta+ left/right to switch windows, page up/page down to switch workspaces. Plus I use Gnome overview’s search-driven app finder, and Advanced Alt-Tab Switcher but only for its fuzzy search feature to switch to specific windows within an app.

    PaperWM has an option to hide windows in a “scratch” layer. I put chat and music programs there, and summon them with AATS.

    I have an ultrawide monitor, and I put a terminal and editor side-by-side in a ¼-¾ ratio. I set browser windows to ½ width. Those ratios let me see important parts of a browser window next to the editor if I slide the terminal out of view to partially expose a browser on the other side. Or I can move the terminal next to the browser and see both fully.


  • I sometimes write a flake with those 4 lines of Nix code, and it comes out just messy enough that tbh I’m happier adding an input to handle that. But I recently learned that the nixpkgs flake exports the lib.* helpers through nixpkgs.lib (as opposed to nixpkgs.legacyPackages.${system}.lib) so you can call helpers before specifying a system. And nixpkgs.lib.genAttrs is kinda close enough to flake-utils.lib.eachSystem that it might make a better solution.

    Like where with flake-utils you would write,

    flake-utils.lib.eachSystem [ "x86_64-linux" "aarch64-darwin" ] (system:
    let
      pkgs = nixpkgs.legacyPackages.${system};
    in
    {
      devShells.default = pkgs.mkShell {
        nativeBuildInputs = with pkgs; [
          hello
        ];
      };
    })
    

    Instead you can use genAttrs,

    let
      forAllSystems = nixpkgs.lib.genAttrs [ "x86_64-linux" "aarch64-darwin" ];
      pkgs = forAllSystems (system:
        nixpkgs.legacyPackages.${system}
      );
    in
    {
      devShells = forAllSystems (system: {
        default = pkgs.${system}.mkShell {
          nativeBuildInputs = with pkgs.${system}; [
            hello
          ];
        };
      });
    }
    

    It’s more verbose, but it makes the structure of outputs more transparent.


  • hallettj@beehaw.orgtoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    10
    ·
    9 months ago

    The link lists 78 CVEs of varying severity levels opened over a period of 11 years. Many of them are patched. (I don’t know how to easily check how many are patched. The NIST listings provide issue tracker links and severity levels, and the handful of CVEs I looked at had fixes released.) I’m not convinced this is evidence that systemd is unacceptably insecure.

    I get that it’s frustrating that systemd has such a broad scope, and that it’s not portable. But these are trade-offs. In exchange we get power that we wouldn’t get otherwise. For example tying device management and scheduled tasks into systemd lets us use the same declarative dependency management in those domains as in the init system. The system is able to bring up services only when needed, boot faster, use fewer resources. The non-portability allows use of, for example, Linux cgroups to cleanly shut down forked processes. Even if we were using an alternative like Upstart I’m gonna guess we would end up relying on cgroups.

    Red Hat’s role is certainly something to keep an eye on. But systemd is open source, and it can be forked if necessary.


  • I think Picard was willing to sacrifice himself to save the kids. He’s an officer who signed up for a risky job - they are not, and also they’re kids. I think he thought that going with them would slow things down enough to add unacceptable risk for the kids. And they did end up spending a bunch of time cobbling together an apparatus to move Picard during which the lift could have fallen.

    When the kids refused to go maybe that changed Picard’s calculation: the advantage of going without him diminishes if they use up time arguing. Or maybe it’s TV writing.

    But maybe Picard wasn’t certain that the lift would fall. Or maybe if he’d stayed he would have managed to pull out a Picard move to save himself at the last second - you know, the kind that’s easier to do when there aren’t kids watching. Or maybe, as far as he knew someone might rescue him in time. But yeah, he probably would have died, and the kids’ mutiny was the only out that let him save himself while also trying to be noble.



  • Debian unstable is not really unstable, but it’s also not as stable as Ubuntu. I’m told that when bugs appear they are fixed fast.

    I ran Debian testing for years. That is a rolling release where package updates are a few weeks behind unstable. The delay gives unstable users time to hit bugs before they get into testing.

    When I wanted certain packages to be really up-to-date I would pin those select packages to unstable or to experimental. But I never tried running full unstable myself so I didn’t get the experience to know whether that would be less trouble overall.


  • I also have mixed feelings about Discovery, but for different reasons. I love the characters and character writing. I disagree that the rest of the crew doesn’t get any development - but a lot of that does come in later seasons. My complaints are about the plots. I think season 1 was the most problematic in that respect with progressive improvements over the next two seasons. (I haven’t seen season 4 yet.)

    • Overly ambitious arcs, and over-the-top stakes make the story feel unbelievable
    • Discovery being the only crew able to address several civilization-threatening crises makes the universe feel small
    • Leaning on action and artificial tension (like, the ship will explode in 3 minutes) is a cheap way to seek engagement that deprives us of time seeing the characters drive the story
    overly-ambitious arcs in season 1

    It wasn’t enough to try to take on the entire Klingon war at the same time as introducing a whole new cast. They also had to add an entirely separate, even more threatening crisis?

    Making Michael responsible for both starting and ending the war makes you feel like the universe begins and ends on one ship.

    We don’t need constant threats of annihilation in the story to be engaged! The most compelling Trek writing has had much lower stakes. When we have had high stakes, like in The Best of Both Worlds and The Dominion War, the writers managed to make us feel like we were seeing a pivotal part of a much larger conflict. They took the time to build up to the big tension, and took the time to play out satisfying resolutions. And they didn’t make it the entire show.

    But things got gradually better,

    over-the-top stakes in season 2

    In season 2 they managed to limit themselves to a single major crisis. And they stepped it down from end-of-every-universe to end-of-all-life-in-one-galaxy. But still unbelievably over-the-top. Still too much artificial tension. Still too Discovery- & Michael-centric.

    I love Michael, and I enjoy watching her be great at everything. But she can be part of a larger society of amazing people, and still be amazing herself.

    somewhat lower stakes in season 3

    And then they stepped it down again to maybe-end-of-what’s-left-of-the-Federation.

    In season 3 things slowed down enough, and they spent enough time letting more of the cast develop and drive the story that I felt like I could enjoy the story without gritting my teeth.

    season 3 world-building

    But I do have similar feelings: the world-building of what is essentially a whole new galaxy in season 3 feels underdeveloped. I was initially frustrated by what felt like an attempt to distance Discover from Star Trek. Trek is supposed to be about a future utopia - we have enough other works that wallow in dystopia. But it seems like maybe it’s only supposed to be dystopian for one season? The ambitious writing is certainly still there.

    I don’t disagree with you about mirror-Georgiou’s participation being unbelievable. The thing where everybody loves Michael to the degree where it becomes their primary motivation is too Mary Sue-like. Again I think that’s at its worst in season 1. OTOH having Michelle Yeoh on the show is a lot of fun so I’m inclined to forgive the stretch in that character arc.