Or at least they were, until I started using cache components the other week, and I'd not noticed they'd regressed. That's frustrating. Give me a few minutes...

Equity grants (and especially options) aren't particularly controversial in tech, and I'm not saying they're the answer to the problem at hand. But they're a mechanism for allowing workers to share in the gain from their investment. All the problems (especially with US tax treatment of options) notwithstanding.

Both Capital and Labour invest in the company, in different ways. It's not at all clear to me that the optimal arrangement is that Capital reaps the bulk of the return from those investments.

The SQLite backup script is part of my separate backup routine that predates HA's backups, and eventually makes it into a Borg backup hosted on rsync.net. Belt and braces.

Anyway, the sync-friendly output is the really important part for me, because it means I can point borg at the zstd-compressed file and it'll only need to store what's changed.

    OUT="${i}.sql.zst"
    PART="${OUT}.part"
    sqlite3 -readonly "${i}" .dump | zstd --fast --rsyncable -v -o "${PART}" -
    mv "${PART}" "${OUT}"

One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive.

The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.

Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.

A huge part of the job of Software Engineering is producing the right amount of code at the right time.

I can imagine Apple being less inclined to allow arbitrary eSIMs on their watches, preferring to only support the case where the eSIM is guaranteed to support the "correct" presentation.

I find it a lot harder to criticise folk who might well have used the controller themselves, at retail price, but upon discovering they've effectively paid 2.5x decide to put their controller onto the resale market.

I do wonder whether such a scheme might work for console launches — you put in the price you'd be willing to pay a scalper, and the batch you're allocated to is the first batch where the auction price is lower than your bid. Then you pay the auction price for that batch.

Faithlife do something with a converse price discovery function for book digitisation: you enter the amount you're willing to pay for the result, and if N people are willing to pay at least $COST/N, they do the work. No point in scalping that: it's a digital product, the question is availability rather than quantity.

In a world populated by humans, and with a mass-market good with restricted availability, there's a societal pressure to avoid enabling scalpers. Whether you act by yourself running some kind of auction, or by attempting to limit the ability of scalpers to buy in bulk, or by ignoring the pressure (and possibly running your own scalping operation to front-run the third-party scalpers), is up to you.

Strictly, just because the standard costs money doesn't mean that the information within it is otherwise unavailable. The C++ spec is an amusing example of this: the actual spec costs $$$, but the final draft is freely available. I can't imagine they sell many copies. I know that back when I was employed to work on a C++ compiler I only had access to the draft.

If demonstrating conformance is important, I suspect that the cost of access to specifications is only going to be a small fraction of the cost of certification. And as I understand things, it's certification that's the target of charging for specifications.