Yes, if you look at a photo of the X220 lid, what looks like a cosmetic accent across the lid near screen-top is actually a seam, between the nice alloy traditional lid, and some plastic that's barely held on, painted to look the same. Even minor impact can break the little plastic screw hole tabs that hold the screen-top edge of the lid. Absolutely not what you want from a ThinkPad, which has a legacy of being durable.
A disappointing thing about this is that someone changed the design, to this, to be more fragile and non-ThinkPad. In this way, it's similar to the series of regression changes to the keyboard, and now the TrackPoint.
> We already have FreeBSD CI; machines for the other 3 are arriving at my place tomorrow as it happens.
That's great.
I hope it works out, and you have CI for NetBSD, OpenBSD, and illumos, too.
Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port.
It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream.
Maybe Zig could play a similar role.
It's a shame GitHub doesn't have native CI even for FreeBSD on x86-64.
I can see the economic case against it, of course.
That said, the third-party Cross-Platform GitHub Action (https://github.com/cross-platform-actions/action) has made Free/Net/OpenBSD CI practical for me.
I have used it in many projects.
The developer is currently working on OmniOS support in https://github.com/cross-platform-actions/omnios-builder.
> Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.
In fact, we do already have cross-compilation support for NetBSD (and FreeBSD). But we currently only "test" NetBSD by building the language behavior tests and standard library tests for it on Linux, i.e. we don't actually run them, nor do we build the compiler itself for NetBSD. Native CI machines will allow us to fill that gap.
As it happens, Go's cross-compilation support does indeed make our lives easier for provisioning CI machines since we can build the Forgejo Runner for all of them from one machine: https://codeberg.org/ziglang/runner/releases/tag/v12.0.0
> For coding, you can use AI to write your code.
For software engineering, you can't.
This is a pretty common sentiment.
I think it equates using AI with vibe-coding, having AI write code without human review.
I'd suggest amending your rule to this:
> For coding, you can use AI.
For software engineering, you can't.
You can use AI in a process compatible with software engineering.
Prompt it carefully to generate a draft, then have a human review and rework it as needed before committing.
If the AI-written code is poorly architected or redundant, the human can use the same AI to refactor and shape it.
Now, you can say this negates the productivity gains.
It will necessarily negate some.
My point is that the result is comparable to human-written software (such as it is).
I didn't realize WebP was limited-RGB in addition to 4:2:0.
According to RFC 9649, this is accurate.
While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB:
> The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.
I assume all process memory may contain residual secrets.
As a mitigation in a password manager and an encrypted file editor, I prevent process memory from being swapped to disk with https://pkg.go.dev/syscall#Mlockall.
No.
age developer Filippo Valsorda has experimented with Kyber/ML-KEM and maintains a Go library for it, https://github.com/FiloSottile/mlkem768.
The public key size is intimidating.
> I'm now experimenting with `age`, which touts itself as "simple, modern, and secure encryption". If needed, I will use `minisign` for signatures.
I have also switched from GPG to age.
When I wanted to start signing my open-source software releases because of recent supply-chain attacks, I first thought of Minisign, too.
I tried it for binaries and even found a few third-party Git integrations (https://codeberg.org/SkyFox42/git-minisign, https://github.com/sug0/git-signify), then discovered that Git and GitHub supported signing with SSH keys (https://stackoverflow.com/questions/72844616).
GitHub supports it in the sense that it will indicate a commit or tag is signed.
I have adopted this approach: I sign tags with `git tag -s foo` and binaries with `ssh-keygen -Y sign`, and I have put the public key and usage instructions on my site (https://dbohdan.com/pubkeys).
Cool concept.
I like the lowercase q a lot.
The misaligned dot (tittle) on the lowercase i and j bugs me.
It feels off to have it at different heights.
I'd try making the i taller to match the j.
> - Display lid is very fragile at the top where the wifi antennas are and can easily crack there
reply