Even with daemon(8), PID files and the lack of process supervision might be my least favorite aspect of FreeBSD, an OS I like overall. Not long ago, I wanted to avoid running a custom service that way on a fresh FreeBSD server. After researching my options, I found an adequate solution in the daemontools family. I'd heard of daemontools but hadn't paid much attention to it.

My service has been managed by runit and, most recently, nitro (https://github.com/leahneukirchen/nitro). Both have run as the service's user. They supervise the process and handle logging. I have found the design of daemontools and its derivatives runit and nitro elegant; it lives up to the reputation.

I have been using daemontools for managing my services on FreeBSD servers that have run 24/7 for almost a quarter of century, with down times of an hour or so only at intervals of a few years of continuous running, whenever I made a hardware upgrade or a complete OS replacement (by passing to another major version of FreeBSD).

Now there are several daemontools derivatives that bring it more up-to-date, but even the ancient original version did most of one would need for reliable service management.

You can use so-called "exec magic" instead of `env -S`. Here is an explanation with Python examples: https://dbohdan.com/scripts-with-dependencies#exec-magic (disclosure: my site). In short:

  #! /bin/sh
  "exec" "/usr/bin/env" "uv" "run" "--quiet" "--script" "$0" "$@"
  # /// script
  # dependencies = [
  #   "cowsay",
  # ]
  # ///
  import cowsay
  cowsay.cow("Hello, world!")

On systems that can't run uv, like NetBSD and OpenBSD, switch to pipx:

  #! /bin/sh
  "exec" "/usr/bin/env" "pipx" "run" "$0" "$@"
  # ...

According to https://old.reddit.com/r/thinkpad/comments/1d13sb6/should_i_...:

> - Display lid is very fragile at the top where the wifi antennas are and can easily crack there

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.

https://www.reddit.com/media?url=https%3A%2F%2Fpreview.redd....

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.

I notice again I haven't internalized how much https://tvtropes.org/pmwiki/pmwiki.php/Main/SuspiciouslySpec... really happens.

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

100% this.

Just don't expect to get decent code often if you mostly rely on something like cursor's default model.

You literally get what you pay for.

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 evaluated but didn't adopt https://github.com/awnumar/memguard in Go. No matter how well-implemented and reliable it is, I can't pass its secrets to https://github.com/FiloSottile/age.

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.

This sounds like what philosophers call "indirect consequentialism" or the related "two-level utilitarianism". The idea is what you say: aim for good outcomes, but use rules or virtues as heuristics because direct consequential reasoning is impractical, and it's easy to go wrong with it. If you're interested, take a look at https://plato.stanford.edu/entries/consequentialism/#:~:text... and https://en.wikipedia.org/wiki/Two-level_utilitarianism.

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.

https://x.com/FiloSottile/status/1544803635237998592 (2022-07-06):

> A Kʏʙᴇʀ768+X25519 recipient would clock in at about 1660 characters.

> Classic X25519 age recipient for scale.

> https://paste.dbohdan.com/1mhc0nc-w7ks3/recipient.png [Alt text: A terminal window. The classic recipient on the first line takes about 2/3 of a line. The PQC one takes 16 lines.]

Oh, that's a shame.

I'd like to use something stable and supported for long term backups, so size doesn't matter. Pre-quantum is not something worth migrating to.