erik_seaberg

Keeping prod stable is more important than alpha testing every team's latest commit, but monorepos tend not to accommodate staying on known-good versions of your dependencies and opting into updates when ready.

Can a headless app talk GLX or EGL and render on the X server's GPU?

A higher learning curve brings a better payoff, because where you stop learning is where the language has run out of ways to improve your work.

This works because casts are allowed to quietly create values whose types are wrong. It would have been better if the cast added a runtime check, or at least we distinguish sound (checked) and unsound casts the way C++ does.

I think Haskell avoid this by actually requiring you to write sound conversion functions between phantom types (it helps that phantom types don't involve any visible state at runtime).

Downtime for your own staff is a quantifiable cost you can expect them to put up with. It's outside customers whose trust will be hard to restore.

This. A single dedicated bare metal server sacrifices too much availability, in return for capacity that you probably don't need yet. Better to use a fraction of a few different servers.

I'm reminded of an evening fairly early on at Facebook where it took a few minutes to realize traffic had dropped because the Academy Awards were on.

Bedroom windows are a sleep hygiene problem for anyone who doesn't plan to wake up at dawn year round. I've installed blackout curtains as I moved, but they don't work all that well.

I knew another student who worked the university computer lab help desk. His comment about a ski injury was "at least it wasn't my space bar thumb."

I think Python got this right, where "x is y" is identity (not often used but still concise) and "x == y" is value equality (a method you can override).

https://en.wikipedia.org/wiki/Nurse_practitioner is a title I've seen.

Deep value equality can also be expensive to check, so some languages default to reference equality even for immutable values.

The way to take advantage of the bandwidth of multiple storage devices is to distribute concurrent writes across them, rather than forcing everything to commit sequentially using contended locks or rollbacks.

Flicker and color temperature. They also used to be expensive for renters who wouldn't see out their lifetimes.

A quorum across isolated facilities doesn't lose data unless a disaster hits all of them at once. Unfortunately, "disaster" includes a bad commit that is deployed too quickly.

I like the power that we see with cheap commodity hardware, but we mustn't forget that it's crap. He talks about Litestream as a continuous backup but doesn't get into how long it takes to bring up a hot spare and whether he's automated that. I'm glad to see Litestream has synchronous replication on their roadmap, but in the meantime writes can be irretrievably lost and I don't know whether transaction boundaries are preserved.

> do you want to know when something bad can happen in your program, or don’t you?

Almost everything can fail, and we don't need our noses constantly rubbed in it. Knowing how it failed might be interesting, but you're on your own to check for error subtypes and it's rare to define any.

2/3 of the code is way too much boilerplate for delegating error handling when it can be automated more reliably.

I liked checked exceptions, but higher-order functions break them. The method signature of stream.map(f) allows a generic type for f but it can't vary with f's exceptions. The choices usually boil down to "only throw unchecked exceptions" (like Runnable) or "throw any exception" (like Callable).

https://en.wikipedia.org/wiki/CAS_latency is how long it takes to read a word out of the active row. Async DRAM had "row access strobe" and "column access strobe" signals.

Wow. I used to drive CNG airport shuttles in Seattle, where there were two pumping stations in the entire county (one just off the airport, fortunately).

You can't deploy a distributed system atomically, and the closer you get the more risk you're taking with prod. The old and new versions need to coexist for at least a couple of weeks in case of rollbacks.

It's weird that any parser that loses digits is tolerated. A parser that forces strings into uppercase US-ASCII never would be.

InnoDB also supports transactions.

If unreachable objects point at each other, that's only a problem for refcounting, not for tracing (their pointers aren't followed).

Unless you have a single monotonic clock, these will be partially ordered. It's risky to design around sorting that won't always work.

What I've seen work is for the team to have a private channel, and whoever isn't in the middle of something can answer, and the whole team will see that answer sooner or later.

Server-side rendering still makes sense, because the server (the user's laptop or phone) has its own dedicated GPU, and the client (racked in a shared datacenter) likely doesn't. So I think we'll keep seeing browser frontends for everything.

Sadly they do drop support for old models in drivers for new OS versions, so I can only print from my aging gaming PC. Maybe network printing solves this but mine is USB-only.

> super rare that a server physically breaks

I kinda want to know where you shop, because commodity hardware has a reputation as just utter crap. Before cloud went mainstream, I worked somewhere that had some racked servers in a colo literally catch fire. (The remote hands put them out, disconnected, and refused to touch them ever again.)

PSA: please don't follow a manual checklist over ssh. At least write an Ansible playbook that does those things repeatably, or even better, script idempotent changes in an .rpm or .deb to install.