Etherplex » Rick

Unfinished, Indeed

Rick — Tue, 04 Oct 2011 02:37:36 +0000

See what I mean? I forget to point at the other site! Anyway, here it is: http://rpdillon.freeshell.org.

Unfinished Thoughts

Rick — Tue, 04 Oct 2011 02:29:59 +0000

It probably seems like I've been quiet for a while now, when actually I've been up to a whole lot. What's been happening is that I've been struggling with an impedance mismatch between my mode of content creation (sporadic, often with many projects worked in parallel in varying states of completion) and a blog's mode of content distribution (linear, discrete posts that are "finished" once they are posted, more or less).

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. =)

In Critique of Patel’s “The Patent System Isn’t Broken – We Are”

Rick — Sun, 14 Aug 2011 04:29:35 +0000

Nilay Patel, of Engadget fame, recently wrote a piece discussing why the patent system in the United States isn’t broken, and touched on all the high points: software patents, patent trolls, and the recent This American Life episode that has been so widely discussed.

I should start by saying that many of his points are sound. He clearly has a good grasp on lots of the patent issues that have concerned me. Even as he starts by by blasting the “conventional wisdom” that “the patent system is broken beyond repair, a relic of a previous time that has been obsoleted by the rapid pace of technical innovation”, he never actually argues that any of the problems that plague the system are either OK, or are not present. A major flaw, then, is that his argument is a straw man argument; he asserts that conventional wisdom is saying the system is completely broken beyond repair. He goes on to assert that the patent system is really just beset by a lot of really bad flaws both in conception and in practice than can probably be overcome by making significant modifications and amendments to the law. I’m not sure I’ve heard a single considered argument anywhere that would disagree with this. In my limited experience, few people are calling for the wholesale dissolution of the entire U.S. patent system.

Moving past a critique on the structure of his argument. he starts with a remedial course in patents, quickly moving past the notion that patents are “just a simple incentive for people to develop new inventions” and describing the fact the patents are an exchange in which inventors make their information public in exchange for time-limited, government-granted monopoly rights on the inventions. I think the subtlety of his point here is that patents encourage the release of novel, innovative patent ideas that wouldn’t otherwise be made public by giving their creators a monopoly on them. The problem is that there is no incentive to keep the ideas secret in the first place. As Richard Stallman said:

Now the patent system is supposed to encourage disclosure of ideas. In fact, in the old days, nobody kept the ideas secret. They kept the code secret, it’s true. The code, after all, represented the bulk of the work. They would keep the code secret and publish the ideas so that way the employees would get some credit and feel good. After software patents, they still kept the code secret and they patented the ideas, so in fact, disclosure has not been encouraged in any meaningful sense. The same things are kept secret now as what were kept secret before, but the ideas which used to be published so that we could use them are now likely to be patented and off-limits for 20 years.

If you look back at the bulk of the major innovations in the software space, this is quite true. I’ve read a lot about it, but Richard Stallman lived through it. His point here is excellent and is not addressed by Patel, but this particular aspect isn’t my primary concern with Patel’s treatment. What concerns me is that he mentions, but never returns to, the notion that patents are first and foremost an “incentive for people to develop new inventions”, to use his words.

In my opinion, it is to this fundamental assumption that we must return when discussing software patents: would software innovation be significantly affected if inventors could not patent their software? He does not explore this topic, and certainly does not point out that unlike almost all other patentable inventions, software is already covered by copyright which already grants software authors government-sponsored monopoly protection for their work for so long that I, and most likely anyone reading this, will be dead when software written today comes out from under that aegis. That fact alone makes software worthy of a second look when it comes to patents, yet Patel points out that

What we keep calling “software patents” are just regular old patents; there is no special section of Title 35 that specifically delineates between hardware and software, or software and machinery, or software and anything else you might dream up.

This indicates that the laws we’re following make no special provision for being able to patent software, yet it is widely acknowledged that software is a significantly different type of endeavor than conventional invention. That realization alone justifies some worry about the status quo.

Patel actually invokes a 2006 essay by Paul Graham to make the point that software patents are just patents. He neglects to mention that Paul Graham advises startups to not “waste your time worrying about patent infringement. You’re probably violating a patent every time you tie your shoelaces”, which Graham writes off as being part a ritualistic battle that all companies must engage in do business here. I can’t immediately think of a more damning statement that indicates the state of software patents is broken. Unfortunately, Graham’s piece was written in 2006 when patent trolls were much newer than they are now, though he had this to say about them:

But because patent trolls don’t make anything, there’s nothing they can be sued for. I predict this loophole will get closed fairly quickly, at least by legal standards. It’s clearly an abuse of the system, and the victims are powerful. But evil as patent trolls are, I don’t think they hamper innovation much. They don’t sue till a startup has made money, and by that point the innovation that generated it has already happened. I can’t think of a startup that avoided working on some problem because of patent trolls.

Unfortunately, the recent events with LodSyshave demonstrated that not only has the loophole has not been closed in the last five years, but that the role of the “startup” or “bedroom developer” has only increased because of the vast increase in prevalence of “App Stores” in which lone developers can market their goods and start making money right away. Prior to the Apple’s App Store, the Google Market, and the Amazon App Store it was quite difficult to market a lone developer’s work, now they make extremely attractive targets for patent trolls because they don’t have the resources to defend themselves but they are making money.Graham closes his essay with a very interesting assertion:

In the software business I know from experience whether patents encourage or discourage innovation, and the answer is the type that people who like to argue about public policy least like to hear: they don’t affect innovation much, one way or the other.

I don’t think I agree, but even if that’s true, why do we even have them? It can’t possibly be cheaper to deal with all the legal wrangling associated with software patents than not. If what he says is true, at the very least software patents are a drain of time, energy and money from the innovation machine we have worked to build.

Is LodSys fostering innovation? Is Intellectual Ventures? If a lone developer in his bedroom develops a mobile application that is significantly infringing on dozens of patents, what does that say about the “non-obvious” clause in practice? This is not a purely academic question: patent trolls are real, and unlike in 2006, they are going after start ups and lone developers.Can you take a step back and honestly say that such a situation is driving innovation?

Patel doesn’t argue with any of this, thankfully. He acknowledges all of these problems, and suggests several “patches” to current law that might help the situation. But, he never really returns to defend its existence in the first place by explaining how it is fostering innovation in the software industry. And for someone so focused on “actually look[ing] at how the patent system works, where it’s specifically malfunctioning, and how we can fix it”, he doesn’t really justify why software, something that is perilously close to (unpatentable) math, should be patentable.

There are thousands of software patent horror stories that keep cropping up, but one of the most atrocious is about John Carmack. Carmack actually developed a software technique known widely as “Carmack’s Reverse”, which Creative (those guys that make sound cards for computers) later patented and then used against him just prior to the release of one of his games (Doom 3) to strong-arm him into promoting their products. The fact that there was prior art was no remedy for him: the game wouldn’t be released because of ongoing litigation and cost Carmack millions, even though he would win in the end. Creative knew he would do whatever he could to avoid that, and he did.

This type of situation is difficult to prevent and is inherent in the costs of having a patent system in the first place. Knowing that, we have to be able to demonstrate that the patent system (for at least software patents) deserves to live; it has to demonstrate that overall it a net win. No one is doing that, and there is in fact substantial evidence from all corners that it is a significant net cost to the system as a whole.

I have only a few heroes in the programming world. I would like to give them some space to voice their opinions on software patents. As you read, remember, these are the people that were the innovators that actually changed with world with the innovations in computer science and software – they are the people on whose backs the very technology you are using to read this was built.

John Carmack:

The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.

Donald Knuth:

I am told that the courts are trying to make a distinction between mathematical algorithms and nonmathematical algorithms. To a computer scientist, this makes no sense, because every algorithm is as mathematical as anything could be. An algorithm is an abstract concept unrelated to physical laws of the universe.Nor is it possible to distinguish between “numerical” and “nonnumerical” algorithms, as if numbers were somehow different from other kinds of precise information. All data are numbers, and all numbers are data. Mathematicians work much more with symbolic entities than with numbers.

Therefore the idea of passing laws that say some kinds of algorithms belong to mathematics and some do not strikes me as absurd as the 19th century attempts of the Indiana legislature to pass a law that the ratio of a circle’s circumference to its diameter is exactly 3, not approximately 3.1416. It’s like the medieval church ruling that the sun revolves about the earth. Man-made laws can be significantly helpful but not when they contradict fundamental truths.

L. Peter Deutsch:

The government desperately needs to be better educated so that it can start to undo the deleterious effects of software patents (by reversing the error of interpretation by the courts that allowed them in the first place).

Linus Torvalds:

US experience shows that, unlike traditional patents, software patents do not encourage innovation and R&D, quite the contrary. In particular they hurt small and medium-sized enterprises and generally newcomers in the market. They will just weaken the market and increase spending on patents and litigation, at the expense of technological innovation and research.

Though not quite a programmer, I’ve always admired Phil Salin, who perhaps wrote the most compelling critiqueof software patents back in 1991, long before it was part of the public consciousness. His argument spoke to me because when I first read it ten years ago, I was as motivated to refine my abilities and develop proficiency within my chosen art as I am today. I find my work as a programmer rewarding precisely because it is a fundamentally creative art form, and Phil’s argument strikes at the heart of why endeavors like my own should be preserved. In that sense, his critique of software patents was highly personal for me. 20 years later, we are no closer to addressing these issues than the day he wrote this. I will defer to him for my closing:

Any assertion that some one individual or organization can ever rightfully establish exclusive ownership of the use or refinement of abstract ideas – obvious or non-obvious, important or unimportant – embodied in a work of prose, music, mathematics, or software, should trouble the conscience of everyone whose creative work is built, as it necessarily must be, in part or in whole, out of ideas and techniques discovered and developed by others.

BART Shutdown of Cellular Repeaters as a Violation of First Amendment Rights

Rick — Sat, 13 Aug 2011 16:40:33 +0000

There was a recent shutdown of cellular service within the BART tunnels (on August 11th, between 4 and 7PM). The story was covered widely and is worthy of note, I think, if for no other reason than the variety of opinions it engendered. I first heard of it through the discussion that sprang up on Google+. It's a good story because it has a lot of elements that provide opportunity of nuanced analysis, I think.

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.

When Patents Attack

Rick — Wed, 10 Aug 2011 06:10:43 +0000

I engaged in a conversation on Google+ recently that related to a recent episode of This American Life entitled "When Patents Attack". The episode focused on the damage that software patents and patent trolls are inflicting on the software industry. I penned a response to that episode, but as it was on Google+ in a limited circle, I thought I would reproduce it here in public. What follows is a simple cut and paste of the response I wrote on G+.

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.

Building Working Code

Rick — Mon, 02 May 2011 05:19:02 +0000

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.

A Few Thoughts on “The Cloud”

Rick — Sun, 24 Apr 2011 05:57:51 +0000

A question was posed to me recently asking what “the cloud” is (in the internet sense). I was going to pen a long response, but in the spirit of not writing emails that are too long, I will instead post this (following Rule 6 in the aforementioned article), Let’s start with a working definition of the cloud.

Let me start by saying that when I first was sent on a mission to understand the cloud computing concept, one of my earliest conclusions was that it was ill-defined and many people used it in a bunch of ways, rendering the term almost meaningless. Larry Ellison famously commented in 2008 venting the same frustrations:

“The interesting thing about cloud computing is that we’ve redefined cloud computing to include everything that we already do. I can’t think of anything that isn’t cloud computing with all of these announcements. The computer industry is the only industry that is more fashion-driven than women’s fashion. Maybe I’m an idiot, but I have no idea what anyone is talking about. What is it? It’s complete gibberish. It’s insane. When is this idiocy going to stop?”

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:

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.
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.
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.

Why 64-bit is Still Not Ready (Hint: Adobe Flash)

Rick — Sun, 03 Apr 2011 18:04:16 +0000

Back in 2004 I built my first AMD64 system over the summer, and I was thrilled. I had just switched from Gentoo to Debian, and I think I even took a video of the process of building the machine. I knew it would take years for the mainstream to start using 64-bit systems, and I was proud that Linux/BSD was first. Later, OS X and Windows followed up with their own 64-bit versions. But what was notable on all platforms was how hard it was to transition.

OS X did rather well just because of the nature of their hermetically sealed ecosystem. Sure, there were casualties (the entire MacFUSE ecosystem comes to mind), but overall it wasn’t bad. Linux has had its rough spots for close to eight years now. More on that in a second. Finally, Windows still struggles with driver compatibility and weird glitches in 64-bit mode. It’s amazing it has been this difficult to make the switch, but it does give a good perspective on how the inertia of an open community can act as an anchor at times. The entire Apple ecosystem is a dictatorship, and therefore is very efficient at making big changes.

The problem both Linux and Windows (and yes, even OS X) have had is that it is very difficult to force entities that won’t give up their source code to make a change. The best example of this is Adobe and their ubiquitous Flash Player. It’s the most polarizing technology on the internet right now, with Apple shunning it almost entirely, and Google embedding it directly into the browser (“keep your enemies closer…”?). In many ways it both enables and hobbles the modern web; it has been a transformative force while violating all the original ideals the web was based on.

So, here I am, once again making the leap to 64-bit thinking “C’mon man, it’s 2011, they must have worked out all the glitches by now…”. I am typing this on my shiny new Lenovo X201 running Ubuntu 11.04 Beta 1 in 64-bit mode, only to find out that Flash still doesn’t work. At all. So, I manually download Adobe Flash “Square” and push the binary-blob to the right directory so all my browsers will find it. And it works…sort of. The new Amazon Cloud Player and my Subsonic setup keep producing this weird metallic buzz in all the music, and it makes my services useless.

So, I spent about an hour searching for what the problem could be. After a whole lot of testing and searching, I determined it must be the 64-bit Linux incarnation of Adobe Flash. It turns out that it is, and no one can force them to fix their broken use of memcpy with something else because their project is still closed source. If it were an open-source project, the changes would be made in under a day and a new version would be pushed out shortly thereafter. As it is, we have to wait for the dictator to do the right thing.

So, I suppose that means that dictatorships can either be the most agile or the most stagnant, and open communities are somewhere in the middle. In any case, I think it is more fun to be part of a community than a subject to a dictator.

Programming Style

Rick — Wed, 23 Mar 2011 07:42:10 +0000

I’ve spent a lot of time trying to figure out the “best” coding style, environment, language, abstraction. One of my mentors over the years once turned to me as we were working on some code and, after I’d delivered a particularly vehement critique of the code I’d been working on, simply said “Rick, there’s no such thing as ‘perfect code’.” And that was it. I never knew him to be a man of many words, but he knew the craft better than any I’d ever met. It struck me at the time, but the simple truth of it has resonated with increasing impact over the years.

Part of it is that, from all the evidence I’ve gathered, I have to to conclude that different systems and methods and mental models work for different people. Such a relativistic view is somehow disappointing to the part of me that seeks universal truth, but the longer I spend programming, the more I realize that the methods that work the best for me (dynamic languages, REPLs, experimentation with many prototypes) not only aren’t appealing to some, they simply aren’t as effective as an IDE with code completion and an incremental compiler for them. It really is relative. Various artists choose different tools. Just as as some writers pen their manuscripts by hand, some use typewriters, and yet others use Emacs, different programmers choose the tools of their craft with equal discretion.

Perhaps it’s not all that surprising, but some part of me still wishes there were some ultimate answer to the art of computer programming.

VLC Removal From Apple’s App Store

Rick — Sun, 09 Jan 2011 05:34:05 +0000

The lastest furor to hit the web regarding free software and Apple’s products is the removal of VLC from the App Store due to licensing issues. Many reports tend to go after the man, Denis-Courmont, who used to be a lead developer for VLC, for pointing out the inherent incompatibility of Free software with Apple’s App Store. I think this is inappropriate; the licenses for the software should be respected. The same people who would publicly decry software piracy as being a violation of copyright are standing up and cheering for copyright infringement of VLC because they feel like they deserve to have the software. So, I decided to take a few minutes and walk through some of the coverage and explain the issues as I see them, and paint a picture of how the situation might be improved.

Audio