OSCON presenter and author of developerWorks columns Charming Python and XML matters, David Mertz is perfectly positioned -- both on the podium and off -- to bring OSCON to us. Check back all week for the latest from the show.

Humanities

I'll only make some brief notes on today's sessions. Hoping for a theme for today as well, I hoped to engage that side of me that spent a decade getting a doctorate in philosophy. You know, that liberal arts urge, at a technical conference. This year has been comparatively thin on sessions that concern social dynamics, legal issues, and histories of ideas. There has been some, but I miss seeing some of the scholars of intellectual property and freedom that have been at OSCon in previous years.

I saw an entertaining talk today by Robert Lefkowitz called Open Source as Liberal Art. I had run into Robert outside his session, and also saw his keynote last night. The keynote had been largely a standup-comedy routine that compared software development methodologies to Qintilian's Institutio Oratoria (i.e. a study of rhetoric; a field whose relative bad fortunes genuinely fills me with sadness). Not because Lefkowitz mentioned it, but just as a service to readers, I highly recommend Jay Heinrich's book Thank You For Arguing, a modern primer in rhetoric. As with all jokes, Lefkowitz' was a bit serious in his keynote. Today's talk, however, leaned slightly farther towards the serious and literal side of things. Lefkowitz presented a general classical opposition between techne and praxis (funny Greek words for... well, technology and practice). The former has been the traditional domain of the working classes, with the latter reserved for intellectuals and "leaders." So goes the tradition of "liberal education," in any case. In humorous fashion, Lefkowitz presented arguments for which side of things Free Software should fall on, tracing ideas of Knuth, Sussman, Marx, Babbage and a merry bunch of other thinkers who see code as a form of literature. Well, some do and some don't, but I think we should, and I think Lefkowitz thinks we should. If anyone wants to seriously injure their brain in this direction, a ponderous and profound philosophical work on this topic is Intellectual and Manual Labor by Alfred Sohn-Rethel. I don't actually think readers will read this classic of critical theory, nor even find a copy in print or at most libraries... but, hey, I'm not getting that decade back, so I better show something for it.

While it probably does not quite count as humanities, I always love topics related to machine extraction of knowledge from free form corpora. A talk entitled Machine Learning for Knowledge Extraction from Wikipedia & Other Semantically Weak Sources by Jamie Taylor, Colin Evans, and Toby Segaran (all from Metaweb) was quite interesting. Continuing today's tongue-in-cheek theme, Jamie Taylor dressed as a pirate, and the speakers presented the project they are working on called Freebase. Mostly what the speakers presented was various technical details of their scraping, slicing, dicing, and restructuring of Wikipedia as a large source of semi-structured knowledge. The underlying idea was to extract interesting connections and categorizations from the work of Wikipedia's millions of contributors. Their work sprinkled a bit of Bayesian magic around, some text processing, some use of semi-large backend databases. It's cool, and at least worth checking out their FOSS code. Or even more cool, they provide (in about 20 GB) a relational version of their filtered and processed Wikipedia content that lends itself to querying with regular SQL, and all the clever joins and filters that allows.

Project leaders

Today OSCon turned to the "regular" sessions, which is to say shorter and far more of them. I popped in on a variety of them, some only for parts of sessions. Unfortunately, I found some of what I noticed about some tutorials as well: some talks seem to be pitched at a surprisingly introductory level. Maybe I am wrong here (but I think I am not), but it seems to me that OSCon attendees should be assumed to have a fair degree of programming knowledge, and talks can and should adopt a fast pace with lots of information presented. After all, attendees are free to followup by studying websites, books, and other materials to fill in any details they don't quite follow on first presentation. I realize that it is partially my personal style to prefer such rapid-fire discussion, but at the same time I think that many speakers gave talks that they had previously developed for less sophisticated audiences. I do not want to single out the particular talks I attended here, but it seems like organizers could give presenters better guidance on what to expect in audiences.

One talk I attended that was definitely not slowed down was Doug Judd' talk on Hypertable: An Open Source, High Performance, Scalable Database. This, like many open source projects, is still in alpha; it looks promising though. The idea is to create something much like Google's (inhouse and proprietary) "Bigtable". That is, Hypertable is a very large, high performance, fault-tolerant, distributed database. Well, it can be very large, the code can run on smaller clusters (or even single machines), but there would be little point in that. What Hypertable is not is a relational database; instead it is simply a mapping of keys to values (a distributed dictionary). For what it is worth (not much), Judd was a delightfully dry speaker, with the presentation being mostly simply an enumeration of high level facts about the design of Hypertable. Content beats showmanship in my mind.

Hypertable has several layers to its operation. Master Servers oversee Range Servers, with each Range Server providing the data for a particular request. The Master Server knows which Range Server to ask for the data, using some clever distribution algorithms. Behind the Range Servers is a Distributed File System, which lives on still other machines (potentially). Redundancy exists at the several levels, for example, if a Range Server fails, responsibilities are dynamically reassigned to the Range Servers that survive. A key in a Hyptertable has the form (row,column-family,column-qualifier,timestamp). Data is not deleted from tables, but rather delete records are used to update expired values. There is more to the design, of course, but it is an interesting design that appears to provide robustness and speed.

The main thing I did today was have some conversations with project leaders; interviews, I suppose, but both were informal in tone, and with interesting people. I spoke with Joe "Zonker" Brockmeir who has been working for Novell as "openSUSE community manager" for about six months. Zonker is an old Linux hand, having edited Linux Magazine for a long time, as well as having written for developerWorks and other publications. Much of my conversation with Zonker was sharing stories about using various distros over time, and our relationship with readerships as writers. Once we got past that, I got around to asking him a bit about openSUSE.

One thing I felt like I had to ask Zonker about was something I think he was very reasonably sick of answering (I didn't expect to be first): What about Novell's patent deal with Microsoft, which left a bad taste in the mouth of many FLOSSS advocates. Of course, this all came before Zonker's job with Novell anyway. Still, his opinion, which seems very reasonable, was that the deal really did not hurt the independence of SUSE or compromise its software stack or development model; if anything, it helped gained enterprise customers and improve interoperability with Microsoft systems (which are sadly not going away in corporations, even if Linux makes strides). Another topic that I found very interesting, but is still, for now, something up in the air, is the future governance structure of openSUSE. Zonker contrasted his goals with those of Debian membership, which is enormously restricted, while still recognizing that it is important to get the participation of contributors who are genuinely involved in the direction of openSUSE itself. At some point, probably sooner rather than later, there will be openSUSE elections, a board, and various other procedural mechanisms to make decisions systematically; just what that will look like has not been decided though.

It is hard to clearly distinguish distros nowadays, I think. Zonker stated a goal of making openSUSE the best and easiest to install/configure Linux distro. However, I think that is necessarily a bit generic. Yast is obviously a pretty distinctive feature of SUSE, and many people very much like the unification of package management and general configuration that it provides. A project that Zonker singled out as notable is the Build Service. This really does show a spirit of community, being a "service [to] provide software developers with a tool to create and release open source software for openSUSE and other Linux distributions easily on different hardware architectures and for a broad user audience." I have not played with the service, but it definitely looks like something to check out.

A really interesting project is Literacy Bridge; I had the opportunity to speak at some length with its founder Cliff Schmidt. Their goal is to create very low cost audio recorders/players for distribution in poor countries. The virtues of this for educational advancement are compelling, some of them not necessarily immediately obvious. I had the opportunity to see a prototype unit, which is a brightly colored box, something in the style of the similarly motivated XO laptop from the OLPC project. However, whereas the XO costs something a bit shy of US$200 (still very inexpensive by standard of the developed world), Literacy Bridge's "Talking Book" is hoping to be produced for something close to $5. This difference makes a huge difference in the developing world, where educational budgets are measured in tens (or at best hundreds) of dollars per pupil, per year.

The Talking Book will have a number of interesting capabilities. It is not that much different in principle from the digital recorders you can buy at office stores for US$30-50; however, the differences that exist are important. Cost is obviously central: my $35 recorder is out of the price range for, e.g. Ghana, where the Talking Book will pilot in September. However, of additional importance is the thought given to navigation of the user interface. The unit has large buttons, iconically labeled to be friendly for use by non-literate people and children. As well, content can be navigated in a variety of ways, configured by the content itself. For example, for some materials it will make sense to skip between chapters; for others, such as learning basic reading skills, skipping page-by-page is the right approach. Think of a first "ABC book" where children (or not-yet-literate adults) sound out a few words on a page; the Talking Book can act as a teacher accompanying a learner sounding out letters. Much of the goal of Literacy Bridge consists of finding sources for local materials, in local languages, that are appropriate for the needs and goals of the communities that use the units.

Distribution of content will take a few paths. To allow viral distribution, each Talking Book can exchange audio files with each other one (again, with navigation of transfers performed entirely with language-localized audio prompts and button presses). As another mechanism, Schmidt envisions local vendors who would set up "data kiosks" that would allow users of Talking Book to acquire new audio at no cost, or at worst at extremely minimal cost. The possibilities are interesting. For example, we discussed the possibility that such kiosks could recommend new content based on the content users currently had on their systems; we talked about the privacy issues that could arise here, however, so there is definitely a fine-line to walk here. Apart from distribution of educational material per se, Talking Book has potential for distributing informational content. It doesn't do much good to send written schedules, instructions, and documents to non-literate people; but those same people can listen to audio describing the same things.

The interface for Talking Book actually opens up a variety of possibilities beyond traditional audio-books. I proposed, perhaps whimsically, that the same interface would allow users to play text adventures, in the style of the old terminal games that us older developers remember. I do not think games like that are important, but thinking about the different ways that one might interact with segments of audio is interesting. Schmidt himself said that one of the great advantages of making the code for the Talking Book open is that it can allow innovations that he has not anticipated in the uses the device can be put to. I also found it interesting that the interface has a lot in common with those provided to blind readers, for example by the non-profit organization Recording for the Blind & Dyslexic (RFB&D).

All of this leads to a plug. Literacy Bridge needs some embedded programmers to finish up the code that will go in the pilot version of Talking Book. Volunteering would be a great opportunity to help out some nations and communities whose lives would be greatly improved by improved literacy and greater access to information. You can do this by writing Free Software!

Parallel day

The lineup allowed it, so I decided today I would devote myself to understanding programming models for concurrency. It may or may not have any relevance, but the gig I am currently working is at an amazingly cool company (DEShaw Research) that is building the world's fastest supercomputer for computational biochemistry, called Anton. This isn't about a few percentages here and there either: in the application-specific domain of molecular dynamics, we are going to beat Blue Gene by more than two orders of magnitude (sorry IBM). The trick here is that DEShaw Research is using highly specialized chips for a problem that is very specific, is much more bandwidth constrained than computationally (but still a heck of a lot of computation), and utilizes shockingly little on-chip memory (which is what general-purpose CPUs use most of their silicon for). Being as I'm working to develop a hugely parallel system--albeit as a tiny contributor among far brighter people than me--I figured it would be interesting to see what sort of problems of parallelism other folks face

I attended some fascinating tutorials today, none of which had the slightest relevance to my abovementioned contract. An interesting feature of Anton is that its developers basically designed the silicon (and the channels, topology, etc) around the best decomposition of the specific problem at hand. In contrast, when developers working on general-purpose, commodity hardware think about decomposing and parallelizing problems, the issues are ones of matching the algorithms to the hardware, whether distributing work over multiple cores, multiple chips in a system, or across multiple boxes. The talks I had the chance to hear were Arch Robison and Robert Reed of Intel, speaking about Ubiquitous Multithreading for a Multicore World and Steven Parkes about An Introduction to Actors for Performance, Scalability, and Resilience.

Actually, I attended part of another session: Francesco Cesarini gave an introductory tutorial on Erlang. Unfortunately, I found Cesarini's talk to be far too slowly paced for me. I do not know Erlang (though I know a little about it), but I am somewhat familiar with concepts in functional programming and general CS ideas (as readers of Charming Python and other writing I have done for developerWorks will know). However, I unfortunately got the sense that his tutorial was aimed at a much more introductory level than the bulk of conference and tutorial attendees, almost all of whom I presume have a decent amount of programming background. It seemed like a course that would be great for novice programmers, but was probably not aimed right for its actual audience.

Intel's Threading Building Blocks (TBB) is an interesting GPL'd project. I had the chance to hear the keynote announcing its initial open source release at last year's OSCon. The idea of TBB is to abstract the work of thread coordination into high-level primitives, to let C++ programmers think about what their algorithms and tasks are, rather than worry about low-level details of acquiring and releasing locks, contention for cache lines, and determing optimal balance between task decomposition, bandwidth constraints, and cache freshness. The moral to keep in mind for the last balancing act is that too much parallelism hurts you as much as not enough: if a processor cache becomes stale because a core is juggling too many threads, the performance hit is awful; moreover, assigning tasks among cores on an ad hoc basis creates optimal load balancing, but typically at the price of wasted bandwidth. Robison and Reed discussed much of what went into the tradeoffs and design of TBB, which was fascinating to follow. I do not think I can explain these details sufficiently accurately, but the TBB documentation is a good place to start to learn more.

Without going into the design subtleties, the general style of TBB is worth describing. It consists of generous use of C++ templates and some custom functions (also some custom debugging tools). The capabilities are generally broken down between concurrency-friendly data structures (STL is not thread safe) and high-level parallel constructs. Containers in TBB include things like concurrent_vector and concurrent_hash_map. Functions include parallel_for and parallel_reduce. Use of the former is worth showing by brief example (taken from the TBB tutorial):

/*****************************************************************
 * INSTEAD OF:
 * void SerialApplyFoo( float a[], size_t n ) {
 *   for( size_t i=0; i<n; ++i )
 *       Foo(a[i]); }
 *****************************************************************/
#include "tbb/parallel_for.h"

void ParallelApplyFoo( float a[], size_t n ) {
    parallel_for(blocked_range<size_t>(0,n,IdealGrainSize), ApplyFoo(a) );
}

Read the tutorial for the real details, it is enough to understand here that all the niggly details of how numbers of cores, size of threads, shared-memory access, distribution of threads, etc. happens "by magic" in the TBB library. Pretty cool.

If the Intel presentation was challenging, Steve Parkes' talk was truly brain-melting. He advocates for the Actor Model of programming. In particular, he has both done work in Erlang, which naturally lends itself to this approach, and has created his own library/framework called Dramatis, implemented in both Ruby and Python. Dramatis itself is still in alpha, but is a way to explore concepts in programming with Actors.

Parkes broader conceptual argument is that threads are a terrible way of handling concurrency, and Actors are an elegant way. It's a sensible enough argument, actually. In fact, this is rather strongly witnessed by the notable success of Erlang (for Ericsson's telecom infrastructure) in implementing the most reliable switches in the world, ones that simply do not have the option of failing or rebooting. I am fairly convinced by the strength of Erlang/Actor "shared nothing architecture". It seems both elegant and approachable. I guess the only problem that really jumps out at me is that in exchange for reliability and ease of use, you simply have to bite-the-bullet of lots of data copying. For problems that are "embarrassingly parallel", or even merely coarse grained, bandwidth doesn't necessarily matter. If computation dominates (as it sometimes does) an Actor model seems great. However, if you really cannot afford to send data over far, slow channels, sometimes shared-memory access (with all the pains of locking, race-conditions, and all the rest) is the better bullet to bite.

First day tutorials

The first couple days of OSCon are the tutorial sessions. These have a bit different feel than the standard talks: if nothing else, they are much longer at 3 1/2 hours, where the later talks will be 1 hour each. This much time lets you get a pretty good initial sense of a particular technology. At the same time, a reporter cannot make it to as many sessions when each one is half the day.

In the morning I jotted between several sessions to try to get a feel for each. Steve Holden, Chairman of the Board of the Python Software Foundation (to which I was recently elected as a plain, lowly member), all around good guy, and Python advocate, gave an introduction to Python intended for people with some programming background, but not necessarily ever a line of Python. It seems like a daunting task. This session was packed; it's a good sign, I think and hope, of the growing popularity of Python.

Other than noting that Steve did a good job, there is not too much new to mention about the session; it did what a first three hours of Python training should do. I did notice that we are starting to get close to that slightly uncomfortable point where deciding between Python 2.x and 3.0 becomes a real issue. 3.0 is still in beta stages, but soon it will be out, and it just might be time to start training new users in 3.0 rather than 2.6 around now. Steve's session, however, was definitely a 2.x tutorial... with just some discrete mentions of upcoming changes. Of course, I am partially guessing on what was covered, since I split my time within the three hour block.

This leads me into another curiosity of the day. I saw both Damian Conway and Randal Schwartz speak as well, and neither had anything to say about Perl. Ok, I exaggerated ever so slightly: neither could completely resist Perl mentions, but that seems fair enough. Conway spoke during the same morning slot as Holden, but about Vim script. Vim script is an interesting creature, about which I knew shockingly little, especially given that I do mostly use Vim when I shell into SSH sessions on various machines. Without getting into a religious war with Emacs users on this (I'm pretty agnostic myself), I just find that I am less likely to be confused about the Vim that is installed at some location than for other powerful editors. Emacs users seem to have their own complex and unique configurations that they take with them wherever they go. Now that I have attended Conway's session, however, I think I may chase down that same rabbit hole with Vim customizations. My mind races with dozens of new helper functions that it would be ever-so-convenient to have in my environment.

Having only popped in and out of the session, I am certainly no expert at Vim script; barely a novice even. I was impressed, however, at just how much slicing and dicing it really is easy to do with Vim functions (not only with sed/awk/grep-like syntax rolled into daunting single commands). Many readers will know more than I did about the pretty nice list manipulation capabilities, the filtering and mapping constructs (almost functional programming!), parameter parsing in functions, and a good variety of string processing functionality. I am not surprised, just embarrased how slow I have been climbing that learning curve. Like some other things, however, Conway made a big point of observing just how very much non-orthogonality has grown into Vim script, with multiple ways to do the same simple-seeming actions, and pitfalls for almost-but-not-quite the same variations. Hmmm... do any readers know of other languages that suffer that danger?

During the morning, I also hopped into a talk called "GIMP demystified" by Akkana Peck. I only heard a bit of it, but Peck did a good job as well. Neither she nor Conway's talks attracted nearly the crowds of Holden's Python intro though. I do not do much graphics manipulation, but it was helpful to see just how sophisticated GIMP's masking and layers really are.

During the afternoon, I heard Randal Schwartz talk about the Seaside web framework. I confess that this one was my second choice, since a cancelled talk was to have covered "Advance Metaprogramming in Ruby". That brain-melting stuff gets my heart all a flitter (I have long wanted to write a book Metaprogramming in Python, but never really felt there was a market to support it). It was not to be today though.

Schwartz' talk was quite interesting, as is the Seaside framework. The most notable thing about Seaside is that it is written in Smalltalk; that and the fact that it is actually pretty widely used (according to Schwartz) by big corporate sites. Schwartz' talk spent the first half as a general introduction to Smalltalk: a cool language that not enough programmers have ever played with. I am very ambivalent about the imposed GUI/development environment/interpreter that Smalltalk (Squeak specifically in the tutorial) imposes on you. Smalltalk code focuses on ultra-short methods that really require the Smalltalk environment to browse and develop. I still feel a purity in separating my text editor from anything about the underlying language mechanisms. Smalltalk/Squeak is as far from that as it is possible to get: think Eclipse on steroids, and without any close button.

The framework itself is based on continuations and maintenance of session state. As with other rapid-development web frameworks, a very small amount of template code does a lot of work. In contrast to, say Ruby or Django, Seaside gives you far more capability of poking inside the running sessions, and even greater dynamism in seeing your code changes reflected on web pages. As a development feedback process, this is great. You can build your applications in baby steps, seeing the changes and improvements at each one, and getting immediate notification and feedback on bugs and glitches. Another respect in which Seaside is unusual as a web framework is that its "templating" language is just Smalltalk itself. While somewhat novel as a concept, in practice it seems little different: it is really just a matter of sticking some method names where you might put various meta characters and escape sequences in other frameworks. In the end, I am not really that impressed that the framework knows how to escape and unescape ampersands in values "behind the scenes." That part of Schwartz' presentation was a little bit "been there, done that." On the whole, however, I think Seaside is worth checking out, and has some definite and interesting advantages over other popular web frameworks.

Arriving and plans

I confess that I approach my interests in a somewhat whimsical fashion, usually letting matters of interest come into my scope of view rather than seek them out. There is so much interesting going on at OSCon that I figured this is a perfectly good approach.

All of that is a long-winded way of saying that once I got my press credentials approved, a variety of companies and organizations contacted me to propose interviews; some of more and some of less personal interest. Novell was particularly "pro-active" in actually following up with a telephone call, which I'll take as indicating their commitment to reaching FLOSS communities; I'll be speaking with Joe "Zonker" Brockmeier who has joined Novell as openSUSE Community Manager (http://zonker.opensuse.org/about/). I know Brockmeier by reputation, but have not had the opportunity to speak to him in the past. I look forward to this conversation on Wednesday.

Another conversation I am also looking forward to on Wednesday is with Cliff Schmidt of Literacy Bridge (http://literacybridge.org/about/boardofdirectors.html ). I hadn't known anything about them, but they seem to have a really worthwhile project for increasing educational opportunities in poor nations. Basically, it looks like their work dovetails with the good work the OLPC project has done. Literacy Bridge has the goal of providing low-cost players for audio books and other learning materials that will have a variety of cool features such as peer-to-peer content exchange, interaction with XO laptops, and provision of localized content. I'll ask Schmidt about more details, of course, but the focus of this work seems to be more about "free information" than about "free software" per se. Both are worthy purposes.

Coverage of OSCon 2008

Interview with Josh Berkus (OSCon 2006)

Josh Berkus is another interesting fellow I had a chance to talk with at some length. Sun really made an effort, it seems, to get folks in the public eye. A lot of the vendors sent me solicitations to check out their booths, usually with blurbs about their products in the press releases. But Sun made the extra effort to schedule interviews between press members and Sun employees. I see that not only because I had such scheduled interviews with Josh Berkus and Tim Bray, but also because some other folks out there in the press (or blogosphere, if that is a real word) have also posted comments from such interviews. For what it is worth, Simon Phipps is another prominent Sun employee who was slated in the interview track—I did not talk to him personally, but I did attend his talk in conjunction with Tom Marble (I might come back to that in another entry).

Let me get the last part of my talk with Josh out of the way first. The reason Sun was putting him forward, was almost certainly to answer the question I asked him towards the end of our talk (or something closely along the same lines), namely: Why is Sun a good fit for maintenance and development of PostgreSQL (for those not in-the-know, Josh has been one of the main developers of PostgreSQL for four years). The sort of vague answer is about the stability and scalability of Solaris and Sun hardware. True enough, but I think slightly at the level of nicety. Of more substance to my mind was Josh's specific statement on the benefits of the ZFS filesystem. In particular, ZFS allows dynamic use of multiple physical volumes, with a volume manager controlling virtual storage pools. Just what you want for growing databases.

What Josh and I talked about in more detail is probably idiosyncratic to my interview with him. Although I had not spoken with him before directly, Josh has also worked with the Open Voting Consortium that I am CTO of, and roughly in affiliation with I gave my paper. It was interesting to get Josh's perspective on these issues, and he is someone quite knowledgeable in this. Clearly, in whatever area he enters, Josh does his homework. Last year, Josh testified before CA legislature on FOSS in relation to voting systems, during a hearing considering legislation to mandate such use. Well, really the hearing followed up on the non-binding CA HR 242 that stated a preference for such systems, instructed the California Secretary of State to conduct hearings on the matter. The SoS wound up stonewalling on hearings, but the California Senate picked up on the gap. Initially, OVC had asked Brian Belendorf to testify; but when Brian was unavailable, he recommended Josh. Lots of background that I just happen to know, but readers need not necessarily follow.

In our interview, Josh expressed some alarm at the conflict of interest that paid lobbyist who get money from proprietary vendors, but work in elections, have. Some of them testified in the same committee. Josh was proud of a coup he accomplished in having on hand, during his testimony, a large list of FOSS vendors (in CA), in refutation of claims by the proprietary software lobby that no such companies existed. In a nicely strident statement, Josh observed that the main "trade secret" of current vendors of election systems is just how bad their source code is. But in a more abstract tone he emphasises the "many eyes" needed to make sure bugs/backdoors are caught; he believes, as I do, that it is not sufficient simply to reveal code in limited contexts. Concretely, as soon as "code auditors" who have signed NDAs start finding bugs in proprietary system that they have been assigned to examine, they (the auditors) find themselves in court, with lawsuits from vendors. Probably these are non-meritorious SLAPP actions; but how many programmers can afford lawyers to aid the public good?

One interesting claim Josh made was that in Canada and the UK, opponents of computerized voters feared that FOSS voting systems would legitimize such systems, despite their technical lack of readiness. This is certainly an interesting inversion of "FOSS-poison" attitude in the USA. That is, here in the USA, a popular equation is of FOSS systems with vulnerabilities (and equation promoted by FUD and lobbying in my opinion, and I am sure in Josh's). Josh made an interesting point that one computer security expert who made the claim about the non-readiness of FOSS systems was overly pessimistic about computer security, and overly optimistic about non-computer security. I think there is a nice point there: while computer systems have vulnerabilities, that does not mean that non-computerized systems are necessarily safe. At least as a general rule: I think the safeguards of the Australian ballot and padlocks on ballot boxes is relatively well-understood, after 150 years.

I also attended one of the three sessions Josh gave (a busy guy), the one on FOSS press relations. He did a nice job with this as well. Probably a failing of many FOSS projects is not knowing exactly how to deal with the broader media, and how to formulate and time good press releases. Certainly these concerns are big for big and widely-used projects like PostgreSQL. Many perfectly usable and useful smaller projects (like, say, my own little Gnosis Utilities are actually probably fine with a sort of "let the release go out quietly" approach... some tools are meant for a narrow and technical audience who already know where to look. PostgreSQL is one of those tools used by millions, including by many big companies and organizations. For something like that, FOSS should show the same savvy (or better) as that big proprietary software vendors with PR departments have. In a lot of ways, FOSS projects can and do achieve better media relations than the unfree guys.

A quick note on Tim Bray and Atom (OSCon 2006)

More on Open Source Voting presentation

• Arthur M. Keller and David Mertz, "Open Source Voting," presented at Open Source Convention (OSCON 2006)", Portland Oregon, July 24-28, 2006.
• Arthur's collection of papers on electronic voting; on most or all of them I am one of his coauthors.
• My own papers related to open source voting issues, again sometimes with coauthors, including Arthur

Second day: Software Libre

Second day: Python 3000

1. Code analyzers along the lines of PyChecker and PyLint that can in many cases extract the intent of code, vis-a-vis the specific types of objects being handled. Most breakage will come about because particular types (think collections) behave somewhat differently than they used to. Guido gave the example of trying to determine whether f(x.keys()) represents code breakage. There are two points of concern here:
   1. Is x.keys() really a call to a method of a dictionary(-like) object, as you would tend to think?
   2. As mentioned below, this call on a dictionary will start returning either an iterator or a view in Python 3.0, rather than a fixed list. Depending on what you do with it, the change may or may not matter to the code in f(). I.e. if you just do "for thing in keys:", all is happy; if you mutate the expected list, problems occur. The exact fix is not generally automatable, since developers can reasonably want different behaviors in response to the change.
2. Warnings about likely changes. Presumably with 2.7 (and later 2.x versions), there will be a means of warning developers of constructs that are likely to cause porting issues. In the simplest case, this will include deprecated functions and syntax constructs. But presumably the warnings may cover "potential problems" like the above example.

1. All strings become Unicode (breaky), and a new bytes type lets you encode mutable arrays of 8-bit bytes. Basically, one is "text" the other is "binary data". Accompanying this will probably be a variety of mechanisms to make I/O methods inherently handle Unicode, transparently deal with decoding on open(fname) and the like (and also things like seeks).
2. Inequality comparisons become even more breaky than they have been (see my recent Charming Python bemoaning inequalities). I have mixed feelings myself, but in a certain way I think it is a reasonable approach. Python will give up (most of) its willingness to guess about what coders intend when comparing unlike types of things. At least that adds consistency. Rather than sometimes-but-who-knows-when having sorts break, we can just assume they do not work unless collections are homogeneous, or unless heroic measures are taken in advance (but as a known requirement).
3. As expected, the move towards iterators and variations on lazy objects continues apace. List comprehensions do not go away, but they are direct synonyms (syntax sugar) for a list() call wrapped around a generator comphrehension. This changes the leakage of variables to surroudning scope, which is a good thing.

Second day: Microformats

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Any sufficiently complicated XML-based ad hoc format, eventually finds a way to embed the moral equivalent of informally-specified, bug-ridden, and ugly XML namespaces

First day of attendance: Presentation

First day of attendance: Sessions

First day of attendance: Exhibition