dchest

You can also use Emacs keys (Ctrl-D) for one-handed delete. Very convenient when Caps Lock is remapped to Control.

Talk at EuroBSDCon 2026: https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u

Talk at EuroBSDCon 2026: https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u

It's recorded in the HTML5 spec under 4.2.5.1 Standard metadata names, which defines the correct format and parsing:

https://html.spec.whatwg.org/multipage/semantics.html#meta-k...

So, it's standardized and not deprecated.

It has this note though:

"Many search engines do not consider such keywords, because this feature has historically been used unreliably and even misleadingly as a way to spam search engine results in a way that is not helpful for users."

HTML 4.01 says the following:

"This specification does not define a set of legal meta data properties. The meaning of a property and the set of legal values for that property should be defined in a reference lexicon called a profile. For example, a profile designed to help search engines index documents might define properties such as "author", "copyright", "keywords", etc."

https://www.w3.org/TR/html4/struct/global.html#h-7.4.4

Why is meta keywords deprecated? I use them for my custom website search. I don't care that external search engines don't index it.

There's more to it than just using a memory safe language.

GPS

Times New Roman (and STIX Two Text, Libertinus Serif clones) has been designed with increased x-height while keeping the same line height, see https://en.wikipedia.org/wiki/Times_New_Roman#/media/File:Ti...

It's normal for it to appear denser vertically. Your example of increased line height looks suitable for subheadings, but in no way represents the typographic tradition of its use.

Indeed:

https://hart.pglaf.org/

From Wikipedia:

"Michael Hart's email messages and blog posts had equal line length paragraphs in monospaced font: he chose the wording in such a way that each line had the same number of characters."

It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).

A warning about openbsdhandbook[.]com - this website has completely incorrect information for some things. Like hallucinated, even though I think it was created before LLMs.

I recently learned that Russ also wrote software for The On-Line Encyclopedia of Integer Sequences (https://oeis.org) and is the president of the OEIS Foundation.

The original: https://www.youtube.com/shorts/uaQyaBRaM9w

> measure and improve your website speed

inserts 31KB JavaScript into tiny HTML pages.

Indeed, https://blog.cloudflare.com/the-rum-diaries-enabling-web-ana...

Lua 5.4 and 5.5 use xoshiro256**: https://www.lua.org/manual/5.4/manual.html#pdf-math.random

Yes, WAL by definition means it writes the data at least twice.

Write-Ahead Log for... logs?

WAL means it will write the same data at least twice. Similar issue, but even worse, with LevelDB -- it will just delay the inevitable huge rewrites for later. Funny to hear those proposals in the write amplification thread.

I believe journald log rotation is basically: close file - open a new one. How is it not completely different?

Looks like it was caused by result confusion: crypto_dispatch returns errors in two different ways:

https://man.freebsd.org/cgi/man.cgi?query=crypto_dispatch&ap...

"crypto_dispatch() returns an error if the request contained invalid fields, or zero if the request was valid."

However, on an actual error from the crypto driver (e.g. invalid MAC), crypto_dispatch result is successful and the error is returned in crp_etype structure field.

https://cgit.freebsd.org/src/commit/sys/dev/wg?id=3427182452...

FORTH LOVE? IF HONK THEN

With CGO disabled, it only reads /etc/passwd, while the glibc getpwnam(3) can query LDAP etc.

Which uses libc via CGO or parses /etc/passwd with no CGO, which won't work for some cases.

https://github.com/tailscale/tailscale/blob/e4144230f410204a...

  // userLookupGetent uses "getent" to look up users so that even with static
  // tailscaled binaries without cgo (as we distribute), we can still look up
  // PAM/NSS users which the standard library's os/user without cgo won't get
  // (because of no libc hooks). If "getent" fails, userLookupGetent falls back
  // to the standard library.

I did something like this using fail2ban for some time, but 1) it didn't help much due to the larger number of IPs, 2) it blocked widely used VPN services.

Can be malware? Something like https://news.ycombinator.com/item?id=48667495

Being able to quickly reject invalid sessions identifiers is a useful property in some cases and is normally done by authenticating stateful session tokens with a MAC using a global app key. This can be used for DoS protection if the cost of a database lookup is more than the cost of MAC, and the complexity is justified. It ensures that the random numbers a user is trying to present as their session token are the numbers generated by the server if the key is not leaked.

Because you're trying to bolt things on top of JWT, you're creating a worse version of that stateful authentication pattern:

1. You lost the statelessness of JWT by making database queries. Your claim that "you don't need to verify against user's secret immediately" is false, as you need to do that in all cases immediately after verifying the JWT signature to get the benefits of your system (token invalidation). Sure, you reject completely invalid tokens early, but you still need the statefulness to authenticate users properly (if your goal is to be able to invalidate tokens).

2. In your version, getting a read-only access to the user database (leaking per-user secrets) completely destroys token invalidation, and all your authentication now depends on one key. If, in addition to that, the JWT signing key leaks, user authentication is completely destroyed and can be bypassed by the attacker, who now can sign in as any user. (A common way to leak all this is by failing to properly secure backups).

Compared to a stateful session system with split-tokens, where the database stores tokenId => verifier, where verifier is Hash(randomToken), and user's token is id||randomToken, read-only access to the database doesn't let the attacker authenticate as any user. If the tokens that users presents are in the form of id||randomToken||HMAC(serverKey, id||randomToken) for early rejection as above, leaking serverKey still won't allow the attacker to authenticate as any user. The attacker needs write access.

> Is author's brain stateless -- my bad, I thought this was not reddit

I didn't realize that you were the author, I thought you were a reader who was misled by this blog post. Even better: you can go and edit it, removing "stateless" everywhere! It's fun to invent various protocols, but when someone points out the errors, surely you'd want to fix them -- no shame in making mistakes if you correct them.

Usually, when I think of a protocol, after writing down "Benefits" (as in your blog post), I write "Drawbacks" and then try to come up with downsides and compare it with existing protocols. I'd suggest you do the same.

PS. Find yourself in this picture: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

WTF:

> Each user has a secret: Stored securely in the database.

> Stateless Validation: The core validation remains stateless. We only need to consult the database for the user's secret, which we'd likely do anyway for authorization checks.

Is "stateless" the same as "serverless" now? Is author's brain stateless?

Yeah, you made a revocation list but with time value instead of the token value.

It's interesting that most of the comments here are about using this feature to bypass security restrictions (whether valid or not). It says a lot about the attack surface of GNU utilities caused by featuritis.