Skip Navigation

Posts
14
Comments
236
Joined
3 yr. ago

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

  • The first computer I used was (I think) a CP/M system that could run BASIC, and I used to use it to play Castle in the early '90s.

    The first computer of my own was a Gateway laptop for college in 2002. It was the first Wi-Fi device I laid hands on. I immediately set it up to play music to wake me up in the morning, and I listened to the fans running all night.

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

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

  • Oh hey I hadn't seen the news about the new default color scheme for neovim https://github.com/neovim/neovim/pull/26334

    And of course great work on kitty-scrollback! Neovim and Kitty are also two of my favorite pieces of software.

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

  • Specifically in Pasadena

  • On Linux, Firefox now defaults to the Wayland compositor when available instead of XWayland.

    It's in! I know some people in the Lemmy Linux communities have been eagerly anticipating this change.

  • Allow me to share, Federated Wiki. I don't think it uses ActivityPub, but otherwise I think it's close to what you described. Instead of letting anyone edit articles it uses more of a fork & pull request model.

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

  • when relays are blownwhen power reserves failwhen life support is gonegravity plating's pull is relentlessit will carry on

  • 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

    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,

    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.

    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.

    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.

  • PaperWM has columns - you can move multiple windows into a column (Super+I by default, or Super+O to move a window out of a column). When you move windows left or right or resize horizontally the column moves or resizes as a group. That's the only feature that groups windows.

    I mention Niri because I'm interested to see more implementations of the same idea. The only other scrolling window manager I know of is CardboardWM which is long dead. A native implementation like Niri might be able to explore ideas that are difficult to implement in an extension.

  • I've been using this for maybe a couple of years, and I love it! I like that windows stay at the sizes I set them to, and at the same time I can put as many windows in a workspace as I want.

    PaperWM is not bug-free, but an active dev community has grown around it, and they do a lot of work to keep it running as smoothly as possible. That includes the essential task of working around breaking extension API changes when new Gnome releases are coming.

    I've also been keeping an eye on Niri which applies the same idea to a standalone window manager. I haven't switched because Niri doesn't currently implement XWayland. But it looks like Wine is getting closer to native Wayland support so XWayland might not be a requirement for me for much longer.

  • And there is also Nushell and similar projects. Nushell has a concept with the same purpose as jc where you can install Nushell frontend functions for familiar commands such that the frontends parse output into a structured format, and you also get Nushell auto-completions as part of the package. Some of those frontends are included by default.

    As an example if you run ps you get output as a Nushell table where you can select columns, filter rows, etc. Or you can run ^ps to bypass the Nushell frontend and get the old output format.

    Of course the trade-off is that Nushell wants to be your whole shell while jc drops into an existing shell.

  • I'm a fan! I don't necessarily learn more than I would watching and reading at home. The main value for me is socializing and networking. Also I usually learn about some things I wouldn't have sought out myself, but which are often interesting.