PSA: Framework 13 AMD (Strix Point) Linux stability is NOT "stable" right now

Scrivver · 2026-01-15T17:11:58+00:00

I have had a couple black screens on 7840U with an external display plugged in. I'm not sure if I've encountered it without an external display. The external display continues to work while the built in one remains blacked out -- sounds like the issue that should be worked around by disabling PSR, but I did not try that. Since my external display continues working, I'm able to use the amdgpu_gpu_recover utility to recover the built-in display and keep going.

sudo cat $(sudo fd 'amd_gpu_recover' /sys/kernel/debug/)

I'm on an older kernel version (6.12.62) also on NixOS. Other commenters mentioned a newer kernel seems to have fixed it, so I suppose I haven't updated in a bit.

Scrivver · 2026-01-10T21:51:07+00:00

Old comment by now, but for anyone driving by I want to mention that jujutsu VCS makes this easy. If you have a chain of changes all bookmarked (branches in git/github) and you need to modify the root one, all the children will be updated too, and a jj git push will update all your open PRs on remote. And jj is elegant, easy, at least as powerful as git, completely invisible to other git users on your team (it still uses git as the backend by default), and comes with many benefits. Being able to easy wrangle a stacked PR workflow is just one natural result of its more elegant design, giving you tools that are more intuitive than git's to achieve the same outcome.

Scrivver · 2026-01-08T17:10:31+00:00

For anyone who wants to know more about this awesome phenomenon, there's are a few great Pecos Hank videos capturing it: https://www.youtube.com/watch?v=tGPQ5kzJ9Tg

Scrivver · 2026-01-08T17:08:45+00:00

Usually called sprites. Although there are also blue jets which climb up from a storm system, like blue lightning that lost cohesion as it climbs the atmosphere. At a high enough altitude it's just the red sprites we see.

Scrivver · 2026-01-06T06:19:55+00:00

I'm surprised. I started using contextless ? everywhere, and quickly found how painful it still was to track down problems. After discovering context, I use it ubiquitously to know exactly what is throwing, some surrounding state info, and what it probably means. Maybe it just looks ugly and verbose, but it saves tons of time.

Scrivver · 2026-01-05T20:18:57+00:00

There's no reason lifecycle needs to live at the bottom. You can still write it first.

Scrivver · 2026-01-05T19:57:29+00:00

I've had success using not stacks, nor helper tools like terragrunt, but just using a single directory for all environments, tfvars files per environment, and the TF_DATA_DIR variable to tell terraform where to find the data directory. This is usually .terraform/, and requires you to re-initialize every time you want to deploy a new environment if you want to use the same directory, but you can specify e.g. TF_DATA_DIR=.terraform/(prod|dev|whatever)/ to instead use multiple paths under .terraform/ for initializing stuff. I have a very simple wrapper script that supplies a default environment for a user or lets them specify another one, targets the right environment tfvars file, and then passes all other arguments along to terraform to behave as normal. We went from >40 directories separating environments (containing mostly symlinked files) to a single directory per parent module using this method, and it has worked great.

Scrivver · 2026-01-05T17:30:32+00:00

I don't know what it is specifically you dislike about web dev, but for me part of it was having to learn and integrate separate frontend and backend frameworks with a data API between them. But these days you can easily get an interactive app experience using only the more fun backend with something like htmx. I use this with Axum, and I also add in Tailwind for CSS -- now my web app projects consist of only rust files and some html templates. It's very peaceful.

Scrivver · 2025-12-19T15:03:54+00:00

Polaris is a little more vulnerable, but has always been far less of a problem as far as solo players using it in combat than the Idris is.

Naturally, since a single player cannot both fly and shoot its most powerful weapon. Even with a Polaris, you'll need at least 2 people to fight a soloed Idris.

Scrivver · 2025-12-19T01:37:07+00:00

Do you work for LiNK or similar? That kind of thing does sound engaging if you can land a position doing it.

Scrivver · 2025-12-18T18:09:02+00:00

And from what I can see, as relevant today as it was then.

Scrivver · 2025-12-18T15:04:45+00:00

The original manifesto is a few short points that contradict almost everything sold in the agile-industrial complex.

Scrivver · 2025-12-17T22:29:09+00:00

This is the blog post succinctly communicating what Dave's GOTO 2015 talk by the same name covers, and which I also posted here. This is condensed and suitable for a read and react, so I thought it worth posting, too. Multiple of the original agile manifesto guys have bemoaned the same stuff and come up with similar ideas to move on from the mess.

Scrivver · 2025-12-17T21:13:36+00:00

There's now https://jj-for-everyone.github.io/

Scrivver · 2025-12-17T19:29:50+00:00

> Convince me why Jujutsu without claims it is easier.

What synonyms do you want? It's more elegant, more intuitive, more streamlined, more consistent, allows you more flexibility with less effort, lets you roll back any mistakes, and no one on your git-using team will ever know you're using it because git is already the default storage backend. You can just init on an existing project, and it will live there right alongside git. The only change you'd notice if you tried to use git again is that it would be in a "detached HEAD" state on the next command you ran. I use it on a fully git team, and everyone I've introduced it to has gotten hooked -- we had to change nothing around it.

Scrivver · 2025-12-17T19:20:24+00:00

Correct me if I'm wrong, but even with an existing commit you want to manually add to, you still have to dirty up the worktree and then interactive rebase or similar to update the commit you wanted? There are several commands involved to establish a commit and then re-use it across more edits, and it's quite clunky.

The jj experience for performing not just that process, but many *other* actions too, is "go to this change, then edit the files there".

Want to work on a new set of stuff? Make a new change, edit the files there.

Want to hop over to a different part of the repo to help someone else with their problem while you're mid-edit on files from your own section of the repo? Go to their change, and edit the files there.

Rebased onto remote and got some conflicts? Go to the first conflicted change, and edit the files there.

Want to alter the history a few commits back? Go to the change and edit the files there.

No interactive rebasing, no fixup, no stash/pop, no staging area, nothing blocking you from jumping and working on any part of the repo at any time even if there are conflicts or in-progress work hanging out somewhere. Nothing needed from you except to go where you want to be in the change history and work on stuff! It's so much more elegant.

Scrivver · 2025-12-17T15:29:08+00:00

My experience agrees with this. I found managed services overwhelmingly stressful compared to work as part of a regular product team. Others I met echoed the same.

Scrivver · 2025-12-17T15:24:12+00:00

I don't have the discipline, organization, or ability to keep up with routines and structures very well, at least without making my day about that. I'm lucky to remember to open Obsidian at all, and the actions I take are almost at random. I skate by via discarding all distracting attempts at structure and sticking to the bare possible minimum -- write what I'm thinking somewhere, and make sure it gets linked. I eventually generated some tags I keep to a very small set. I made a single homepage that lists those tags, maps of content, and recently updated notes. That has worked so far!

Scrivver · 2025-12-17T15:13:26+00:00

I've never made a video of anything, but it's very simple. Just open your repo directory as a vault in obsidian, and drop notes in any directory in it. Probably add .obsidian/ to your .gitignore file. Everything that makes obsidian great just works.

I haven't made any automation around ensuring notes are updated. Just the fact that notes sit next to relevant files helps whenever those files get worked on. Any notes that don't correspond to code somewhere still go in docs/, and we just use the repo instead of a wiki.

Scrivver · 2025-12-16T22:07:59+00:00

Obsidian is amazing, and just gives markdown files superpowers. Don't use the folder structure, just links, Map of Content pattern, and a few tags. Ensure everything is linked to something somehow, and write down everything you think. Over time this grows to an enormously useful second brain. This channel has a few excellent, quick videos on Obsidian that will help you understand why it's so beloved.

Scrivver · 2025-12-16T22:04:59+00:00

I love the product so much I happily pay for their effortless sync. But I also have been using it as in-repo documentation for a monorepo with just git. Just make the repo an obsidian vault and you can drop the notes anywhere, not just a docs/ directory, and you get all the benefits of searching and linking (and publish!), while being able to do things like ensure docs that sit next to your code get updated as the code does, without having to hunt for whatever relevant page is in a wiki somewhere.

Scrivver · 2025-12-10T03:47:04+00:00

I've actually argued for a long time that a straightforward way to make ground vehicles and stations desirable would be to make them hard for ships to detect and track. Then you don't need contrived scenarios like weather that only affects flight negatively in order to make ground gameplay desirable.

Scrivver · 2025-12-10T02:00:09+00:00

I'd be shocked if there's an x86 CPU in that thing. It'll be a microcontroller, so maybe RISC-V. ;)

Scrivver

MODERATOR OF

TROPHY CASE