482 stories

“History Is Watching Us”

1 Comment and 2 Shares

After two days of debate on the Senate floor, the Democrats’ Hail Mary push for voting rights came up short, as Sens. Kyrsten Sinema and Joe Manchin joined with the GOP to block a rules change to the filibuster. Republican politicians quickly deployed the procedure to squash the John Lewis Voting Rights Advancement Act and the Freedom to Vote Act, the paired bills that aimed, among other things, to stem gerrymandering and voter suppression across the nation.

The defeat of the two bills had been all but inevitable since at least last week, when Sinema announced that she wouldn’t vote to curtail the filibuster to protect voting rights. However, the Democrats did manage to make an impassioned case for the legislation, which they cast as crucial to counter efforts by Republicans to suppress minority votes, gerrymander congressional maps, and even seize control of election boards. In addition, progressives and moderates alike, from Bernie Sanders (I-Vt.) to Amy Klobuchar (D-Minn.), emphasized that the filibuster is an arcane rule, applied selectively to block broadly popular legislation. 

Republicans, on the other hand, argued that the Democrats were inventing a crisis and claimed that expanding the right to vote was tantamount to a Democratic power grab.

“This party-line push has never been about securing citizens’ rights,” said Senate Minority Leader Mitch McConnell (R-Ky.). “It’s about expanding politicians’ power.”

The topic of racism loomed over the proceedings: Some of the GOP’s most blatant attempts at gerrymandering have centered on majority-minority districts. One of the most impassioned disagreements occurred between two of the Senate’s Black members: Sens. Cory Booker (D-N.J.)  and Tim Scott (R-S.C.), who argued vehemently over whether the GOP’s efforts at voter suppression should be compared to Jim Crow. Scott claimed that the characterization was overblown and offensive, while Booker responded that it was all the more shocking that voter suppression efforts continue in the present day. 

The Democrats’ voting rights push may have ended in bitter failure, but the final vote on the filibuster also showed how far Democratic thinking on the procedure has shifted. Forty-eight out of 50 Democratic senators opted for reform, including moderates like Jon Tester (D-Mont.) and Mark Kelly (D-Ariz.), a number that would’ve been unthinkable just a few years ago. This week, Democrats managed to unite progressives and most of their moderates around a new consensus: For the health of democracy, the filibuster must go. 

Read the whole story
8 days ago
Kyrsten Sinema and Joe Manchin destroy the world again. Never miss a chance!
6 days ago
Share this story

The Gift of It's Your Problem Now

1 Comment and 6 Shares

Recently a security hole in a certain open source Java library resulted in a worldwide emergency kerfuffle as, say, 40% of the possibly hundreds of millions of worldwide deployments of this library needed to be updated in a hurry. (The other 60% also needed to be updated in a hurry, but won't be until they facilitate some ransomware, which is pretty normal for these situations.)

I have a 20+ year history of poking fun at Java in this space, and it pains me to stop now. But the truth is: this could have happened to anyone.

What happened was:

  • Someone wrote a library they thought was neat
  • They decided to share it with the world for free
  • Millions of people liked it and used it everywhere
  • Some contributors contributed some good ideas and, in this case, at least one bad idea
  • Out of a sense of stewardship, they decided to maintain backward compatibility with the bad idea
  • The bad idea turned out to have one or more security flaws that affected all the users
  • The stewards responded quickly with a fix

From this, if you believe the Internet Consensus, we can conclude that open source doesn't work, people don't get paid enough, capitalism is a sham, billionaires are built on the backs of the proletariat, your $50 Patreon donation makes a real difference, and Blorkchain Would Have Solved This.

(Miraculously the Internet Consensus is always the same both before and after these kinds of events. In engineering we call this a "non-causal system" because the outputs are produced before the inputs.)

Nevertheless, I have been dared to take my take on the issue. It, too, was the same before and after, but the difference is I didn't write it down until now, which makes this journal a causal system. You could probably write an interesting philosophical paper about observations of a non-causal system nevertheless being causal, but mercifully, I will not.

Free Software is Communism

So anyway, meandering gently toward the point, let's go back in time to the original Free Software movement. Long ago, before the average reader of this sentence was born, a person whose name is now unpopular was at a university, where they had a printer, and the printer firmware was buggy. This person firmly believed they could quickly fix the printer firmware if only they had the source code. (In the spirit of every "I could do this better in a weekend" story, I'm not sure whether we ever confirmed if this was true. In any case printer firmware is still buggy.)

As a result, they started a nonprofit organization to rewrite all of Unix, which the printer did not run and which therefore would not solve any of the original problem, but was a pretty cool project nonetheless and was much more fun than the original problem, and the rest was history.

This story archetype is the Hero's Journey that inspires all software development:

  • I have a problem
  • I do not know how to solve that problem
  • But I strongly believe, without evidence, that I can solve a generalized version of that problem if I form a large enough team and work at it for 35 years(*)
  • We are now accepting donations

(*) initial estimate is often less than 35 years

Now, you have probably heard all this before, and if you're a software developer you have probably lived it. This part is not really in question. The burning question for us today, as we enjoy the (hopefully) peak of late-stage capitalism, is: ...but where will the donations come from?


Before we get back onto communism, let me draw an important distinction. Most communist governments in history ended up being authoritarian systems, which is to say, top-down control. Ironically, the people at the top seem to have more power than the people at the bottom, which at first seems like the antithesis of communism. This is not the place to claim an understanding of why that always seems to happen. But one has to acknowledge a pattern when one sees it.

On the other hand, it's easy to find examples of authoritarianism outside communism. Our world is filled with top-down control systems. Many corporations are in many ways, top-down controlled. The US system of government is increasingly top-down controlled (ie. authoritarian), despite the many safety measures introduced early to try to prevent that.

When politicians rail against communism it is because they don't want you to notice the ever-growing non-communist authoritarianism.

Authoritarianism is self-reinforcing. Once some people or groups start having more power, they tend to use that power to adjust or capture the rules of the system so they can accumulate more power, and so on. Sometimes this is peacefully reversible, and sometimes it eventually leads to uprisings and revolutions.

People like to write about facism and communism as if they are opposite ends of some spectrum, but that's not really true in the most important sense. Fascism blatantly, and communism accidentally but consistently, leads to authoritarianism. And authoritarianism is the problem.

Authoritarianism is about taking things from me. Communism, in its noncorporeal theoretical form, is about giving things away.

I read a book once which argued that the problem with modern political discourse is it pits the "I don't want things taken from me" (liberty!) people against the "XYZ is a human right" (entitlement!) people. And that a better way to frame the cultural argument is "XYZ is my responsibility to society."

As a simple example, "Internet access is a human right," is just a sneaky way of saying "someone should give people free Internet." Who is someone? It's left unspecified, which is skipping over the entire mechanism by which we deliver the Internet. It's much more revealing to write, "To live in a healthy society, it's our responsibility to make sure every person has Internet access." Suddenly, oh, crap. The someone is me!

Healthy society is created through constant effort, by all of us, as a gift to our fellow members. It's not extracted from us as a mandatory payment to our overlords who will do all the work.

If there's one thing we know for sure about overlords, it's that they never do all the work.

Free software is a gift.

I would like to inquire about the return policy

Here's the thing about gifts: the sender chooses them, not the recipient. We can have norms around what gifts are appropriate, and agreements to not over-spend, and wishlists, and so on. But I won't always get the exact gift I want. Sometimes I didn't even want a gift. Sometimes the gift interprets JNDI strings in my log messages and executes random code from my LDAP server. This is the nature of gifts.

On the other hand, the best gifts are the things I never would have bought for myself, because they seemed too expensive or I didn't even realize I would like them or they were too much work to obtain, or because someone hand-made them just for me. These feel like luxuries of the sort capitalism cannot produce, because deciding, going out, and buying something for myself isn't luxury, it's everyday. It's lonely. It's a negotiation. It's limited by my own lack of creativity.

The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite).

The worst part of free software is you get what you get, and the developers don't have to listen to you. (And as a developer, the gift recipients aren't always so grateful either.)

Paying for gifts

...does not work.

You don't say to someone, "here's $100, maybe this time get me a gift worth $100 more than you'd regularly spend." It's kind of insulting. It still probably won't get you exactly the thing you wanted. Actually, the other person might just pocket the $100 and run off with it.

We already have a way for you to spend $100 to get the thing you want. It's a market. A market works fine for that. It's not very inspiring, but most of the time it's quite efficient. Even gift-givers will often buy things on the same market, but with a different selection criteria, thus adding value of their own.

When you try to pay for gifts, it turns the whole gift process into a transaction. It stops being a gift. It becomes an inefficient, misdesigned, awkward market.

There's research showing that, for example, financial compensation in a job is more likely a demotivator than a motivator (ie. if you pay me too little, I'll work less hard or quit, but if you double my pay, it won't double my output). If you tie cash compensation to specific metrics, people will game the metrics and usually do an overall worse job. If you pay someone for doing you a favour, they are less likely to repeat the favour. Gifts are inherently socially and emotionally meaningful. Ruin the giftiness, and you ruin the intangible rewards.

So it is with free software. You literally cannot pay for it. If you do, it becomes something else.

This is why we have things like the Linux Foundation, where the idea is you can give a gift because you appreciate and want to support Linux (and ideally you are a rich megacorporation so your gift is very big), but it dilutes the influence of that money through an organization that supposedly will not try to influence the gift of Linux that was already happening. You end up with multiple gift flows in different directions. Money goes here, code goes there. They are interdependent - maybe if one flow slows down the other flow will also slow down - but not directly tied. It's a delicate balance. People who keep receiving Christmas gifts but never give any might eventually stop receiving them. But might not.

Anyway, gifts will not get you 24-hour guaranteed response times to security incidents.

Gifts won't get you guaranteed high quality code reviews.

Gifts will not, for heaven's sake, prevent developers from implementing bad ideas occasionally that turn into security holes. Nothing will. Have you met developers?

Open source

I've avoided the term "open source" so far because it means something different from the original idea of Free Software.

Open source was, as I understand it, coined to explain what happened when Netscape originally opened their Mozilla source code, back at the end of the 1990s. That was not a gift. That was a transaction. Or at least, it was intended to be.

The promise of open source was:

  • You, the company, can still mostly control your project
  • Customers will still pay you to add new features
  • Actually customers might pay other people to add new features, but you can still capitalize on it because you get their code too
  • Linux distributions only package open source code so you'll onboard more customers more easily this way
  • You can distance yourself from this anti-capitalist gift-giving philosophical stuff that makes investors nervous
  • Plus a bunch of people will look at the code and find bugs for you for free!

Maybe this sounds cynical, but capitalists are cynical, and you know what? It worked! Okay, not for Netscape Corporation (sorry), but for a lot of other people since then.

It also failed a lot of people. Many developers and companies have been disappointed to learn that just uploading your code to github doesn't make a community of developers appear. (It does make it more likely that AWS will fork your product and make more money from it than you do.) Code reviews are famously rare even in security-critical projects. Supply chain issues are rampant.

In fact, we've now gotten to the point where some people hesitate to give away their source code, mainly because of this confusion of gifts and customers. If I spend some spare time hacking something together on a weekend and give it away, that's a gift. If you yell at me for making it, that makes giving less fun, and I will spend fewer weekends making gifts.

Whereas when a company has a product and open sources it and you complain, that's customers giving valuable feedback and it's worth money to learn from them and service them, because you eventually earn money in exchange (through whatever business model they've established). No gift necessary.

Call it cynical or call it a win/win relationship. But it's not a gift.

The startup ecosystem

Since the creation of the open source designation 20+ years ago, software startups have taken off more than ever. I attribute this to a combination of factors:

  • Cloud computing has made it vastly cheaper to get started
  • Incubators like YCombinator have industrialized the process of assembling and running a small software company
  • Megacorps have become exponentially richer but no more creative, so they need to acquire or acqui-hire those startups faster and faster in order to grow.

Although a lot of startups open source their code, and they all depend heavily on open source ecosystems, the startup world's motivations are amazingly different from the free software and open source worlds.

Gifts exist in the startup world. They are things like "we were both in YCombinator so I will intro you to this investor I like" or "I got extremely rich so let me invest in your startup and incidentally I get a lottery ticket for becoming even more rich." These absolutely are still gifts. They each strengthen social ties. The startup world is a society, and the society is built up from these gifts. It's a society that largely ignores the trials and tribulations of anyone who isn't a rich software engineer insider, but history has hosted many past societies of that sort and it takes a long time to build and deploy enough guillotines, and anyway they are having fun and producing a lot and surely that counts for something.

If free software gifts are communism and open source is cynically capitalist exploitation, then startups may be, weirdly, the democratization of capitalism.

Hear me out. Big companies don't care what you think; you can't pay them enough to care. Gift givers care only a little what you think; if they gave you what you wanted, if wouldn't be a gift. But startups, well, there are a lot of them and their mantras are "do things that don't scale" and "focus on the customer" and "build rapid feedback loops." What that spells for you is a whole bunch of people who want to give you what you want, in exchange for money, and who are excited to amortize the costs of that over all the other customers who want the same thing.

It's kind of exciting, conceptually, and more self-optimizing than untuned gift giving, and so it's not super surprising to me that it has started to eclipse the earlier concepts of free software and open source. More and more "open" projects are backed by small companies, who have financial incentives to make their users happy because some of the users turn into paying customers. They'll even provide the uptime SLAs and security fix turnaround guarantees you wanted so much. Our company, Tailscale, is unabashedly one of those. Nothing to be ashamed of there. The system works.

What doesn't work is assuming those startup mechanics apply to everyone out there who gives you a software gift. Not every project on github is the same.

Not everyone has the same motivations.

Giving them money won't change their motivations.

Trying to pay them or regulate them taints the gift.

If you wanted to pay someone to fix some software, you didn't want a gift. You wanted a company.

But if there is no company and someone gave you something anyway? Say thanks.


This isn't where evolution stops. There's a lot more to say about how SaaS taints the unwritten agreement of open source (because you don't have to give back your changes to the code), and how startups tend to go bankrupt and their tech dies with them, and how the best developers are not good at starting companies (no matter how much easier it has become), and how acquiring a startup usually destroys all the stuff they innovated, and how open source is often used as a way to exfiltrate past those kinds of disasters, and how simultaneously, whole promising branches of the "gift economy" structure have never been explored. But that's enough for today. Maybe another time.

Read the whole story
16 days ago
Plain talk about what free software and open source actually means.
29 days ago
Pittsburgh, PA
29 days ago
Washington, DC
Share this story

What NPM Should Do Today To Stop A New Colors Attack Tomorrow

1 Comment

Over the weekend, a developer named Marak Squires intentionally sabotaged his popular NPM package colors and his less popular package faker. As I write this, NPM claims 18,971 direct dependents for colors and 2,751 for faker. Open Source Insights counts at least 42,000 more indirect dependents for colors. Many popular NPM packages depend on these packages.

A misfeature in NPM’s design means that as soon as the sabotaged version of colors was published, fresh installs of command-line tools depending on colors immediately started using it, with no testing that it was in any way compatible with each tool. (Spoiler alert: it wasn’t!)

The specific misfeature is that when you use NPM to install a package, including a command-line tool, NPM selects the dependency versions according to the requirements listed in package.json as well as the state of the world at that moment, preferring the newest possible allowed version of every dependency. This means that the moment Marak updated colors, installs of aws-cdk and the other tools started breaking, and the bug reports started rolling in, like this one:

And also these in apostrophe, cdk8s, compodoc, foreversd, hexo, highcharts, jest, netlify, oclif, and more.

NPM users may be upset at Marak today, but at least the change didn’t do anything worse than print garbage to the terminal. It could have been worse. A lot worse. Even ignoring this kind of intentional breakage, innocent bugs happen all the time too. Essentially every open source software license points out that the code is made available with no warranty at all. Modern package managers need to be designed to expect and mitigate this risk.

Anyone running modern production systems knows about testing followed by gradual or staged rollouts, in which changes to a running system are deployed gradually over a long period of time, to reduce the possibility of accidentally taking down everything at once. For example, the last time I needed to make a change to Google’s core DNS zone files, the change was tested against many many regression tests and then deployed to each of Google’s four name servers, one at a time, over a period of 24 hours. Regression testing checks that the change does not appear to affect answers it shouldn’t have, and then the gradual rollout gives plenty of time for both automated systems and reliability engineers to notice unexpected problems and stop the rollout.

NPM’s design choice is the exact opposite. The latest version of colors was promoted to use in all its dependents before any of them had a chance to test it and without any kind of gradual rollout. Users can disable this behavior today, by pinning the exact versions of all their dependencies. For example here is the fix to aws-cdk. That’s not a good answer, but at least it’s possible.

The right path forward for NPM and package managers like it is to stop preferring the latest possible version of all dependencies when installing a new package. Instead, they should prefer to use the dependency versions that the package was actually tested with, or versions as close as possible to those. I call that a high-fidelity build. In contrast, the people who installed aws-cdk and other packages over the weekend got low-fidelity builds: NPM inserted a new version of colors that the developers of these other packages had never tested against. Users got to test that brand new configuration themselves over the weekend, and the test failed.

High-fidelity builds solve both the testing problem and the gradual rollout problem. A new version of colors wouldn’t get picked up by an aws-cdk install until the aws-cdk authors had gotten a chance to test it and push a new version configuration in a new version of aws-cdk. At that point, all new aws-cdk installs would get the new colors, but all the other tools would still be unaffected, until they too tested and officially adopted the new version of colors.

There are many ways to produce high-fidelity builds. In Go, a package declares the minimum required version of each dependency, and that’s what the build uses, unless some other constraint in the same build graph requests a newer one. And then, it only uses that specific newer one, not the one that just appeared over the weekend and is entirely untested by anyone. For more about this approach, see “The Principles of Versioning in Go.”

Package managers don’t have to adopt Go’s approach exactly. It would be enough, for example, to record the versions that the aws-cdk developers used for their testing and then reuse those versions during the install. In fact, NPM can already record those versions, in a lock file. But npm install of a new package does not use the information in that package’s lock file to decide the versions of dependencies: lock files are not transitive.

NPM also has an npm shrinkwrap command, as well as an npm ci command, both of which appear to fix this problem in certain, limited circumstances. Most of the authors and users of commands affected by the colors sabotage should be looking carefully at those today. Kudos to NPM for providing those, but they shouldn’t be off to the side. The next step is for NPM to arrange for that kind of protection to happen by default. And then the same protection is needed when installing a new library package as a dependency, not just when installing a command. All this will require more work.

Other language package managers should take note too. Marak has done all of us a huge favor by highlighting the problems most package managers create with their policy of automatic adoption of new dependencies without the opportunity for gradual rollout or any kind of testing whatsoever. Fixing those problems is long overdue. Next time will be worse.

Read the whole story
16 days ago
Conservative package management logic is, at this point, probably the better route.
Share this story


Dan Lyke:

New research on emissions strengthens case for a 20mph default urban speed limit

New research[1] from engineering consultants, Skyrad, models the impact of capping speeds at 20mph vs. 30mph. This “real life” modelling that takes account of the stop/start nature of urban traffic yields a very different result from traditional steady-state models. It shows significant and substantial reductions in emissions: CO2 lower by 26% and NOx 28% lower. With UK hosting COP26, campaigners are calling on governments to set 20mph or 30km/h limits as national urban/village defaults.

Read the whole story
100 days ago
Washington, DC
111 days ago
111 days ago
Share this story

Walking Places Is Part of the Culture Wars Now


Approximately two million years after our ancestors first learned to move about the planet with an upright gait, whether or not walking places is good or bad has become yet another dividing line in the American culture wars.

According to a recent Pew Research Center poll that studied the issue of whether people prefer to live in places where "schools, stores, and restaurants are within walking distance" versus where they are "several miles away," the biggest divide in opinion is not young versus old, urban versus rural, or education level. It is political preference.

Just 22 percent of Conservatives want to live in walkable neighborhoods, while 77 percent prefer driving everywhere. A slightly higher percentage of Republicans or people who lean Republican as a whole, 26 percent, want walkable neighborhoods. Meanwhile, 44 percent of moderate Democrats and 57 percent of liberals want walkable neighborhoods, resulting in a 50/50 split among Democrats as a whole.

That gap of 35 percent between Liberals who want to live in walkable neighborhoods and Conservatives who do is larger than the gap between those with postgraduate degrees and high school diplomas or less who want walkable neighborhoods (14 percent) or 18-29 year olds versus 50-64 year olds (12 percent). The poll also shows a 26-point gap between Asians who want walkable neighborhoods (58 percent) versus whites (36 percent), although the poll was only conducted in English.

Pew Study
Image: Pew Research Center

But one of the most striking findings is that the gap in walkable neighborhood preference according to extreme political views is even wider than the gap between urban and rural respondents, where 50 percent of urban residents polled want walkable neighborhoods and 25 percent of rural ones do. In other words, whether or not you actually live in an urban or rural area is less of a predictor of whether you want walkable neighborhoods than the political beliefs one holds regardless of where they live.

But, there is still a lot of disagreement on the issue, even among people who consider themselves part of the same ideological cohort.

If we put the above a slightly different way, 42 percent of liberals prefer to live in places where they have to drive everywhere. That is a very high number for the group in the survey one would think is most concerned about climate change, of which driving is a huge contributor. And while electric cars may help reduce emissions from cars significantly in the long run, they need to be accompanied by an equally significant reduction in how often and how far we drive. The most obvious and attainable solution is to live in places where we can sometimes walk to the places we need to go.

It is wrong to equate the above with the idea that everyone has to live in cities. Rural towns have and continue to thrive with houses and businesses clustered around a main street or town center built around a transportation hub to a major city. This is how much of the country looked, especially but not only in the northeast and midwest, prior to World War II. And it is how much of, say, Europe and East Asia still look. In fact, the U.S. is one of the few places where massive, suburban sprawl with mandatory single-family zoning that legally bans businesses from opening near people is the rule, norm, and general expectation. It is, also, ironically, one of the most dramatic examples in modern U.S. history of government mandates interfering with the rights of private property holders, which the Conservative movement was once ideologically opposed to.

There are all kinds of other implications from these poll results. Cars are expensive to buy and maintain, and living patterns that continue to rely on them are yet another financial burden on people who may not be able to afford them. And because building homes is expensive, there is a general housing shortage in this country, and real estate is often more of an investment than a place to live, real estate companies tend to build the largest homes they can to sell at the highest price, which means houses keep getting bigger and bigger. Meanwhile, large, detached homes use more energy than smaller or attached ones.

If the climate crisis concerns you, this is all bad news. In the two million years since our ancestors learned to walk, we have evolved to understand and manipulate our planet in ways our predecessors quite literally could not even conceive of. And yet, in some very important ways, we are going backwards.

Read the whole story
131 days ago
147 days ago
149 days ago
149 days ago
Washington, DC
151 days ago
Earth, Sol system, Western spiral arm
Share this story


1 Comment
Read the whole story
186 days ago
Regular delights
Share this story
Next Page of Stories