As it looks like blogging is now the preferred way of sharing your thoughts, I guess I'll have to answer in my own blog to the problems starting with Thomas Hood post about withdrawing from the NM process.

Some people have replied to this and I think I should present my position, as I'm the most active of the unresponsive NM Front Desk, yaddayaddayadda.

Until Thomas blogged, I did not know that he considered the missing report as an issue.

To clear up the situation: Thomas completed all stages of the AM checks after he was reassigned to Alexander (formorer) this spring.
When Alex wanted to prepare the reported, he noted that some mails from the conversation between Madkiss (the old AM) and Thomas were missing. No problem, FD to the rescue, I still had those mails in my archive. After these initial problems, Alex' daytime job needed a lot of attention, so he didn't write the application report. I kicked him on a regular basis to do so, but it needs time and is not really very interesting, so it got delayed.

OK, that delay is not a good thing, but Alex told me that he planned to do the report on Saturday. Yes, this delay is quite annoying if you worked so hard and always had to wait for your AM to check your stuff and blabla. Now, the problem I have is that in this case, it's simply not true. Madkiss was assigned as AM to Thomas for 18 months - of these 18 months, 15 were spent waiting on a reply from Thomas to the usual NM questions.

Thomas, I can understand if you don't like the templates and think that they're boring, useless and whatever. But don't blame other people for time you have lost.

A brief case study in a flamewar diverted. The release managers are currently preparing a followup to the architecture requalification, following the efforts made over the past couple of months. Four ports are currently looking shaky, namely m68k, arm, s390 and sparc. An early draft begins going into the details by saying the following:

ARM has been borderline on a lot of the criteria, which we were willing to consider waiving; but there are two points in particular which we aren’t willing to waive. First is that the porting machine for arm, debussy.debian.org, has been off-line now for a number of months, and a replacement machine has not yet been activated by DSA. […]

Even without the already existing tensions on debian-devel and elsewhere, I’d expect the RM posting the above to the developers announcement list to immediately result in hue and cry about DSA trying to kill arm and how unfair and inappropriate that was. And I can’t even say that’d be unreasonable. OTOH, I can say it would’ve been unjustified, enough so that the above won’t actually make it out to -devel-announce. Why? Read on past the fold. Read the rest ...

 Anyway, I think Portugal is not, at all, a small team, and I think, on group D, is the one that we have to pay more attention. Iran qualified as the 3rd out of 4 on the Asian seats, and we cannot minimize them, neither. And Angola qualified as the first of their group on the African zone; they made 21 points, just behind Côte d'Ivoire. Group D is a hard group, yes it is. In case Mexico qualifies to the second stage, the 1st and 2nd place of group D would go against 2nd and 1st places (respectively) of group C, where I, personally, fear Argentina :) Go Mexico! :) 

I got an e-mail yesterday evening with a link to this article at the Atlantic Monthly: If America Left Iraq: The Case for Cutting and Running by Nir Rosen. This article does a good job of explaining what just about everybody else has failed to do: why leaving Iraq now actually does more towards building a stable, free, and peaceful Iraq than keeping our military there does. (And does less to embolden terrorists.)

At the end of an interesting piece on permissions, Joey Hess concludes:

I could give many more examples of subsystems in Debian that exist at different point in the spectrum between locked down unix permissions and a wiki. There seems to be a definite pull toward moving away from unix permissions, once ways can be found to do so that are secure or that allow bad changes to be reverted (and blame properly assigned). Cases of moving in the other direction are rare (one case of this is the further locking down of the Debian archive server and BTS server after the server compromise last year).

I think Joey’s focus on “unix permissions” is a bit misleading; you could make the same argument more generally by talking about permissive and restrictive regimes. Permissive systems have the obvious risk of vandalism in various forms, whether deliberate and malicious like adding false information to wikipedia, or well-intentioned contributions that are low quality due to simple ignorance or carelessness. On the other hand restrictive systems have the somewhat subtler risks that good contributions will be turned away because the restrictions are more effort than they’re worth, and that the time it takes to administer the restrictions start detracting from the time to actually do the work in the first place. So obviously there’s a tradeoff. But as well as that, there are ways of easing both risks: the risk of vandalism can be overcome if the stuff isn’t relied upon too heavily and can be changed relatively easily – so problems in unstable aren’t much of an issue since they can be fixed in a day, and don’t affect people running mission-critical systems because they should be using stable or testing or similar. Likewise, managing restrictions can be distributed too: the new-maintainer process is a good example of that, in that a range of people are involved in helping people pass through the qualification round, and in that sponsorship allows people who haven’t passed through the main lot of restrictions to get their contributions in by going through a different process. One interesting approach, to my mind, is worrying less about permissions and more about space – so that different people with different ideas on how to do things can do them independently. That’s part of the idea behind usertags and usercategories: rather than having people try to find an imperfect compromise, let them work on the same stuff in the way they actually prefer. That reduces the risk of carelessness, in that you stop having any reason to bother other people, and also reduces the problem of restrictions, in that if you don’t have permission to work in someone else’s area, you can just setup your own area and work there. Perhaps the worst problem is if the drawbacks feed on each other: a restrictive system turns away contributions, which causes prospective contributors to get frustrated and hence careless, which then reinforces the reasons that the restrictions were put their in the first place and diminishes the chance they’ll be reconsidered. That’s a hard cycle to break, but it’s not one where anyone really wins. I’ll leave the last word to Joey:

Anyway, the point of this is that, if you survey the parts of dealing with the project where Debian developers feel most helpless and unempowered, the parts that are over and over again the subject of heated discussions and complaints, you will find that those are the parts of the project where unix permissions still hold sway. […] The challenge, then is to find ways to open things up to everyone, without throwing security out the window. It has to be done a piece at time, and some of the pieces that are left are the ones most resistant to this change.

In Debian, we work on developing a unix-style operating system, and when the project was getting started, the obvious way to deal with delegating powers to various people was naturaly to use standard unix permmissions on our master server. So the list administrators were the only people who could write to the list configs and archives, the BTS admins were the only ones who could write to the BTS, the archive admins were the only ones who could manipulate the archive, the build daemon admins were the only ones who could modify various bits of that stuff, etc. As time went on, these services were split off to seprate machines and in some cases access to the machine running a service was limited to the maintainers of that service, again in a way that would be familiar to unix admins everywhere. But as time went on and things like revision control systems became available, Debian also began to make some choices that didn't involve unix permission or host based security. The best example of this is the Debian bug tracking system, which allows anyone to manipulate any bug status in any way without any authentication at all. It works because the BTS keeps a record of all changes, and informs interested parties about changes, so vandalism or accidents can be reverted. Aside from spam, vandalism in the BTS is such a rare problem that I cannot think of an example. Thus the Debin BTS partakes somewhat of the WikiNature, although it predates the wiki by a long time. The archive itself only uses unix permissions at its core, while the upper layers do not partake of them: Any maintainer can upload any package and superscede data in the archive automatically, although actual unix write permissions are very limited. The archive administrators use archives of old versions of packages, automated checks, and forced manual review of certian classes of packages (such as NEW) to limit this so that Developers don't make messes. Social norms are used to avoid other problems. The Debian website is in an interesting period in its history. It's been maintained in a way that mostly avoids unix permissions for a long time, by keeping it in CVS and building it automatically. However, for reasons that I suspect have never been adequately explored, not all Debian developers can commit, you have to be in the webwml group. Though gaining access to the webwml groupo is trivial for any Debian developer. But the most interesting thing is that Debian now also has an official wiki, which is open to editing by all, and that increasingly it is used for at least the more fluid and development-based website stuff. For example, the debian-installer home page is a thin stub giving the essential information and links, and mostly linking to the wiki for the rest. The debian-installer project itself occupys another point on the scale between locked down unix permissions and free modification by all. People have to get an alioth account and demonstrate basic competance to get debian-installer write access, but don't need to be Debian developers or spend more than an hour or so to get access. Once you have access, you can change anything in svn (and everything is in svn) we don't limit write access to parts of the project. We avoid malicious commits through patch review. I could give many more examples of subsystems in Debian that exist at different point in the spectrum between locked down unix permissions and a wiki. There seems to be a definite pull toward moving away from unix permissions, once ways can be found to do so that are secure or that allow bad changes to be reverted (and blame properly assigned). Cases of moving in the other direction are rare (one case of this is the further locking down of the Debian archive server and BTS server after the server compromise last year). Anyway, the point of this is that, if you survey the parts of dealing with the project where Debian developers feel most helpless and unempowered, the parts that are over and over again the subject of heated discussions and complaints, you will find that those are the parts of the project where unix permissions still hold sway. This can range from simple cases such as a cron job that only one person can look at and modify[1], to various data files that could perhaps be kept in svn, but aren't, all the way through to stuff like the Debian keyring. I would love to see a full list developed, although many of the things that remain are obscure little corners like certian blacklists in the BTS, bits of the buildd infrastructure that only a half dozen people know about, etc. The challenge, then is to find ways to open things up to everyone, without throwing security out the window. It has to be done a piece at time, and some of the pieces that are left are the ones most resistant to this change. I hope that people can keep this progression away from unix permissions in mind while working on Debian infrastructure. (If I ever ran for Debian Project Leader (which I won't), this would be one of the areas that I would be sure to investigate basing my platform on. Speaking of which, it's nearly election season again, isn't it?)

---

[1] The best solution I have found to this common problem so far is simply to keep the cron job in svn with everything else, and if someone modifies it, review it and update it via semi-automated means (some simple command). There are probably better ways to do it.

Kathy and I had a nice long weekend in Dublin this weekend past, celebrating 10 years of hell together. Was good, except for getting rained on lots on the Friday (solved by buying umbrellas) and Kathy starting the weekend with a cold and me finishing with one. Bah. I realised it's been about 5 years since I was in Dublin itself, rather than just the airport. Various comments:

• The traffic lights still explode. This is fantastic and I think more places should do it. They sort of beep while waiting to go red (so a pedestrian can cross), then make an exploding noise and tick until going green again.
• It's very expensive. When we arrived we ordered room service as it was late and though the prices quite high. And then discovered that they weren't really that bad when compared against the normal cost of eating out. What gives? I'm sure it didn't used to be so bad. That was pre Euro - is that the difference?
• The Elephant & Castle still do the best chicken wings I've ever had.
• Ryanair are bastards. I'd bought a cup of coffee just before they started boarding and they wouldn't let me take it on. They mumbled some nonsense about turnaround times or something, but given you can buy coffee on the plane I think it's fairly clear they just object to losing the chance to sell you something.
• I'm not convinced Guinness in Dublin is any better than a good pint of Guinness in England. Maybe that's due to the fact it's all brewed in Dublin these days.

The editors of the New Oxford American Dictionary have chosen 'podcast' as the word of the year. I bet next year they'll choose 'vlog'. We'll see. (via digg)

Various samples of code:

#* In all cases CONFIG_SMP redetermined bye 'cpu0'-line in /proc/stat.

do if (smbusDebug & (1 << ( 1 ))) printk(KERN_DEBUG "smbus(%d):" "asus_PowerDown(%p,%p,%p)\n" , (int)(jiffies-jiffies0),CmdBuffer, ResultBuffer, fSmbiExec ); while (0) ;

typedef char CHAR;
typedef CHAR *PCHAR;

* All rights reserved
MODULE_LICENSE("GPL");


Thanks, Fujitsu Siemens. You COPYRIGHT INFRINGING INCOMPETENT FUCKMONKIES.

I mean, christ.

CHRIST.

UNBELIEVABLE HOLY CHRIST ON A FUCKING BIG STICK.

Are you gonna setup a wiki anytime soon? Checkout the WikiMatrix site which allows you to compare various wiki software projects according to a huge amount of criteria. My favorite has always been MediaWiki (probably because I occasionally write for the Wikipedia). I use that for both, the Unmaintained Free Software wiki, as well as the Crazy Hacks wiki (both need some more love and contributors, hint hint). I'll checkout some of the other wiki software projects soon, though... (via ZDNet Blogs Between the Lines)

I’m pleased to have prompted a bit of a discussion on the linux-aus mailing list about Linux AU and the relationship with NZ. James Purser kicked things off with a blog post on Friday and so far the discussion is going really well. I’ve outlined a few more of my thoughts below. I think the issue of national identity is probably the key to this whole discussion. It is important for the NZ community and LUGs to retain their own identity and not be subsumed into Australian identity. When Craig, John and I started the Linux NZ discussion, it came in part from a fair degree of envy from what we were seeing Linux AU acheiving. If you read our initial invitation it was quite clear that we were looking for support to “duplicate” Linux AU into NZ. We didn’t get there, and after taking a month or two to think about it, I believe that trying to duplicate Linux AU into NZ was the wrong approach to take. As beneficial as it would be in terms of creating a distinct identity there are far too many other things that it just doesn’t make any sense to duplicate at all. LCA, the podcasts and Advocacy preparation are the three key things that pop immediately to my mind and I’m sure there are others too. I think the biggest thing we learnt from our LinuxNZ endeavours is that we don’t (currently?) have huge numbers of people available to do things in NZ, and we are always going to suffer from problems of scale to some extent. In many ways the more duplication we can avoid the better. That allows us to free what people we do have to focus on the things that are NZ specific. This is the key reason that I’m pushing to see if there is support for Linux Australasia. It’s not that we want LinuxAU to adopt or subsume NZ LUGs, the idea is that LinuxAU would grow to include NZ and become a bigger, better and more inclusive organisation as a result. I guess the flipside for Australians is that the resulting organisation would be less nationalistic…. More on that in a minute. ISON probably fits in here too, I only just become aware them yesterday so I’m still reading their site. However my impression is that while it is definitely an organisation we should be linked with, its aims and goals are orthogonal to what I’m trying to achieve by proposing Linux Australasia. The impression I’m getting from talking to Pia, and lurking on this list is that LA is working very hard to empower the members to be the workers rather than the committee. With the committee providing the organisational oversight, legal structure, vision and authority needed to keep everything hanging together. I think it’s a great strategy, and would fit in perfectly with the bigger, broader Linux Australasia that I’m proposing. Give NZ members the opportunity to work on the press, publicity and advocacy sub-committees too and you’re pretty much there in terms of
achieving Linux Australasia! The sub-committees as a whole can work on their specific areas (avoiding unnecessary duplication) and then the
NZ/AU components of each sub-committee can do the necessary (hopefully minor) localisation work if and when required. Following from this, if there is a need for a more nationalistic component then it’s simply a matter of creating a sub-committee to do the work required to “promote national identity”… perhaps we need to have FOSS competitions across the ditch so we can beat each other in something other than sport… Plenty to think about and as many have pointed out the key place to resolve all this is probably going to be at LCA’06 in Dunedin. I think as James has pointed out though, it is going to be very beneficial for us all if we can do much of the talking beforehand and at least get an idea of where everyone is at, even if we are poles apart in terms of what we think.

Dear Msnbot: why do you hammer on port 8080 when there is nothing listening there? I recently set in place a comprehensive iptables firewall and have started logging dropped packets. I’ve noticed the highest number of dropped packets comes from 65.54.188.51 aka msnbot.msn.com. Does it just try port 8080 on every known domain name, “just in case”?

Without the vast number of voluntary supporters past LinuxTag events wouldn't have been possible at all. On the financial side LinuxTag has always made only little profit after the event. Without these nearly 100 volunteers who have supported us directly during the event and during its preparation the show wouldn't have been possible. Without the help of so many supporters during the event, the entire show isn't possible. Hence, it is important to either generate more income and be able to pay for hostesses and callboys or manage a proper environment in which many supporters want to help. For this, accepting the importance of the supporters, acknowledging their work and supporting them with food, fluids, fun and other advantages is very important. To my regret, I have to admit that this has not always been the case inside the core team. I have argued in favour of the supporters several times, so hopefully not much of it has been noticed by them. Supporters have worked in several different areas. I'll try to list them below but I'm sure I already forgot half of them even though I have coached most supporters directly or indirectly. We have maintained the parking ground so we were able to ensure that the Festplatz in the middle of LinuxTag is not abused as a parking place during the event. This required us to maintain a gate with at least one gatekeeper from 6 a.m. to 10 p.m. This was a lot of work, and it wasn't that interesting, but good for people who want to read or hack in the gatekeeper pavilion. We have manually built the projects network in the exhibition halls. In the conference building it was built by the KaLUG. All information signs and plans had to be drawn, printed, magnified and fixed at their respective locations. There are a lot of additional signs that we have maintained to help visitors find their way. I'm sure still a lot of signs were missing. I have used the opportunity to prepare most of them after the last event, so that we have less work for the new one. Our own office had to be set up, since we've used naked rooms with only some cupboards, tables and chairs inside. More furniture had to be arranged, the network had to be built up, the server had to be installed or configured, the printer had to be attached, the network configuration needed testing, the desks had to be set up. For some years now one to three volunteers have helped us in the office in order to support the core team and so that we are able to present visitors, exhibitors, the press etc. We've had an an additional human firewall who worked for two or three days usually and was able to support most people already without clogging the office room. The firewall (Arne) himself had the idea to become a firewall several years ago and I have to agree that it was a very good idea. However, with the exhibitor support maintained at a special booth at the entrance less work had to be done for the firewall this year. Several large and self-standing signs had to be prepared or repaired after the had been broken at the last event or their content has been obsoleted. Signs for the gate from above had to be printed and fixed at proper locations so that exhibitors find their way. We have built up the entire audio and video equipment on our own with a service provider from Bremen. Since this affected up to six rooms a lot of equipment and cables had to be moved, installed and dismantled after the show. For this we've helped J rg and Sven with several volunteers. The business congress had to be prepared as well. Stuff for the attendees had to be created and taken to the conference building. The entrance counter for it had to be maintained and staffed. Doors had to be secured. Deliveries had to be maintained in a storage area, since before LinuxTag a lot of stuff is delivered to LinuxTag without the target booth built up already. During setting up the booth, the booth builders also had to be supported and problems detected, discussed and corrected. During the entire time of our siege of the fairground we've had to maintain our own storage of fluids and food. Due to the high temperatures having around enough fluids was very important. In addition to this demands for several goods also required us to send somebody out for shopping each day. In order not to die of starvation during the event we have also organised a delicious lunch for all supporters and core team members. Kudos to Thomas we were able to order large pots of salad and cooked food for two years so that we didn't have to eat unhealthy food (such as fat pizza for six days) and everybody could decide on their own how much they want to eat. In the years before we've had rented a cook and even ordered Pizza. The food had to be fetched from the restaurant, arranged, together with table clothes, cutlery and stuff, and finally taken back at the evening. Cutlery had to be cleaned regularly as well. For the social event the location had to be cleaned and prepared. This year we've had the great opportunity to use the Nancy Caf which was unused for about 10 years, and hence required a lot of cleaning. As it turned out just before the show began, it required a lot more cleaning than expected. However, thanks to the competent and highly motivated supporters the location was cleaned in time. Kudos to Claudia, this year's social event was also one of the most successful. For the legendary KaLUG party the location had to be prepared as well and the food cooked. Looking at the pictures, the pavilions had to be built, tables and chairs arranged, cutlery and fluids organised. In the evening all the stuff had to be cleaned as well. This year KaLUG had organised a so called "Sp lmobil" that helped with doing the washing-up, but somebody had to work in it as well. The KaLUG has maintained the Internet caf in the conference building and has set up the network for the exhibiting projects in the conference building. For this they have acquired a lot of computers and network equipment that had to be built up and dismantled after the show. They have also acquired a number of movable walls for separating booths and providing poster space. During the show we have distributed fluids for the conference rooms and exchanged information posters and flyers with the daily schedules. When you're giving a talk, your throat often gets quite dry, hence, a cup of fresh water is a good cure, but requires the organisator to maintain water and cups. Since the conference program changed daily posters and handouts had to be exchanged during the evening. Project exhibitors were supported directly by us while company exhibitors were supported by a service provider. Additionally all speakers had to be supported as well. The conference rooms were also maintained by a moderator who supported the speaker, announced the talks and speakers, ran (!) around with a microphone, helped in case of technical problems and maintained the schedule. Even though it may look strange for an outsider there are a lot of costs that emerge when such an event is organised at a commercial fairground. LinuxTag has always had the problem of only little yield after all bills have been paid after the show but had to start preparing the event for the upcoming year. In the past years it was always a struggle to continue with only little financial substance trying to get the next event set up properly. LinuxTag has been unique in its configuration, looking at its history, its organisation structure, its size and its components. There are basically only three ways of creating income: commercial exhibition, business congress and sponsoring. All three have obviously been on the descending path for several years now, reducing a lot of flexibility for the organisation. This income has had to be used for all expenses. On the other side there are a lot of areas that just cost money, such as the conference building, exhibition hall, hotel, travel reimbursements, projects booths, advertising. In addition to that we've had two service providers that have taken over some tasks and needed to be paid as well. A very rough overview is in my Howto LinuxTag talk from this summer.

Steinar, your comments on the limited utility of Get/Set methods both struck a chord and touched a nerve with me. On the one hand, I completely agree that people need to spend more time writing methods that do something useful to an object rather than just exposing public methods. For example, how often have you seen something like this (in faintly python-inspired syntax):

 obj.count += 1
 [...]
 obj.count -= 1
 [...]
 if obj.count == 0:
 	obj.destroy

Instead of the far more descriptive (and well-encapsulated):

 obj.register_user()
 [...]
 obj.unregister_user()
 [...]
 obj.destroy_if_unused()

(or any one of a thousand other similar idioms). This is a contrived example, of course, and a real example would involve doing at least a dozen operations on an object's public attributes from another class (which results in class-associated logic being located in other classes in the system) instead of putting it in a method and calling that (thus keeping all of the logic with the data it's manipulating -- which is the point of OOP). Anyone who writes code like the first example above and calls it OOP is kidding themselves. Of course, you could make the code even more ridiculous with getter/setters:

 obj.setCount(obj.getCount()+1)
 [...]
 obj.setCount(obj.getCount()-1)
 [...]
 if obj.GetCount() == 0:
 	obj.destroy

Incidentally, if you ever see anyone turn the first example into the last example and say they're "improving encapsulation", please do the programming world a favour and kill them. kthx. On the other hand, Steinar, you say "I'm not denying that getters and setters for a few variables might make sense", which clouds the issue immensely. The idea of routing attribute access through a method is immensely useful. It even has it's own name -- the Uniform Access Principle. A few examples are in order (you might already have thought of these, Steinar, but who knows who reads my dribblings!):

• (Not taken from real life, but certainly plausible) An accounting system has an Invoice class, which contains line items. After an all-nighter binge-drinking Stupid, the original programmer wrote the Invoice class to store the total as a separate attribute. Then, after sobering up (and possibly some cluebat-inspired rehab) s/h/it decides to create the total by adding up the subtotals in the line items when someone wants the invoice total. Except, by now (it was a long rehab session), there's about 15,000 places which ask for inv.total, and finding them all and replacing them with inv.total() is Aegean-stables level pain.
• ("Based on a true story") A class that interfaces to some piece of physical hardware has an attribute whose value gets sent to the hardware. Either a hardware change or a "we didn't think of that" moment results in a requirement that the value of the attribute, as sent to the hardware, be within certain bounds. Just truncating to the required size isn't going to work. What you'd like to do is raise an exception (or log a call trace) when that attribute is set with and out-of-bounds value, so you can track who is setting the OOB and fix the problem at the source. But of course, since it's just an attribute, you can't do a bounds check and exception-throw, so it's call-wrapping-and-funky-logic time.
• (Taken from my last few days programming, but it happens often enough) A class hierarchy has a map of IDs and names stored in it (these are dynamic maps, but are set via config file so don't change over time or during program invocation). This is stored in an object attribute. Yay for object attributes. Then, somebody decides that a new class (in the same hierarchy) should be able to dynamically generate value maps in some circumstances (specifically, from a remote database). Since these maps can change in real-time, we can't just generate-and-cache.

In my real-life case, there were few enough places to change all of the calls to a method, and since it's all written in Python I could have played __getattr__ games to get back to a method if I'd had to, but it would have been messy. But imagine a system written in a language that doesn't (somehow) support the Uniform Access Principle, and which was widely deployed (possibly even used by programs outside of our direct control) so the users of the class couldn't be adapted easily. Nightmare. Now, the real solution to the problem is to only use languages which support the UAP (Python can be hacked to do it; Ruby is, IMHO, almost a case-study in How To Do It; and there are other good languages out there). But, in ass-backwards languages that can't transparently map attribute accesses to method calls, I'd rather deal with getX()/setX() everywhere than have to try and perform the necessary gymnastics to later support dynamic value generation from what-was-previously-an-attribute. If, on the other hand, your post was primarily targeted at said ass-backwards languages, or programmers who cargo-cult manual getter/setters everywhere, let me join you in your derision. <grin>