Etherplex

This has led to me maintaining a blog for years that I don't update all that often.  Alongside the blog, in a slew of private files, I maintain the current state of all my work and thoughts.  This struck me as perhaps the "most pessimum" (to quote Mel), so I've resurrected/updated an old site I made years ago over at the public access unix system sdf.org (for you Robotech fans, yes, that stands for "Super Dimensional Fortress"…it's that cool).  I host a wiki there, which I think offers a mechanism more conducive to my work flow and allowing me to make more of what I do public as I do it.

It's sort of an experiment at the moment, but it might eventually take over killring.org, etherplex.org or a subdomain of either, if it ends up working out.  One huge benefit for me is that I can access the content of the Oddmuse wiki that runs the site seamlessly from my editor of choice and never have to format my posts in a browser, which I sort of hate doing.

All in all, it should lead to a more interactive and oft-updated site.  Which might be good or bad, depending on your perspective. =)

The story is essentially that some protesters were allegedly planning to enter the paid areas of the BART stations and disrupt train service to protest the fatal July 3rd shooting of a man armed with a knife by BART police.  One position is that a state-owned agency (BART) shut down the citizens' means of communication, and the action was therefore an impingement on free speech and was worthy of a Middle-East dictator.  The other position is that public safety was at risk, and that the limited (in both space and time) curtailment of cell service to disrupt the protest is justified.

I think I'm in the second camp, and I'd briefly like to defend that position by drawing some lines in a field of gray.

• The primary mandate of BART is the continuity of its transit service, not the provision of cellular service during transit.
• The threat being responded to was credible; there had already been protests that had shut down stations in the system last month.
• Protests in many urban areas require permits to ensure proper police presence to protect both the protesters and the bystanders.  This protest had no such permit, and the planned protest in fact constituted an illegal action that likely created significant safety concerns for legitimate users of the BART system.
• The removal of cellular service within the subway was clearly not a curtailment of political speech; the protesters are free to get their message out in a multitude of ways, including right outside the BART station, or in the non-paid areas of the station.  The removal of cellular service was intended to inhibit their ability to share intelligence on the location of BART police so they could direct their protests to areas least protected and shutdown service there.
• The fact that a service is provided by a government agency neither means that the service is a right, nor that its removal constitutes a violation of citizens' civil liberties.
• The cell repeaters that were disabled were in fact owned and operated by BART.  This was not a case where the government reached out into private infrastructure (like that owned by AT&T, Verizon, Sprint or T-Mobile) and forced them to shut down service.  I think they made those providers aware of their action, but based on the stories I've read, there was no strong-arming of the private sector involved.

I'm not sure that's an exhaustive list, but I think it represents some of the big differences I see between this action and, say, revolutions in the Middle-East.

In summary, I'm not at all sure conspiring to elude authorities so you can commit crimes constitutes "protected speech".  I would reign in the claims of first amendment breach here.

Finally got around to listening to this. IV's position, along with the other patent holders pursuing litigation, boils down to "We've found a way to extract money from industry players." That's it. There's nothing deeper than that in anything they say. To the hardcore capitalist that drinks the Ayn Rand kool-aid, the ability to extract money means there must be value.

The problem with that reasoning is that patents are a government-granted monopoly that is fundamentally unnatural (that's why the government has to grant the monopoly on something that can't really be monopolized: ideas). To a more traditional conservative that views the actions of all large organizations with suspicion (whether it be the government or a company), the grant of such an unnatural monopoly must be justified, and indeed, the founding fathers did justify the monopoly powers they gave the government, including copyright and patents (trademarks are something of a different beast). That justification was very clear: the purpose of the monopoly is to promote a public body of creativity and invention.

The missing piece in all of this, then, is any evidence at all that these patents for upgrading software over the internet, making online purchases, purchasing software through an mobile application and literally millions of others would not have been created and shared with the public if the government didn't intervene. No one, in any discussion of this topic I have ever heard or read, has made the argument that we are technologically ahead because of software patents. Even if someone were to make that assertion, I would have to ask them to cite a case in which a piece of technology that is critical to the way we live was created because of that system.

Since controlled tests aren't possible, we must resort to the bailiwick of the social scientist: statistics. So, I pose a simple question: since the patent office became more friendly to allowing software patents, have we seen a marked increase in innovation in the software industry?

Let's plot a graph of notable advances in computer science versus the number of software patents granted. It would be a good exercise, but I think I can guess the result. The sad truth is, most companies would be inventing just as much regardless of whether their code were patentable, simply because:
1) no software company today relies on exercising patents as a primary source of income, and
2) code is already protected by copyright, so even if the code is made publicly available, the "no derivative works" clause provides substantial protection.

Perhaps the most telling fact in all of this is that the people inventing in the software world, the computer scientists and software engineers, almost universally hate software patents. This was pointed out in the story, and has been my experience as a programmer.

At a more fundamental level, the entire debacle stems from the misguided belief that there are "super men" than invent things and deserve huge compensation for doing so. That way of thinking is deeply misguided: we all rely heavily on the inventions that precede our work to make progress. That is, the system for granting monopolies on these ideas seems to assume that inventors live in a vacuum as an isolated individual in a lab somewhere, not as part of an active, connected global community of practitioners. In the software world, we find that if a university wants to stay even remotely current, they find themselves presented students with courses filled with nothing but patented concepts. Is this really the intent? If we try to monetize every instance of the use of an idea, we increase the friction involved in the creative process — a process that, in my experience, is already fraught with difficulty. It makes everything cost more, and, as usual, lines the pockets of the lawyers and those in government that must shepherd us through the exercise of determining "damages" when someone uses an idea the government has dictated is owned by someone. All this is ignoring the fact the the legal system is hideously biased in favor of the big players at the direct expense of the smaller companies that have the most incentive to innovate (since they want to innovate to differentiate themselves from the current major players).

It's nice to see This American Life addressing the issue, but making the lay citizen understand the long term costs associated with this behavior is folly. Sadly, the lawyers, the government, the patent trolls and the big companies (which have already invested in vast portfolios of defensive patents) don't have a vested interest in seeing the system change, only the poor, often young, innovators do. And so, we find ourselves discouraging the very thing we sought to foster. Folly, indeed.

Every so often, I run across a manifesto that captures something I know about programming, but couldn't quite express before I read it.  That was true when I first read the Ion Window Manager Manifesto, and struck me again tonight when I read the Sepia Philosophy:

A development environment should support three activities: code spelunking, interaction, and customization. Emacs as an environment for developing Emacs Lisp thoroughly supports all of them: It has commands to visit individual functions' code and documentation, commands to evaluate or step through expressions, and an architecture that encourages customization in Emacs Lisp…Modern IDEs also support these three activities, but do so awkwardly. Rather than having functions to visit definitions (find-function) and search for functions (apropos), they clutter the screen with class and file trees. Rather than supporting interactive evaluation of small pieces of code, they perform background semantic checking on whole projects and highlight errors. Rather than allowing minor customizations to grow organically into features, they support limited configuration files and baroque plug-in APIs. Sepia tries to adhere to the apparent Emacs philosophy that rich semantic information should be unobtrusive, and that the best way to build working code is to start by experimenting with small pieces.

The idea that the best way to build working code is to experiment with small pieces has been a philosophy I have followed for years, but I'd never seen it captured so eloquently.  I thought it might be worth sharing, especially for folks that have an interest in the REPL way of programming, but learned using a modern IDE that doesn't support the REPL style.

That might have been more true in 2008 than it is now, because I now feel that it is well defined, but is nevertheless used incorrectly quite often.  One of the reasons Ellison might have reached this conclusion so readily is that the cloud makes readily available what companies like Oracle, Sun and IBM have been selling to high-end customers for years.  So, what exactly is cloud computing?

In my way of thinking, a cloud has three main properties:

1. Clouds are vast collections of hardware that are networked into tiers at the rack and datacenter level, usually globally.  Microsoft, for example, has six global locations for its Azure Cloud datacenters.
2. Clouds are composed almost entirely of commodity hardware (i.e. no “big iron” as you’d expect to be sold by Oracle or IBM for some special purpose).  Another way to think of this one is that they’re mainly composed of the same type of components that you’d find in a desktop computer.
3. Clouds allow for elastic computing.  While a single site’s traffic and downtime may be hard to predict (due to, say, the “Slashdot Effect” or some random hardware failure), when taken in aggregate across thousands of sites and servers, traffic and failure become much more predictable.  By aggregating many single sites together on a large collection of servers and allowing resources to be allocated to sites on-demand, loss of service due to traffic spikes or hardware failure can be mitigated.

There are many other things clouds do, mind you.  You will find people talk about “IaaS”, “PaaS” and “SaaS” in the context of cloud computing, but all these mysterious concepts are just variations on the idea that you can build web sites and services on top of a vast collection of compute resources located in data centers around the world.  Another oft-mentioned concept is that of redundancy, which cloud computing offers, of course, but I do not mention it because it is a trait that so many other computing platforms offer.

I came back from a conference a few weeks ago in which a brief was given summarizing cloud computing for executive types, and the take-home conclusion was that “Cloud computing is an evolution, not a revolution”; the argument was that it didn’t materially affect the normal course of business for technology companies.  The reason I mention this is that I think there are least two reasons that cloud computing is a revolution.

First, supercomputing has traditionally not been a field where some kid in his basement can compete in any meaningful way with a large corporation.  The investment required to buy, operate and maintain supercomputer-quality compute resources has dropped over the decades, allowing more competitors into the field, but cloud computing makes developing and testing serious algorithms possible from the comfort of your armchair on a modest laptop.  For roughly $80, you can rent the compute power in the Amazon Cloud to align a human genome in an afternoon, for example.  This task would take weeks on everyday hardware.  The moral of the story here is that markets that were formerly not very competitive due to the cost of entering them are now subject to a whole new source of competitors using the cloud as their platform for development and deployment.  This represents a revolution in the market dynamics.

Second, cloud computing is based on cheap, commodity hardware.  This means that it has ushered in the common use of algorithms that scale out, rather than scale up.  That is, the software being developed today for the cloud doesn’t rely on the use of massive computers with hundreds of gigabytes of RAM to operate.  Rather, it can make use of a variable (but can be quite large) number of more modest computers that can be dynamically added and removed as needed to ensure a good quality of service.  These kinds of algorithms can be more challenging to write, and at least require different abstractions than conventional multi-threaded algorithms.  These changes represent a revolution in the computer science being used to develop high performance applications.

There’s another set of points related to this about the reliability of the cloud in light of Amazon’s recent EC2 troubles, but that’s for another time.