Predictably, the Stoneman Douglas High School shooting has triggered some talk on the left – and in the mainstream media, but I repeat myself – of repealing the Second Amendment.
I am therefore resharing a blog post I wrote some time back on why repealing 2A would not abolish the right to bear arms, only open the way to the U.S. government massively violating that right. Rights are not granted by the Constitution, they are recognized by it. This is black-letter law.
Thus, repeal of any right enumerated in the Constitution is not possible without abrogating the Constitutional covenant – destroying the legal and moral foundations of our system. The ten in the Bill of Rights are especially tripwires on an explosive that would bring the whole thing down. And of all these, the First and Second are especially sensitive. Approach them at your peril.
I will now add a very sober and practical warning: If the Constitution is abrogated by a “repeal” of 2A, it will be revolution time – millions of armed Americans will regard it as their moral duty to rise up and kill those who threw it in the trash. I will be one of them.
Left-liberals, you do not want this. I’m a tolerant libertarian, but many of the revolutionaries I’d be fighting alongside would be simpler and harder men, full of faith and hatred. If that revolution comes, you will lose and the political aftermath is likely to be dominated by people so right-wing that I myself would fear for the outcome.
You should fear it much more than I. Back away from those tripwires; you are risking doom. Ethnic cleansing? Theocracy? Anti-LGBT pogroms? Systematic extermination of cultural Marxists? In a peaceful, Constitutional America these horrors will not be. If you blow up the Constitution, they might.
Yesterday I posted about how the streetlight effect pulls us towards bad choices in systems engineering. Today I’m going to discuss a different angle on the same class of challenges, one which focuses less on cognitive bias and more on game theory and risk management.
In the face of uncertainty, buy options. This is a good rule whether you’re doing whole-system design, playing boardgames, or deciding whether and when to carry a gun.
I’ve been getting a lot of suggestions about the brand new UPSide project recently. One of them nudged me into bringing a piece of implicit knowledge to the surface of my mind. Having made it conscious, I can now share it.
I’ve said before that, on the unusual occasions I get to do it, I greatly enjoy whole-systems engineering – problems where hardware and software design inform each other and the whole is situated in an economic and human-factors context that really matters.
I don’t kid myself that I’m among the best at this, not in the way that I know I’m (say) an A-list systems programmer or exceptionally good at a couple other specific things like DSLs. But one of the advantages of having been around the track a lot of times is that you see a lot of failures, and a lot of successes, and after a while your brain starts to extract patterns. You begin to know, without actually knowing that you know until a challenge elicits that knowledge.
Here is a thing I know: A lot of whole-systems design has a serious drunk-under-the-streetlamp problem in its cost and complexity estimations. Smart system engineers counter-bias against this, and I’m going to tell you at least one important way to do that.
A week ago I argued that UPSes suck and need to be disrupted. The response to that post was astonishing. Apparently I tapped into a deep vein of private discontents – people who had been frustrated and pissed off with UPS gear for years or decades but never quite realized it wasn’t only their problem.
Many people expressed an active desire to contribute to a kickstarter aimed at this problem. I got one offer from someone actually willing to hire an engineer to work on it. Intelligent feature suggestions – often framed as gripes about the deficiencies of what you can buy out there – came flooding in.
Perhaps most remarkably, the outlines of a coherent design began to emerge. We identified a battery technology we could buy COTS that would improve on the performance and lifetime of lead-acid but without the explosion risk of lithium-ion. The way that safety and regulatory requirements would require a partition between low- and- high-power electronics became clearer. A feature list solidified. We took in good ideas and rejected some not-so-good ones.
Therefore, even though we don’t yet have a lead hardware engineer, I have initiated Project UPSide. There’s no code or schematics yet; we’re still developing requirements and architecture. By “architecture” I mean, for example, what specific kinds of information the hardware subsystems need to exchange.
All interested parties are welcome to browse the wiki
and apply for write access. Roles we are especially looking for:
* Lead hardware engineer – needs to be able to do overall design and systems integration.
* Someone who knows how to program USB endpoints. (It will land on me to learn this if we can’t find someone with experience.)
* Someone who understands battery-state modeling. (Again, I’ll learn this if nobody steps up.)
My own job is, basically, product manager – keeper of the requirements list and recruiter of talent.
UPDATE: If you want to request features or changes to the design wiki, the best way to do that is by opening an issue in the tracker. That way the discussion stays on record for later viewers.
I have issued a new version, 1.19, of The Lost Art of C Structure Packing.
The document now covers Go and Rust as well as C, reflecting their increasing prominence as systems-programming languages competing with C and being deployed in contexts where structure-size optimizations can be of some importance.
TL;DR: C alignment and packing rules map over to Go in the most obvious way except for one quirk near zero-length structure members. Rust can be directed to act in a C-like way but by default all bets are off.
Warning: this is a rant.
I use a UPS (Uninterruptible Power Supply) to protect the Great Beast of Malvern from power outages and lightning strikes. Every once in a while I have to buy a replacement UPS and am reminded of how horribly this entire product category sucks. Consumer-grade UPSes suck, SOHO UPSs suck, and I am reliably informed by my friends who run datacenters that no, you cannot ascend into a blissful upland of winnitude by shelling out for expensive “enterprise-grade” UPSes – they all suck too.
The lossage is extra annoying because designing a UPS that doesn’t suck would be neither difficult nor expensive. These are not complicated devices – they’re way simpler than, say, printers or scanners. This whole category begs to be disrupted by an open-hardware design that could be assembled cheaply in a makerspace from off-the-shelf components, an Arduino-class microcontroller, and a PROM.
How badly do UPSes suck? Let me count the ways…
Yesterday was the 20th anniversary of the promulgation of the term “open source”. Three days before that, Christine Peterson published How I coined the term ‘open source’ which apparently she hd written on 2006 but been sitting on since.
This is my addition to the history; I tried to leave an earlier version as a comment on her post but it disappeared into a moderation queue and hasn’t come out.
The most important point: Chris’s report accurately matches my recollection of events and I fully endorse it. There are, however, a few points of historical interest that can be added.
One of the staples of SF art is images of alien worlds with satellites or planetary twins hanging low and huge in the daylight sky. This blog post brings he trope home by simulating what the Earth’s Moon would look like if it orbited the Earth at the distance of the International Space Station.
The author correctly notes that a Moon that close would play hell with the Earth’s tides. I can’t be the only SF fan who looks at images like that and thinks “But what about Roche’s limit”…in fact I know I’m not because Instapundit linked to it with the line “Calling Mr. Roche! Mr. Roche to the white courtesy phone!”
Roche’s limit is a constraint on how close a primary and satellite can be before the satellite is actually torn apart by tidal forces. The rigid-body version, applying to planets and moons but not rubble piles like comets, is
d = 1.26 * R1 * (d1 / d2)**(1/3)
where R1 is the radius of the primary (larger) body, d1 is its density, and d2 is the secondary’s density (derivation at Wikipedia).
And, in fact, the 254-mile orbit of the ISS is well inside the Roche limit for the Earth-moon system, which is 5932.5 miles.
The question for today is: just how large can your satellite loom in the sky before either your viewpoint planet or the satellite goes kablooie? To put it more precisely, what is the maximum angle a satellite can reasonably subtend?
There’s a common folk model of how housecats relate to humans that says their relationships with us recruit instincts originally for maternal bonding – that is, your cat relates to you as though you’re its mother or (sometimes) its kitten that needs protecting.
I don’t think this account is entirely wrong; it is a fact that even adult cats knead humans, a behavior believed to stimulate milk production in a nursing mother cat. However, through long observation of cats closely bonded to humans I think the maternalization theory is insufficient. There’s something else going on, and I think I know what it is.