These service status pages have so many other problems, I can't really get excited about this article's point. As a user of a service, I don't really care that an additional 0.09% of uptime is any more or less difficult to achieve than an additional 0.9%, even if you describe it in terms of fractions of time. I only care about two things: what the service status is right now and your service reliability's impact to me over the long term (get out of here with your 30-day crap).

In the electric utility world we have a few IEEE standardized metrics (with appropriately IEEE'd acronyms) for tracking service reliability that I like much better and always wish for when I'm looking at a status page. Pie in the sky stuff for sure, nobody wants to do this analysis and publish the results without a regulator telling them have to, but c'est la vie.

SAIDI - System Average Interruption Duration Index. How many minutes an average customer experienced service interruption in a year. This is the big one I'd want to see on your service status page IMHO. For the power grid, we consider any outage longer than five minutes to be an interruption ("non-momentary outage").

SAIFI - System Average Interruption Frequency Index. How many total periods of interruption occurred for the average customer in a year.

CAIDI - Customer Average Interruption Duration Index. How long it takes service to be restored for the average customer when there is an interruption.

For the US, here is what these numbers look like: https://www.eia.gov/electricity/annual/html/epa_11_03.html. If you're outside the US look up yours and have a good laugh at us. :)

For the "right now" aspect you have probably visited your utility's outage map, but here I would say we do much better than most utilities. The level of detail on the investigation and resolution is often more detailed, and we usually know better than to bother providing much in the way of a concrete estimate for restoration time of a current outage (though this is getting better in the utility space).

> If you're outside the US look up yours and have a good laugh at us. :)

If you want to feel better about that, check out South Africa. You know you have a problem when "load shedding" is a household word.

(I should note that things have improved recently: it was a big milestone when they went a full year without load shedding, as of May 16.)

Based on my very amateurish skim of this and a related paper, maybe so? They simulated the neutrino background as solar and cosmic ray atmospheric sources, so any source with a different energy distribution is perhaps a possible explanation for the event, I think.

But probably more likely is for this to have been a particularly energetic event in the tail of one of the known sources of neutron recoil detection they did model. More events needed!

My friend, handling the waste of all the people that live in a city is one of the most basic examples of the public commons I can imagine lol. What are you talking about?? It is a bit fundamental to the concept of a city!

I've seen and loved this before but only today I thought to zoom all the way out and see the true terminator affected by elevation. We usually only seen the idealized smooth curve. Very neat!

Very nice article, and I appreciate SQLite's explanation of the bug too. And how extremely cool Tailscale appears to have been about it (paying for the VFS shim, etc.).

I'd have liked to have heard more about the decision to checkpoint so frequently that put them on this path though. Presumably that's to keep the WAL tiny for very fast recovery. Trying to mitigate some of the deleterious effects of inserting a DBMS into your network layer, I suppose? Tricky stuff. Wonder how that compares to typical etcd snapshot frequencies too.

Agreed, I was also wondering about this. Maybe the aggressive checkpointing was for preventing WAL-overflow?

Was wondering the same, doesn’t mention if they tried checkpointing less frequently

And how about safety of life systems? They use computers in chemical plants and on planes, you know lol. Integer overflows have a body count!

In these applications we want what's called "Functional safety" where what we care about is that the humans are kept safe. A Memory Safe language can be useful to help achieve this, which is why https://ferrocene.dev/ exists but it's also important to have business processes to assure that what the software is supposed to do will keep the humans safe, memory safety doesn't distinguish between "Ensure the human operator is in the containment zone when a cloud of toxic vapour is released" and "Ensure the human operator is NOT in the containment zone when it is released". But for that operator this difference is crucial.

Ok fine, but I bet you can't come up with a good gluten free banana bread recipe.

Isn't this basically how more modern "chatty" CLIs use stderr? Put all the nice progress bars and emojis behind `if isatty(2)`? I thought so anyway, but I'll admit I've never actually looked at what npm, uv, etc. do.

That's the right approach. Output goes to standard output, and user facing messages go to standard error. That way output can still be piped or redirected while the program talks to the user, and messages can also be suppressed by redirecting to the null device.

I've always been annoyed by the fact file descriptor 2 is called the "error" stream. Should have been called the "user" stream.

If a tool unconditionally produces diagnostics on standard error, whether there is an exceptional situation or not, I consider that poor behavior, contrary to the quiet tool philosophy from Unix.

Standard error is special output that the user should be able to somehow see (e.g. on a terminal) even if the regular output is redirected (as you note above).

That doesn't mean standard error is above the quiet tool guideline.

Or the "status" stream (you can still redirect it and it is useful sometimes).

Man, that project is such bait for my particular sensibilities but just looking at the copy about not sharing your data and only sharing weights has me feeling very disappointed in the project already. I would want a project like this to not elide fact that sharing your weight updates probably effectively means sharing your data too.

To actually follow through with this fully they would have had to revoke all kinds of internal access for foreign nationals and demand they immediately return their hardware (at 5pm on a Friday no less), no?

Unless folks are hearing that they did this I smell marketing and/or PR as the main driver of the action.