Like you, dear Internet readers, I have no shortage of reading material. I have ready access to more engaging, high quality, informative and relevant information than I can possibly digest. Every day, I have to choose what to read, and what to pass by. This seems like an important thing to do well, and I wonder if I do a good enough job of it. This is just one example of a larger breadth/depth problem, but I m finding the general problem difficult to stomach, so I m focusing on reading for the moment. These are my primary sources of reading material on a day-to-day basis:

• Email I read everything which is addressed to me personally. I don t reply to all of it, and my reply time can vary greatly, but I am able to keep up with reading it, and I consider it important to do so. I am still subscribed to a selection of mailing lists, but I find them increasingly awkward to manage. There are a few which I scan on a daily basis, but most of them I process in batches when I m offline and traveling. I m subscribed to far fewer mailing lists than I was five years ago, though I feel they are still the most effective online discussion facility available. I find myself doing more and more discussing in real-time on IRC and by phone rather than by email.
• Blogs I subscribe to a few big aggregators and a random sampling of individual blogs. Most of them I scan rather than read. I do most of this offline, while in transit, and so I don t tend to follow links unless they re promising enough to save for later. I ve recently stopped trying to keep up (scan every post) on most of them, and instead just sample whatever is current at the time. It feels like turning on a television, flipping through all of the channels, and turning it off again. Even when I do find something which I feel is worth reading, it s hard for me to focus my attention after a long session of scanning. I do find a lot of good stuff this way, but I m pretty dissatisfied with the overall experience. I never feel like I m looking in the right places.
• Shared links I share my own links publicly, and follow those shared by friends and acquaintances. I do this with multiple groups of people who don t connect directly, and pass items back and forth between those groups. I place an increasingly high priority on reading items which are shared by people I know, more than on trying to follow the original sources, because the signal-to-noise ratio is so good: my personal network acts as a pretty good filter for what will interest me. I have the nagging feeling that I need to maintain a balance here, though. If I read mostly what other people are sending me, I feel like I m living in a bubble of like-minded people and fear that I ll lose perspective.
• News I read hardly any proper news. I don t subscribe to any newspapers, and generally don t read the online versions either. I do read articles which are shared by people in my network. Traditional media never seems to have the right scope for me. There may be particular journalists, or particular topics I d like to follow, but news outlets simply don t group their content in a way which fits my mind.
• Books Remember these? My diet of books has shrunk drastically since I started reading more online media. Devoting my full attention to a book just doesn t feel as energizing as it used to. I hesitate at the prospect of sinking so many hours into a book, only to decide that it wasn t worthwhile, or worse, to forget what I learned as I m bombarded by bite-sized, digestible tidbits from the Internet. I feel sad about losing the joy of reading I once had, and want to find a way to reintegrate books into my regular diet.

How do you decide what to read, and what not to read? How does your experience differ between your primary information sources? How have you tried to improve?

DevOps I first heard about DevOps from Lindsay Holmwood at linux.conf.au 2010. Since then, I ve been following the movement with interest. It seems to be about cross-functional involvement in software teams, specifically between software development and system administration (or operations). In many organizations, especially SaaS shops, these two groups are placed in opposition to each other: developers are driven to deliver new features to users, while system administrators are held accountable for the operation of the service. In the best case, they maintain a healthy balance by pushing in opposite directions, but more typically, they resent each other for getting in the way, as a result of this dichotomy:

	Development	Operations
is responsible for	creating products	offering services
is measured on	delivery of new features	high reliability
optimizes by	increasing velocity	controlling change
and so is perceived as	reckless and irresponsible	obstructing progress

Of course, both functions are essential to a viable service, and so DevOps aims to replace this opposition with cooperation. By removing this friction from the organization, we hope to improve efficiency, lower costs, and generally get more work done.
So, DevOps promotes the formation of cross-functional teams, where individuals still take on specialist development or operations roles, but work together toward the common goal of delivering a great experience to users. By working as teammates, rather than passing work over the wall , they can both contribute to development, deployment and maintenance according to their skills and expertise. The team becomes a devops team, and is responsible for the entire product life cycle. Particular tasks may be handled by specialists, but when there s a problem, it s the team s problem. Some take it a step further, and feel that what s needed is to combine the two disciplines, so that individuals contribute in both ways. Rather than thinking of themselves as developers or sysadmins , these folks consider themselves devops . They work to become proficient in both roles, and to synthesize new ways of working by drawing on both types of skills and experience. A common crossover activity is the development of sophisticated tools for automating deployment, monitoring, capacity management and failure resolution. DevOps meets Cloud Like DevOps, cloud is not a specific technology or method, but a reorganization of the model (as I ve written previously). It s about breaking down the problem in a different way, splitting and merging its parts, and creating a new representation which doesn t correspond piece-for-piece to the old one. DevOps drives cloud because it offers a richer toolkit for the way they work: fast, flexible, efficient. Tools like Amazon EC2 and Google App Engine solve the right sorts of problems. Cloud also drives DevOps because it calls into question the traditional way of organizing software teams. A development/operations division just doesn t fit cloud as well as a DevOps model. Deployment is a classic duty of system administrators. In many organizations, only the IT department can implement changes in the production environment. Reaping the benefits of an IaaS environment requires deploying through an API, and therefore deployment requires development. While it is already common practice for system administrators to develop tools for automating deployment, and tools like Puppet and Chef are gaining momentum, IaaS makes this a necessity, and raises the bar in terms of sophistication. Doing this well requires skills and knowledge from both sides of the fence between development and operations, and can accelerate development as well as promote stability in production.
This is exemplified by infrastructure service providers like Amazon Web Services, where customers pay by the hour for black box access to computing resources. How those resources are provisioned and maintained is entirely Amazon s problem, while its customers must decide how to deploy and manage their applications within Amazon s IaaS framework. In this scenario, some operations work has been explicitly outsourced to Amazon, but IaaS is not a substitute for system administration. Deployment, monitoring, failure recovery, performance management, OS maintenance, system configuration, and more are still needed. A development team which is lacking the experience or capacity for this type of work cannot simply switch to an IaaS model and expect these needs to be taken care of by their service provider.
With platform service providers, the boundaries are different. Developers, if they build their application on the appropriate platform, can effectively outsource (mostly) the management of the entire production environment to their service provider. The operating system is abstracted away, and its maintenance can be someone else s problem. For applications which can be built with the available facilities, this will be a very attractive option for many organizations. The customers of these services may be traditional developers, who have no need for operations expertise. PaaS providers, though, will require deep expertise in both disciplines in order to build and improve their platform and services, and will likely benefit from a DevOps approach. Technical architecture draws on both development and operations expertise, because design goals like performance and robustness are affected by all layers of the stack, from hardware, power and cooling all the way up to application code. DevOps itself promotes greater collaboration on architecture, by involving experts in both disciplines, but cloud is a great catalyst because cloud architecture can be described in code. Rather than talking to each other about their respective parts of the system, they can work together on the whole system at once. Developers, sysadmins and hybrids can all contribute to a unified source tree, containing both application code and a description of the production environment: how many virtual servers to deploy, their specifications, which components run on which servers, how they are configured, and so on. In this way, system and network architecture can evolve in lockstep with application architecture. Cloudy promises such as dynamic scaling and fault tolerance call for a DevOps approach in order to be realized in a real-world scenario. These systems involve dynamically manipulating production infrastructure in response to changing conditions, and the application must adapt to these changes. Whether this takes the form of an active, intelligent response or a passive crash-only approach, development and operational considerations need to be aligned. So what? DevOps and cloud will continue to reinforce each other and gain momentum. Both individuals and organizations will need to adapt in order to take advantage of the opportunities provided by these new models. Because they re complementary, it makes sense to adopt them together, so those with expertise in both will be at an advantage.

Since some time the good people at NlNet have been sponsoring Collabora to add multi-party audio/video calling to XMPP and do an implementation of this in Telepathy. This project is otherwise known as Muji. This work has resulted in:

• an experimental XMPP extension called Muji
• a new and more modern telepathy API for doing calls (currently still in draft), which allows multi-party calls as well as adding the possibility to support call forking (ringing multiple remote devices, call goes to the one that's picked up first).
• An implementation of both of these in telepathy-gabble
• A small telepathy client for testing and demo purposes.

To proof it actually works, a nice screenshot of the demo client in a 4-way call: The screenshot is featuring myself in Collabora's UK office (top-left), Robert McQueen from a hotelroom in Taipei (top-right), Will Thompson and Magical trevor also from the Collabora UK office (bottom-left) and Mike Ruprecht from somewhere in Missouri. So we were quite spread out over our little planet. Both audio and video quality was quite good, even though the network in robs hotel was a bit flaky from time to time. In case you want to try it out have a look at the MujiDemoClient page.

Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades. When I was unborn

the Toto band were releasing their song "Africa" and some smart guys were working on a windowing system: the X Window System (this is its full name) which therefore has a (too) long history. The latest version of its protocol, the 11th one, has been designed in the 80's. You can learn more about the history in the Wikipedia article about X. In 2010, we still listen disco music and we still use various protocols designed in the 80's and even before X. Music have evolved, protocols have evolved, and so did X11. The problem is that X11 did not evolve that well. The guys at MIT-and-some other-places-with-very-smart-people-in-it created X version 1 in 1984, and updated it until X version 11 (the one we're still using) in 1987. Eleven version in 3 years, that was following the "release early, release often" model. But I don't know why, it just stopped to happen for the last 23 years¹. I don't know what changes have been made in the first 11 major versions of the X protocol, but I'm rather sure we should have deserve a couple of major version updates this last 2 decades. In my humble opinion, X11 was not designed to live 23 years. But hey, I'm not blaming anyone here: I was 4 years old and playing Lego when they released this latest version of the X protocol, so there is little chance I'd have done something better.

1. That's not totally true: they added (and then deprecated) many extensions. We won't fix. We'll work-around.

That is probably one of the guideline of the X protocol for the last years. And don't misread me: I'm not bashing anyone thereafter. Since the X11 protocol was aging, the X guys started to add extensions. They added tons of them over the years. This, in application of one of the early principles of X:

It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

All of them with no exception were added because, bad luck, the X11 protocol did not anticipated the things that happened in the last 23 years, like video, OpenGL, multiple monitors, or the pleasure to draw oval windows. Some of this extensions are still in use, while some of them have been dropped. While this is not a bad thing to extends the protocol, it seems like a bad thing to try to fix the protocol with for example the XFixes extension, even with all the good intentions Keith Packard might have in his greatness. Actually it's even worst than you think

The X11 protocol (without extensions) defines about 120 types of requests: create a window, move a window, etc. Nowadays, there's at least 25 % of them which are useless: usage of server-side font, or the drawing of squares and polygon, are unused by any modern application or toolkit. All of this is superseded by requests from extensions, like the XRender one. The handling of multiple monitors displays has totally been screwed up. X11 has been designed to work in Zaphod mode (independent monitors). But Xinerama, and nowadays XRandR have replaced it up: recent X servers (released after ~2007) does not support Zaphod mode anymore, even if it's a core piece of the X11 protocol. Worst: on many requests, there's limitation or design flaws, like described in this document: Why X Is Not Our Ideal Window System by DEC researchers. We'll add more broken standard on top of that

Following its early principle, X does not define policies but only mechanisms, which seems like a good thing, Consequently, people started writing specifications to determine a number of stuff and dogmas: ICCCM. That was 22 years ago in 1988. It's useless to add that many things in this specification are now obsolete, useless, or that it misses many modern stuff. I was not the only one to think that. The people from what will be the major desktop environments, KDE and GNOME, saw that too in the 90's while I was learning to count. So they wrote EWMH, another standard that comes on top of ICCCM and extends it with nifty features like maximization, full screen mode, etc. The problem is that this standard has also been written by narrow-minded people who at that time, were working on GNOME or KDE (and maybe others). This desktop environments were having and still have some strong concepts of how should work a desktop: "it should have work-spaces", "a window is only on one workspace", "we only see a workspace at a time", "you do not have multiple screens", etc. Dude, we don't care: we have toolkits!

This vision of how the desktop should work have now been written in marble in all applications and libraries implementing EWMH, like GTK+ or Qt. Nowadays, everybody forgot about all of this standards. Toolkits have implemented this, circumvented the X11 protocol limitation and flaws, and nobody wants to look back. Like all standards, obviously some people implemented them badly. This had some side effects, like OpenOffice acting like a pager. We don't look back? Worst, we forgot where we came from!

With all these layers of bad designed standards, the desktop continued to evolve for more than a decade. They continued to add more standard, the more recent ones being based on D-Bus like the Desktop Notification Specification or the latest Status Notifier Specification developed by KDE. The Status Notifier is a new implementation of the good old system tray based on XEmbed, using D-Bus instead of the X11 mechanisms, and adding the possibility to show the system tray with something else than icons. This specification draft saw an important issue and design flaw raised by Wolfgang Draxinger in this thread on the XDG mailing-list. What Wolfgang points out, is that X is network-oriented, and D-Bus is not. Therefore, making the Status Notifier specification to use D-Bus to pass system tray messages around is a bad idea, since running a X application from host A on host B will draw the system tray on the wrong host! Apparently, reading the thread, this does not fear some of the KDE people:

of course this is a bizarre corner case not worth much thought. at least that's what you'll think until you actually run into it yourself (be it because you are testing something or because you are setting up some weird kiosk environment).

What Oswald describes as a corner case is an actual common use case for many of us. Of course, YMMV. From my point of view, this is a step back in the wrong direction. But we can conclude that the network part of X is now worthless, to at least KDE. I used to believe in XCB

When I joined Freedesktop, it was to work on XCB, the X C Binding. XCB is a nice, clean, 21st century technology based API to play with the X11 protocol. Its code is auto generated based on XML file describing the protocol. In comparison, Xlib is 80's obfuscated code with almost no comments and hard-coded things. Only a few people can understand some of its corner like its i18n or XKB implementations. And all its code is synchronous. For people not knowing it yet, X is a network protocol where you send request (like a GET in HTTP) and then get a response. Xlib forces the application to wait for the reply to its request, so the application is blocked until the X server sends the reply to the request. XCB on the other hand does not block and allows the application to send a batch of requests, do some other stuff in the mean time, and then gets the replies. It's like your Web browser would send one request at a time to a Web server, and would wait until you downloaded all the images one by one to display the page. In cases where X and all its clients are on the same host, the latency is small and not really visible, therefore the gain for XCB to be asynchronous is small. On slow network however, the gain can be huge, as proved in the rewrite of xlsclients with XCB by Peter Harris. One of the long standing goal of the XCB folks is to kick-out Xlib, to increase speed and hides latency in X11 applications. That requires to port many libraries, because almost none of them (Cairo being an exception) supports XCB. From where I stand, I don't really see if the work is worth it now. The desktop world is trusted by GNOME and KDE, meaning GTK+ and Qt. It seems none of this toolkits are interested to work on XCB, neither on the X protocol. They probably put hard effort in bypassing X limitation and flaws, and they now sit on top of crap of workarounds and broken-by-design-standard implementation. It seems to me they don't want to go back in the layers and improves things. They're too high to go back down and they don't see what the gain would be. Enlightenment with its EFL was the first toolkit to have an XCB back-end with the work of Vincent Torri. Unfortunately, the back-end is not maintained and nobody cares about it. Last time I tried it, it did not compile at all. X12 ?

There's a page called X12 on the Freedesktop wiki, listing all the things that should be fixed some days. Unfortunately, the list continues to grow up an no one talks about working on X12. On the other hand, there's a handset of people trying to work when they will have time on XKB2, the second version of the "let's-try-to-fix-up-the keyboard-part-of-the-protocol-we-wrote-23-years-ago-a-second-time" extension. To me, it does not seem X12 will happen in the next decade neither. Alternative ?

Do we got alternative to X ? There's Wayland, but it's far from being usable. There's DirectFB, but that's not very portable. None seems candidate to replace X some days to me. Anyhow, none of the main toolkits around support this alternative. GTK+ once supported DirectFB, but as far as I know, it is not supported nor works nowadays, as stated by Josselin Mouette. This is why recent versions of the Debian installer have migrated to X for the graphic part, thanks to Cyril Brulebois work. Conclusion

XCB has been around for more than half-a-decade, and very few people showed interested in it. As far as I can see, nobody is interested to use the X protocol and everybody tries to encapsulate it in some higher-level API as soon as possible to stop seeing it. This leads to poorly written application and toolkits, with a lot of ugly hack. All of that also means that starting to write applications and graphical toolkits based on XCB would be a very interesting project, but that would lead to spend too much time learning to circumvent the X protocol flaws, things that have been done in years by predecessors like Qt and GTK+. Major toolkits implementations have almost nothing to win in going back in the dark water of X. I guess most of their folks prefer to work on shiny 3D effects based on your GPS location, rather than redefining better basis for everyone. The manpower available in the X world is very small. Debian lacking of X maintainers is just the summit of that. There is very smart and very competent and skilled guys in the X world, as you can see by simply reading blog posts on Planet Freedesktop for example (me excluded). Unfortunately, there's not enough of them to cover all the things involved in X: input devices, graphics devices, new protocol extension specification and so on. The X server is really late, and it seems most of the developers prefers to work on the server itself than on the protocol behalf. Which is understandable. I'm curious to see where all of that will lead in the upcoming years. I've been walking in the X world hallways for about 3 years now, and I feel desktop alternatives to KDE and GNOME will all die sooner or later. The time were you could choose between a dozen "modern" window managers has passed away. After all, maybe that is simply Darwinism applied to computer software.

This is a repost from the ubuntu-devel mailing list, where there is probably some discussion happening by now. After each UDS, the organizers evaluate the event and consider how it could be further improved in the future. As a result of this process, the format of UDS has evolved considerably, as it has grown from a smallish informal gathering to a highly structured matrix of hundreds of 45-to-60-minute sessions with sophisticated audiovisual facilities. If you participated in UDS 10.10 (locally or online), you have hopefully already completed the online survey, which is an important part of this evaluation process. A survey can t tell the whole story, though, so I would also like to start a more free-form discussion here among Ubuntu developers as well. I have some thoughts I d like to share, and I m interested in your perspectives as well. Purpose The core purpose of UDS has always been to help Ubuntu developers to explore, refine and share their plans for the subsequent release. It has expanded over the years to include all kinds of contributors, not only developers, but the principle remains the same. We arrive at UDS with goals, desires and ideas, and leave with a plan of action which guides our work for the rest of the cycle. The status quo UDS looks like this: This screenshot is only 1600 1200, so there are another 5 columns off the right edge of the screen for a total of 18 rooms. With 7 time slots per day over 5 days, there are over 500 blocks in the schedule grid. 9 tracks are scattered over the grid. We produce hundreds of blueprints representing projects we would like to work on. It is an impressive achievement to pull this event together every six months, and the organizers work very hard at it. We accomplish a great deal at every UDS, and should feel good about that. We must also constantly evaluate how well it is working, and make adjustments to accommodate growth and change in the project. How did we get here? (this is all from memory, but it should be sufficiently accurate to have this discussion) In the beginning, before it was even called UDS, we worked from a rough agenda, adding items as they came up, and ticking them off as we finished talking about them. Ad hoc methods worked pretty well at this scale. As the event grew, and we held more and more discussions in parallel, it was hard to keep track of who was where, and we started to run into contention. Ubuntu and Launchpad were planning their upcoming work together at the same time. One group would be discussing topic A, and find that they needed the participation of person X, who was already involved in another discussion on topic B. The A group would either block, or go ahead without the benefit of person X, neither of which was seen to be very effective. By the end of the week, everyone was mentally and physically exhausted, and many were ill. As a result, we decided to adopt a schedule grid, and ensure that nobody was expected to be in two places at once. Our productivity depended on getting precisely the right people face to face to tackle the technical challenges we faced. This meant deciding in advance who should be present in each session, and laying out the schedule to satisfy these constraints. New sessions were being added all the time, so the UDS organizers would stay up late at night during the event, creating the schedule grid for the next day. In the morning, over breakfast, everyone would tell them about errors, and request revisions to the schedule. Revisions to the schedule were painful, because we had to re-check all of the constraints by hand. So, in the geek spirit, we developed a program which would read in the constraints and generate an error-free schedule. The UDS organizers ran this at the end of each day during the event, checked it over, and posted it. In the morning, over breakfast, everyone would tell them about constraints they hadn t been aware of, and request revisions to the schedule. Revisions to the schedule were painful, because a single changed constraint would completely rearrange the schedule. People found themselves running all over the place to different rooms throughout the day, as they were scheduled into many different meetings back-to-back. At around this point, UDS had become too big, and had too many constraints, to plan on the fly (unconference style). We resolved to plan more in advance, and agree on the scheduling constraints ahead of time. We divided the event into tracks, and placed each track in its own room. Most participants could stay in one place throughout the day, taking part in a series of related meetings except where they were specifically needed in an adjacent track. We created the schedule through a combination of manual and automatic methods, so that scheduling constraints could be checked quickly, but a human could decide how to resolve conflicts. There was time to review the schedule before the start of the event, to identify and fix problems. Revisions to the schedule during the event were fewer and less painful. We added keynote presentations, to provide opportunities to communicate important information to everyone, and ease back into meetings after lunch. Everyone was still exhausted and/or ill, and tiredness took its toll on the quality of discussion, particularly toward the end of the week. Concerns were raised that people weren t participating enough, and might stay on in the same room passively when they might be better able to contribute to a different session happening elsewhere. As a result, the schedule was randomly rearranged so that related sessions would not be held in the same room, and everyone would get up and move at the end of each hour. This brings us roughly to where things stand today. Problems with the status quo

1. UDS is big and complex. Creating and maintaining the schedule is a lot of work in itself, and this large format requires a large venue, which in turn requires more planning and logistical work (not to mention cost). This is only worthwhile if we get proportionally more benefit out of the event itself.
2. UDS produces many more blueprints than we need for a cycle. While some of these represent an explicit decision not to pursue a project, most of them are set aside simply because we can t fit them in. We have the capacity to implement over 100 blueprints per cycle, but we have *thousands* of blueprints registered today. We finished less than half of the blueprints we registered for 10.04. This means that we re spending a lot of time at UDS talking about things which can t get done that cycle (and may never get done).
3. UDS is (still) exhausting. While we should work hard, and a level of intensity helps to energize us, I think it s a bit too much. Sessions later in the week are substantially more sluggish than early on, and don t get the full benefit of the minds we ve brought together. I believe that such an intense format does not suit the type of work being done at the event, which should be more creative and energetic.
4. The format of UDS is optimized for short discussions (as many as we can fit into the grid). This is good for many technical decisions, but does not lend itself as well to generating new ideas, deeply exploring a topic, building broad consensus or tackling big picture issues facing the project. These deeper problems sometimes require more time. They also benefit tremendously from face-to-face interaction, so UDS is our best opportunity to work on them, and we should take advantage of it.
5. UDS sessions aim for the minimum level of participation necessary, so that we can carry on many sessions in parallel: we ask, who do we need in order to discuss this topic? This is appropriate for many meetings. However, some would benefit greatly from broader participation, especially from multiple teams. We don t always know in advance where a transformative idea will come from, and having more points of view represented would be valuable for many UDS topics.
6. UDS only happens once per cycle, but design and planning need to continue throughout the cycle. We can t design everything up front, and there is a lot of information we don t have at the beginning. We should aim to use our time at UDS to greatest effect, but also make time to continue this work during the development cycle. design a little, build a little, test a little, fly a little

Proposals

1. Concentrate on the projects we can complete in the upcoming cycle. If we aren t going to have time to implement something until the next cycle, the blueprint can usually be deferred to the next cycle as well. By producing only moderately more blueprints than we need, we can reduce the complexity of the event, avoid waste, prepare better, and put most of our energy into the blueprints we intend to use in the near future.
2. Group related sessions into clusters, and work on them together, with a similar group of people. By switching context less often, we can more easily stay engaged, get less fatigued, and make meaningful connections between related topics.
3. Organize for cross-team participation, rather than dividing teams into tracks. A given session may relate to a Desktop Edition feature, but depends on contributions from more than just the Desktop Team. There is a lot of design going on at UDS outside of the Design track. By working together to achieve common goals, we can more easily anticipate problems, benefit from diverse points of view, and help each other more throughout the cycle.
4. Build in opportunities to work on deeper problems, during longer blocks of time. As a platform, Ubuntu exists within a complex ecosystem, and we need to spend time together understanding where we are and where we are going. As a project, we have grown rapidly, and need to regularly evaluate how we are working and how we can improve. This means considering more than just blueprints, and sometimes taking more than an hour to cover a topic.

Michael Specter gave an interesting TED talk about the dangers of science-denial [1]. Most of his talk is about the people who oppose vaccines, such as the former Playboy model Jenny McCarthy who thinks that she knows more about medicine than people who do medical research. He notes that a doctor who advocates vaccination has been receiving threats from the anti-vaccine lobby, including threats to his children. An good new development is that Andrew Wakefield (the British ex-Doctor behind the discredited research linking Autism and Vaccination) has been barred from practicing by Britain s General Medical Council [2]. Michael also mentions the opposition to GM food which has the potential to save many lives in developing countries that have food shortages. This convinced me to reduce my opposition to GM food, it s really not GM food that I m opposed to but the poor testing, the bad features (such as the Terminator Gene), and the Intellectual Property controls which allow GM companies to sue farmers who accidentally have GM crops grow on their land due to wind-borne seeds. It s also a pity that there is no work being done on GM versions of any food crop which is only used for feeding poor people. Every GM plant is one that is used to provide food for rich people and is essentially a way for farmers in first-world countries to make more money. But GM versions of Cassava (with less of the toxic chemicals among other things) and Sorghum would improve the situation of many poor people. One interesting related development is that Craig Venter has just announced the creation of the first synthetic life [3]. This technical development could lead to dramatic changes in the production of basic foods, such as algae that produce proteins that have the ideal mixture of all the essential amino acids needed for humans as well as the semi-essential ones that children need. While feeding pond slime to children isn t going to be glamorous it would be a lot better than the current situation where a significant number of children in developing countries have their physical and mental development stunted due to malnutrition. Craig mentions the possibility of using his research to develop vaccines much faster, including perhaps the possibility of vaccinating people against fast evolving viruses such as the common cold!

• [1] http://www.ted.com/talks/michael_specter_the_danger_of_science_denial.html
• [2] http://news.yahoo.com/s/ap/20100524/ap_on_sc/eu_britain_autism_doctor_11
• [3] http://www.ted.com/talks/craig_venter_unveils_synthetic_life.html

The usual semi-regular bits of news from the FusionForge project. We continue being quite active, with several hundred commits each month. The momentum doesn't seem to stop even after the 5.0 release last month. A large part of the activity stems from the Coclico project, which has several work-packages related to convergence of code across forges (mostly between FusionForge and Codendi). This convergence comes in three flavours:

• some new features are developed in common for both forges; as an example, the Mailman and ForumML plugins recently committed can now run unmodified in FusionForge and in Codendi (or at least that's the goal);
• some features existing only on the Codendi side are ported across to FusionForge; this includes the Codendi widgets system, which allow drag-and-drop customization of some of the web pages, and the Hudson plugin;
• finally, some of the core code is rewritten so that a common API and abstract data model can be used by higher-level pieces of code; the configuration system has been almost completely converted to a simple API, and the role-based access control system has also been rewritten into a clean model that extends both FusionForge's previous RBAC system and Codendi's, so each forge will provide new features for access control (the immediate gain for FusionForge is the ability to grant different permissions to anonymous visitors and to visitors that are logged in even if not members of the current project).

All in all, a fairly busy period for FusionForge. The current trunk is evolving rather fast, with some long-overdue rewrites being underway. Interesting times.

Now that we have released the slightly updated version of Debian's Machine Usage Policy (DMUP), I am thinking about a major rework for the next version. Maybe we should even start with a completely new text for it. I am currently doing a bit of brainstorming about how the new version could look.

Here are some of my ideas (completely unsorted):

• Debian is not an ISP. All services are offered on a best-effort basis. While we provide @debian.org email addresses, they should only be used for Debian-related work.
• Debian resources should be used for Debian-related work only. Even though I think this is self-evident, it should be explicitly mentioned.
• Data meant to be private should stay private, and not mirrored elsewhere. This especially includes log files and subscription data of any kind. I am not sure yet what to do with anonymized data, but in my personal opinion we should not even allow mirrored data of that.
• Drop large parts of the document and move it to a new document, called Debian Machine Usage Guidelines or Debian Machines Best Practices. Some parts of the current document are outdated, so let's see if we can drop those entirely.
• We forbid unlawful activities on our machines. Machines should not be used for private financial gain or for commercial purposes.
• Penalties might need some rework, in coordination with DAM.
  

Please note that this brain dump is my very personal opinion and does not reflect the opinion of the complete DSA team.

I would like to see a discussion on what the new DMUP should look like. Even though the final decision on which paragraphs make it into DMUP should stay with DSA, I think the Debian community should be involved in the evolution of this document.

Even though i am not attending DebConf10 (actually I think no one from DSA will make it), it might be a good idea if the conference could be used to do some further brainstorming. Maybe having a BoF on DMUP 2.0 might be a good idea.

Hello Currently Config::Model can upgrade /etc/ssh/sshd_config file because Sshd model is complete. All 80 parameters mentioned in sshd_config man pages are described there. The whole model (including doc is about 1000 lines long). If one just want configuration upgrade capability, requiring a complete model is too much work. The aim of this GSoC project is to find a way to provide upgrades at a reasonable cost. Ep 01 focused on what feature was missing from Config::Model to provide a model that could handle unknown parameters in most cases to enable upgrades without a complete model. This covered the use case of an unmaintained model facing software evolution. Now, let s go on with the OpenSsh example and let s see what would be the minimal model that would enable upgrades from older sshd_config version to a more recent one. (Note that this blog is based on upgrade requirements mentioned in sshd_config man page). This will cover the use case of a maintained model targeted for upgrades. From last blog, we know that this minimal model must feature:

• structural information (i.e. Match parameter)
• upgrade information (KeepAlive to TCPKeepAlive)

Let s tackle the structure of this minimal model by re-using the current model structure. We will need 2 classes:

1. Sshd: to handle all leaf parameters a the the Match parameter
2. Sshd::MatchElement: to handle parameters within a Match block

Sshd::MatchElement will need to handle unknown leaf parameters (exceptd Match parameters), so its declaration should be like: 'Sshd::MatchElement' =>
accept =>
match_not => '/Match/i'' ,
type => 'leaf',
value_type => 'string'


Note that there s no element declaration. The accept structure means that Config::Model will accept any parameter that does not contain match in its name and will handle it as a string parameter. (Note that this feature is not yet implemented in Config::Model) Now, we must declare the main class: Sshd. It will feature the a wider accept statement and element declarations for the following parameters:

• Match (the only structural element)
• KeepAlive (obsolete parameter)
• TCPKeepAlive (value migrated from KeepAlive)

Here we go: Any unknown parameter will be accepted by Sshd configuration class: accept =>
type => 'leaf',
value_type => 'string'
, Here are the element that require a special treatment: Match just refer to the class declared above
Match =>
type => 'hash',
index_type => 'uniline',
cargo =>
type => 'node',
config_class_name => 'Sshd::MatchElement'
, KeepAlive is the obsolete parameter. Parameter with status 'deprecated' are handled by Config::Model but will not be written back in the configuration file. Hence re-using the deprecated information elsewhere is more than recommended.
KeepAlive =>
type => 'leaf',
value_type => 'enum',
status => 'deprecated',
choice => [ 'no', 'yes' ]
, Here's the new parameter. It's value is computed from KeepAlive.
TCPKeepAlive =>
type => 'leaf',
value_type => 'enum',
choice => [ 'no', 'yes' ],
migrate_from =>
formula => '$keep_alive',
variables => keep_alive => '- KeepAlive'
,
,
Now that we have the model, we must figure out how to read and write value with minimal coding efforts. Due to the mismatch between the syntax of the file (flat structure) and the actual structure (special Match parameter), a dumb parser/writer cannot be used. A parser that takes into account Match is required. Either dedicated Perl code (like the parser/writer delivered with Config::Model::OpenSsh) or use Augeas and its sshd lenses. In summary, we ve seen that the model required to perform upgrades is about 30 lines instead of the 1000 lines required for a complete model. On the other hand, the syntax of sshd_config makes the parser and writer harder to write. But, normally, this parser/writer should not evolve during the life of OpenSsh project. Now the question that I cannot answer is: Can a packager handle the extra work to maintain this minimal model ? Feedback is welcome here Next episode will study how upgrades based on Config::Model can be applied on files with other syntaxes. All the best

on DMs and the packages they maintain The notion of Debian Maintainer (DM) has been with Debian for about 3 years. As of now, Debian has approximately 120 DMs, which maintain a significant part of the packages in the archive. I'm hereby happy to evilly spoil that Enrico Zini has just set up an index of Debian Maintainers and of the packages they maintain. The index is linked from the people section of our website as a symbolic step in giving more credit to DMs. Now, if anyone would like to setup a nice graph for the statistics page, which monitors the evolution of DMs (and DDs?), that would be useful.
Any idea on how to do that retroactively too?

The EGU conference is packed, and this blog isn't anything remotely like real-time, but some interesting talks came up on Monday evening : Simon Katterhorn gave a neat presentarion on icy moon tectonics, specifically on Europa and Enceladus. He showed the cycloid tracks on Europa, and how these are probably generated by tidally-driven ice tectonics. The presence of these of different ages shows the existence of a global ocean underneath, and the decoupled ice shell on top. More on this can be seen in Greenbergs book on Europa; but he also showed further follow-on work on Enceladus. Enceladus is small enough that people thought it had cooled and could not support an ocean, explaining the geysers and plumes by "small reservoirs". He shows instead that the 'tiger stripes' at the south pole are also tidally-created stresses, and moreover older generations of stripes, at an angle to the current ones, are also present: the plumes occur at the intersections. This shows free rotation of the ice shell and almost certainly an ocean. As to how to heat it: tidal heating is the primary candidate. I'm looking forward to Tidal heating and orbital evolution of Enceladus on Thursday. Tags conference, egu, europa, enceladus

Hello The GSoC project Krzysztof and I are working aims to facilitate configuration upgrade during package upgrades. Most of the cases, this upgrade should not require any input from the user, even if the user had previously customized his configuration file. Currently configuration upgrade may ask questions to the user which may be hard to answer for most non-technical users. For more details see PackageConfigUpgrade on Debian wiki. (If you are not familiar with upgrade issues, you might want to read this page.) At the 2 extremes of upgrade tools, we have:

• tools based on diff3 (like ucf)
• Config::Model based upgrades

Each tool has its own advantages and drawbacks. On the plus side of diff3 tools :

• minimal work required on upstream or packager

On the other hand, here are the issues with diff3 based tools:

• may produce syntactically wrong files
• may leave conflicts unresolved
• may leave duplicated (and conflicting) statements
• may loose user data

For more details on diff3 issues, see Benjamin Pierce s paper (thanks to David Lutterkort from Augeas for the info) On the other end of the spectrum, Config::Model pros are:

• Very robust, should work in most cases
• Can be set up to migrate user data from old config format to new format
• Leave upstream more room to change their project

But, Config::Model main problem is:

• Lot of work required from upstream or packager to create models

diff3 tools is lackluster for users. While Config::Model puts too much strain on packagers because it requires configuration models where all parameters are defined and declared in the model. For fast evolving projects, this can be a huge recurrent task (been there, done that for Xorg) . (Well, this recurrent task is a problem until doc, implementation and config model can be extracted from a single meta-description But I digress, this may be a project for GSoC 2011 :-p ) So, this GSoC project (for 2010) aims to find a compromise between these 2 extreme cases. On Config::Model, I ve always had a drawer statement whenever I was asked why Config::Model does not handle unknown parameter:

a configuration file cannot be validated if an unknown parameter can t be distinguished from a user typo.

This stance is fine for casual user interaction on a stable system: an unknown parameter is most likely an error. And the user must be warned of his error as soon as possible. For a stable distro release, packagers should have the time to provide complete models, so basing upgrade on complete models should be possible (famous last words ?). On the other hand, a lot of configuration upgrades will be done on unstable systems where software evolve quite fast, where models will likely fall behind software evolutions. Another shorcoming of my drawer statement is that it assumes user interaction where erroneous input is more likely. In case of configuration upgrades, there should be no user interaction. And we can assume that the config file to be upgraded was used (and thus validated) by the old version of the software. So unknown parameters should be tolerated and managed as best as possible. Now, the big question is: how ? In all attempts I ve seen in managing upgrades that goes beyond diff3 tools, the configuration is stored as structured data. Sometimes this structure can be infered from the configuration file syntax (shell vars, INI files, YAML, XML), sometimes not (sshd config file). In the latter case, some structural knowledge must be built in the upgrade tool. Currently, Config::Model is designed to bring a complete description of the structure and semantics of a configuration file. This is perceived as bringing too much structural and semantic knowledge ( too semantic ). So the maintenance cost is perceived as too important. That may be right or wrong, but that does not matter. Perception is more important here. So, let s figure out a way to reduce the amount of work required to perform upgrades (you may want to read a little bit more on configuration model creation before going on ) One possibility would be to support configuration models that allow unknown leaves in nodes. Such a model would provide a kind of fallback leaf description. Something like: this parameter is unknown, let s assume it s a simple string value . Let s consider sshd_config example to see how such a behavior would pan out for some upgrade scenarios. sshd model is made of 2 main classes:
- Sshd
- SshdMatchElement The second one contains all parameters allowed in a Match class (in fact, Match parameter is the only one in sshd that defines a new hierarchical level. All other parameters are simple leaves). Now let s consider typical upgrade scenarios from old version (with old models) to a more modern version. Let s assume that the model is lagging behind and the model does not follow sshd evolutions. So Config::Model will face 3 upgrade cases (extracted from sshd config history):

1. Unexpected parameter that are actually simple leaf parameters. E.g. introduction of ClientAliveInterval.
2. Obsolete parameters that should be migrated. E.g KeepAlive is renamed into TCPKeepAlive
3. New structural parameters (introduction of Match element)

So what would happen with a model allowing unknown parameters but lacking specific instructions for these upgrades:

1. ClientAliveInterval value would be kept.
2. KeepAlive would be kept as is.TCPKeepAlive would also be kept. No migration is performed, but the configuration would be good. As long as sshd supports the old parameter, we re good. :-/
3. Without knowledge of the structure brought by Match parameters, Config::Model would consider that parameter in Match block would duplicate parameters in the main block and remove the duplicate. User data may be lost.

So, there s not silver bullet. Let s resume what we ve learnt:

• to perform upgrade, the structure of the configuration must be specified
• A minimal model that would perform upgrade for Sshd without any validation would require only knowledge of Match parameter

Next step is to figure out what would happen if the same strategy is applied to other types of configuration files. But that will be for another blog. All the best

People s the deadline is fast approaching. Don t worry though, the best ideas come under deadlines and your proposal need not be lengthy. So get those typing hands out and submit a proposal (a few sentences suffices) for a presentation! The annual Debian conference is being held in NYC this year. First time
setting foot in the imperial empire. Are you doing something related to
free software that might be interesting to share, show off or talk about
at Debconf? I bet you are! We are looking for art installations,
performances, movie screenings, maybe you are wanting to host a
roundtable/panel discussion, coordinate a workshop (you dont have to
know the subject deeply to do this!). I know the deadline is soon, but don t let that scare you. The
submission requirement bar is very low, and we are flexible! here is the submission information: [1] ********************* Calling all potential contributors to DebConf10! One more week until
the final submission deadline! The DebConf team is excited to announce that we are now accepting
proposals for contributions to this year s Debian conference! We
invite you to submit proposals for how you would contribute until the
deadline: soon There are many ways you can contribute, you could present a technical
paper, host a panel discussion, put on a tutorial, do a performance,
an art installation, a debate, host a meeting (BoFS, or Birds of a
Feather Session), or other possibilities that you devise. This year we
are also accepting proposals for tracks=E2=80=94a thematic grouping around a
particular subject, and people to coordinate those tracks. If you are
looking for ideas of things that you could contribute, or have ideas
for things that you would like to see happen at DebConf, have a look
at the Contribution Brainstorm[0] page. DebConf talks will be broadcast live on the Internet where possible,
unless otherwise requested. Videos of the talks will be published on
the web along with the presentation slides and papers. =3D=3D Step 1. Submit Proposal =3D=3D Proposals should provide an overview of your proposed contribution,
similar to an abstract, and be no more than 600 words. Since
contributions can cover a range of issues, please describe what your
proposal covers, be it political (Free Software, law, advocacy,
access, etc.), technical (d-i, OpenPGP, etc.), social (Debian
structures and groups). It s okay to hit all three of these. Your
proposal should also include some information on why you re qualified
to present, or coordinate this topic. For example, you can include
links to posts you have made to Debian mailing lists or other material
that indicates your qualifications. Proposals and their abstracts will
be accepted until May 1st, 2010, 23h59 UTC. To submit your proposal, go to Penta[1] and register as an
attendee. Once you are registered, there is a Submit a proposal
link. You will see your proposal on the site. You can choose between
different presentation types. If you are unsure what type you should
use, please read our glossary of definitions[2]. If it s not there for
some reason, or you have questions, please contact us immediately at
mailto:talks@debconf.org. =3D=3D Step 2. Committee Review =3D=3D The review committee for this year will make its decision by May 1st,
2010. All correspondence will be done by email. =3D=3D Step 3. Paper Submission =3D=3D Like last year, we are asking for papers to be submitted along with
the presentations. A full paper is optional, however we strongly
encourage you to submit one if possible as we intend to provide
written information along with transcripts of the sessions for later
viewing. Having written papers in advance will allow us to get
translations done to help non-native-English speakers feel more
comfortable with the topics presented. Papers are due by July 1st,
2010, and should cover the topic in reasonable depth (3 pages A4 text,
plus pictures and diagrams). We will use LaTeX to typeset the
proceedings. Please submit your paper formatted in LaTeX. Should you
be unfamiliar with LaTeX earlier submission in plain text is also
fine. =3D=3D Step 4. Live Presentation =3D=3D Longer presentations may have a break in the middle and should include
workshop items that directly involve the participants. If using slides
or any other presentation, please consider that your audience will
consist of people who use free software, and your choice of
application to prepare and display the slides should reflect this if
at all possible. =3D=3D Fine Print Publication Rights =3D=3D DebConf requires non-exclusive publication rights to papers,
presentations, and any additional handouts or audio/visual materials
used in conjunction with the presentation. The authors have the
freedom to pick a DFSG-free license for the papers themselves and
retain all copyrights. The presentations will be recorded, and may be
broadcast over the Internet. Any copies of the presentation will be
made available =3D=3D Failure to Submit =3D=3D In the event that a deadline is missed we reserve the right to revoke
any offer to present. =3D=3D About DebConf =3D=3D The annual DebConf conference is a technical and social forum for
Debian developers, sponsors, affiliates, and friends. It allows
various groups within Debian a chance to come together, network, and
share their work. Until we see you in the big city,
DebConf Talks Team [1] introduction written by Micah Anderson

I ve been asked by the Debconf 10 talks team to coordinate a Debian Enterprise track at the upcoming Debconf 10 conference. I m really excited about this, and I could use your help. From my standpoint, this all started with a BOF proposal looking at better coordination and what is missing in Debian enterprise integration. The track will also include talks and other events on what exciting things are happening with Debian in the enterprise. I need your help in the form of suggestions for talks, panels and the like (especially if you would be willing to give the talk or coordinate an activity). We re under a fairly tight deadline; ideally proposals would be in by May 1, but if they are not, it s still definitely worth discussing with me. From my standpoint, topics include:

• Managing groups of machines together
• Working with Active Directory
• Open source answers to the use cases of Active Directory if you aren t a Windows shop
• Responses especially in the form of working code or ideas for getting there to my concerns about how we re letting Microsoft drive the evolution in the enterprise
• Federated authentication, authorization and personalization
• Integrating with asset tracking, ERP, and other enterprise processes and how Debian fits in.
• Bringing enterprise players into the community as contributors to the project

Obviously, many other things could fit in and I d be interested in your ideas as well.

For many activists in net-politics it is apparent that the fight against child pornography is just an excuse for establishing a EU-wide content filtering infrastructure. This infrastructure for content filtering can be used to filter other content than child pornography as well. For example politicians in Germany already requested blocking gambling sites, Nazi sites, left extremistic political sites and others, when we had that kind of discussion last year over here. The proposal of a law putting up stop pages in front of child pronography sites by former minister for family Ursula "Zensursula" von der Leyen passed the parliament, but shortly after last years parliament elecetion all political parties didn't want that law anymore.
EU commissioner Cecilia "Censilia" Malmstr m introduced a similar proposal for a EU-wide blocking iinitiative a short while ago, as you might now. Christian Engstr m, member of the EU parliament of the swedish Pirate Party, wrote today on his blog that content right industry welcomes child pornography as a way to introduce content filter and blocking infrastructure:

Child pornography is great, the speaker at the podium declared enthusiastically. It is great because politicians understand child pornography. By playing that card, we can get them to act, and start blocking sites. And once they have done that, we can get them to start blocking file sharing sites .

The venue was a seminar organized by the American Chamber of Commerce in Stockholm on May 27, 2007, under the title Sweden A Safe Haven for Pirates? . The speaker was Johan Schl ter from the Danish Anti-Piracy Group, a lobby organization for the music and film industry associations, like IFPI and others.

[...]

Start with child porn, which everybody agrees is revolting, and find some politicians who want to appear like they are doing something. Never mind that the blocking as such is ridiculously easy to circumvent in less than 10 seconds. The purpose at this stage is only to get the politicians and the general public to accept the principle that censorship in the form of filters is okay. Once that principle has been established, it is easy to extend it to other areas, such as illegal file sharing. And once censorship of the Internet has been accepted in principle, they can start looking at ways to make it more technically difficult to circumvent.

If you already have not, then please act now and contact your local EU representive and kindly ask to refuse this directive of Malmstr m and enlighten them by supplying arguments such those MOGIS (MissbrauchsOpfer Gegen InternetSperren, abuse survivors against internet blocking) put up on their webpage (English and other languages).

The abuse of childs and the documentation of such abuse (child pornography is a bad term anyway) needs to be stopped! But access blocking is the wrong direction. Better take care of a more effective criminal prosecution. Documentation of child abuse needs to get removed from the web and the producers needs to get arrested.

So, please act now!

P.S.: there's a nice video on http://cleanternet.org/

When I first started using Free Software yes, that s quite some time ago I found it the right thing to do. It felt like I was first time ever really controlling what my computer does. Took just a bit of time to notice I really never knew anything about it. Well, almost at least. Then when I started contributing to Free Software this obviously changed. One of the freedoms is to learn from the code you re running. And I did it by reading, contributing, doing nonsense with it, reimplementing it you know the deal. Starting to work on Debian was something that just evolved out of it. Doing so gave me the opportunity to give back. I never achieved that actually, though. At least I don t consider my contributions even remotely sufficient to make up for the great deal of software that I use sometimes without noticing it. Still there s lots of stuff that I don t have a clue of and I rely on other developers to do their (volunteer) job. Otherwise my knowledge wouldn t help much. I could never continue kernel development if those kernel hackers all stepped back for instance. I guess, it s getting more and more difficult the closer the piece of code is to hardware. Another thought I had was about Free Software in general. It s more than just the code (although it might be the most important part), it s also a concept that needs to be communicated. Firefox on Windows shows how Free Software can have a big market share in an otherwise closed source environment. Yet I m not sure all users know about it being open source and what that means (hear them talk about Freeware instead). And who is dealing with this conceptual stuff? I decided to do something about all that. Now I don t really have money but a bit I thought I could share. And I could set yet another sign by publicly talking about it, or casually mentioning that I consider Free Software and Linux a good thing. So you will see a mail signature now below all my mails. I always wondered what one might gain with such and now I found a reason to include one. It reads:

Debian Developer                                 www.debian.org
Member of the Linux Foundation                    www.linux.com
Fellow of the Free Software Foundation Europe      www.fsfe.org

Sam Harris gave an interesting TED talk about whether there are scientific answers to moral questions [1]. One of his insightful points was that when dealing with facts certain opinions should be excluded it would be good if journalists who report on issues of science could understand this. Another insight was that religious people most strongly agree with him regarding the issue of whether there are factual answers to moral questions but they think that God just handed the answers to their ancesters rather than making it an issue that requires consideration. He cites the issue of gay marriage as being a distraction from moral issues such as genocide and poverty. He asks how have we convinced ourself that every culture has a point of view worth considering? . He asks how the ignorance of the Taliban on the topic of physics is any less obvious than on the topic of human well-being. Dan Gilbert gave an insightful TED talk titled Why Are We Happy? [2]. One interesting fact he cites is that people who become paraplegic are no less happy in the long term than people who win the lottery. He points out that a shopping mall full of Zen monks is not going to be particularly profitable and uses this fact to explain the promotion of natural happiness over synthetic happiness in our society. Dan Barber gave an amusing and informative TED talk How I Fell in Love with a Fish [3]. He speaks about ecological fish farming and how the fish are more tasty as well as the farm being good for the environment. The farm in question is in the south-west of Spain, hopefully there will be more similar farms in other parts of the world soon. Gary Lauder gave an interesting brief TED talk about road signs [4]. His main point was to advocate a road sign saying take turns , but there are already signs in the US at freeway on-ramps saying that 1 or 2 cars may enter every time the light turns green which is a similar concept. The innovative thing he did was to estimate the amount of time and petrol wasted by stop signs, add that over a year based on the average income and then estimate that an annuity covering that ongoing expense would cost more than $2,000,000. This makes two stop signs at an intersection have an expense of $1,000,000 each. He suggests that rather than installing stop signs it would be cheaper to buy the adjacent land, chop down all trees, and then sell it again. Alan Siegel gave an insightful TED talk about simplifying legal documents [5]. He gives an example of an IRS document which was analysed with a Heat Map to show which parts confused the readers the IRS adopted a new document that his group designed which made it easier for taxpayers. He advocates legislation to make legal documents easier to understand for customers of financial services. Tim Berners Lee gave an interesting TED talk about Open Data, he illustrated it with some fantastic videos showing how mashups have been used with government data [6] and how the Open Street Map project developed over time. Martin F. Krafft gave an interesting Debconf talk about Tool Adoption Behavior in the Debian project [7]. One thing that I found particularly interesting was his description of the Delphi Method that he used to assemble a panel of experts and gather a consensus of opinion. The post-processing on this talk was very good, in some sections Martin s presentation notes are shown on screen with the video of him in the corner. As an aside, I think we really do need camera-phones. The Big Money has an interesting article comparing the Mafia Bust Out with the practices of US banks [8]. Mark Roth gave an exciting TED talk about using Hydrogen Sulphide to trigger suspended animation [9]. They are now doing human trials for suspending people who have serious injuries to reduce tissue damage during the process of surgery. Pawan Sinha gave an interesting TED talk about how brains learn to see [10]. He started by talking about curing blindness in people who have been blind since birth. But he then ended by showing some research into the correlation between visual processing and Autism, he showed that an Autistic child had significantly different visual patterns when playing Pong to an NT child. Adora Svitak gave an insightful TED talk about what adults can learn from kids [11]. She made some particularly interesting points about the education system requiring that adults respect children more and expect them to do better than their parents which is essential for all progress in society. The NY Times has an interesting article on animal homosexuality [12]. In terms of research it focusses on lesbian relationships between albatrosses. But a large part of the article is devoted to the politics of scientific research into animal sexuality. BrowserShots.org shows you what your web site looks like in different web browsers [13]. Cory Doctorow wrote an insightful article titles Can You Survive a Benevolent Dictatorship about the Apple DRM [14]. He describes the way the Apple Digital Restrictions Management (DRM) doesn t stop copyright violation but does reduce competition in the computer industry. He is not going to sell his work on the Apple store (for the iPad or iPhone etc) and suggests that customers should choose a more open platform. It s unfortunate that he didn t suggest a better platform.

• [1] http://www.ted.com/talks/sam_harris_science_can_show_what_s_right.html
• [2] http://www.ted.com/talks/lang/eng/dan_gilbert_asks_why_are_we_happy.html
• [3] http://www.ted.com/talks/dan_barber_how_i_fell_in_love_with_a_fish.html
• [4] http://www.ted.com/talks/gary_lauder_s_new_traffic_sign_take_turns.html
• [5] http://www.ted.com/talks/alan_siegel_let_s_simplify_legal_jargon.html
• [6] http://www.ted.com/talks/tim_berners_lee_the_year_open_data_went_worldwide.html
• [7] https://penta.debconf.org/dc9_schedule/events/381.en.html
• [8] http://www.thebigmoney.com/articles/money-trail/2010/03/19/bust-out?page=full
• [9] http://www.ted.com/talks/mark_roth_suspended_animation.html
• [10] http://www.ted.com/talks/pawan_sinha_on_how_brains_learn_to_see.html
• [11] http://www.ted.com/talks/adora_svitak.html
• [12] http://www.nytimes.com/2010/04/04/magazine/04animals-t.html
• [13] http://browsershots.org/
• [14] http://www.publishersweekly.com/article/456751-Can_You_Survive_a_Benevolent_Dictatorship_.php

If you re convinced that cloud is a useless buzzword, being used to describe everything under the sun, old and new, then well, you re right that is, except for the useless part. It s true that this word is being (ab)used in many different products, services and technologies, which do not seem to relate to each other in any concrete way. Cloud in the abstract is being defined in many different ways, based on different fundamental characteristics of cloud technology . Nonetheless, there is something genuinely important going on here, and this is my view of what it s about. The hype Countless business which only had web sites or web applications in 2008 now call them cloud services . They aren t delivering any new benefits to their users, and they haven t redesigned their infrastructure. What do they mean by this? Cloud is defined, some say, by where your data is kept, and cloud means storing your data on remote servers instead of internal ones. Millions of Gmail and Flickr users have been in the cloud without even knowing it, and so has everyone who reads their mail over IMAP, or uses voicemail. In short, cloud is just data that is somewhere else. Last September, I watched a presentation on Cloud computing where Symantec pitched their anti-virus product as having something like three different cloud computing technologies. These, it turned out, all involved downloading files over the Internet. In this view, cloud is essentially about the network, derived from our habit of using a drawing of a cloud in our network diagrams for so many years. Wikipedia currently shares this view, as its Cloud computing article opens with Cloud computing is Internet-based computing . No Internet, no cloud. Maybe cloud is just SaaS, and any service provided on a pay-per-use basis over the Internet is a cloud service. It would seem that cloud is about paying for things, especially on a utility basis. The cloud is computing by the hour; it s something you buy. Others maintain that cloud is just virtualization, so if you re using KVM or VMWare, you ve got a cloud already. In this view, cloud is about operating systems, and whether they re running on real or virtual hardware. Cloud means deploying applications as virtual appliances, and creating new servers entirely in software. If your servers only have one OS on them, then they re not cloud-ready. If this vagueness and contradiction irritates you, then you re not alone. It bugs me, and a lot of other people who are getting on with developing, using and providing technology and services. Cloud is not just a new name for these familiar technologies. In fact, it isn t a technology at all. I don t think it even makes sense to categorize technologies as cloud and non-cloud , though some may be more cloudy than others. Nonetheless, there is some meaning and validity in each of these interpretations of cloud. So what is it? A different perspective Cloud is a transition, a trend, a paradigm shift. It isn t something which exists or not: it is happening, and we won t understand its essential nature until it s over. Simon Wardley explains this, in presentation format, much better than I could in this blog post, so if you haven t already, I suggest that you take 14 minutes of your time and go and watch him do his thing. This change doesn t have a clear beginning or an end. Early on, it was a disconnected set of ideas without any identity. We re now somewhere in the middle of the bell curve, with enough insight to give it a name, and sufficient momentum to guess at what happens next. In the end, it will be absorbed into the way things are . What s going on? So, what is actually changing? The key trends I see are:

1. People and organizations are becoming more comfortable relying on resources which do not exist in any particular place. Rather than storing precious metals under our beds, we entrust our finances to banks, which store our data and provide us with services which let us use our money . In computing terms, we re no longer enamored with keeping all of our programs and our data on our hard drive: as it turns out, it s not very safe there after all, and in some ways we can actually exercise more control over programs and data out there than in here . We can no longer hoard our gold, or drive off would-be thieves with a pistol, but that wasn t a productive way to spend our energies anyway. While we can t put our hands on our money, we can know exactly what s happening with it from minute to minute, and use it in a variety of ways at a moment s notice.
2. IT products are ceding ground to services. In many cases, we no longer need to build software, or even buy it: we can simply use it. As computing needs become better understood, and can be met by commodity products, it becomes more feasible to develop services to meet them on-demand. This is why we see a spike in acronyms ending in aaS . Simon explains the progression in detail in his talk, linked above.
3. Hardware, software and data are being reorganized according to new models, in order to provide these services effectively. Architectural patterns, such as hardware/OS/framework/application are giving way to new ones, like hardware/OS/IaaS/OS/PaaS/SaaS/Internet/web browser/OS/hardware . These are still evolving, and the lines between them are blurry. It s a bit early to say what the dominant patterns will be, but system, network, data and application architecture are all being transformed. No single technology or architecture defines cloud, but virtualization (at the infrastructure level) and the web (at the application level) both seem to resonate strongly with cloudy design patterns.

These trends are reinforcing and accelerating each other, driving information technologies and businesses in a common direction. That, in a nutshell, is what cloud is all about. So what? This transformation is disruptive in many different ways, but the angles which most interest me at the moment are:

• Operating systems Cloud seems to indicate further commoditization of operating systems. We will have more operating systems than ever before (thanks to virtualization and IaaS), but we probably won t think about them as much (as in software appliances). I think that the cloud world will want operating systems which are free, standard and highly customizable, which is potentially a great opportunity for Ubuntu and other open systems.
• Software freedom As Eben Moglen and others have pointed out, this trend has significant consequences for the free software movement. As the shape of software changes, our principles of freedom must evolve as well. What does it mean to have the freedom to run a program in the cloud? To copy it? To change it? What other protections might people need in order to exercise these freedoms in the future?
• DevOps I see a strong resonance between cloud which is blurring the lines between hardware and software, infrastructure and applications, network and computer and DevOps, which is bringing together the people who currently work in these different categories. Cloud means that we can no longer afford to treat these elements separately, and must work together to find better approaches to developing and deploying software, knocking down barriers and mapping new territory. Fortunately, cloud also means developing powerful new tools which will power this revolution.
• Clients A majority of cloud related activity seems to be focused on what happens to back-end servers, but what about the computers we actually touch, on our desks, and in our pockets? How will they change? Will we end up reverting to a highly centralized computing model, where clients are strictly limited to front-end user interface processing (e.g. a web browser)? Will clients join the cloud and be providers of computing resources, not only consumers? What new types of devices will we need in order to make the most of cloud?

I d like to explore some of these topics in future posts.

A few People on IRC have ask me to elaborate on my email reading setup. ( As far as hosting I use Google Apps for your domain, but I wont be getting into the details of that. )

First this will work for anyone that uses IMAP to currently fetch their mail, no matter the provider even though I'll be hi-lighting Gmail because thats what I use. This also works well for GMail and/or IMAP Backup of your email.

In short the setup is as follows:
IMAP Server --> offlineimap --> Local Maildir --> Evolution Reading Local Maildir

Soo lets get to the meat of this, first install offlineimap sudo apt-get install offlineimap then lets configure it, below is my config file, most everything should be straight forward (the formating below seems wrong on planet click the post link to copy/paste):
[general] accounts = brandonholtsclaw maxsyncaccounts=1 ui = Noninteractive.Basic metadata=~/.offlineimap [Account brandonholtsclaw] localrepository = gmailLocal remoterepository = gmailRemote [Repository gmailLocal] type = Maildir localfolders = /home/bholtsclaw/.maildir/brandonholtsclaw/ sep = / [Repository gmailRemote] type = Gmail remoteuser = me@brandonholtsclaw.com remotepass=XXXX realdelete = no # This translates folder names such that everything (including your Inbox) # appears in the same folder (named root). #nametrans = lambda foldername: re.sub('\[G.*ail\] ^\.INBOX\.*', '.', re.sub('^', './', foldername)) nametrans = lambda foldername: re.sub('^(\[G.*ail\] INBOX)', '.', foldername) # This excludes some folders from being synced. You will almost # certainly want to exclude 'All Mail', 'Trash', and 'Starred', at # least. Note that offlineimap does NOT honor subscription details. folderfilter = lambda foldername: foldername not in ['[Gmail]/All Mail', '[Gmail]/Trash','[Gmail]/Spam','[Gmail]/Starred']
Save that file as ~/.offlineimaprc and then create the directory ~/.maildir/

Make sure to chmod 0600 ~/.offlineimaprc so because it stores your email password and you dont want anyone else reading that. Other than that you are now all set, just Setup a new email account in Evolution and tell it to use Maildir , point it at your ~/.maildir directory and your golden.

If anyone else uses a setup similar to this and noticed something glaring I missed please drop me a comment, and I'll update the post ( plus I might learn something new ).

Cheers!
P.S. Dont forget to add a crontab to run offlineimap once in a while ( every ~10 minutes ) to check for new mail and sync your local changes back to the IMAP server.

I ve got a bit of a problem. I enjoy writing software. I often write software to solve some sort of problem that I ve had. Usually virtually any code I write winds up in my git repositories, on the theory that it might be useful to someone else. Some of the code that I think might really be useful to people gets even better treatment. OfflineIMAP, for instance, has a very comprehensive manpage, heavily commented example config file, wiki, mailing list, public bug tracker, etc. Most of these I did the majority of the work to create, but OfflineIMAP does occasionally receive code and documentation contributions from others. Now here s my dilemma. For my purposes, OfflineIMAP is, well, finished. It does everything I ever wanted it to do, and does it better than I ever expected it would. There are some people that would like it to do other things; for instance, optimize performance for IMAP folders with 100,000 messages in them, do UTF-8 folder name translation, and retry a sync if a connection is lost rather than crash (OfflineIMAP was designed to crash gracefully and be automated, so this has never bothered me.) None of these are features that I care about, and I don t have much time to devote to OfflineIMAP these days. It is not an interesting problem to me anymore as, well, I ve solved it already. Yet I ll be honest and say I feel guilty about the bug reports that are stacking up in the OfflineIMAP bug tracking system. OfflineIMAP is used by people that have an expectation for improvement. My efforts to hand over maintainership of OfflineIMAP have failed (the people have gone AWOL shortly after agreeing to maintain it). This problem is even more acute for hpodder, my command-line podcatcher. hpodder works great and is simple. But I no longer listen to podcasts. At all. (I blame my Kindle for that.) Therefore I no longer even use hpodder. Again, I feel guilty for not working on it; for instance, when language changes broke its UTF-8 support, I haven t gone in to fix it. Neither has anybody else, for that matter. This leads me to a dilemma. If I do nothing with my code but toss it on git.complete.org, few people will benefit from it. Most people need documentation, packages for their distribution, etc. git repos don t tend to show up highly in search engines. So, although technically I ve shared things with the world by putting them there, practically speaking I haven t done people many favors. On the other hand, if I go the whole responsible maintainer route, writing documentation, wiki, mailing list, Debian packages, etc., then I have the problem of, well, actual users who want actual support. I feel bad if I m not in a position to give it to them. Many people seem to have the expectation that software is never finished and will continue to be improved. (Ah, if only my name were Knuth I might stand a chance to evade that one. But only a chance, given all the TeX spinoffs.) This expectation, in turn, reduces my enthusiasm for publishing my code online as Free Software. Because now I can t just toss it up there and say help yourselves . Now I get angry emails about all the bug reports piling up. On the other hand, I also get occasional small contributions via my PayPal tip jar , which are awesome and motivating. Despite my grumbling, I do continue to maintain OfflineIMAP, primarily as a patch reviewer these days. I take an aggressive stance on quality, and when I get patches that add features without documentation, I usually write documentation for them before committing them. If I have evidence that a patch hurts quality, I yank it (as I had to do with IDLE support, which was a great feature, but the patch caused all sorts of stability problems due to its requirement of imaplib2.py). For that reason, I suspect, forks haven t taken off. So what s a person that writes niche software to do? OfflineIMAP isn t at the level of popularity of something like Gnome, or even debhelper, and never will be; its userbase consists of people that think that IMAP support in $MUA isn t good enough. hpodder is the somewhat small domain of console-loving podcast listeners. What are your suggestions? Should I abolish the bug trackers and just go for simple? Is there something more I could be doing to make the community feel more empowered? Is simple posting on git.complete.org not as bad as I thought?