Programmer in California

I’m also on https://leminal.space/u/hallettj

  • 3 Posts
  • 117 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.




  • 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.



  • Yeah, that makes a lot of sense. If the thinking is that AI learning from others’ works is analogous to humans learning from others’ works then the logical conclusion is that AI is an independent creative, non-human entity. And there is precedent that works created by non-humans cannot be copyrighted. (I’m guessing this is what you are thinking, I just wanted to think it out for myself.)

    I’ve been thinking about this issue as two opposing viewpoints:

    The logic-in-a-vacuum viewpoint says that AI learning from others’ works is analogous to humans learning from others works. If one is not restricted by copyright, neither should the other be.

    The pragmatic viewpoint says that AI imperils human creators, and it’s beneficial to society to put restrictions on its use.

    I think historically that kind of pragmatic viewpoint has been steamrolled by the utility of a new technology. But maybe if AI work is not copyrightable that could help somewhat to mitigate screwing people over.


  • That sounds like a good learning project to me. I think there are two approaches you might take: web scraping, or an API client.

    My guess is that web scraping might be easier for getting started because scrapers are easy to set up, and you can find very good documentation. In that case I think Perl is a reasonable choice of language since you’re familiar with it, and I believe it has good scraping libraries. Personally I would go with Typescript since I’m familiar with it, it’s not hard (relatively speaking) to get started with, and I find static type checking helpful for guiding one to a correctly working program.

    OTOH if you opt to make a Lemmy API client I think the best language choices are Typescript or Rust because that’s what Lemmy is written in. So you can import the existing API client code. Much as I love Rust, it has a steeper learning curve so I would suggest going with Typescript. The main difficulty with this option is that you might not find much documentation on how to write a custom Lemmy client.

    Whatever you choose I find it very helpful to set up LSP integration in vim for whatever language you use, especially if you’re using a statically type-checked language. I’ll be a snob for just a second and say that now that programming support has generally moved to the portable LSP model the difference between vim+LSP and an IDE is that the IDE has a worse editor and a worse integrated terminal.


  • 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.mlSystemD is still too raw
    link
    fedilink
    English
    arrow-up
    10
    ·
    6 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’ve been reading about increasing unionization and strike activity, leading to better deals for large groups of workers. The industry-level negotiations we’re already seeing are helpful in isolation; but that’s also the kind of energy that can lead to economic reforms that have a real impact on quality of life. Workers seem like the little guys, until a lot of them are pulling in the same direction, and then suddenly their demands become existentially important.

    About a century-ish ago Americans were worse off than they are now. That led to desire for change, which led to decades of trust-busting, unionization, and regulation. We got things like weekends off, and a livable minimum wage. And not entirely unrelated, we also got national parks, the EPA, and endangered species preservation. We’ve back-slid a lot since those advances. But we can get them back, and push the needle even further next time. We did it before, we can do it again.


  • I pretty much always use list/iterator combinators (map, filter, flat_map, reduce), or recursion. I guess the choice is whether it is convenient to model the problem as an iterator. I think both options are safer than for loops because you avoid mutable variables.

    In nearly every case the performance difference between the strategies doesn’t matter. If it does matter you can always change it once you’ve identified your bottlenecks through profiling. But if your language implements optimizations like tail call elimination to avoid stack build-up, or stream fusion / lazy iterators then you might not see performance benefits from a for loop anyway.