The first part will demonstrate Audacity's range of features, while highlighting some of the capabilities that make Audacity unique. A recurring theme will be the idea that Audacity has a deceptively simple user interface, but has lots of sophisticated techniques and algorithms "under the hood" making very intelligent decisions that many users never even realize are happening, without getting in the way of advanced users that want more control over the system. The demonstration will be focused around a scenario of a garage band who is using Audacity to create a demo CD. Creating this CD will take several steps that each illustrate different features of Audacity.

The second part will give an overview of the issues Audacity faces from a developer's perspective. We will explain the challenges we have encountered in keeping Audacity fully supported on three platforms such as UI consistency and supporting native sound APIs. We will also describe legal issues we have encountered: specifically, patent issues surrounding MP3 encoders/decoders and copyright problems with our support of VST plugins, which requires linking against a nonfree SDK. Finally there will be a short explanation of the nontraditional data representation scheme Audacity uses to support nondestructive editing, and how that scheme allows for innovative features such as Josh's recent work with lossless Ogg Vorbis editing: it allows one to import a lossy-compressed Ogg Vorbis file, edit with cut/copy/paste, then export to another Ogg Vorbis file without re-encoding. This work is part of a senior thesis he is working on this semester. More information about this work is available at http://www.reverberate.org/computers/thesis/.

Audacity 1.0 was reviewed in the Washington Post summer of 2002. Also that summer Audacity was mentioned on TechTV during a segment where a caller was looking for software to remove some clicks from a sound file.

Both parts of the presentation will be supported by technical demos.

One of the primary design goals of FunFS is massive persistent caching. It is currently common practice to use NFS to mount the root filesystem for terminals and cluster machines to simplify administration. This approach, however, does not scale well, because of the strain it puts on the NFS server. FunFS clients are much more independent. By caching the files locally, they minimize the dependence on the server. In fact, a system with the root filesystem mounted using FunFS is able to remain functional even during a complete network failure. This situation will be simulated in the first part of the demo.

To show the real world impact of the latency reducing techniques used in FunFS, a benchmark of FunFS vs. NFS will be used. The same set of file operation will be performed and timed using both filesystems, while counting the number of round trips performed and the amount of data transmitted. While both filesystems transmit roughly the same amount of data, FunFS is a clear performance winner. The explanation lies in the number of round trips performed by each filesystem during the test. The latency-centered protocol design of FunFS allows it to outperform NFS by a significant margin.

• Make better use of CSS to handle layout and feel
• Get word-diff working in the diff page, so you can see which words changed on a modified line
• Create a configure page to allow easier configuration of the wiki settings
• Make an uninstall script that cleanly removes the wiki
• Design and implement with better access controls
• Handle plurals, and specially designated "WikiWords"
• Lots more plugins!

• A brief overview of Zero Configuration networking, discussing the principles, the required protocols and where mod_zeroconf fits in.
• Demonstration of the module at work
• Walkthrough of the module architecture
• Discussion of pertinent module code
• Discussion of build-time and run-time requirements
• Q&A

• Working, demo-able code
• Developed on X86 linux
• Apache license

• More platforms
• More mDNS responder APIs as they become available
• Backport to Apache 1.3
• Aiming for donating the project to the Apache Software Foundation

1. our permission model
2. a system designed to eliminate the need for writing screen scrapers
3. a technique for authenticating sessions using HMAC
4. the ease of application development in our framework.

Next, I will show a variety of transport mechanisms: direct TCP connections, encapsulated SMTP messages, alt.anonymous.messages postings, and remailer network usage (for outbound messages).

Finally I will show how a recipient who lives behind a remailer network can automatically publish their SURBs to a Transport Server and how a sender can establish easy communication with them despite each message requiring a different transport path.

1. Custom hardware accelerated GUI framework built with Java2D and JOGL (OpenGL).
2. NDimensional event system that can interoperate between multiple components on 1D, 2D, 3D levels and beyond.
3. Optimized network architecture for high volume network transmissions. Scream communicates via the OSC network protocol to OSC enabled software / hardware.

France Telecom is indeed a good company for this kind of projects: France Telecom do not operate (almost) any servers, it instead operates networks, and peer networks are networks, aren't they?

1. run the software and have a live chat with internet users and/or the Codecon attendees (depending on the local network config).
2. While so, present the Solipsis architecture and algorithms.
3. And to get feedback and support, we will present also how we envision = the future of Solipsis (open source, standardization, colonization,...).

• Code is usable, stable enough, portable, and small (~11k lines of C)
• Code is released unencumbered as free software
• We've written a clear byte-level specification and design paper

• Location-hidden servers via rendezvous points
• Restricted-route (non-clique) network topology
• Threshold agreement between directory servers
• Widely deployed testbed network

Differences between the Vesta paradigm and other popular versioning/build systems will be illustrated.

The web interface will be demonstrated.

In the last three years, it's been ported to Linux on four different CPU architectures and transformed from a corporate research project into a free software project.

The builder provides completely automatic language-independent dependency detection.

Because of the way the builder is designed, there's a guarantee of precise build repeatability.

It's competitive with [expensive] commercial configuration management systems, but it's free.

(More details at: http://www.vestasys.org/why-vesta.html)

• Installable RedHat/Debian packages (probably by the time of CodeCon).
• Secure authentication between remote repositories and encryption of transactions.
• The ability to trigger arbitrary actions on repository changes (e.g. sending e-mail on checkin).
• Ports to new platforms (Solaris, FreeBSD, Darwin/MacOSX, others).

• Read in a simple c-language program and graph it's Abstract Syntax Tree (AST)
• Edit and debug the program at the AST level
• Write the program back out both in c and in python and show that both versions run
• Give a walkthough of the system's novel user interface