On Thursday at Secure Con [1] I gave a lecture about SE Linux that went according to plan, and they gave me a nice bottle of Penfolds Shiraz afterwards (thanks to the sponsors). During my lecture I announced my plan to run the hands-on training session over the net. The idea is that the Debian and CentOS images from jailtime.org with minor modifications will be put online somewhere for anyone to download. Anyone can then run the images on their own Xen server, go through the exercises, and ask questions on IRC at the same time. If you are interested in such training then please indicate in a comment what times would be good for the IRC discussion. Note that I’m only available between 7AM and 10PM starts in time zone +1100 (that is 20:00 to 11:00UTC for the starting time), the finishing time would be two hours later - and it would be possible to do the training in multiple sessions. One interesting thing was that at the end the moderator of the session offered a box of lollies to the first person who could tell him my user-name (which was included in ls output on one of the slides). Afterwards I was in idle conversation with some delegates and the topic of the Mac Mini [2] machines came up. Those machines are smaller than the Cobalt Qube (that I have in the past lugged around for portable SE Linux demonstrations), quite powerful (1G of RAM with an 80G hard drive seems to be the minimum for buying new at the moment), and they have keyboard and video ports which is often more convenient than sys-admin by serial port. I am now patiently waiting for Intel-based Mac Mini’s to start selling cheaply on eBay. Such a machine with 1G of RAM would make a nice SE Linux demo machine, I could run at least 7 Xen DomU’s for different users! Of course a second-hand laptop would do just as well, but laptops seem to hold their value better than most other machines. One thing that disappointed me was the small turn-out for the conference dinner. It seemed that as there was a gap in the program between the official end of the conference at 5PM and dinner at 6PM most people decided to go home. One thing to note for future events is that leaving gaps in this way is probably a bad idea. Maybe if they had said “drinks at the restaurant from 5PM and dinner at 6PM” then the turn-out would have been better.

• [1] http://securecon.unimelb.edu.au/


• [2] http://en.wikipedia.org/wiki/Mac_mini

Share This

A few weeks ago, I announced that Debian maintainers of shadow were about to take upstream development over. This has now happened and, after final cleaning work (90% by Nicolas Fran ois and 10% by /me), we released shadow 4.0.18.2 which is just a simple take-over of the package, with inclusion of the trivial patches we had in the Debian package. Immediately after, the Debian package was uploaded (release name "Vacherin", to continue our tradition of naming releases of the Debian package from French cheese names) and we're now officially in charge of this software which is used by several Linux distros. The main contact point for shadow maintenance is the pkg-shadow-devel mailing list on Alioth.

Up until recently, I’ve been supporting John Connolly as candidate for city council. In addition to the recent concerns about anonymous mailings, I’m now getting hammered by his auto-dialer. I’ve received four prerecorded phone calls today and yesterday reminding me to vote for Connolly. (By contrast, I got one real human phone call from a Michael Flaherty supporter.) Now with a few hours left to vote, I’m on the fence. I wish this guy would leave me alone. In the meantime, a WBUR interview claims that Felix Arroyo is the most vulnerable candidate (something I’ve never heard elsewhere). If that’s the case, I’m tempted to just bullet-vote for Felix. I hope this last-minute vacillation doesn’t make me an idgit voter. 5pm update: three more automated phone calls! One for Murphy from Consalvo; and two for Connolly (one from Tobin, the other I forget). They’re pulling out all the stops, only at the last minute. I wonder who the dismal weather (and poor turnout) favors. 7pm update: three or four more calls, now including real humans! My wife figured out part of the reason we’re getting so many — separate calls each for her and me, even though it’s all on the same phone number. In any case, we’ve all voted now. I did end up including Connolly in my votes despite these over-the-top tactics. I guess it shows, at least, that he’s well organized. Technorati Tags: Boston, City Council, Felix Arroyo, John Connolly

Share This

One of the things I have been tasked to do in my current assignment is to create a dashboard of the status of various software components created by different contractors (participating companies) in the program. These software components are built by different development groups, utilizing unlike toolsets, languages and tools though I was able to get an agreement on the VCS (subversion yuck). Specifically, one should be able to tell which components pass pre-build checks, compile, can be installed, and pass unit and functional tests. There should be nightly builds, as well as builds whenever someone checks in code on the release branches. And, of course, the dashboard should be HTTP accessible, and be bright and, of course, shiny. My requirements were that since the whole project is not Java, there should be no dependencies on maven or ant or eclipse projects (or make, for that matter); that it should be able to do builds on multiple machines (license constraints restrict some software to Solaris or Windows), not suck up too much time from my real job (this is a service, if it is working well, you get no credit, if it fails, you are on the hot seat). And it should be something I can easily debug, so no esoteric languages (APL, haskell and Python :P) So, using continuous integration as a google search term, I found the comparison matrix at Damage Control I looked at anthill, and cruisecontrol, and the major drawback people seemed to think it had was that configuration was done by editing an XML file, as opposed to a (by some accounts, buggy) UI is not much of a factor for me. (See this). I also like the fact that it seems easier to plug in other components. I am uncomfortable with free software that has a commercial sibling; we have been burned once by UML software with those characteristics. Cruisecontrol, Damagecontrol, Tinderbox1 & tinderbox2, Continuum, and Sin match. I tried to see the demo versions; Sin s link led me to a site selling Myrtle Beach condo s, never a good sign. Continuum and Damagecontrol were currently down, so I could not do an evaluation. So, here are the ones I could get to with working demo pages: http://cclive.thoughtworks.com/ and http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey Cruisecontrol takes full control, checking things out of source control; and running the tests; which implies that all the software does build and run on the same machine this is not the case for me. Also, CC needs to publish the results/logs in XML; which seems to be a good fit for the java world; but might be a constraint for my use case. I like the tinderbox dashboard better, based on the information presented; but that is not a major issue. It also might be better suited for a distributed, open source development model; cruisecontrol seems slightly more centralized more on this below. cruisecontrol is certainly more mature; and we have some experience with it. Tinderbox has a client/server model, and communicates via EMAIL to a number of machines where the actual build/testing is done. This seems good. Then there is flamebox nice dashboard, derivative of tinderbox2; and seems pretty simple (perhaps too simple); and easily modifiable. However, none of these seemed right. There was too much of an assumption of a build and test model and few of them seemed to be a good fit for a distributed, Grid-based software development; so I continued looking. . I finally decided CABIE

Continuous Automated Build and Integration Environment. Cabie is a multi-platform, multi-cm client/server based application providing both command line and web-based access to real time build monitoring and execution information. Cabie builds jobs based upon configuration information stored in MySQL and will support virtually any build that can be called from the command line. Cabie provides a centralized collection point for all builds providing web based dynamic access, the collector is SQL based and provides information for all projects under Cabie s control. Cabie can be integrated with bug tracking systems and test systems with some effort depending on the complexity of those systems. With the idea in mind that most companies create build systems from the ground up, Cabie was designed to not have to re-write scripted builds but instead to integrate existing build scripts into a smart collector. Cabie provides rapid email notification and RSS integration to quickly handle build issues. Cabie provides the ability to run builds in parallel, series, to poll jobs or to allow the use of scripted nightly builds. Cabie is perfect for agile development in an environment that requires multiple languages and tools. Cabie supports Perforce, Subversion and CVS. The use of a backend broker allows anyone with perl skills to write support for additional CM systems.

The nice people at Yo Linux have provided a Tutorial for the process. I did have to make some changes to get things working (mostly in line with the changes recommended in the tutorial, but not exactly the same. I have sent the patches upstream, but upstream is not sure how much of it they can use, since there has been major progress since the last release. The upstream is nice and responsive, and have added support in unreleased versions for using virtual machines to run the builds in (they use that to do the solaris/windows builds), improved the web interface using (shudder) PHP, and and all kinds of neat stuff.

Over one year ago, still at DebConf 6, the Latin American Debian people (and by people I mean just interested people, regardless of whether they were/are official DDs or not) held a BoF session. One of the ideas we discussed there was that, in order to increase Debian presence in our region (which is by no means small - Let alone the geographical aspects, I'm guessing we are about 350 million people, roughly split in half between [officially] Spanish- and Portuguese- speaking countries). Yet, this is an area with very little involvement in Debian in particular, and with Free Software in general.One of our first issues seems to be language - Just by its scale and economic importance, we cannot even put in the same scale Brazil and the Spanish-speaking countries... So I'll focus on Spanish-speaking Latin America, as (I recall) we did in that session.So, we agree: We need more local involvement in each of our communities. And, so far, we have seen quite relevant results. The number of people directly involved in Debian in Argentina, Chile, Per , Colombia, Venezuela, El Salvador and Mexico (excuse me if I forget you in another country!) has notably risen since I brought this topic up, together with Christian Perrier, back in DebConf5, Helsinki. An undeniable fact is that distances in our continent, however, are huge. In the 2006 BoF, we agreed we should promote regional meetings, that would serve both for working focused on Debian topics (i.e. hack sessions, as we do in DebConf) and for spreading our work to the local population, to help them see that it is not needed to be super-skilled or anything like that to contribute to a real, important and large Free Software project such as ours. Of course, taking into account the distances in the continent, we thought it would be sensible to split it in two - and to try and hold regional mini-debconfs - One for the Northern half (i.e. Per , Ecuador, Colombia, Venezuela, Central America, Cuba and Mexico), and one for the Southern half (Bolivia, Chile, Argentina, Uruguay, Paraguay). And, for logistical reasons mainly, I strongly advocated having our first Northern meeting in Panam . Why Panam ? Because it is a place cheap and easy to get to. They have a very important international airport, connecting to most if not all countries in the region, and -as they have risen as a business center- have good connectivity. Visa is required for many of the interested countries, but trivial to get (as opposed to what happened here in Mexico :-( ). Of course, other countries also looked interesting (there was some argument pushing Venezuela, but in the end, we all conceded it would be in Panam .I have to strongly thank Guillermo Garc a - He is not (yet? :) I hope he still wants to get involved with this bunch of people) in Debian in any way, but after I contacted him, he agreed to start looking for a way to get us the right facilities in Panam . He coordinated with a team which did most of the organization - A very nice web site is still available so you can look at their work - Quite a good job, I must add.They contacted Universidad Tecnol gica de Panam , started talking with several potential sponsors, got information regarding hotels for us... But in the end, it flopped. Why? Because, although many of us were originally interested, in the end very few people (only three, none of them officially a Debian Developer, according to their last press release) confirmed their intention to attend.Which brings me again to the question: Why?First and foremost, I think it was lack of involvement. For one reason or another, all of the people that in the beginning pushed for this miniDebConf ended up busy doing other stuff, and didn't get at all involved in organization. It would have been a great present from our Panaman friends, yes, but quite unfair. And, of course, with no Debian people involved in organizing it, we got an chicken-and-eggesque situation... Where it didn't grab the attention of other Debian people.Second, what they offered us was quite different to what we intended in the first place - At least, to what I imagined. On my first messages both to debian-devel-spanish and to Guillermo, I tried to get something close to what we had in mind: Something as informal and as intimate as it could be. My original request to Guillermo was just to get us a room where we could hack and talk, and probably sleep with sleeping bags.Of course, I can perfectly imagine that when he requested the space to the university, on one hand, they didn't feel at ease having International Guests (with capital I and G - Very important for most Latin American universities!) sleeping on the floor. And, on the other hand, they would love to be able to show us around! Having an international project focus on a university in a non-technologically-well-known little country is quite something to show off!Anyway... What happened? I was among the instigators, but Real Life called me away (I've been mostly inactive in Debian since September! :-( ). The miniconf was scheduled for November 14-17. I also insisted originally on having the miniconf on a long weekend (say, Friday through Sunday), as -being a miniconf and not the Real Deal- it'd be much easier for most of us to rob one day off work than a full week. In the end, this was the most important point for my decision not to join: I cannot afford more time off my work, not at this time of year. About the other involved people? I do not want to speak for any other people.In the end, sadly, Guillermo had to inform us they cancelled - No, not postponed, but definitively cancelled. Why? Because -and I have to agree- next year we will have DebConf in Argentina... And many people in the region will focus our time and money on getting there. Ok, making this whole story short: I'm very, very ashamed and sorry, with you personally, Guillermo, and with your whole team. And I hope we can resurrect this idea - be it in Venezuela (as it was suggested once) or elsewhere.

I had somehow managed to miss out on The White Company while I was growing up and devouring all of Sherlock Holmes stories and The Lost World. This is a pity, since I would have like this bit of the hundred years war much better when I was young and uncritical. Oh, I do like the book. The pacing is fast, if somewhat predictable. The book is well researched, and leads you from one historic event to the other, and is peppered with all kinds of historical figures, and I believe it to be quite authentic in it s period settings. Unfortunately, there is very little character development, and though the characters are deftly sketched, they all lack depth, which would not have bothered the young me. Also, Sir John Hawkwood, of the white company, is mentioned only briefly in passing. This compares less favourably than Walter Scott s Quentin Durward, set in a period less than 80 years in the future. but then, I ve always have had a weakness for Scott. As for Conan Doyle, the lost world was far more gripping. I am now looking for books about Hawkwood, a mercenary captain mentioned in this book, as well as Dickson s Childe Cycle books. The only books I have found so far on the golden age of the Condottieri are so darned expensive.

Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues. GnuTLS is the “clearer” solution from a license point of view: The client library is LGPL, and it can thus be safely linked to everything that is part of Debian main. This is the main reason why we decided to use GnuTLS for exim4 years ago, so that we do not need to worry about licensing issues when some other library is linked to by exim some time in the future. On the other hand, my impression gets stronger and stronger that GnuTLS is not ready for prime-time. There is a truckload of interoperability problems with a number of “remote sides”. The most prominent issues are TLS aborts when exim4 is SMTP server for some clients, most notably Incredimail and some mobile Phones from Nokia and other vendors. Most of them can be nailed down to misnegotiation of certain ciphers, but exim does currently not allow disabling of some ciphers at run-time, and - even worse - one would need to disable them completely since one cannot judge in advance whether we are facing a client with issues or one without. The GnuTLS maintainers of both Debian and upstream try being helpful, but I do not see a long-term solution here. Additionally, nobody upstream knows its way around the GnuTLS related code in exim, which was contributed by Nikos Mavroyanopoulos years ago. So, there is little chance to get GnuTLS-related bugs ironed out from exim. OpenSSL, on the other hand, does not have these interoperability issues. At least, I haven’t heard of any, and the recommended fix for the reporters of GnuTLS related bugs, “recompile exim with OpenSSL” (which the packaging has been supporting for nearly two years now), usually fixes their problems. I am not in a position to judge whether this is caused by people actually testing against OpenSSL, or OpenSSL generally being more tolerant towards strange implementations, or GnuTLS being buggy or poorly written. However, building exim4 again OpenSSL may post the license issues that convinced us to use GnuTLS in the first place. Exim itself has an OpenSSL exception, and from what I have been told, the MySQL FLOSS License Exception allows linkage to OpenSSL as well. At least, it does now, since historical evidence in the exim4 package either shows that it used to be a license violation to link MySQL and OpenSSL in the past, or that we (the Debian exim4 team) wrongly thought so. On the other hand, if it is illegal to have OpenSSL and “really” GPLled code in the same execution space, we already have that license violation today, brought to us by PostgreSQL, which links against OpenSSL. ftpmaster has already indicated that they won’t consider an exim4 linked against OpenSSL a license violation and that the packages would go through, the packaging can handle the change by virtue of flipping a switch and rebuilding, but I am still not fully convinced that doing so is the right thing from a political and license point of view. I might still need that final nudge by feedback to this blog article, or have my reluctance fed. Please comment. No, I do not plan to take this to debian-legal; I’d prefer exim4 staying in Debian main.

A few weeks ago, I announced that Debian maintainers of shadow were about to take upstream development over. This has now happened and, after final cleaning work (90% by Nicolas Fran ois and 10% by /me), we released shadow 4.0.18.2 which is just a simple take-over of the package, with inclusion of the trivial patches we had in the Debian package. Immediately after, the Debian package was uploaded (release name "Vacherin", to continue our tradition of naming releases of the Debian package from French cheese names) and we're now officially in charge of this software which is used by several Linux distros. The main contact point for shadow maintenance is the pkg-shadow-devel mailing list on Alioth.

I have just read an interesting article titled Why Crunch Mode Doesn’t Work [1] which documents the research on efficiency vs amount of time spent working (and by inference amount of time spent on leisure activities and sleep). It shows that a 40 hour working week was chosen by people who run factories (such as Henry Ford) not due to being nice for the workers but due to the costs of inefficient work practices and errors that damage products and equipment. Now these results can only be an indication of what works best by today’s standards. The military research is good but only military organisations get to control workers to that degree (few organisations try to control how much sleep their workers get or are even legally permitted to do so), companies can only give their employees appropriate amounts of spare time to get enough sleep and hope for the best. Much of the research dates from 80+ years ago. I suspect that modern living conditions where every house has electric lights and entertainment devices such as a TV to encourage staying awake longer during the night will change things, as would ubiquitous personal transport by car. It could be that for modern factory workers the optimum amount of work is not 40 hours a week, it could be as little as 30 or as much as 50 (at a guess). Also the type of work being done certainly changes things. The article notes that mental tasks are affected more than physical tasks by lack of sleep (in terms of the consequences of being over-tired), but no mention is made about whether the optimum working hours change. If the optimum amount of work in a factory is 40 hours per week might the optimum for a highly intellectual task such as computer programming be less, perhaps 35 or 30? The next factor is the issue of team-work. In an assembly-line it’s impossible to have one person finish work early while the rest keep working, so the limit will be based on the worker who can handle the least hours. Determining which individuals will work more slowly when they work longer hours is possible (but it would be illegal to refuse to hire such people in many jurisdictions) and determining which individuals might be more likely to cause industrial accidents may be impossible. So it seems to me that the potential for each employee to work their optimal hours is much greater in the computer industry than in most sectors. I have heard a single anecdote of an employee who determined that their best efficiency came from 5 hours work a day and arranged with their manager to work 25 hours a week, apart from that I have not heard any reports of anyone trying to tailor the working hours to the worker. Some obvious differences in capacity for working long hours without losing productivity seem related to age and general health, obligations outside work (EG looking after children or sick relatives), and enjoyment of work (the greater the amount of work time that can be regarded as “fun” the less requirement there would be for recreation time outside work). It seems likely to me that parts of the computer industry that are closely related to free software development could have longer hours worked due to the overlap between recreation and paid work. If the amount of time spent working was to vary according to the capacity of each worker then the company structures for management and pay would need to change. Probably the first step towards this would be to try to pay employees according to the amount of work that they do, one problem with this is the fact that managers are traditionally considered to be superior to workers and therefore inherently worthy of more pay. As long as the pay of engineers is restricted to less than the pay of middle-managers the range between the lowest and highest salaries among programmers is going to be a factor of at most five or six, while the productivity difference between the least and most skilled programmers will be a factor of 20 for some boring work and more than 10,000 for more challenging work (assuming that the junior programmer can even understand the task). I don’t expect that a skillful programmer will get a salary of $10,000,000 any time soon (even though it would be a bargain compared to the number of junior programmers needed to do the same work), but a salary in excess of $250,000 would be reasonable. If pay was based on the quality and quantity of work done (which as the article mentions is difficult to assess) then workers would have an incentive to do what is necessary to improve their work - and with some guidance from HR could adjust their working hours accordingly. Another factor that needs to be considered is that ideally the number of working hours would vary according to the life situation of the worker. Having a child probably decreases the work capacity for the next 8 years or so. These are just some ideas, please read the article for the background research. I’m going to bed now. ;)

• [1] http://www.igda.org/articles/erobinson_crunch.php

Share This

After two weeks of testing, I'd like to announce Czech pages about phpMyAdmin - http://phpmyadmin.cz/. You will find there various tips and howtos for using phpMyAdmin as well as project and development news. I'd like to build there a community where people could find help about this tool in their native language, but I have no idea whether it has a chance to succeed. Anyway the domain name was cheap so I had to try to realize idea, which was sitting in my head for quite a long time.

Yesterday I received an unsigned notice in the mail from some residents of an area comprising my street and an adjacent one. They advised me that their children were going to do the Halloween thing and that if I wanted to be involved I should leave my porch light on. This is a really good idea, people who like that sort of thing can leave their light on and give lollies to children (whatever happened to “don’t take lollies from strangers”?). People who don’t like pagan festivals can leave their porch light off and not be bothered. One thing that occurred to me is that the anonymous flyer might have been posted by someone who doesn’t like Halloween to provide a way for themselves and like-minded people to opt-out of it. I’m sure that everyone told their children not to knock on a door unless there is a porch light on. It’s almost 10PM and no-one has rung my doorbell, it seems to have worked.

Share This

Even though Adrian von Bidder suggests that I'm starting a bit early with the DPL campaigning, I thought I could add a few more thoughts to the blagosphere.

Adrian suggested to make the discussion of our of "vision of Debian" a regular event on debconf - I think it's a nice idea, but that doesn't mean we should keep silent about that topic the rest of the year. I think one of the problems we see in Debian is that we are missing an aim to strive for. We are currently just moving from release to release, while more and more developers have actually lost interest in stable releases. The impression that a common ground like Debian 4.0 is irrelevant seems to prevail, because the people most vocal in our user base usually want to see the newest and shiniest software on their desktop. We have been spending more and more effort to cater to their wishes and have ignored the fact that a majority of Debian-based installations are not run by such people, but by system administrators who do mass roll-outs and neither want nor need the newest X.org with more *bling*.

Ubuntu, the biggest Debian-based distribution, has found its users by packing up new software behind a nice installer, adding some branding elements and then shipping it. Stability is an issue for Ubuntu, but they don't spend as much time as we do on eliminating the last seemingly important bug in some esoteric software package before actually releasing. That observation is the ground for one of my ideas: Our current metric to determine how far testing is away from a release is counting the number of rc bugs - it doesn't matter if the rc bug is X.org crashing for all people or if it is a policy violation in a package with 12 users. Perhaps we should start thinking about a new metric, keeping in mind that for a majority of users, some bugs matter a lot and some matter not at all. With the release of etch, the number of installations of popcon has risen a lot, so for the first time, we have actual usage data that could help us with such a metric. There are a few problems with that approach, though:

• Popcon data is inherently wrong, because single computer installations tend to have popcon, while large installations (like the one in Extremadura) don't.
• A majority of popcon users uses the last stable release, not the one currently in development.
• 3 bugs in packages seldomly used can be more annoying for our users than one central bug - you might be able to find a work around somewhere for something that happens to a lot of people, but a bug only hitting a few users will stay unfixed for a long time.

I don't have more time right now, so the rest of my ideas will follow in the next few days, so stay tuned or add me to your killfile.

I am running a tutorial and giving a talk about SE Linux at SecureCon 2007 [1]. The tutorial will go for 3 hours on Wednesday the 7th of November and will cover using SE Linux in CentOS 5 and Debian Etch, it will be a hands-on tutorial where every delegate gets ssh access to their own Xen DomU. The lecture is on Thursday the 8th of November and will be a 45 minute talk with an overview of SE Linux. It will be similar to my speech at the AUUG conference [2] but probably cover more of the features. The AUUG talk was driven by questions from the audience to spend a lot of time justifying SE Linux design decisions which took time away from other materiel. This wasn’t inherently a problem (I provided the information the audience seemed to want and everyone seemed happy), but I would like to cover more of the features and new developments.

• [1] http://securecon.unimelb.edu.au/


• [2] http://etbe.coker.com.au/2007/10/14/auug-2007/

Share This

It's this time of the year again: The one where I look back at my involvement in the project and decide that I've been a member long enough, so I should probably get out. For Debian, there are two ways to do it: Either become MIA or become DPL. As I have too many real life connections to other DDs, I guess I can't really do the MIA thing, so I should probably get elected as DPL. Whenever I consider this way out, I think about all the issues that make me unhappy about Debian. This time, I've written them down. So, here's a list of things I would like to see and would work on if I had the power to do so:

• Enforce addition of new architectures to the main archive. This includes kfreebsd-* and hurd-* - after all, we claim to be the universal OS. I've sometimes heard that our ftp mirrors wouldn't be able to handle the increased archive size - I don't believe that. We had the mirror split to work around this, not everyone is forced to mirror all architectures anymore. If actual Debian hardware should be a problem, we should use the money we collect to get the hardware we need.


• Make backports.org official, just like volatile. This doesn't mean kicking out the current team and give the responsibility for bpo to the dysfunctional ftp-team, but simply move the service as it is into Debian. A start for that would be to add backports.debian.org as CNAME for backports.org and then add fitting hints to our release notes.


• Resurrect the practice of porting machines. In ancient times, Debian had all kinds of machines available to all developers so that they could log in and debug architecture-specific porting problems. Nowadays, Debian collects hardware, Debian's hardware collects dust and Debian's BTS collects porting bugs. At the moment, most of these machines are not available to the developer body and access is granted to only a handful of persons besides DSA.


• Fix the constitution, so that the ftp-team, the account managers, the buildd admins, the system administrators and all other teams that currently don't see themselves as delegates of the DPL can in some way be changed when they are not doing their job. There is currently a GR for that in preparation, see the excellent proposal from Josip Rodin for more information. When that is done, we can turn to actually fixing those teams, starting by giving full permissions to active people that currently have only restricted access (ie Joerg Jaspert should be able to modify the LDAP holding Debian's account data and should also get to act as full ftp-master, not only -assistant). There are also quite a few people experienced with the tasks of the other teams, so we should add some of these people soonish.


• [Not really depending on DPL super cow powers:] Work on half-releases, like etch + 1/2. Besides adding a newer kernel for hardware support and updating the installer, we could think about adding backports packages to update desktop stuff. Many people seem to be interested in that.

Besides those things that I really miss in Debian, there are also a few things I would simply like to see done in the near future:

• Add more buildd admins.


• Resolve our conflicts with the FSF, get them to accept that we don't like the GFDL and then go on with lobbying for free software.


• Improve our appearance on conferences by creating common Debian material. This means creating "official" ISO images for DVDs from time to time (just like they are done by people for a specific conference from time to time), creating official information material that can be translated by the l10n teams, discuss guidelines for the people behind the booth (like "Please don't wear a shirt which allows visitors to see what you've eaten in the last week") and give advice for presentations.


• Clean up the DD list, so that we stop telling people that there are ~1000 DDs if only ~600 actually work on Debian. Yes, work on that is already on the way.


• Create a place (a ML, wiki page, pseudo package) where Debian people can simply drop interesting ideas. Often, busy developers have great ideas for new projects, but lack the time to actually implement them. Usually, the inside knowledge is only needed to conceive the idea, not to implement it, so we should have a place where people with free time at their hands can find great ideas. It shouldn't be needed to actually describe every detail of your idea, it should be more like "Wouldn't it be cool to collect all left socks and then get to world domination by tying them together?". This could also be the basis for a bounty system (and of course for the GSoC people)


• dpkg development - symbol-based shlibs look almost ready, but what happened to Wig&Pen alias dpkg-source v2?


• At some point, we should discuss our vision of Debian. I guess we won't find a common one, but it would be interesting to see where people want to see Debian in 5 (or 10) years. Should we "just" be a supermarket so that CDDs and forks can be based on us? Should we work on reintegrating all those efforts into Debian proper? Is that even possible?


• We should create a team (or, preferably, a DPL delegate) whose sole task is to communicate with the rest of the Debian ecosystem, so that common problems can be noticed, discussed and solved. I have to admit that I have lost track and couldn't say how many distributions are using Debian as their basis nowadays, but there seem to be quite a lot. I wish for a place where I can find such information (or at least a person who I can ask about it).

So, what do you think? Are all of those ideas crap or should we perhaps try to implement them? Have I missed something important?

I have just read Career Development for Geeks [1] by Erik de Castro Lopo [2]. It makes some interesting points about a traditional approach to an IT career. The path I followed for most of my career (after I had a few years experience) was to work as a contractor and happily leave jobs without having anything else lined up. Erik suggests getting Engineers rather than managers to give references, it’s an interesting idea. Engineers can give better references about quality of work, while managers can speak on behalf of their employer (in theory). In practice a sane manager won’t give a bad review for legal reasons so the value of a reference from a manager is probably limited. Of course one problem with reviews is that I have never heard of a recruiting agent or employer actually verifying the ID of a reference. I could be listed on a friend’s CV as a senior manager in a multi-national company (which doesn’t have a major Australian presence) and give a good review and it seems unlikely that the typical recruiter would work it out. For someone with plenty of spare time and no significant assets (no risk of being sued) it could be entertaining to apply for a bunch of positions that they are not qualified for with friends using pre-paid mobile phones to give references. This could be done as a documentary on corporate hiring practices, or to simply try and get the highest paid job possible. Based on observing some former colleagues it seems that little skill is required to get a job and that when people do really badly they get paid for at least a few months. I am constantly amazed when reading reports about so-called “con artists” who commit crimes for what are often small amounts of money. Getting an income significantly greater than average without knowing anything about how to do the work is very common and is never treated as fraud (the classic example was a former colleague who wanted to write his own encryption algorithm but who didn’t even know about binary and therefore couldn’t use operations such as XOR). Erik’s main suggestion for dealing with recruiting agents is to talk about projet management issues (recruiters don’t understand technology). My way of dealing with them has been to assure them that I know it all and tell them to forward my CV to the client. Another suggestion is to learn new skills and diversify your skills. I don’t supoprt this because I believe that the majority of people who read my blog are significantly more skillful than the typical programmer. If an area of technology starts to go out of fashion then it’s the people with the least skills who suffer the most. If you are good at your work and enjoy it then it shouldn’t matter much if people around you are being laid off. Of course to rely on this you have to be working in a reasonably large field. For example if you develop software in a language which has hundreds of programmers then you may be at risk, but if there are tens of thousands of programmers using the language then you only need to be in the most skillful 10% to be assured of employment for the next decade or two. That said there are benefits to moving around, meeting new people, and working on new contracts. One thing you don’t want is to have 10 years of experience which are the same year repeated 10 times! Update: Here is a paper Erik submitted to OSDC on the same topic [3]. Mostly the advice is the same but with more detail and in a better format for reading.

• [1] http://www.mega-nerd.com/Career-dev/career-dev.pdf


• [2] http://www.mega-nerd.com/erikd/Blog


• [3] http://www.mega-nerd.com/erikd/cddg.pdf

Share This

First the good thing: I updated wordpress to 2.3. Now the bad thing: I updated wordpress to 2.3. With 2.3 there where many infrastructure changes. For a complete list, see the Release Announcement. The most extensions breaking change was the implementation of native tag support. Referencing to Not working Plugin List Ultimate Tag Warrior and Extended Live Archives are problematic. Both caused troubles on update, but there is a fix for ELA and one for UTW. By reviewing the informations for writing this articel, I noticed that I’m running fine with the Ultimate Tag Warrior Bugfix Release provided by Christine from the Internet.
My theme K2 was needing also an update, which caused the style to be broken. So waiting for a fix did take little longer, but when reviewing it, I noticed that only a css class name did need an update.
This all teaches me, when using a project with much depencies, it will be a mess when updating, as long as isn’t all provided by one source. It’s some kind of using a project “still in development”.
Update: While we are at “still in development” .. I updated to 2.3.1-RC1 some seconds ago. :)