Mar 03

upside wants a firmware dev

The UPSide project, announced here two weeks ago, has come together with amazing speed.

We now have:

* A hardware lead – A&D regular Eric Baskin – with thirty years of experience as a power and signals engineer. He is so superbly qualified for this gig that my grin when I think about it makes my face hurt.

* A high-level system design (about which more below) that promises to be extremely capable, scalable, flexible, and debuggable.

* A really sharp dev group. Half a dozen experts have shown up to help spec this thing. critique te design docs, and explain EE things to ignorant me.

* Industry participation! We have a friendly observer who’s the lead software architect for one of the major UPS vendors.

* A makerspace near me where the owner recruited himself onto the project and is looking forward to donating bench time and skilled hands to the hardware build.

All this helpfulness almost – but not quite – fills in my deficits as a designer/implementer. I don’t really know from hardware design, so I’m attacking the problem with the modularity and information-hiding principles I know from software.

Here is how the design looks:

An I2C bus that ties together a “forebrain” which is a Unix SBC, almost certainly at this point an Olimrx LIME2, with a “midbrain” that is an Arduino-class microcontroller.

The midbrain is mechanism – a simple state machine whose job is to control the high-power subsystem (inverters, battery, AC input and output). Policy decisions and stuff like battery state modeling will live in the forebrain. It will also run the USB and Ethernet interfaces, and host the development environment for the firmware

The forebrain will talk to a 20×4 LCD panel over I2C, and various other controls like alarm mute and self-test buttons via GPIO pins.

I’ve actually written the spec for the I2C bus messages already. And here’s your cute hack for the day…

I realized early on that one of the first things I needed to do was draw a state/action diagram for the system so I could pin down its behavior in response to any given transition in its environment (mains power up, mains power down, battery dwell limit approaching, those sorts of things). So I reached for one of my favorite tools, a graph-drawing DSL called dot.

Only when I write the first version of the graph, I found the dot markup cluttered and repetitive. So I wrote a couple of cpp macros named “state” and “action” that expand to dot markup, and expressed the graph as a sequence of macro calls.

Then I blinked, looked again, and realized…hey, I could compile these calls to C source code for a state machine! And now it is done – I can already generate the tricky part of the application logic for the midbrain directly from the state/action diagram. (The action functions are stubs but the control flow is all there.)

(If the fact that I just solved a design problem by writing a DSL to generate code in another DSL and provably correct equivalent C application logic seems weird to you, you must be be new here. This is how I think all the time. It is obedience to the Unix wisdom: never hand-hack code you can generate from a higher-level description.)

This, however, does not solve the entire firmware problem by any means. The midbrain’s going to need system logic to do things like receive and send I2C messages, poll A2D converters from sensors watching the mains and battery voltage, and so forth.

Accordingly, we need a firmware developer. I’ll learn how to do this if nobody steps up (which is why I said “wants” in the post title) but the whole process will doubtless go faster and more smoothly if we have someone with experience. So:

WANTED: One firmware hacker. Must be familiar with AVR-class microcontrollers and the Linux toolchains for them. Experience with I2C and low-level programming of USB endpoints would be a plus. Perks of the job include getting one of the first UPSides made, your name in lights, and working with a dev crew that is impressive even by my elevated standards.

EDIT: Well, that didn’t take long. A&D regular Jay Maynard has signed on.

Feb 26

How elites are blind about immigration

I had been thinking about posting about immigration recently, because some facts on the ground have caused me to move away from a pure laissez-faire position on it. A few minutes ago I wrote a long comment on G+ that I realized says a lot of what I wanted to. This is a slightly revised and expanded version of that comment.

I am asked, by another member of the educated white elite, why we shouldn’t simply end border enforcement entirely rather than buid a wall or tolerate Joe Arpaio’s squalid detention camps.

Both here and in Europe there’s been a significant spike in communicable diseases that can be traced back to low immunization rates in what Trump may or may not have called “shithole” countries.

Crime is a real issue. Legal immigrants have a slightly higher criminal propensity than the native born (the difference is small enough that its significance is disputed) but illegals’ propensity is much higher, to the point that 22% of all federal incarcerees are illegals (that’s 92% of all jailed immigrants).

But the elephant in the room is the impact of illegal immigration on social trust.

Continue reading

Feb 21

If you blow up the Constitution, you’ll regret it

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.

Feb 18

In the face of uncertainty, buy options.

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.

Continue reading

Feb 17

System engineering for dummies

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.

Continue reading

Feb 16

Announcing: The UPSide project

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.

Feb 12

“The Lost Art of C Structure Packing” now covers Go and Rust

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.

Feb 08

UPSes suck and need to be disrupted

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…

Continue reading

Feb 04

How “open source” was coined

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.

Continue reading

Feb 03

The Roche motel

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?

Continue reading

Feb 02

Rethinking housecat ethology

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.

Continue reading

Jan 23

Three times is friendly action

Today, for the third time in the last year, I got email from a new SF author that went more or less like:

“Hi, I’d like to send you a copy of my first novel because [thing you wrote] really inspired me.”

All the novels so far are libertarian SF with rivets on – the good stuff. Amusingly, I don’t think any of these authors knew in advance that I’m a judge for the Prometheus awards,

It’s really gratifying that I’m making this kind of difference.

Jan 18

Sorry, Ansari: a praxeologist looks at the latest scandalette

This is an expanded version of a comment I left on Megan McArdle’s post
Listen to the ‘Bad Feminists’ in which she muses on the “Grace”-vs.-Aziz-Ansari scandalette and wonders why younger women report feeling so powerless and used.

It’s not complicated, Megan. You actually got most of it already, but I don’t think you quite grasp how comprehensive the trap is yet. Younger women feel powerless because they live in a dating environment where sexual license has gone from an option to a minimum bid.

I’m not speaking as a prude or moralist here, but as a…well, the technical term is ‘praxeologist’ but few people know it so I’ll settle for “micro-economist”. The leading edge of the sexual revolution give women options they didn’t have before; its completion has taken away many of the choices they used to have by trapping them in a sexual-competition race for the bottom.

Continue reading

Dec 28

The blues ate rock and roll!

I’ve been diving into the history of rock music recently because, quite by chance a few weeks ago, I glimpsed an answer to a couple of odd little questions that had been occasionally been bothering me for decades.

The most obtrusive of these questions is: Why does nothing in today’s rock music sound like the Beatles?

It’s a pertinent question because the Beatles were so acclaimed as musical innovators in their time and still so hugely popular. And yet, nobody sounds like them. Since not long after the chords of the “Let It Be” died away in 1969, every attempt to revive the Beatlesy sound of bright vocal-centered ensemble pop has lacked any staying power among rock fans. It gets tried every once in a while by a succession of bands running from Badfinger to the Smithereens, and goes nowhere. Why is this?

Continue reading

Dec 18

C, Python, Go, and the Generalized Greenspun Law

In recent discussion on this blog of the GCC repository transition and reposurgeon, I observed “If I’d been restricted to C, forget it – reposurgeon wouldn’t have happened at all”

I should be more specific about this, since I think the underlying problem is general to a great deal more that the implementation of reposurgeon. It ties back to a lot of recent discussion here of C, Python, Go, and the transition to a post-C world that I think I see happening in systems programming.

(This post perhaps best viewed as a continuation of my three-part series: The long goodbye to C, The big break in computer languages, and Language engineering for great justice.)

Continue reading

Dec 16

You’re gonna need a bigger Beast

I’m taking a management-approved break from NTPsec to do a repository conversion that dwarfs any I’ve ever seen before. Yep, more history than Emacsmuch much more. More backtrail than entire BSD distributions, in fact about an order of magnitude larger than any repo I’ve previously encountered.

Over 255000 commits dating back to 1989 – now in Subversion, formerly in CVS and (I suspect) RCS. It’s the history of GCC, the Gnu Compiler Collection.

For comparison, the entire history of NTP, including all the years before I started working on it, is 14K commits going back to 1999. That’s a long history compared to most projects, but you’d have to lay 18 NTPsec histories end to end to even approximate the length of GCC’s.

Continue reading

Dec 02

Decentralized threats as the mother of liberty

Dave Kopel gives us a fascinating account of the divergence between American and British gun culture in The American Indian foundation of American gun culture. I learned some things from this article, which is not a trivial observation because I’ve studied the same process from some different angles.

While Kopel’s article is excellent of its kind, it stops just short of some large and interesting conclusions that immediately present themselves to me, upon reading his evidence, because I think like a science-fiction writer. A significant part of that kind of thinking is a broad functionalist perspective on how societies evolve under selective pressure – a drive to look beyond specific historical contingencies and ask “What is the adaptive pressure motivating this social response? Can we deduce a general law of social evolution from this case?”

I’m going to anticipate my conclusion by coining an aphorism: “Decentralized threats are the mother of liberty.” Kopel’s account of how the American and British traditions of citizen arms diverged illustrates this brilliantly.

Continue reading

Nov 30

As the pervnado turns

I’m a libertarian who tried to stop Donald Trump with my vote in the PA primaries – even changed party registration to do it. But Trump’s opponents may make me unto a Trump supporter yet.

From Harvey Weinstein’s casting couch through John Conyers being the guy every female reporter in DC knew not to get on an elevator with to a remote-control lock on Matt Lauer’s office rape room at NBC. These are the people who lecture me about sexism and racism and global warming and deviant-minority-of-the-week rights and want to confiscate my guns because they propose my morality can’t be trusted? Well, fuck them and the high horse they rode in on.

I have more and more sympathy these days for the Trump voters who said, in effect, “Burn it all down.” Smash the media. Destroy Hollywood. Drain the DC swamp. We’ve all long suspected these institutions are corrupt. What better proof do we need than their systematic enabling of rape monsters?

As a tribune of the people Trump is deeply flawed. Some of his policy ideas are toxic. His personal style is tacky, ugly, and awful. But increasingly I am wondering if any of that matters. Because if he is good for nothing else, he is good for exposing the corruption, incompetence, and fecklessness of the elites – or, rather, in their desperation to take him down before he breaks their rice bowls, they expose themselves.

Yeah. Is there anyone who thinks all these rocks would be turning over if Hillary the serial rape enabler were in the White House? Nope. With her, or any establishment Republican, it’d be cronyism all they way down, because they’d feel a need to keep the corrupt elites on side. Not Trump – his great virtue, perhaps overriding every flaw, is that he doesn’t give a fuck for elite approval.

Maybe Trump’s voters aren’t angry enough yet. It’s not just a large number of women our elites have raped and victimized, it’s our entire country. Our infrastructure is crumbling, our debt is astronomical, our universities increasingly resemble insane asylums, our largest inner cities are free-fire zones terrorized by a permanent criminal underclass. And what’s the elite response? Oh, look, a squirrel – where the squirrel of the week is carbon emissions, or transgender rights, or railing at “white privilege”, or whatever other form of virtue signaling might serve to hide the fact that, oh, look, they put remote-controlled locks on their rape dungeons.

It’s long past time for a cleansing fire.

Nov 28

Proposal – let’s backport Go := to C

The Go language was designed with the intention of replacing C and C++ over much of their ranges. While the large additions to Go – notably automatic memory allocation with garbage collection – attract attention, there is one small addition that does an impressive job of helping code be more concise while not being tied to any of the large ones.

I refer to the := variant of assignment, which doesn’t seem to have a name of its own in the Go documentation but I will pronounce “definement”. It must have an unbound name on its left (receiving) side and an expression on the right (sending) side. The semantics are to declare the name as a new variable with the type of the right-hand expression, then assign it the value.

Here’s the simplest possible example. This

void foo(int i)
    int x;
    x = bar(i);
    /* More code that operates on i and x */

becomes this:

void foo(int i)
    x := bar(i)
    /* More code that operates on i and x */

A way to think about definement is that it generates a variable declaration with an initialization. In modern C these can occur anywhere a conventional assignment can.

Definement is a simple idea, but a remarkably productive one. It declutters code – scalar and struct local-variable declarations just vanish. This has two benefits; (1) it improves readability, and thus maintainability; and (2) it eliminates a class of silly errors due to multiple declarations falling out of sync – for example, when changing the return type of a function (such as bar() in the above example), you no longer gave to go back and tweak the declaration of every variable that receives a result from its callsites.

Definement syntax also has the property that, if we were to implement it in C, it would break cleanly and obviously on any compiler that doesn’t support it. The sequence “:=” is not a legal token in current C. In gcc you get a nice clean error message from trying to compile the definement:

foo.c: In function ‘foo’:
foo.c:3:5: error: expected expression before ‘=’ token
  x := i

This makes it a low-risk extension to implement – there’s no possibility of
it breaking any existing code.

It is worth noting that this will actually be slightly simpler to implement in C than it is in Go, because there are no untyped constants in C.

I think there’s a relatively easy way to get this into C.

First, write patches to implement it in both gcc and clang. This shouldn’t be difficult, as it can be implemented as a simple parser change and a minor transformation of the type-annotated AST – there are no implications for code generation at all. I’d be surprised if it took a person familiar with those front ends more than three hours to do.

Second, submit those patches simultanously, with the notes attached to each referencing the other one.

Third, wait for minor compilers to catch up. Which they will pretty quickly, judging by the history of other pure-syntax enhancements such as dot syntax for structure initialization.

Fourth, take it to the standards committees.

OK, am I missing anything here? Can any of my readers spot a difficulty I haven’t noticed?

Will anyone who already knows these front ends volunteer to step up and do it? I certainly could, but it would be more efficient for someone who’s already climbed the learning curve on those internals to do so. If it helps, I will cheerfully write tests and documentation.

EDIT: No, we can’t backport C++ “auto” instead – it has a different and obscure meaning in C as a legacy from B (just declares a storage class, doesn’t do type propagation). Mind you I’ve never seen it actually used, but there’s still a nonzero risk of collision with old code.

UPDATE, DECEMBER 2ND: I have been in touch with Ken Thompson. He approves, raising two minor technical caveats about stack growth and name shadowing.

Nov 18

Language engineering for great justice

Whole-systems engineering, when you get good at it, goes beyond being entirely or even mostly about technical optimizations. Every artifact we make is situated in a context of human action that widens out to the economics of its use, the sociology of its users, and the entirety of what Austrian economists call “praxeology”, the science of purposeful human behavior in its widest scope.

This isn’t just abstract theory for me. When I wrote my papers on open-source development, they were exactly praxeology – they weren’t about any specific software technology or objective but about the context of human action within which technology is worked. An increase in praxeological understanding of technology can reframe it, leading to tremendous increases in human productivity and satisfaction, not so much because of changes in our tools but because of changes in the way we grasp them.

In this, the third of my unplanned series of posts about the twilight of C and the huge changes coming as we actually begin to see forward into a new era of systems programming, I’m going to try to cash that general insight out into some more specific and generative ideas about the design of computer languages, why they succeed, and why they fail.

Continue reading