This presupposes knowing that a fitbit uses bluetooth. As I understand it, there are also models (e.g. Fitbit Charge) which cannot be turned off anyway.
Plus there is an overall assumption here that the owner of a Fitbit knows that the device nickname is visible to anyone, and not just themselves.
These things are certainly not at all obvious in an app-centric bluetooth device context.
Part of the productivity gains did go to workers. Depending on the country that's somewhere between 0% (Japan) and ~70%. The US seems to sit at 10-20%. The remainder is pocketed by others.
CBOR and COSE are pretty bad formats. The original "rationale" for CBOR was that messagepack didn't distinguish bytes and strings, which was added around ~2013. Afterwards CBOR was changed up a bit from messagepack and became a decidedly worse format. And COSE just goes against every other principle of well-engineered crypto, but that's not particularly surprising giving it is a JOSE derivative.
A good zero-order classifier for "is this signing format a dumpster fire" is whether the spec mentions canonical encodings.
It took me quite some time to realize what an utterly presumptuous product name Claude Code actually is, but only because Shannon is rarely mentioned with his first name. It's golden calf levels of hubris, even more so if you consider how incapable it was on release. It's like renaming calc.exe Einstein. Incredibly poor taste, but entirely in line with AI tech bro mentality.
That linkage never occurred to me, or, I suspect, them. Claude use to be a reasonably common name. I have an uncle Claude. Why do you believe they named it after Shannon in particular?
There are some good designs which prevent them from getting dirty. For example, Mercedes and VW put them in the rear badge and they're only exposed when needed.
This is the fault/price of backwards compatibility. Most users of SQLite should just fire off a few pragmas on each connection:
PRAGMA journal_mode = WAL
PRAGMA foreign_keys = ON
# Something non-null
PRAGMA busy_timeout = 1000
# This is fine for most applications, but see the manual
PRAGMA synchronous = NORMAL
# If you use it as a file format
PRAGMA trusted_schema = OFF
You might need additional options, depending on the binding. E.g. Python applications should not use the defaults of the sqlite3 module, which are simply wrong (with no alternative except out-of-stdlib bindings pre-3.12): https://docs.python.org/3/library/sqlite3.html#transaction-c...
While it has bad ergonomics, you can also use CHECK constraints. For example, using sqlite's built in date support, it's possible but awkward:
CHECK (
date(my_date_col) IS NOT NULL
AND my_date_col = date(my_date_col)
)
The IS NOT NULL is needed because date returns NULL for invalid dates; the other check because it also accepts Julian days (date('2026') is sometime during year 4707 BC).
It literally is? Changing the defaults shown in the PRAGMAs above would break backwards compatibility. SQLite is strictly semantically versioned and does not break backwards compatibility.
Their complaint was SQLite's type system was poor. You said this was the price of compatibility. And the documentation of your recommended pragmas said nothing of types. They seemed unrelated helpful advice seemingly.
New types would break forward compatibility in SQLite's terms. 3.7.0 added WAL mode was their example of a forward compatibility break.[1] 3.y.0 could add better type system mode.
Plus there is an overall assumption here that the owner of a Fitbit knows that the device nickname is visible to anyone, and not just themselves.
These things are certainly not at all obvious in an app-centric bluetooth device context.
reply