akshayshah

In the US, it’s typical for hospitals to provide and launder scrubs used in sterile environments (especially surgical scrubs). However, scrubs are worn in many non-sterile environments too - and it’s often the employee’s responsibility to launder those scrubs. Sometimes, it’s also the employee’s responsibility to purchase non-sterile scrubs.

IMO, this isn’t as crazy as it may sound. It’s reasonable to expect healthcare workers to be professionally dressed (so no gym shorts and tee shirts). It’s also reasonable to want their clothing to be as washable as possible (no neckties, no infrequently-washed blazers or sweaters, fabrics made for harsher detergents and hotter wash water, etc.). Scrubs fit the bill and they’re an improvement over the business casual attire that preceded them.

So why not make everyone use hospital-owned, hospital-laundered scrubs? Because employees don’t like them. Hospital scrubs are usually baggy, scratchy, inconsistently sized, and just plain ugly. I’m a man, but the fit problems seemed especially bad for women. For many people, it’s not pleasant to spend every work day uncomfortable, dissatisfied with their appearance, and with their pants about to fall off.

The methods in the article aren’t super convincing, though the conclusion (wash everyone’s scrubs in a commercial facility) has some intrinsic appeal. Accelerating the rate at which hospital bacteria acquire resistance to detergents is certainly bad - it’s already quite hard to adequately clean healthcare facilities.

I claimed that Google is the only major cloud provider with all three of:

- single-zone object storage buckets

- regional object storage buckets

- transparently replicated, dual region object storage buckets

I agree that AWS has two of the three. AFAIK AWS does not have multi-region buckets - the closest they have is canned replication between single-region buckets.

The cross-region replication I’ve seen for S3 (including the link you’ve provided) is fundamentally different from a dual-region GCS bucket. AWS is providing a way to automatically copy objects between distinct buckets, while GCS is providing a single bucket that spans multiple regions.

It’s much, much easier to code against a dual-region GCS bucket because the bucket namespace and object metadata are strongly consistent across regions.

Sure, but AFAIK S3’s multi-region capabilities are quite far behind GCS’s.

S3 offers some multi-region replication facilities, but as far as I’ve seen they all come at the cost of inconsistent reads - which greatly complicates application code. GCS dual-region buckets offer strongly consistent metadata reads across multiple regions, transparently fetch data from the source region where necessary, and offer clear SLAs for replication. I don’t think the S3 offerings are comparable. But maybe I’m wrong - I’d love more competition here!

https://cloud.google.com/blog/products/storage-data-transfer...

Very cool! This makes Google the only major cloud that has low-latency single-zone object storage, standard regional object storage, and transparently-replicated dual-region object storage - all with the same API.

For infra systems, this is great: code against the GCS API, and let the user choose the cost/latency/durability tradeoffs that make sense for their use case.

To someone who hasn’t worked much with XML, this seems like a reasonable take!

For cases where a host system wants to execute user-defined data transformations safely, XSLT seems like it might be useful. When they mature, maybe WASM and WASI will fill the same niche with better developer ergonomics?

Em- and en-dashes have been well-supported by LaTeX, the smartypants family of Markdown extensions, and plain HTML for more than 20 years.

In your support, though, calling the extension “smartypants” really hints at the target audience :)

It’s certainly possible to gain that fluency, as Reginaldus demonstrated. But it seemed to me that fluency reading unfamiliar texts simply wasn't the goal of my Latin education; instead, we were studying to know Catullus, Ovid, Horace, Cicero, and Vergil, with a small smattering of other Roman authors. It was an education in classics, not the Latin language. We just weren’t asked to extract information from large volumes of text, speak extemporaneously, or comprehend casual conversation.

The best analogy I can give is this: imagine taking Spanish from grades 7-12, culminating in a full year reading and understanding selections of Don Quixote. The entire curriculum builds towards this capstone year, and other areas of inquiry get very short shrift. Nobody cares if you can live comfortably in a Spanish-speaking country or watch Spanish-language TV. Nobody cares about modern idiom, or any more recent works of literature, or technical writing. s/Don Quixote/Aeneid + a small corpus of Roman poems/g and you have the bulk of my Latin education.

This sounds negative - we weren’t fluent in Latin! But for a teenager, it was a wonderfully deep exploration of Rome’s greatest hits. I loved it.

I had the chance to attend some of Father Reginaldus’s summer school in 1999, and it sparked a lifelong love of Latin. The article did a wonderful job capturing the verve that Reginaldus brought to the material.

I’ve always imagined the Recurse Center being similar-ish for programming.

Second-year high school students do read actual Roman texts, but they typically do so very slowly and laboriously - a day’s homework might be translating a single paragraph.

I studied Latin from 7th grade through my early undergraduate years (1990s to early 00s), and that dynamic didn’t change as much as you might expect - the focus remains on deeply reading a few texts, rather than building the fluency required to quickly read and understand new texts on unfamiliar subjects. The corpus of texts for standardized exams is also relatively small and well-known - I didn’t see a single unfamiliar passage on either AP Latin exam.

Perhaps some classics professors read Latin as fluently as the average Spanish literature professor reads a Madrid newspaper, but I certainly never met any outside Reginaldus’s orbit.

Apart from being backed by Postgres instead of MySQL, is this different from Vitess (and its commercial vendor PlanetScale)?

https://vitess.io/

It sure looks like they’re going quite a ways beyond Kafka-on-Pulsar - the Ursa/Oxia work they’re focused on right now replaces BookKeeper and seems very firmly Kafka-oriented. Or does Ursa also work with the Pulsar protocol?

Couldn’t agree more - the most exciting thing about KIP-932 is how much easier it’ll become to build a good HTTP push gateway.

Uber wrote a Kafka push gateway years ago, when it was considerably harder to do well: https://www.uber.com/blog/kafka-async-queuing-with-consumer-...

Even StreamNative is effectively abandoning Pulsar and going all-in on the Kafka protocol. I can see the theoretical benefits of Pulsar, but it just doesn’t seem to have the ecosystem momentum to compete with the Kafka juggernaut.

It’s not obvious from the website, but Rob Pike and Andrew Gerrand started work on Upspin after stepping back from the Go team. I suspect that many of the folks early to Go have at least occasionally checked in on Upspin.

I’m sad to see this chapter of their work shut down, but excited to see where each of them goes from here.

South Bay Systems: https://lu.ma/southbaysystems

SF Systems: https://www.sfsystems.xyz/

There’s the Valkey fork, which is now evolving independently.

Microsoft’s Garnet and Dragonfly are independent implementations that are pretty different under the hood.

Earthly is a very similar idea too.

It’s interesting that the author now works on TigerBeetle (written in Zig). As I understand it, TigerBeetle’s style guide leans heavily on this style of resource management.

It’s an ourobouros of influences: the Husky creators left DD to make Warpstream, Warpstream inspired Quickwit, and now Quickwit is joining DD.

Batshit crazy.

(I just can’t help myself!)

No, that's not the case - there's a standard to how protoc exposes plugin options as CLI options that doesn't require the compiler to know about each plugin. It's obtuse, annoying, and badly documented, but it's there :)

The whole situation is extra confusing because some of the core codegen plugins are built into protoc. That's a distribution and version-matching strategy from the Google team rather than a requirement of the plugin system. I'd very much like Google to ship the built-in plugins as standalone binaries, even if they're also bundled with protoc.

James Mickens is a comedic genius. The linked article always makes me laugh out loud.

https://www.usenix.org/system/files/1311_05-08_mickens.pdf

The whole FlatBuffers toolchain is wildly immature compared to Protobuf. Last I checked, flatc doesn’t even have a plugin system - all code generators had to be upstreamed into the compiler itself.

Best bet is likely https://github.com/protocolbuffers/protobuf/blob/main/docs/f..., which predates editions.

The delay that Apple Intelligence introduces into notifications is also unacceptable. On both desktop and iOS, notifications are _very_ late - often more than a second on my M2 Max laptop - which ends up being quite distracting.

It uses Pebble, the key-value store that backs CockroachDB.

The series of outages early in 2023 also had some Corrosion-related pain: https://community.fly.io/t/reliability-its-not-great/11253

100% this! S3’s lack of write preconditions spawned the whole Iceberg catalog ecosystem anyways.

The channel-focused approach to stream processing reminds me of Heka [0]. It was a contemporary of Samza and Heron, and it was fairly prominent in the early Go ecosystem (maybe 10 years ago). As I recall it, quite foggily and quite a long while later, one of the final nails in Heka's coffin was that channel throughput didn't scale well. Do you have benchmarks for Rill, or is it not intended for high-throughput use cases?

[0]: https://github.com/mozilla-services/heka