Archive

Archive for the ‘Technology’ Category

Fast Factory, Video 1

April 13th, 2013 No comments

I spent the past few months developing the perception system behind this video of a PR2 grasping moving objects.

Perception is driven entirely by the Kinect mounted on the robot’s head, and all processing of the Kinect data is done in Haskell. I will write up a report on that side of things in the near future, but suffice to say that Haskell is more than ready for top flight performance and reliability (we’ve done about a month of testing, where a test day generally involves launching the perception software, then letting it run all day). It’s multithreaded, networked, and GPU accelerated. Free monads were involved. Lenses were involved. Burritos played a crucial role.

Behind Closed Doors

December 31st, 2007 Comments off

Nick Carr suggests some reading, including a provocative post from Jaron Lanier. To extend the link chain just once more, Jaron’s post was made as somewhat of a response to an article by Freeman Dyson. Phew.

Lanier’s point is that work in private can produce good things, or, more pointedly, better things than more public, open-source methodologies. My initial reaction to this was not exactly one of surprise.

Jaron’s portrayal of open-source as being eminently capable of producing polished clones of existing artefacts, while struggling to produce large-scale paradigm shifts makes a lot of sense. Of course, one has to couch all these claims and descriptions in some meliorating language. Namely, even if you, unfairly, view Linux as a purely derivative product, its continued development, making it a better and better product, does change the operating system game in terms of redefining what a potential customer expects from a product, and what that customer is willing to pay for. However, it is quite a bit harder to make the argument that Linux, in and of itself, represents a bold new direction for operating system design.

Importantly, one does not need to categorically decry either open- or closed-source development to consider Lanier’s submission. What seems clear is that the act of copying an existing artefact has the significant advantage of inherently providing a shared goal for all contributors. There is a platonic truth at the core of the effort captured in the object being copied itself. Unfortunately, the development of something substantially different from what has come before must instead rely on much more mundane forms of communication, and this is where closed-source development can have an advantage.

Once an artefact has been created, it may speak for itself. But until that time, the responsibility for communicating that artefact’s nature lies in the, effectively, side-band communication capabilities of its designers. The development process itself may in fact be viewed as the attempt to communicate this new idea. Unfortunately, without tangible evidence at hand, most people are unable to sufficiently convince others of the worthiness of one particular goal over another such that potential supporters are willing to set aside their own misgivings over particular design choices. A silly analogy is the fabrication of a chair. If you and I are to copy an existing chair, then who am I to disagree with the plan that we give our chair four legs? But if we are instead tasked with inventing a new mechanism for supporting the human form, then who are you to tell me that we must give our device four legs?

We are able to resolve, for better or for worse, the problems engendered by our own communication shortcomings by barter: I offer you some amount of money to follow my design. That way, a design that I couldn’t possibly implement on my own is brought into the world. Of course, closed-source approaches fail at least as often as they succeed, for hidden within the simple-to-express notion of, “I’ll pay you to follow my plan,” is the necessity that the contributor bring his or her own ingenuity to bear in figuring out how best to implement the given plan, or even improve it with the designer’s consent. We don’t want smart workers stupidly following orders, but we also don’t want too many chefs in the kitchen. No, there is still a place in the world for the cathedral and the bazaar. Neither can accomplish all that the other is capable of.

So, what motivated Lanier’s potential-flame-bait-yet-simultaneously-easily-defensible article? I can’t say for sure, but I think a lot of it stems from a single phrase in Dyson’s article describing the detrimental effect of speciation on Darwinian evolution: “It probably slowed down the pace of evolution considerably.” Delivered in such an off-hand manner, this statement doesn’t invite much scrutiny, but I think that this is where the disagreement begins. The comparisons to technology development are no stretch at all. The question is, does providing momentary succor for a single voice in the chorus facilitate the creation of something new, something better? Researchers do not scatter their best thoughts across peer reviews, they must instead cultivate some ideas in a controlled environment — asking for input from select others, working through the details themselves, maybe getting a post doc. to run some experiments — and present the seeds of the idea as a cohesive whole that has grown to something substantial enough for others to evaluate. This closed development is how complex communication is achieved, and while it may slow down diversification of ideas, or genetics depending on which branch of the discussion you find more compelling, it strongly supports the effort to strike out from today’s local minimum.

Categories: Technology Tags:

Gearing Up for Synchronization

June 6th, 2007 Comments off

I think Dare’s hit on a big question mark surrounding technologies like Google Gears: branch and merge. I’m sure that any programmer who’s used source control and thought about how it all works has come up with situations in which an automated merge just isn’t possible (e.g. two people edit the same line of source). In the server replication arena, the same thing happens if you have backup servers that fail a lot. With one failure, you can switch to a backup, and then playback the changes to the first system when it comes online again (or even do a full re-sync). But if the backup goes down, then the primary comes online, you’ve got issues. The first server will potentially present the user with a state that is inconsistent with changes the user has made. This is the same scenario that will be encountered by users interacting with web services in offline mode. Make no mistake: this is not a solved problem. There are always going to be scenarios that will reveal the fact that offline != online.

That said, I don’t think too many software developers using a one-user source code repository have any problem mentally recognizing the need for offline changes to be synced before they will be available from the server. It’s a valid question whether or not that understanding will be found in people using Google Docs in offline mode, and I think it’s also the case that, a deeper understanding of the situation notwithstanding, developers have an easier time of merging thanks to a usage pattern based on having many discrete files that can be edited independently (that is, merging the text is less of a problem even if dependencies can break the program). But my opinion is that it won’t be that big of a deal. Most users won’t be editing documents on multiple devices with any great frequency, so there’s less of a chance of stumbling into an inconsistent state. Moreover, despite specifically targeting the disconnected state of modern devices, I don’t think the people providing offline enabling technologies are arguing that that state will be anything other than a transient disturbance (e.g. going through a tunnel, cable’s out for an hour, etc.). In that case, the most critical question when evaluating the potential for trouble relates to a specific usage pattern: how likely is it that the first device a user connects to an online service after a period of involuntary disconnectedness is the same as the last device the user connected with? I’d say it’s pretty likely, and, in that case, manual merges won’t become a significant part of software usage for the masses.

Categories: Technology Tags:

Subverting Offline Access

April 5th, 2007 Comments off

I’ve been struggling to make sense of the offline web application access being brought to us any day now by the likes of Adobe’s Apollo and Joyent’s Slingshot. It’s a struggle because it’s hard to figure out what the big deal is. I downloaded the Apollo alpha packages, and haven’t actually built anything because I was so underwhelmed by the screencasts I could find that show off what Apollo can do. Yet, many folks are pretty sure these technologies are a big deal, some others aren’t so sure.

For myself, I’ve been somewhat caught up by the implications, but I think that has had a lot to do with the way the key web languages (HTML, CSS, and JavaScript) have come on so strongly as of late. A while back, Mono’s Jackson Harper made a conflicted post about how today’s web GUI controls are better than, and simultaneously worse than, traditional desktop WinForms GUI controls. I think those conflicted feelings are relevant to the excitement about offline access to web apps. The fact of the matter is that presentation techniques on the web have some distinct advantages over most desktop frameworks.

For the most part, our desktop apps suffer for being rooted in technologies and techniques that were developed when computer performance was an entirely different beast. Parsing a text description of a GUI layout at run-time, then animating everything, was just impractical, you simply had to hardcode things. Now, when we have the computing horsepower to build the GUI on the client’s computer at run-time, the game is completely different. Microsoft is rolling out WPF to address the presentation side of things (declarative programming makes sense for GUIs!), but the offline web access folks have another crucial advantage that I don’t think is getting enough specific attention.

Suppose a user lives in a world that is, unfortunately, frequently disconnected. What does that user gain from offline web apps? It may turn out they gain a more pleasing UI thanks to the rich interplay between HTML, CSS, and JavaScript that seems to be hard to mimic using traditional desktop technologies. They also gain (I’m hoping) automatic updates when they are able to connect, but this is a feature that should be available in most applications, regardless of technology. No, I think a key aspect of this user’s experience is the fact that they will be getting automatic online, potentially versioned, backups of their data. It is assumed that this functionality is available because web-app authors started from a point of view that holds that there is no storage on the client. These developers had to figure out how to store client data on their servers.

In effect, the revolution of web services has forced developers to figure out a killer feature for desktop applications. While I’m quite happy to manually use SVN to version and backup pretty much everything I do, most computer users would not be. These people, and this technology, represent an enormous opportunity. But it is an opportunity that is hard to sell to makers of desktop applications. The idea of offering free online storage to all users sounds like a huge commitment when viewed from the past, but it is taken for granted when viewed from even today’s web, much less the future.

Offline access for web apps is not just a feature for technophiles who find themselves on airplanes every other day. This technology’s real power lies in the way that it brings the back-end data services of web applications to the desktop. Let’s forget about using a web page while disconnected, and start thinking about users who are only comfortable with desktop-class applications getting rich, automatic online backups integrated into the core of their experience.

Categories: Technology Tags:

DRM’s Poison Apple

January 11th, 2007 Comments off

Nate Anderson at Ars Technica says that Apple is singlehandedly keeping DRM alive in 2007. I disagree completely: If DRM is to die in 2007 it will be because of Apple. Everyone else’s DRM scheme is failing because Apple controls so much of the digital download market, leaving anyone who wants to sell content without going through Apple only the option of selling it unprotected. If FairPlay were open to partners, then I believe that most distributors would happily adopt it at this point to get onto those precious iPods. Not only are would-be competitors in the area of distribution throwing in the DRM towel, content producers themselves are more likely to give up on DRM because, in today’s market, selling DRM protected content means giving Apple control over pricing.

DRM has been very good to Apple. By selling DRM content, Apple locks buyers into their hardware as long as the DRM scheme is viable. DRM has allowed Apple to create a switching cost that is, for many customers, now higher than the cost of switching from a PC to a Mac as a general computer (thanks to Boot Camp and Parallels).

If Apple had been less successful with the iPod and iTunes, we might have seen customers revolt at an ecosystem of incompatible DRM schemes. Had Apple been less successful, there could have evolved an industry-wide DRM standard (for whatever industry one wishes to consider) which would let content producers sleep more soundly at night, and let digital distributors compete on their competencies. But Apple has been successful, phenomenally so. There has been no customer revolt because there aren’t any DRM compatibility issues as long as you stay true to the iPod/iTunes path. There is no industry-wide standard, because Apple, through its success, has effectively become the industry.

So here we are, back to the future. Competitors looking to negate Apple’s advantage need to negate DRM. MP3s, here we come.

Categories: Technology Tags: