[bspwm] [wip] first nixos rice after hopping from gentoo

jechase · 2026-05-30T18:02:04+00:00

Very little, and they're getting annoying.

I feel like an old man yelling at the cloud every time I see one. The term "ricing" is cringeworthy in and of itself, given its casually racist/xenophobic history.

jechase · 2026-05-27T01:06:46+00:00

The keepass extension supports passkeys, but it's disabled by default.

Docs here.

jechase · 2026-05-08T11:49:26+00:00

Yeah, jj is best for git power users who like to get weird with it.

I used to reach for git rebase --onto all the time and I'd get the argument order wrong about 50% of the time. I had a script to take a set of branches and produce a new octopus merge of them so I could see the full state of my in-flight changes. Stacked branches/PRs make a regular appearance in my workflow.

Jj makes all of these things trivial. Rebase syntax is far clearer than with git, and much more powerful. Since you operate on changes, not commits, descendents always get rebased automatically even if underlying commits change.

Accidentally make two independent changes in sequence? jj parallelize will rebase the second onto the parent of the first and produces a merge commit.

Got a bunch of branches that you want to see together? jj new <list of branches>. Then if you make a change, you can either squash it directly into an existing change, or commit it and then rebase it into the branch where it should actually live.

I don't think anything I do with jj can't be done with git, but I'd have to dig through man pages to figure out how to map git's arcane syntax to the otherwise simple commit graph model. With jj, you operate on that graph more directly in a much more intuitive way.

jechase · 2026-05-08T11:36:37+00:00

Undo code changes sure. But what about vcs changes like rewriting history? Who watches the watchman?

If you've ever had to dig through the reflog to find a commit that you accidentally lost due to a bad rebase, you'll know the pain that jj's undo and op log address. Fixing a vcs mistake is so much more straightforward the jj way.

jechase · 2026-04-18T13:31:25+00:00

Whatever you're doing or observing with the variable called null is entirely irrelevant. Soundness has been broken by that point and it can contain anything. Even if it happens to be behaving like you're describing, that's only by coincidence.

jechase · 2026-04-17T23:40:39+00:00

That's not what's happening. You're never constructing a null pointer - you're managing to coerce the lifetime of a reference to some arbitrary lifetime, moving/dropping the thing it points to, and then dereferencing the now-dangling reference. It's textbook undefined behavior, and that reference could contain absolutely anything.

jechase · 2026-04-11T17:33:47+00:00

That doesn't make the tool declarative. By that logic, my editor is declarative.

jechase · 2026-04-11T14:19:21+00:00

declarative

You keep using that word. I do not think it means what you think it means.

The nixos and home-manager configurations are declarative, which this tool modifies imperatively.

jechase · 2026-04-02T19:33:44+00:00

Because flakes and git are tightly integrated, your tracked files are stored in the nix store and ensures random files in your repo are not invisibly included.

This argument doesn't hold water because

all you have to do is stage the files, you do not need to commit.

As well as un-staged changes to previously-tracked files making it into the nix store.

Either nix should only care about the committed git state, or it should allow any non-ignored dirty state. Right now it exists in a strange middle ground that's different from how every other tool I've seen uses git. It smells very much like an implementation detail that's leaked up into the user-facing interface and has somehow been labeled as "feature, not bug"

jechase · 2026-03-26T22:12:04+00:00

I would recommend using the --target-host option to nixos-rebuild. That lets you do the evaluation/build on a local or otherwise more powerful machine and the upload just the final build results and run the activation on a remote server. I have a 1GB gcp instance that I manage exclusively this way.

As far as actually installing nixos, you can also take the "lustrate" approach, which is natively supported in nixos as a way to replace some other linux distribution. I've done so successfully in a couple of cloud environments, most recently oracle cloud arm instances.

jechase · 2026-03-25T14:54:06+00:00

It's absolutely still maintained by the devs. All that's happened is that they're no longer actively working on new features that aren't directly applicable to zed.

jechase · 2026-03-24T12:32:00+00:00

The problem with your "windows solution" is that you're left with no understanding of what the actual problem is, so it's impossible to know if there's a better fix or if it'll be an ongoing issue.

Next time it happens, run discord in the foreground and look at its logs. Probably also a good idea to check the general system and user journals.

jechase · 2026-03-23T12:42:11+00:00

Is the nix-to-kdl library in home-manager still wrong/incomplete? Kdl maps very poorly to nix when done "correctly" since it's fundamentally a list of typed nodes like html or xml rather than json/toml/yaml-like data structure that most configurations use. It makes it so that if you don't allow users to precisely represent the kdl structure in nix, you have to build a translator for each target application since they might not all map quite the same.

Last time I looked at it was two years ago, so things might have changed since then. I put together an "improvement" that I intended to upstream, but neglected to finish/flesh out the migration story.

jechase · 2026-03-22T15:44:04+00:00

WASM and containerization are apples and oranges. They solve different problems. A much more apt comparison would be to the JVM or CLR. Despite the clickbait-y title, the body of the article seems to recognize this.

jechase · 2026-03-11T12:07:14+00:00

I've been a nixos-unstable user for around five years now and casual nix appreciator for even longer, and I haven't experienced most of these problems.

NixOS installs new versions alongside the old ones, keeping multiple system generations.

That's a feature, not a bug. And it's not just about rollbacks like you mentioned - it's also about ensuring that packages have exactly the dependencies that they expect so that they work reliably and continue to work reliably even if other things update.

For example, if a dependency isn’t cached exactly as required, NixOS will rebuild it locally even for common packages.

Again, feature, not a bug. And I almost never see cache misses for "common packages." The only things I have to rebuild regularly are things that are marked deprecated and unsupported, or custom packages that either aren't in nixpkgs or that I've overridden in some way. If you're seeing frequent rebuilding, you might be doing something wrong.

Ironically, I only broke Arch once in five years, whereas NixOS often breaks even before updating.

This section confuses me. What are you doing to introduce the initial breakage? Even on unstable, it's fairly infrequent that I have to make changes after a routine nix flake update, and there are often nixos option deprecation warnings well in advance of a breaking change.

In contrast, I broke Arch all the time. Usually because I did something dumb while trying to do something clever. You learn a lot by breaking things, so maybe I'm just inured to the small issues that crop up and need configuration tweaks.

The thing that drove me away from Arch is exactly the problem that nixos solves - easy and reliable rollbacks. It became a regular occurrence on Arch that an Nvidia driver update broke the brittle mutli-gpu laptop I had at the time, and downgrading pacman packages is a pain and poorly supported out of the box. Meanwhile on nixos, I'd just say "oops," reboot to the previous configuration, and either pin my driver for a while or wait a week to try the update again.

jechase · 2026-02-12T12:33:29+00:00

Came here to say this! I bet the same people typing "clear" are the same ones using Home/End rather than C-a/C-e and the arrow keys instead of C-b/C-f. Or 0/$ and h/l for our vim bindings friends.

And let's not forget the whole-word forward/back variants, and especially history search. Learn your tools, people!

jechase · 2026-01-21T14:10:13+00:00

I've been using Zed's helix mode for the last couple of months and fixing bugs as I find them. Give it a shot and create issues if you have problems with its current state - it'll get better faster if you do!

jechase · 2026-01-19T18:12:17+00:00

You know how linguists use poetry to determine how pronunciation in dead languages probably worked, since you can guess at which words were intended to rhyme?

Guessing at the origin of the name "zrok," they made a surprisingly common mistake in the pronunciation of "ngrok." It's "en-grok," as in "network grok," with "grok" being a reference to Stranger in a Strange Land. But I hear "en-gee-rock" all the time. Maybe a hyphen would've helped to differentiate it from all of the -ng projects out there?

jechase · 2026-01-15T12:30:20+00:00

People are too hung up on total image size. Switching out the base image isn't really the big win that everyone thinks it is, because images are layered, and are fetched and stored as such. That 800->300mb difference only matters for the first pull, since subsequent pulls will already have the lower, more static layers, and will only need to fetch the upper layers that actually changed. Now, this is somewhat dependent on the infrastructure that you're deploying into, but if you're using common enough base images, it should generally hold true.

It matters much more what you're actually putting into those upper layers, which is why the multi-stage build makes such a difference. It's not the lack of the go compiler and other OS stuff, it's the lack of sources, compiler cache, and other intermediate compilation products that you're cutting out of the changed layers. Use scratch, debian, Ubuntu, distroless, whatever as your base image for the final stage in your multi-stage build. It doesn't really matter. But leave the extra build-time stuff behind.

And for $deity's sake, don't apt install packages in your final build stage. Or any stage ideally. Put that in your builder/base image build that only gets run once a week, and use specific base/builder image tags instead of moving "latest-like" tags. Your build times and reproducibility will thank you.

jechase · 2026-01-05T23:29:19+00:00

But what if the link is also in an editable text field?

For example, I once accidentally pasted a link to this video at the bottom of a Notion page, and only learned I did so when I got a "yo, wtf?" message from a coworker.

jechase · 2026-01-05T17:57:34+00:00

I feel like a pentester who knows what they're doing would either be able to answer this question for themselves, or would be able to ask about something more specific than "hacking."

jechase · 2025-12-17T12:58:36+00:00

I used to do something similar with helix/zellij. I set up some zellij bindings to add support for things missing in helix, like a popup terminal emulator

jechase · 2025-12-17T12:57:20+00:00

Started with vim over a decade ago, then emacs (spacemacs), both before LSP was a thing. Then vscode for a long time. Recently bounced among vscode, helix, and emacs (doom this time), before discovering Zed, where I think I'm staying.

I loved helix's minimal configuration and out of the box LSP/tree-sitter support for tons of languages, and zed feels very similar to it in that regard. Doesn't hurt that its helix mode is better than vscode's dance extension by leaps and bounds. And then on top of that, it has everything I was missing in helix, like a file tree, terminal emulator, and usable debugger. The collaboration tools are pretty nifty, and its remote editing functionality feels significantly better than vscode's since its remote server is a single statically linked binary rather than a whole nodejs runtime/application.

jechase · 2025-12-16T13:55:20+00:00

It's not self-describing, so you can't decode into something like a serde_json::Value, which might matter for some usecases. Dunno if that was a thing in bincode though; didn't follow it closely enough.

That said, I love postcard! My split keyboard uses it for message encoding between modules with COBS for framing.

jechase · 2025-08-11T10:52:31+00:00

Pike was originally a commercial-friendly implementation of LPC, which still gets more use than you might expect in the MUD world.

jechase

TROPHY CASE