TIL that the term "planned obsolescence" was in use at least as far back as 1963!

sometimes it's the really simple things, like ordering food for pickup while you're still a few stops away on transit and having it become ready just as you arrive.

Of course, the ClickHouse instance in question is hosted on my tailnet and so thanks to @tailscale.com I could publish the username and password here and it wouldn't matter in the slightest (not that I'm going to try that, mind you...). But the same approach works for "real" secrets, API keys, etc.!

You completely eliminate the risk of a sensitive file going astray; you eliminate the risk of something getting copied-and-pasted or zipped up and sent somewhere it shouldn't go.

Sure, you can put credentials in a .env file, and I've certainly done that before, and it works, but it's so much easier to say "hey, the credentials this script needs are already in my password manager, why don't we just get them from there?".

Screenshot of Python code: import clickhouse_connect from onepassword.client import Client, DesktopAuth client = await Client.authenticate( auth=DesktopAuth(account_name=""), integration_name="", integration_version="20260406", ) conn = clickhouse_connect.get_client( host=await client.secrets.resolve("op://Personal/ClickHouse/host"), port=await client.secrets.resolve("op://Personal/ClickHouse/port"), username=await client.secrets.resolve("op://Personal/ClickHouse/user"), password=await client.secrets.resolve("op://Personal/ClickHouse/password"), )

I have just discovered the @1password.bsky.social SDK for Python (github.com/1Password/on...), and I love that I no longer have to worry about accidentally publishing credentials because it becomes LITERALLY IMPOSSIBLE. Need a connection to @clickhouse.com? There it is!

This was genuinely so much fun—sorry we didn't have more time to catch up but hopefully I'll be back on that side of the country before too long!

My BLÅHAJ turns one today!

this is why you can't take anyone seriously who says they're safer than cars; as these things become more commonplace for middle class people, they're gutting the will to support public transit among those groups, *who used to take transit*

a reminder that, as long as Waymo is undercutting the popular will for public transit, they are actively making people *less* safe

so not only are www.prana.com/p/stretch-zi... excellent pants but they also appear to be engaging in pocket reparations because the equivalent pants in the men's line have *fewer* pockets!

Need to go from geographic points to time zone identifiers in @clickhouse.com? With @evansiroky.bsky.social's time zone boundary shapefiles and ClickHouse's support for polygon dictionaries, it's fast and easy: kurtraschke.com/2026/04/clic...

bringing motonormativity to rodentia, i see…

https://www.bbc.com/news/world-us-canada-50167812

I don't know who needs to hear this, but if you design a system and 50% of its users are using it wrong, that is not user error.

You cannot blame users for that, you built a terrible system.

Let’s talk about how this works and why we have older devices. When I started doing cabin integration back in 2017, we actually had a 2020 launch date. We bought the tablets the crew used for Artemis II back then. To not spend as much, we limited our choice to devices that were in the ISS catalog.

3.1.3 Databases Access and Management Utilizing the OPS LAN, crewmembers will be able to access database information from anywhere in the ISS. Database systems supported by the OPS LAN include IMS and HazMat. 3.1.3.1 IMS Equipment and material aboard the International Space Station will be cataloged and stored in Microsoft SQL databases that will reside on the OPS LAN File Server. The Inventory Management System (IMS) controls placement and use of Station equipment and parts. The IMS will be a Web-based system using Microsoft Internet Information Server (IIS) and Microsoft SQL Server. Modifications to the IMS database will be downlinked daily to keep the ground records synchronized. Server database updates can be sent via the OCA. 3.1.3.2 HazMat The Hazardous Material (HazMat) database lists potentially harmful substances that may be encountered aboard the ISS. At present, HazMat is a Microsoft Access application; to conform to S-POCCB standards (see Section 2.7), HazMat will be hosted on SQL Server.

Now, if you really want something to get your hackles up about, how about *Microsoft Access in space*?

Anyway, quit laughing. It may sound absurd at first but it's a good solution to a unique problem and it has worked for years.

And that's without even getting into the security concerns around directly linking IP networks onboard a space vehicle and on Earth. (It's not impossible! It's been done before, but it's something we have to design for and think about carefully!)

Until and unless we invent some kind of faster-than-light communication, you're always going to have latency challenges which will strain terrestrial communication protocols. It simply makes no sense to try to run EWS over the DSN.

Will there ever come a time that the Station LAN is "just another network"? In many ways, it already is. The ISS has Wi-Fi, printers (and printer problems!), and many of the other trappings of a "real" network.

But there's no getting around physics.

OUTLOOK: All the .ost (offline) files reside on the ProShare PGSC. You must either be on the ProShare PGSC or networked to it to use Outlook. Close Outlook and every email message when you are finished composing e-mail or else it will cause problems when the .ost files are synced by MCC. To sync means to downlink the messages that you composed, and uplink your mail. If Outlook is running during this process, these files may be corrupted, and the e-mail may not make it to its destination. While the .ost files are being synced, Outlook will be disabled temporarily; you may get a message after you launch it that tells you this. Just try again later. Save your read e-mail by dragging and dropping it in your personal folder. This keeps the size of the .ost files small and speeds up the uplinking during the syncing process.

Instead, astronauts read their mail in offline Outlook, and before they go to bed, they quit Outlook, and then "overnight", their Outlook .ost file gets sent to the ground, opened, synced, sent back, and replaced on the on-orbit computer.

Is it weird for us earthlings? Sure. Does it work? Yes.

You could even then pack up Outlook's data files again, send them back, and keep right on going.

And indeed, this is how mail works in space. Outlook isn't talking to an Exchange server via TDRS or the DSN. Nor IMAP, POP3, or SMTP.

But, Outlook can operate just fine without a direct connection to a mail server. If you just happen to close Outlook, transport its files to another computer, and open them there, it'll send and receive mail as if nothing ever happened.

3.1.4 Crew Mail (E-Mail) Handling Currently, Microsoft Outlook 98 is installed on SSCs to support crew email operations on-orbit. The manner in which Space Station crews create, send, and receive email messages is identical to how email is managed on the ground. However, since orbiting crews do not have a direct network or Internet link for sending or receiving email, their messages are temporarily saved to an Outlook-unique ‘offline’ folder, or *.ost file. An *.ost file exists for each Station crewmember mail account, based on the crewmember’s network username; i.e., email from or to William Shepherd is stored in shep.ost file. These *.ost files are periodically downlinked and uplinked to the crew via the Station OCA file transfer system. After the downlinked *.ost files are received by the ground, the OCA operator will log into the same mail accounts that exist on a JSC mail server. The mail server will synchronize the downlinked *.ost files with the ground mail accounts. Email being sent by the Station crew and saved in the *.ost files will be distributed over JSC networks and the Internet during the synchronization. New email sent to the crew is also saved to the crew *.ost files during the synchronization with the mail server. The updated *.ost files, with the new email, are later uplinked to the Station crew on-orbit to be viewed with MS Outlook.

I can't speak for Artemis, but I can speak, from primary source documentation, to how email was handled on the Shuttle and is handled on the ISS.

In this era of ubiquitous connectivity, I suspect some folks have forgotten what it means for a mail client to be "offline", or what an "outbox" is.

Okay, I'm getting tired of people cracking jokes about Outlook (or worse, "hurr durr stupid NASA"), so, look, we're going to talk about email in space.

Yes, Outlook is in space. It has been for decades. Literally. However, the way Outlook is used is, well, you might say "out-of-this-world".

i recently learned, via @nat.makhijani.us, that some bodegas sell sleeves of Ritz crackers this way.

We used to have Sun Solaris in space, running on IBM ThinkPads. Those were the good days.

We've been down this road before: there is _literally_ the APTA Contactless Fare Media System Standard, plus ISO 24014.

Screenshot of SQL code: CREATE OR REPLACE FUNCTION do_something LANGUAGE WASM ABI BUFFERED_V1 FROM 'my_udfs' ARGUMENTS (args Tuple(DateTime('UTC'), String)) RETURNS Tuple(DateTime('UTC'));

On the ClickHouse side, you'll pass and return tuples, and aside from some extra parentheses when you call the function, it's basically seamless!

Screenshot of Rust code: #[derive(Serialize, Deserialize, Debug)] struct FunctionArgs { #[serde(with = "ts_seconds")] some_timestamp: DateTime<Utc>, some_string: String, } #[derive(Serialize, Deserialize, Debug)] struct FunctionReturn { #[serde(with = "ts_seconds")] some_timestamp: DateTime<Utc>, } #[clickhouse_udf] pub fn do_something(args: FunctionArgs) -> Result<FunctionReturn> { Ok(FunctionReturn { some_timestamp: args.some_timestamp + Duration::hours(args.some_string.parse::<i64>()?), }) }

chrono's serde support provides optional serializers and deserializers for seconds, milliseconds, and nanoseconds, but you can't annotate function arguments nor return types with those! What to do?

The answer is easy: just wrap your arguments and/or return type in a struct!