Recently much ink has been spilled on the forms of micro-writing (Twitter, Facebook status updates, micro-blogging) that have captivated the hearts, minds, and especially keyboards of those, like me, who spend a lot of time in front of the blue screen (whether a computer or a phone). Lately, perhaps in part because I was home bound for days, I went on a status-update frenzy, updating my Facebook feed like there was no tomorrow and checking in as often to read the short nuggets left by friends. Despite this recent bonanza, I don t admit to all my friends of this addiction as some of them seem to really dislike no the more accurate term is detest this linguistic genre. Generally, it seems to me, there are those that love these messages, and then there are those who disparage them for being inane, short blasts of egotistical information that reflect and worse, reinforce the rampant, raw, unfiltered American love with self, performing the individual, and all that related jazz. I am sympathetic with the haters and at times, I admit I feel nothing but the hate (and perhaps this is why I have yet to Twit) but after thinking about it I have decided I am not really in their camp. Why? Well, something I do when I am thinking through phenomenon is ask: What Would Bakhtin Think (WWBT) as he is a theorist that I adore for he avoids so many of the traps, mostly of binary thinking, that befall most academic theorists. The answer to WWBT, at least from the way I read him, would be that he would dig and find something quite significant about these linguistic ephemera. Bakhtin, who was a Russian literary critic and thinker , thought highly of the novel as a genre for, unlike poetry, it provides a window into everyday life, into the depths and heights of the prosaic, which, however prosaic, is actually where all the extraordinary stuff of life resides. For in the humdrum of life is where he locates wonder, magic, suffering, laughter, mystery, love, oppression, and joy even if its significance often slips right on by our awareness, our perceptual world, until it is unearthed by such genres as the novel (and I would add film). You really can t get more mundane than these micro-statements, though albeit they can be fantastically funny, frustratingly opaque, devilishly satiric, and in rare occasions, poetic; and it is for all these reasons that I find them personally enjoyable and analytically valuable. So much of our life is seeped and steeped in the mundane and yet it is whizzes by us without much reflection. We certainly don t have much of a window into the mundane lives of others, especially in any real time sense. These updates are short pauses, like a temporal parenthesis (which any reader of this blog can I tell I am fond of) or a pleasant hiccup. While many say that they are egotistical blasts, I experience them otherwise, especially when I find myself smiling, laughing, wondering not at what I say but what others throw out there. For with the short update, I am transported, however ephemerally and momentarily, to your mundane world and share in the pleasures of life as is. And for those that remain unconvinced, at least take my word that Bakhtin is worth paying attention to (that is, if you pay attention to academic theory), here is a review essay that might convince you (subscription required but I will try to post a full copy later)

I don't know if Aaron is an Ubuntu Developer. I hope not. And I hope that no one of the commenters is one. But this post and especially the comments to it (because the article may have some justification) is certainly not a way to improve the relationship between projects like Ubuntu and the projects its based on.

Yes, it is true, that we have a rough tone in our mailing lists and yes it is sad that every now and then topics pop up that need to be discussed till somebody is hurt and leaves (the project). I certainly hope that this can be improved over the time, but most likely this is not something which breaks the project. Who knows what its worth. We have a large community, very much different opinions and therefore conflicts. Possibly it enhances the quality of our distribution, because things that certainly would make our product worse (e.g. lowering quality standards) won't get done, because they'll get a strong opposition.

But whats the point with the innovations, Aaron? Is it the job of a distribution to serve with innovations? A distribution that serves as a base for more then 10 other distributions? A distribution that is known to care a lot about freedom and is known (and appreciated) for a high quality standard. I don't think we need to serve innovations. We served innovations back in a time where it was needed. Where things were missing. Like a good package management, like conf.d directories. Apart from this I think there were enough innovations in the past years. Possibly not that user-visible and trendy as a graphical virtualization frontend. What about xen-tools for example?
Now its all about reinventing the wheel or developing frontends. Launchpad for example is just reinventing the wheel. Savannah exists, GForge exists. Bazaar is just reinventing the wheel. Git exists. So does Mercurial.

But whats most sad about your posts and the comments is that you (and your commentors) seem to share the opinion that all Debian does is packaging software and nothing more. According to you Debian developers do not fix bugs, forward patches, file (important) wishlist bugs, encourage upstreams to remove horribly broken licensed software, improve their own software and tools (dpkg, aptitude, apt-get, the devscripts, ....), do integration work (alternatives, $EDITOR usage, ...), documentation work (writing manpages). The reality is that there are many small and greater things driven by Debian Developers that serve the whole community. Additional to the ground work that your favorite operating system is based on and without which it could not exist.
Its just not beeing doped like it is done by companies with their marketing departments that actually earn money with what they do. Take the projects you named. They all have one. They all have paid developers.

In any way such a ranting (with no real constructiveness) will not serve the relationships between other projects and Debian.

Russ Allbery recently commented that it is really nice to receive patches for trivial scripts posted online. I agree. More than once I've posted a trivial script and had it be improved by people, or later included elsewhere. So in the spirit of sharing here is my latest toy script:

• make-whitelist

This is a trivial script which searches a Maildir hierarchy and outputs a list of each email address which you've ever sent mail to. Why would you want that? In my case my (personal) spam filtering makes use of whitelisting, and the assumption is that if I've ever mailed you in the past then I want to see your replies, and you get a break. These days my (personal) mail filtering has a couple of broad rules:

• If your mail is HTML it is junk. Unless I'm bored.
• If your mail is GPG signed/encrypted I will see it.
• If your mail address is on my whitelist then I want to see it.

After that then I see your message only if CRM119 decides I should.

#
# remove potentially spoofed header
#
:0 fhw
* ^X-whitelist:
  $FORMAIL -I "X-whitelist"
#
#  GPG-signed messages are OK and will be whitelisted
#
:0fW
* < 1024000
 /home/steve/bin/isgpged
:0e
  $FORMAIL -A "X-whitelist: yes" -A "X-GPG-Signed: Yes"
#
#  Get the sender of the message.
#
FROM= formail -x From:  sed 's/^\([^@]*[ <]\)//'   sed 's/\([ >]\).*$//' 
#
# Add a whitelist tag if appropriate
#
:0 fhw
* !^X-whitelist: yes
* ? test -s $HOME/.procmail_whitelist
* ? echo $FROM  fgrep -qisf $HOME/.procmail_whitelist
  $FORMAIL -A "X-whitelist: yes" -A "X-Whitelist-Test: $FROM"

The net result of these tests is that I can now run the spam filter on non-whitelisted mails:

#
# Run CRM114 mailreaver
#
:0fw: .msgid.lock
* !^X-whitelist: yes
  /usr/bin/crm -u /home/steve/.crm /usr/share/crm114/mailreaver.crm
#
#  Spam.
#
:0:
* ^X-CRM114-Status: SPAM.*
* !^X-whitelist: yes
.CRM.Spam/
#
#  Unsure.
#
:0
* ^X-CRM114-Status:.*UNSURE
* !^X-whitelist: yes
.CRM.Unsure/

There is more to my setup than that, but that's the minimum you'd need to see. Of course this is a reminder, once more, that the kind of filtering that you carry out for yourself is different from that that other people will do. ObFilm: The NeverEnding Story

Attention Tiago. In the future please follow standard Debian Planet protocols.

Many people ask me why there are such few female hackers. While I think this is an important/interesting question (that is also extraordinarily hard to answer), there is another one which has captivated me for much longer, which is the followingL why are there such few females represented in the academic/activist world of free software/free culture, etc.? It seems like every turn I take, there are books galore, talks galore, essays galore being written by men with females sprinkled on top, like some confectionery after thought. Take for example Joi Ito s recent photograph collection, Free Souls (women are represented in the beautiful array of photographs) but in the essays which reflect on freedom/free culture/the souls of freedom, there is (I think, correct me if I am wrong), not a single female voice, despite the fact that there were clearly females authors/activists that could have potentially contributed.

Essays 1. Lawrence Lessig
Foreword by Lawrence Lessig
2. Christopher Adams
Share this book
3. Joi Ito
Just another free soul
4. Howard Rheingold
Participative Pedagogy for a Literacy of Literacies
5. Lawrence Liang
Free as in Soul: The Anti-image Politics of Copyright
6. Cory Doctorow
You Can t Own Knowledge
7. Yochai Benkler
Complexity and Humanity
8. Isaac Mao
Sharism: A Mind Revolution
9. Marko Ahtisaari
Intelligent Travel

Now, am I overreacting here; or is this reason for worry?

I have been positively surprised to find out that some people are taking seriously the fact that some people are being put off from actively participating in Debian s discussions because doing so would lead to offensive behaviour and personal attacks, and to try to find a solution to the fact that a very vocal minority is dominating the silent majority. Of course, some people are happy with the statu quo and strongly opposes to changing anything in that direction, not very surprisingly. The part about I m really starting to think that this Project could do a lot better without some people is crystal clear and needs no comments. I m not really sure that the current social environment can be fixed just with technical measures. Another proposal talks about some mailing lists extracted from the official ones but with the offending comments filtered out. I must confess that I find this idea very interesting and that I might think about rejoining such a list. Of course, technical details on how to properly and effectively implement any of this methods, or even a mixed one, can be very tricky.

Just saw the LF announcement:

http://video.linuxfoundation.org/category/video-category/-linux-foundation-video-contest

I love the effort, and I'm sure people will do great work, but there's a problem here. There needs to be *two* contests. The first, with the award that they propose, should be the serious one - The one that might get rolled out to suits and businesses everywhere, that we'd be proud to show off on our corporate web sites.

Then there's the second category. The "too honest" ones that get made for the equivalent "I'm a Mac" / "I'm a PC" ads and wind up on YouTube and email attachments. Not so much fan fiction as fan honesty. =)

I'm thinking start with a focus on a keyboard, crusted with Doritos and possibly an ashtray beside it, zoom out to a couple people playing Quake or Tetrinet or something that clearly haven't washed in days, zoom out, show that this is a dorm room. The room next to it (with cutaway walls and what not) has someone composing an email saying that either Gnome or KDE sux0rs. Further out, two floors, more rooms: Some people lit just by the glow of a CRT, decorated by Debian and Gentoo logos, maybe a vague outline of some porn on a monitor. The zoom out picks up to show ESR writing another book, maybe another ELER comic being written, someone "upgrading" their home wiring, various people arguing, one shower in the building total, and finish the zoom out and fade in the facade to the building: All shiny, glass and steel with a front door with a business person leading a tour past it saying "These are the Linux Development Labs, where all the magic happens. It's closed to visitors right now (points to goth in the back with a laptop who's probably running kismet), except you - you're welcome in." And then fade in the letters "We are Linux"

The soundtrack to this should be a background hum, just at the edge of what a TV speaker will play for volume. Queue in fifths and octaves during the zoom out, fade in some drum and base, some Simcity type of background talking and open up the chord as the words fade onto the screen.

(This is fiction, people. Noone expects another ELER)

Two policy issues have been brewing in debian and I ve been mostly quiet about them because I ve been busy with TTLLP work. One is the Lenny release GR which I m still trying to make sense of. I mean: yikes! I ve been reading debian-legal and -vote for years and this ballot confuses me. I think I ll vote 5324671 but I m really not sure what that means. The other big issue is that Manoj has resigned as secretary. I think this is a good thing, if for no other reason than he s been secretary for 7 years and I feel it s not healthy for one person to hold that post too long in a thousand-strong group. I ve disagreed with Manoj about some tasks, but I didn t see any point in making this difficult job even less fun, so I stopped criticising him a while ago. Since then, my comments on the secretary s work have usually been limited to small review comments on ballots (which are then apparently ignored anyway, but at least I offer help). I m apprehensive about who will replace Manoj. In the short term, Bdale Garbee acts as secretary, but surely Bdale is busy enough already? Given his increased vote-taking activity, Neil McGovern seems a likely choice, but the work left undone after his term as SPI secretary may count against him. More generally, I think there s a problem with Debian s secretary, so anyone who would be a good secretary would probably refuse to do it as currently defined. There s an email about bundled votes and the secretary by Steve Langasek which touches on this major problem:

the secretary is the *only* line of defense against gaming of the GR process by a small group of developers who propose an uncontroversial but orthogonal amendment that will always win over the alternatives, in the process preventing the will of the project from being formally enacted

In other words, in Debian, the secretary is both secretary (usually an appointed or consensual post in most organisations, in my experience) and chairman (usually an elected post) - both doing the hard administrative leg-work and actually ruling on contentious issues, rather than just giving an opinion to the chairman. Manoj commented that he would be happy if the constitution was changed, to clarify the issue, or to explicitly add another entity to handle intepretations . Is it time to split the secretary s role?

Ciar n O'Riodan blogs about how to blog, and his post is a good read. Most of it is solid advice, and I find there's little I disagree with; if you want to get a blog that's well-read by many people, then his advice is probably sound. So why am I posting this in my 'retorts' category? Because I feel that blogging isn't something that should be taken too seriously. A blog is an outlet, a place to get your thoughts out; it is a bit of a combination between a column and the readers' letters section in a newspaper. The writing style of a blog should reflect that; when I write a blog post, I don't care about what the truth is, I only care about my opinion. If I want to write the truth, I'll write a wikipedia article. If I want to read about the truth, I'll go and kill myself because I'm not naive enough to think something like "the truth" exists in this life. And if I want to read a magazine-style article, how about I'll go buy a magazine instead of reading a blog post? A blog post doesn't require references (beyond, perhaps, what you're replying to); a blog is a reference, one to the personal opinion of the author. If you think something is great, then as far as your blog is concerned, that something may be the best thing since sliced bread. If you think something is ugly, crap, and should be forgotten about, then on your blog it is. In more than one sense, blogs are like opinions: everybody has one. That doesn't mean I disagree with most of what Ciar n wrote; on the contrary. Points 1 through 3, and 6 through 10, will help you develop a good writing style. I couldn't agree more on point 11, that you have to push for publication yourself; and it's certainly true that being aggregated is a good way to put your thoughts in context, and to expose yourself to a larger readership. But I vehemently disagree with his point 4:

It can take time. A good article-style blog entry can take six hours to write!

Not that I think writing a blog post should take no time at all this particular one has been almost an hour in the making, now but because I feel that, simply, articles, with all their references, scientific or other background, and whatnot, simply do not belong on a blog. A bunch of articles with an RSS feed is not a blog, plain and simple. So while I do agree that it can take time, I do think you're doing fundamentally wrong if your blog post takes more than, say, an hour and a half, to be written. So, in the interest of being constructive, here are my own suggestions:

1. Don't think too much, just write. It may sound stupid, but the most important part about blogging is actually doing it, and not wondering about how or why.
2. Do reread if possible. While blog posts are usually read in a few minutes, they take much longer to write; it's easy to lose track of your line of thinking during that process, in which case you may end up with a completely incoherent post. That certainly is to be avoided.
3. Ciar n's argument that if it's worth doing, it's worth blogging about certainly holds merit, but I'd go one step further: if it's worth thinking about, it's also worth blogging about. After all, a blog is mostly a braindump, so why not?
   That's not to say every thought can be turned into a coherent blog post, and I have a bunch of half-finished unpublished blog posts on my local hard disk which I may revisit at some undefined point in the future; but the principle is there.
4. And last, but not least: don't care about what other people are doing. Your blog is your own, not someone else's; if you get an email that your content sucks, ignore it. If you get an email that you should be writing about something else instead, ignore it. You're not getting paid for your blog, are you?

Really, now is the day 3 I am just considering this day 2 for I had to do a lot of things again due to my dumbness. Let me explain: I had a desktop environment in place (with fluxbox), wired network, and most of my daily softwares (Iceweasel, X-Chat, Pidgin, GkRellM), then I decided to test the Suspend-to-Disk At first, it seemed to work well: I made a swap file for uswsusp, just as documented what is not documented is that this file must be outside the encrypted partition! So, when I turned it on again, an error telling me about some corruption in the opened luks partition. I though OK, something gone mad, just a matter of running an e2fsck . So I booted with the netinst pendrive, opened the luks partition and ran it with -y. Everything seemed to be corrupted!!! It spend almost 5 minutes fixing bogus inodes and stuff before I decided to interrupt the process this fixed filesystem would never work anyway. So I began from scratch All over again. When I got into a working base-system, some other thought stroke me: what if Brenda were to use rohan (have I mentioned the name is rohan? I name all my machines after places in Middle-earth)? So, a minimal user-friendly desktop is needed After some research, I decided to go for LXDE. This is a minimalist desktop with OpenBox as the window-manager. I ve been using FluxBox for a long time now, so running another BlackBox-based would not be such a problem. LXDE is quite good. So far, everything I expected is working fine . Then I decided it s time to move on to configure the Wi-Fi stuff. I installed the RT2860 modules from Debian/EEEPC Repository and added rt2860sta to /etc/modules. At first I was worried that some reports of it not working with WEP showed up in a Google Search But nothing could be smoother! I installed wicd and it detected our WEP AP like a charm (and a bunch of other APs nearby)... after entering our key it just connected fine and I ve been using it since no glitches so far. I would like to play a little more, but I called the day since I got a lot of work going on Next item planned is the webcam

After two and half months of development, new Gammu stable release is out. Since last testing version there are only minor changes in vCard export, but full changelog since 1.21.0 is quite long:

• Disable ATOBEX for Motorola V180.
• vCard can now store caller group and private flag (bug #269).
• vCard now stores location and memory type.
• Add ID for Nokia 6131 NFC (bug #775).
• Better skipping of corrupted messages in AT (bug #768).
• Autoload 6510 module if phone is S40 (bug #767).
• Add ID for Nokia 6500s (bug #770).
• Add automatic detection of Nokia phones (bug #770).
• Catch error when calls can not be deleted (bug #738).
• Better documentation of addnew (bug #734).
• Fix detection of OBEX capability on older Siemens phones.
• Try to detect wrongly formatted CMGL reply (bug #771);
• Handle phones which fail to report supported charsets.
• Fixed encoding of WAP indicator messages.
• Support for photos in vCard (bug #227).
• vC* saving now protects against buffer overflows.
• Drop own crosscompilation support, rely on CMake one.
• Also standard CMake parameters used when possible (eg. BUILDSHAREDLIBS).
• Search does not create thread for non existing devices.
• Fixed possible crash when backing up ringtones.
• Fix possible race condition in searching.
• Fixed invoking of CMake with output to custom directory.
• Compile on platforms where ssize_t does not exist.
• Fix detection of towlower on some compilers.
• Make Bluetooth compile using BCC.
• Fix compilation if strtoull does not exist.
• Compile on platforms where intptr_t does not exist.
• Fixed compilation in BCC (see changes above).
• Check whether compiler supports FUNCTION.
• Reimplement locking and add tests for it.
• GSM_SetDebugFileDescriptor now accepts flag whether file descriptor can be closed (bug #749).
• Soname change due to API breakage (see above).
• Fixed compilation on Mac OS X, thanks to Juan A. Bertolin for testing.
• Script gammu-config can now also work with whiptail.
• Minor fixes in gammu-config script.
• Extra spaces from connection or device name are now stripped.
• Automatically reinitialize FBUS connection if it is dropped.
• Disable OBEX with Motorola Z6c, it is broken (bug #746).
• Refresh manufacturer information on second init of AT (bug #746).
• Always get charset information on AT phone initialization.
• Better handling of OBEX switching for Siemens phones.
• Fix flags for 2630 and 3109c (bug #752).
• Fix handling of caller groups and picture IDs (bug #752).
• Properly set calendar location while adding (bug #747).
• Sign Windows binaries during build.
• Detect long FM station names (bug #727).
• Add ID for Nokia 2630b.
• Handle properly very long lines in vcards (bug #728).
• Do not build and install locales if gettext is not compiled.
• Increase number of calendar entries (bug #725).
• Leak free test runs.
• Support backup of phone phonebook from Siemens (bug #732).
• Properly handle GetNextMemory on Siemens (bug #732).
• Save textual category to backup (bug #737).
• Enable dashboard testing using CTest/CDash.
• Add option to do coverage analysis.
• Properly handle debug file closing.
• Add test case for debug logging.
• Fix decoding of some SMS messages from Nokia phones (bug #735).
• Hack for (still) unknown error code (bug #733).

You can download from usual place: http://cihar.com/gammu/, Binary packages will be available soon in all usual places (Debian Unstable, OpenSuse build service, Ubuntu PPA repository).

Dell chose to ship Linux on the Mini 9, and so they were not required to plaster Windows stickers all over the case. They made up for this sticker deficit with a useless sticker that reads just "Inspiron M series" (or something approximating that). My mind boggles at the decision process behind that. Removing this sticker, I scratched the case of my new laptop. I also spent about 20 minutes scrubbing off the evil glue they used, which spread everywhere.

---

I had hoped the white power LED on this laptop would be less eye-searingly painful than the blue leds that were trendy before. It is, but it's also right on the front of the laptop, which is often in a direct line of site to the screen. In any dim enviroment, the LED is still brighter than the screen. I fixed this by applying some electrician's sticky tape to the case. Obviously, I can't win.

So today, I discovered that MoinMoin has an all or nothing attachment setting: either everyone with write permission to a page can upload attachments, or uploading attachments is disabled for the entire site. No exceptions. Period. Not only that, but there is no maximum attachment size setting unless the attachment was uploaded embedded in a ZIP file. How s that for irony? Not wanting to have my railroad site turn into a file trading site, I don t really want to let everyone upload attachments. Oh, also MoinMoin doesn t maintain a history of attachments. So if somebody drives by and vandalizes an attachment, you get to . restore the original version from tape. Yay? So I decided I d look back at MediaWiki, which has better attachment controls. I still had my test installation, so I went to use it. I edited the main page. I wanted to read about the markup, so I clicked the Editing help link. Whoops, broken link. It links to Help:Editing on the local wiki. Which MediaWiki does not install for you. I asked about it on #mediawiki. The answer was: copy from mediawiki.org. OK, fine. How? Cut and paste. Yes, that s right. Every time a new version of MediaWiki comes out, you get to cut and paste dozens of pages from mediawiki.org to your wiki, or else you ll have outdated help. Yay? The MediaWiki folks on IRC seem to like it this way. Not everyone wants the same help. Fine, but provide a sane default for those that don t care. Who thought running a wiki would be so hard? Update: since yesterday, I went to moinmo.in and fixed the ThemeMarket page to reflect what versions a MoinMoin theme works with. I m happy to help out with fixing Free Software though I don t really have time to add fundamental features like working syntax help links on this particular project.

I'm posting way too much to debian-vote right now, which I realize and which I'm going to try to cut back on. (I at least did start the lintian.d.o upgrade process today, so I got non-discussion Debian work done.) The reason why I keep reacting, though, is that I'm finding it frustrating that people seem to be asking the wrong question for resolving the firmware freeness argument. We currently have a strong disagreement over what the implications of the Debian Social Contract and DFSG should be for our release process. Some Debian Developers believe that releasing lenny as-is requires a special exception to the Social Contract. Some Debian Developers believe that releasing lenny as-is is consistent with the Social Contract. We've tried and failed to achieve consensus. That's the first point of my frustration: some people don't seem willing to accept that this has happened. They are apparently having a hard time understanding how anyone couldn't agree with them, and are therefore repeatedly reopening the discussion on which we don't have consensus. Once it's clear that consensus doesn't exist, this is very counter-productive. The discussion is futile, which frustrates people, and then in that frustration they become increasingly angry and harsh. Once consensus fails, all interesting decision-making processes start. A decision-making process basically reduces to "who decides?". When you have a dispute and consensus is not possible, some body has to make a decision. If people believe in the decision-making process, they can then support, or at least live with, the decision because they respect the process, even if they disagree with that particular outcome. The most important output of a decision-making process is closure: you stop debating and move on. If that doesn't happen, the decision-making process has failed, even if it makes a decision. Why does this all matter and why am I going on at such length about it? It's simply this, which I think is so important I'll highlight it:

Even people who strongly disagree on some issues can work together cordially and well in the same project provided that they can agree on a decision-making process in those areas where they disagree.

Agreeing on how decisions are made in Debian is important because that's how we continue to work together when we disagree (and we will disagree). If we can agree on how disputes are resolved, we can all respect and honor the outcome even if it isn't what we would have wanted, and then move forward. If we don't agree on how disputes are resolved, we'll keep re-arguing them rather than accepting the outcome. The discussions will get more heated, more people will get upset, and more people will not have fun working on Debian. What I've been trying to analyze on debian-vote is the "who decides" part of this question. We have a decision-making process outlined in the Debian constitution for non-technical decisions (of which this is one). That process is somewhat scattered through the document, but bringing it together in one place, it seems to go like this:

1. Developers are empowered to make decisions about their own work. That means that, according to the constitution, the primary people who get to decide how the SC and DFSG should apply are every Debian Developer in the tasks on which they're working.
2. The project leader can define an area of ongoing responsibility and delegate to a developer or a group of developers responsibility for making decisions in that area. There are two relevant delegations here. The ftp team has the delegated authority to determine what packages may enter Debian given, among other things, licensing and DFSG issues. The release team has the delegated authority to decide what goes into the next stable release and when that release happens. (Let's put aside quibbles over whether or not that authority was formally delegated; I think that we can all agree in practice that it's close enough.) The ftp team has accepted the relevant firmware packages into Debian main and hence have made a decision in their area of responsibility. The release team, through the lenny-ignore tag, has decided that the relevant packages can be part of the next release. Those are delegate decisions that have already been made, and neither of those teams seem to want to change their mind.
3. The final decision-making body in this case, therefore, is the developers at large, who can override any delegate decision via a GR. That's what Robert Millan proposed, although he doesn't seem to have realized he was doing that, and it's not marked as such on the ballot.

Now that this has happened, we all vote whether or not to override the delegate decision. The only option on the ballot that does so, by my reading, is the first one, so if the first option does not win the GR, the delegate decision is not overridden and both the ftp-master and release team decisions stand. This is why Further Discussion means we continue the release as previously planned. We have a decision-making process, which has been followed, and the current decision is to release including those packages. In order to change that decision, it has to be overridden. A result of Further Discussion on a GR means that GR does nothing, and hence the decision stands. The second point of frustration is the decision that option four on the ballot (delegate to the release team the power to make decisions about how DFSG issues affect what is included in the release) needs a 3:1 majority. They have already been delegated the authority to do that as part of their delegated authority to manage the release. The effect of option four on the project is therefore identical to Further Discussion; the only difference is whether we make a positive statement or fail to make a negative statement. It makes no sense to treat it as supersession of a foundation document when it just supports the existing decision-making process in the constitution. A third point of frustration is the apparent feeling that foundation documents like the DFSG are outside of the normal decision-making process described in the constitution. I can find no evidence of this in the constitution, but more fundamentally, the people arguing this are not stating what decision-making process they believe does apply other than "my view of the DFSG is obviously the only reasonable one and hence you should follow it." This reduces to a plea for consensus, which we've already established that we don't have, and hence, as mentioned above, is horribly unproductive to keep raising. There will never be a policy document that is so clear that everyone will agree on its implications in every situation. I find it much more useful to analyze governance processes by looking at who decides disputes rather than looking at position statements. The decision-making process is what will determine the outcome of all the really interesting cases.

I am sure this is making the rounds but this seems like an appropriate place for this list: If Programming Languages Were Religions. My favorite description:

Lisp would be Zen Buddhism - There is no syntax, there is no centralization of dogma, there are no deities to worship. The entire universe is there at your reach - if only you are enlightened enough to grasp it. Some say that it s not a language at all; others say that it s the only language that makes sense.

Speaking of computer languages and projects and religious holy wars, in the last few weeks I have been totally intrigued by the culture being built by the Ruby on Rails guys. As a researcher of Free and Open Source Software, I, like others, actually tend to see the similarities more than the difference between these two poles (in part because I focus on practice, not on the purist ideologies or two ideologues, you know who I am taking about) but it seems to me -and I could be wrong here but I suspect I am not -that Ruby on Rails is producing a unique Open Source culture, one that really diverges from some of the core principles of Free Software, much more so than other Open Source projects like Apache. The rail guys as I have heard, are Open Source evangelists of a certain stripe, who are quite cultish (you know, it is weird if you don t use github, a Mac, TextMate). What do you think of Ruby on Rails? Are the attacks fair? Are they a bunch of douchebags, as this (very incisive) post argues? Is it where Open Source meets and marries, for better or for worse, the Web 2.0 craze? If I could clone me, this is definitely one line of research, I would love to dive into right now but since I can t, your opinions would be greatly appreciated.

I just added a script from Thomas Viehmann to our dak repository to create a few graphic files out of our dinstall cronjob. We now have (click the graph for the full size version)

• one graph that shows the whole dinstall runtime together with the two most timeconsuming parts of it ,
• one graph that shows the most interesting points of dinstall and combines the rest into an other part ,
• and one that shows the rest of them .

These images are now updated at the end of each dinstall run, showing the last 20 runs. Now, if you are an R expert and want to make the graphs look nicer, we always love to get patches. Our git repository is at https://ftp-master.debian.org/git/dak.git/ and you want to look into tools/logs.py,pretty much at the end of the file. (If you dislike git, a copy of the file is available here, and our data input file is also available. You just need to modify the header of the script, changing the path entries and can start playing. :) Yes, at the time of writing this post the two first entries look a little odd. Thats known. Ignore. Thanks.

So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others. SSD disk I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it s the second generation of Samsung SSD) and I m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds. X server The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It s possible to force the usage of the intel driver by adding a Driver intel line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn t use the Keyboard section of xorg.conf. You have to create /etc/hal/fdi/policy/10-keymap.fdi by using /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi as template and reload HAL then restart X. Wifi support The Intel 5100 Wifi chipset requires Linux 2.6.27 at least for the new iwlagn driver. This driver also needs a new firmware (the iwlwifi-5000 one) that is not yet integrated in the non-free package firmware-iwlwifi (see #497717). Sound support It works ok with alsa and the version integrated in linux 2.6.27 but it still has some rough edges when used in combination with the dock. Using the output jack connector on the dock doesn t stop the output in the integrated loudspeakers and the volume on that connector is so low that you could think that it doesn t work at all if you don t pay attention. Using the microphone works fine. For reference, if you play in the mixer, Front mic means the microphone connected on the dock while Mic means the one connected on the laptop. Each Analog loopback X option goes pairwise with the corresponding Input source X setting. In order for the recording to work, I have to set Digital Input Source to Analog Input , Digital must be activated and Input source 1 defines the default input used for the recording. Bluetooth support Contrary to the previous laptop, Dell offered no choice on the bluetooth chipset, they only propose the Dell 365 Bluetooth Card so I took it but it doesn t seem to work out of the box. In fact I can t even see it with lspci or lsusb so I wonder if they did something wrong during the assembly. Googling on the topic didn t gave me any good result, let me a comment if you know how to get this working. Update: so apparently the bluetooth component is there (ID 0a5c:4500 Broadcom Corp.), it just appears as an USB hub so it s somewhat difficult to guess that it s effectively a bluetooth card. Freezes, in particular with an amd64 installation I first installed the system in 64 bits mode (amd64 architecture) but I had very regular freezes of the system (I couldn t finish a single kernel compilation for example). Since I switched to an i386 installation, the system is more stable but I still get an occasional freeze every other day. It might be that a more recent kernel fixes this or maybe it will be fixed with a future Dell Bios update we ll see, but it s my biggest complaint with this laptop so far. Links Lucas Nussbaum bought the same laptop, you might want to read his remarks as well. More details Load the full article only if you want to see the lspci and lsusb output on this laptop.


rhertzog@rivendell:~$ lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 RAID bus controller [0104]: Intel Corporation Mobile 82801 SATA RAID Controller [8086:282a] (rev 03)
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
02:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05)
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
02:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22)
02:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
0c:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
Kernel driver in use: iwlagn
Kernel modules: iwlagn
$ lsusb
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 019: ID 046d:c03d Logitech, Inc. M-BT69a Pilot Optical Mouse
Bus 004 Device 018: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader
Bus 004 Device 017: ID 0424:2602 Standard Microsystems Corp.
Bus 004 Device 016: ID 0424:2502 Standard Microsystems Corp.
Bus 004 Device 007: ID 045e:00dd Microsoft Corp.
Bus 004 Device 006: ID 0c45:63fe Microdia
Bus 004 Device 004: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 003: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 413c:8162 Dell Computer Corp.
Bus 001 Device 004: ID 413c:8161 Dell Computer Corp.
Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0a5c:5800 Broadcom Corp.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Partagez cet article / Share This

At work, we have quite a few Debian servers. We have a few physical machines, then a number of virtual machines running under Xen. These servers are split up mainly along task-oriented lines: DNS server, LDAP server, file server, print server, mail server, several web app servers, ERP system, and the like. In the past, we had fewer virtual instances and combined more services into a single OS install. This led to some difficulties, especially with upgrades. If we wanted to upgrade the OS for, say, the file server, we d have to upgrade the web apps and test them along with it at the same time. This was not a terribly sustainable approach, hence the heavier reliance on smaller virtual environments. All these virtual environments have led to their own issues. One of them is getting security patches installed. At present, that s a mainly manual task. In the past, I used cron-apt a bit, but it seemed to be rather fragile. I m wondering what people are using to get security updates onto servers in an automated fashion these days. The other issue is managing the configuration of these things. We have some bits of configuration that are pretty similar between servers the mail system setup, for instance. Most of them are just simple SMTP clients that need to be able to send out cron reports and the like. We had tried using cfengine2 for this, but it didn t work out well. I don t know if it was our approach or not, but we found that hacking cfengine2 after making changes on systems was too time-consuming, and so that task slipped and eventually cfengine2 wasn t doing what it should anymore. And that even with taking advantage of it being able to do things like put the local hostname in the right places. I ve thought a bit about perhaps providing some locally-built packages that establish these config files, or load them up with our defaults. That approach has worked out well for me before, though it also means that pushing out changes isn t a simple hack of a config file somewhere anymore. It seems like a lot of the cfengine2/bcfg tools are designed for environments where servers are more homogenous than ours. bcfg2, in particular, goes down that road; it makes it difficult to be able to log on to a web server, apt-get install a few PHP modules that we need for a random app, and just proceed. Any suggestions?