hallettj

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.

Makes sense. What are you thinking would be better? km/kWh efficiency, kWh capacity, and kWh/h charging rate?

I guess that last one could be kW charging rate. I raised my own eyebrows at myself typing kWh/h.

Then again it's tough to capture a non-linear charge rate in one number. Maybe the press release could come with an asterisk: "*This is the coefficient of a logarithmic function." I'm guessing you have something more sensible in mind like time to X kWh, or time to 80% charge.

Do you think people would stand for the technically-equivalent-and-simplified m/Wh instead of km/kWh? Slaps roof of car "Got a lotta meters in this one!"

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

What makes you think all hands of those ships were erased? In the Star Trek stories I remember where something significant was prevented from happening due to time travel the characters involved wound up somewhere else instead.

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.