Sunday was the 100th anniversary of the modern marathon: It was during the London 2008 Olympics that the marathon was run for the first time for the 26 miles 385 yard, or 42.185 km, distance. And it so happens that I was there to run the 2008 edition of the London Marathon. Pretty nice weather at the start and finish: sunny, not too hot, occassional clouds. But being London, we still managed to get drenched for about 30 minutes. Overall, the conditions were good -- or else Martin Lel would have had a hard time for a new course record. The course is pretty nice, right from the start in Greenwhich all the way to the spectacular finish in Westminster. Crowd support was good too, if only a little uneven. But the second half of the race, and particularly the last miles in the back from Canary Whard through the City to Westminster past Parliament and Buckingham Palace were awesome. Lots of people, lots of noise. Oh, and I even saw the leaders in a group of five, including Lel and Hall as the course had parallel 'out' and 'back' tracks around miles 13 for me and 22 for them. I had planned to take it easy and not try to run too hard, and aimed for a time of around 3:25 and then finished at 3:24:41. A little less 'even' than I had hoped, but still a very satisfying result. And for once the legs aren't all that shot afterwards :) And the whole weekend was nice as I got to stay with friends in the southwest of London. Staying up late on both ends of the trip suppressed the jet lag fairly well. At least that's what I keep telling myself.

We are at T-48h of fisl9.0, and everything starts to take form. I spent the whole afternoon getting our icecast infrastructure online. We ve got 6 servers, all with different bandwidth and not all with the same architecture The debian boxes were prevalent (4 of them 1 amd64 and 3 i386), all of them etch. We ll be able to follow the statistics at tvstats website (not all the servers are enlisted yet). In this process I found an evil bug in debian s icecast package, I will have to debug to understand it better: when relaying from a master server (which is our set-up), if the source stops feeding the master, the relay segfaults. The strace shows it just segfaults while pooling I got no explanation for it and I ll have to dissect it if I want to build a proper bug report. In the meantime, I installed the sarge-backports version, and it worked so, the bug report will have to wait until after fisl :-) I took some pictures to show how s everything being put together. Take a look: And some of the infrastructure crew: See you all there!

Albert writes about software development and how much teamwork is used [1]. He makes an interesting clash of analogies by suggesting that it’s not a “team sport” because “its not like commercial fishing where many hands are used to pull in the net at the same time“. I think that software development for any non-trivial project is a team sport. You don’t have the same level of direct coordination as required for pulling in a net (or the rugby scrum [2] to use a sporting analogy), but that doesn’t stop it being a team effort. Some parts of team development projects are like a relay event, in corporate environments the work is done in parallel simply because everyone is working the same hours but in free software development projects the work is often serialised. I think that it’s often more effective to serialise some work, if someone is actively working on one sections of code it may save time to avoid working in that area until they are finished. There is little benefit in writing code to old interfaces. Some parts of team projects have specialised skill areas (EG debugging, skills in particular programming languages, and graphical design). Soccer is one sport where different rules apply to different players (the goal keeper can use their hands). In ice-hockey the protective clothing used by the goal keeper is considerably different from that used by other players. In most team sports where the aim is to put a ball through a goal at one end (EG basketball and all versions of football) there seems to be some degree of specialisation, some players are dedicated to scoring goals while others are dedicated to defense. The fielding team in cricket has every player assigned to a different part of the field - with slight differences in the skills required. Then there is the issue of large projects such as Linux distributions. It seems to me that a Linux distribution will always comprise multiple teams as well as some individual projects. Maybe we could consider Linux distributions (and distributions of the other free OSs) to be similar to countries that compete in the Olympics. The culture of the Free Software (or Open Source if that’s your idea) community can be compared to the Olympic Spirit. Of course the Olympic idea that people should come together in peace for the Olympic Games and that it’s about honor not money is pretty much dead. Maybe the Free Software development processes should be compared to an ideal of what sporting contests would be if there weren’t unreasonable amounts of money (and therefore corruption) involved. Of course no analogy is perfect and there are many ways in which this one breaks down. One of which is the cooperation between distributions. There is a lot of private discussion between developers of various distributions and upstream developers about how to plan new features. It’s not uncommon for developers to announce certain development decisions as soon as they are made to help other distributions make decisions - for a developer in a distribution project if there is an issue which doesn’t matter much to you or your users then it’s often good to strive for compatibility with other distributions. When users advocate new features or changes they sometimes try multiple distributions. It’s not uncommon for a feature request to be rejected by one distribution and then accepted by another. Once a feature is included in a major distribution the upstream developer is more likely to accept it due to it’s wide testing. Then when the feature is in upstream it’s almost certain to be included in all other distributions. I often recommend that when someone disagrees with one of their bugs being closed as “not a bug” that they try reproducing it in another distribution and reporting it there. As a side note, the criteria for reporting a bug in any free software distribution is that you can describe it in a way that allows other people to reproduce it - whether it’s a bug that afflicts you every day or whether you installed the distribution for the sole purpose of reporting the bug in a new forum is not relevant. As a general rule I recommend that you not have the same bug report open in more than one distribution at any time (if you notice a bug reported in multiple distributions then please add a note to each bug report so that work can be coordinated). As a general rule the only situation where I will open the same bug in multiple forums is if I have been told that the responsible person or people in one forum are unwilling or unable to fix it. Finally, the people who consider that they don’t need to be a team player because they do their coding alone might want to consider Qmail. Dan Bernstein is a great coder and Qmail is by most metrics a fine piece of software, in terms of security Qmail is as good as it gets! If Dan was more of a team player then I believe that his mail server would have been much more successful (in terms of the number of sites using it). However I do understand his desire to have a great deal of control over his software.

• [1] http://www.docunext.com/blog/2008/04/13/the-people-who-live-on-planet-debian/


• [2] http://en.wikipedia.org/wiki/Scrum_(rugby)

Share This

Last month we had a brief discussion on debian-devel about what images would be good to have for lenny – we’re apparently up to about 30 CDs or 4 DVDs per architecture, which over 12 architectures adds to about 430GB in total. That’s a lot, given it’s only one release, and meanwhile the entire Debian archive is only 324GB. The obvious way to avoid that is to make use of jigdo – which lets you recreate an iso from a small template and the existing Debian mirror network. I’ve personally never used jigdo much, half because I don’t usually use isos anyway, but also because the few times I have tried jigdo it always seemed really unnecessarily slow. So the other day I tried writing my own jigdo download tool focussed on making sure it was as fast as possible. The official jigdo download tool, ttbomk, is jigdo-lite – which you give a .jigdo file, and the url of a local mirror. It then downloads the first ten files using wget, and once they’re all downloaded, it calls jigdo-file to get them merged into the output image. This gets repeated until all the files have been downloaded. By doing the download in sequence like this, you miss out on using your full network connection in two ways: one during the connection setup latency when starting to download the next package, and also while jigdo-lite stops downloading to run jigdo-file. And if you’ve got a fast download link, but a slower CPU or disk, you can also find yourself constrained in that you’re maxing those out while running jigdo-file, but leaving them more or less idle while downloading. To avoid this, you want to do multiple things at once: most importantly, to be writing data to the image at the same time as you’re downloading more data. With jigdodl (the name I’ve given to my little program), I went a little bit overboard, and made it not only do that, but also manage four downloads and the decompression of the raw data from the template. That’s partly due to not being entirely sure what needed to be done to get a speedy jigdo program, and partly because the communicate module I’d just written to deal with this sort of parallelism making that somewhat natural. In the end, it works: from wireless over ADSL to my ISP’s Debian mirror, I get the following output:

Jigsaw download:
  Filename: debian-40r3-amd64-CD-1.iso
  Length:   675477504
  MD5sum:   d3924cdaceeb6a3706a6e2136e5cfab2
Total: 679 s; d/l: 586 MB at 883 kB/s; dump: 57 MB at 57 MB/s          
Finished!

which is only slightly short of maxing out my downstream bandwidth, taking a total of about 11m20s. Running jigdodl with a closer mirror works pretty well too, though evidently some of my more recent changes weren’t so great, because I’ve gone from 9153 kB/s on a 100 Mbps link down to 7131 kB/s or lower. The CPU usage also seems a bit high, hovering at between five to ten percent at 900 kB/s. For comparison, running jigdo-lite on the same file took 17m41s, which is about 566 kB/s, with the overhead being about 6m20s. What that means is if I doubled my bandwidth to about 20Mbps, jigdodl would halve its time for the download to about 5m50s, while jigdo-lite would still have about the same non-download overhead, and thus take 12m10, which is still 69% of its original speed. Going from 10Mbps ADSL speed to 100Mbps LAN gets jigdodl down to 1m31s (13% of the time, with optimal being 10%), while jigdo-lite would be expected to still be about 7m51s (43% of its original time). I suspect the next thing to do is to rewrite the downloading code to use python-curl instead of running curl, and thus downloading multiple files with a single connection, and tweaking the code so that it writes the file in order, rather than updating whichever parts are ready first. Anyway, debs are available for anyone who wants to try it out, along with source in the new git source package format.

It has now been more than 4 months since the last Debian developer account was created. 18 contributors have been through all steps, and are simply waiting for this simple administrative task to be done. We are sending a terrible message to potential contributors. We have strong requirements on the technical level of our developers. During the new maintainer process, we ask them to answer about 80 questions about Debian. We ask them to do grunt work. We review their reports twice (New Maintainers’ Front Desk, then Debian Account Manager). But even after we are totally satisfied about what they did, even after they became more qualified than many of our current DDs, we ask them to wait for months, so that the only person allowed to create accounts can finally do his “job”. It discourages the contributors currently in the NM process. I’ve seen several signs of frustration, or even depression. Some of them reduce their involvement in Debian, so we lose them before they even became Debian developers. Some of them consider resigning from the NM process. We should all feel guilty about that. But it also discourages people from joining Debian. Instead, they go to other more welcoming projects, which is totally understandable. Debian isn’t the only distribution with developers from the community those days. There’s Gentoo, Ubuntu, Fedora, openSUSE. Some of those have nice programs for new contributors, like “school” sessions. Sure, Debian is the “biggest” distribution without a company behind it. But is independance worth all the trouble? Of course, we have Debian Maintainers. DM is great for people who want to work on their packages. But, when we are trying to release lenny, we need more: people who are going to go through RC bugs, submitting patches. Who are going to do QA work. In short: people who care more about the whole distribution. Can we afford not recruiting anybody? Can we run Debian with the current manpower? I don’t think so. There are more than 550 RC bugs in lenny, many packages are currently blocked from migrating to lenny because they are RC-buggy, and many packages are orphaned or neglected. There are also a lot of bugs which haven’t been filed yet (I asked for help with running piuparts, which would probably result in 100-200 new RC bugs, but nobody had time to help). Most of the work that needs to be done is not rocket science. We could use a lot more manpower. Currently, the same small set of developers is doing most of the grunt work. They will get tired too. So, what can we do, as simple developers? There’s no magic solution, but we can try a few things.

1. It seems that some people disagree that there’s a problem. Let’s prove them wrong: we could start a blog meme with “I, too, agree that the Debian accounts and keyring situation is severely hurting Debian, and that a solution needs to be found RSN.” It’s not going to solve the problem by itself, but it will at least show that we consider it very important. Pressure could help.
2. We could start discussing solutions together. Our newly elected DPL said that he would talk with the problematic teams to determine how the situation could be improved. Unfortunately, this has been tried in the past (and failed). It might work this time, of course, but we could prepare a backup plan. So let’s find one or two good plans, and vote on them. (I liked the idea of giving accounts creation/management to DSA. After all, it’s only an sysadmin task once the report has been approved by FD and DAM.)
3. We could push forward Josip Rodin’s proposal about infrastructure teams. It might not solve the DAM problem immediately, but would probably help avoid similar problems in the future.

Notes:
1. Maybe the 18 waiting accounts will be created today or tomorrow. Even if that happens, it won’t solve anything. Waiting 4 months for a simple administrative task is not acceptable, and we need to fix that problem anyway.
2. Account creation is not the only problem. Some people have been unable to upload packages or to vote for the DPL election, because their PGP key expired, and nobody updated it even if they have been asking for more than 4 months.

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness. But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

I don't think any of these are mine, but this needs to be published to the general public (at least until it rests on AlumNit).

Poo Alliterations
- The Earl of Excrement
- The Duke of Dung
- The Prince of Poop
- The Sultan of Shit
- The Father of Feces
- The Matriarch of Merde
- The Steward of Stink
- The Dignitary of Dangleberries
- The Grand Poohbah of Grand Poo
- The Tyrant of Turd
- The Shogun of Scheisse
- The Baron of Bowels
- The Cardinal of Crap
- The Director of Dump
- The Surveyor of Stool
- The Lord of the Log
- The Crown Prince of Cow Patties
- The Royal Archbishop of Road Apples
- The Duchess of Droppings
- The Princess of Poodie
- The Legionnaire of Loaf
- The Supervisor of Stinkers
- The Pharaoh of Floaters
- The Magnate of Manure
- The Tycoon of TCPDumps
- The Czar of Czesspools
- The Mogul of Bowel Movements
- The Ruler of the Runs
- The Dean of Diarrhea
- The Royal Ringleader of Rump Raisins
- The Denizen of Doo-doo
- The Emperor of Evacuations
- The Headmaster of Horrible Odors
- The Titan of the Trots
- The King of Klingons
- The Big Boss of Bum Beans
- The Taskmaster of Turtleheads
- The Supervising Sovereign of Sewer Serpents
- The Colonel of Colon Cobras
- The Nobleman of Number Two
- The Top Dog of Toilet Twinkies
- The Kingpin of Keester Cakes
- The Shepherd of Sea Pickles
- The Head Navigator of Heinie Nuggets
- Rectal Representative
- The Commander of Cow Pie
- The First Mate of Fecal Matter
- The Creator of Cloth Touchers
- The Protector of Porcelan
- The Theologian of the Throne
- The God of Grunts
- The Small Insignificant Yodeling President of Shit in your Pants
- The Diaper Destroyer
- The Loader of Loincloths
- The Pontiff of Plum Pudding
- The Daiymo of Dysentery
- The Master of Montezuma's revenge
- The Squire of Squirts
- The [Weaver] of [WvLog]s
- The Primary Contact of Pudding Cookies
- The Best Producer of Brown Puddles
- The Senior Partner of Steaming Piles
- The Fine Baker of Fudge Brownies
- The Sheriff of Stench
- The Don of the Deuce
- The Torrid Putrid Tainted Pervert of Two-Ply Toilet Paper
- The Sacred Monarch of Skid Marks
- The Main Scientist of Microfeceological Studies
- The G.I. Joe of Gastro Intestinal Journeys
- The Premier of Polyps
- The Brigadier General of Bedpan Gold
- The Plunger Pilot
- The Specialist of Splashers
- The Foreman of Fake Farts
- The Ambassador's Under-Secretary of Astounding Unearthly Scents
- The Old Man and the Sea of Odiferous Monsters in the Sink
- The Bafflingly Blunt and Blasphemous Bearer of Big Bad Beastly Booty Burdens
- The Crisp Pungence of Chain Pooping
- The Goddess of Groundhogging
- The Burly Bobby's Brief Battle with Brim Blasting Bowel Bombs
- The Nasty Neighbour's Noisy and Nefarious Neglect of Normal Nasal Niceties
- The Judge Jury and Executor of Jolly Jumper Excrement
- The Forwarder of the Forwarded
- The Wizard of the Water-closet
- The Grunting Lobber of Great Logs
- The Annoyingly Arrogant Architect of Awful and Abhorrent yet Amazingly Aerodynamic Anal Atrocities
- The Dark, Dangerous and Delusional Dealer of Death-Defying Doses of Disturbingly Decadent Dung
- The Shakespeare of Sinfully Smelly and Supremely Scary Scripture with Soggy Stains and Screaming Splashes
- The Wise but Weakened Warlord Whose Willful Wrath Was Wholly Wrought With Wicked and Wretched Winds from Within
- The Languid and Lackluster Legend of the Little Log from the Loo and its Lavish Life of Luxury in a Lasagna
- The Kahuna of Kaka
- The Emergency Evacuator of Enraged Entrails
- The Squire of Sultry Stinknuggets
- The Deadening Discomfort of a Dearth of Dumps
- The Far From Favourable Fragrance of Four Fragments of Fantastically Fresh Feces
- The Principal of Prodigiously Putrid Pellets
- The Markedly Morose Maintenance of Maniacally Mounded Midden Movements and Mostly Meaty Meals Mysteriously Made Mushy
- The Crass and Cranky Coroner Connecting Clues Concerning a Cornucopia of Casualties Caused by a Crude Cluster of Completely Contemptible Colon Concoctions
- The Thinking Thoughts of a Thinker
- The Horrible, Hubristic Heathen Hoarding Hoary Humps of Hideousness Hailing from His Huge Hairy Heinie in His Harmfully Heady Hovel
- Inane Writings on Irritated Wreathing of the Incubator of Wrath
- That Special Numbness from Sniffing Noodled Stink Nougat
- The Moral Sanctity of the Mystery Shit
- The Ornery Opressor's Opulent Outpost Overseeing the Ordinary Occupants' Outrageous and Ongoing Observance Of an Occasional but Offensive Orgy Of Offal
- The Rector of Relief
- The Rectal Regurgitator
- The Shit Squat
- The Smelly Surprise
- The World Wide Wisdom
- The Slayer Supreme of System Shock

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness. But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

Habits control our choice sometimes more than we would like to admit… New mobile phone Since about two weeks ago I’ve a new mobile phone. The Nokia E51 will replace my slowly dying Nokia 6130i. I knew I needed a new mobile phone when my 6310i started to turn off itself shortly after I turned it on. I needed up to about ten times switching it on to make it stay on. Sometimes it already switched itself off before I could enter the PIN. Looks like a loose contact, but I never figured out where it is. Although I know about Nokia’s behaviour in Germany, I still had to buy a Nokia, because after using a 6130 (the GSM 1800 only clone of 6110 and 6150), a 6210i and the already mentioned 6130i over the last decade, I got so used to how Nokia mobile phones are navigated and how you type with Nokia phones (blank on 0, point and comma on 1, case changing on #), everything else (especially those with blank on 0 and case changing on *) would be worse than the half-dead mobile phone, I’m currently using. Spoilt for choice So which Nokia? For a long time I refused to buy a mobile phone with a camera or radio in it. But since the E70 was no more available (and is said to have quite buggy software) and the E61 has been replaced with the E61i, there are no more smartphones without a camera, at least not from Nokia. But I also found some useful uses of camera phones. After a while I could track down the number of choices to four: Communicator E90, E61i, E65 or E51: The picture above shows that the main differences of those models is size: Although having a QWERTY keyboard on the phone would be nice (for ssh, Jabber, the web, etc.) and the E90 being only slightly bigger than the 6310i on the paper, the size difference to the 6130i is more than only noticeable since the 6310i tapers off at the top. Besides, for the price of an E90, I get an E51 and an EeePC together… (Thanks to maol in whose blog I read about Sizeasy.) The E61i also has a (very small) QWERTY keyboard and is primarily only much wider than any of the other phones. It even has no bigger screen resolution than the E51 or E65. (Only the no more available E60 – a normal monoblock smart phone like the E51 – had a better resolution: 352x416 pixel instead of 240x320 pixels.) And since I usually carry my mobile phone in my trouser pockets, width matters most. So I had the choice to either get a phone which is too big for my trouser pockets or one without a QWERTY keyboard. The I remembered those foldable external keyboards for PDAs. There are at least three different makers of foldable bluetooth keyboards said to be working with Nokia Symbian S60 3rd Edition phones, so a QWERTY keyboard on the phone itself was no more important. (Only passwords will need to be entered over the number keypad since I don’t want to broadcast them… ;-) The choice between E65 and E51 was made easier by their reviews (E65, E51) at Xonio: The E65 seems to have not that good standby and phoning times while the E51 seems to be quite good regarding endurance. I looked through the usual shops around Z¨rich HB: Swisscom Shop, MobileZone, Phonehouse: All had the same prices (about CHF 250 for a two years contract at CHF 25 per month), except that Phonehouse had no E51 available in the shop. Interestingly digitec had a much lower price (CHF 100 for the same contract) and the choice of color (the shops always only offered one color), so I ordered a black one there. Converting a prepaid card to a postpaid contract isn’t that easy I wanted to change from a prepaid card to a postpaid contract, both at Swisscom, so I already own a SIM card. But digitec only offers new contracts including a SIM card or contract renewals, but no switching to a contract with keeping the number. And a new SIM card costs CHF 40 extra in their online shop. So I called their hotline and asked. The answer was: I need a new SIM card since prepaid SIM cards can’t be converted to postpaid SIM cards (but can be used with different providers). When I came to the shop, the employee needed three tries to fill out the Swisscom form for the number migration and still did it wrong somehow. No postpaid contract acknowledgement from Swisscom after two workdays. So I called their hotline. They told me, the wrong SIM card number has been entered and I need to make digitec to enter the correct one. A few days later back at the shop they were overextended. After a while an internal e-mail was on the employee’s screen which clearly stated that in case of prepaid to postpaid conversions (and a few other cases) no new SIM card must be given out and if this happens too often for the same employee he will be charged the CHF 30 a new SIM card costs digitec… (So they have a 25% margin of every sold SIM card…) About one hour after they closed their doors (I was there about ten minutes before shop closing time) Swisscom had accepted the contract changes and I had a credit note of CHF 40 for the erroneously sold SIM card. And the mobile phone became even cheaper than in all the other shops. :-) New gadget, new features So after a week, I can say that in general I’m quite happy with the new phone. It has a nice web browser, an IMAP over SSL capable mail reader and a feed reader, it can connect to the internet via WLAN and the 240x320 resolution isn’t as bad as I expected. I already have a Symbian port of PuTTY on it and sshing into my workstation works fine, even if I currently only have the phone keyboard and T9 as input device and helper. I also have Opera and Opera Mini installed, but to my own surprise the included web browser from Nokia (said to be based on Apple’s HTML rendering engine WebKit which itself is based on KDE’s HTML rendering engine KHTML) is way better, especially in navigation, even although Opera Mini 4.1 caught up a little bit in comparison to Opera Mini 4.0. (Hey, and you hear that from a web browser fetishist and Opera fan!) The only thing which currently really bugs me on the builtin web browser is that even an enforced updating of my feeds sometimes just results in nothing. Maybe a firmware upgrade can help… As barcode reader, I have installed the i-nigma Reader. (The Quickmark QR Code Reader download just showed the content of something which seems to be a Windows DLL instead of downloading it. *plonk*) It’s amazing how fast the i-nigma Reader recognizes a 2D barcode from Semapedia on my laptop screen. Of course I also have ScummVM on my new Symbian phone. I will also play around with Amora which turns your Symbian S60 mobile phone into a remote control for your presentations on Linux (or any other unixoid operating system) running laptop as soon as I managed to get an amd64 Debian package of it. (Currently there seems only i386 packages and no source packages available, but this may be due to the “Show all downloads” link gives a server error…) Oh, and many thanks to foosel since I found Amora in her blog. BTW: Any recommendations for a free (preferably free as in DFSG) Jabber and/or IRC client for Symbian S60 3rd Edition? I already downloaded and installed Gizmo5, but somehow it refuses to work each time I try to create an Gizmo account. Accessories Since the E51 has no QWERTY keyboard, I ordered a Nokia SU-8W Foldable Bluetooth Keyboard at Brack. It was a little bit bigger and thicker than expected, but OTOH the metal case seems to be very stable and robust. Since this keyboard is designed to fit on Nokia mobile phones it also has the two Nokia typical soft keys and the middle select key. So nearly all phone functions can be used with the external keyboard, even turning off the phone’s key lock. Only locking the phone’s keys again doesn’t work via the external keyboard. Additionally I equipped my E51 with a 2GB microSD card. Probably a bluetooth headset for driving will come once, too. What the Nokia 6310i did better than the E51 There are a few things which are annoying regarding Nokia’s UI consistency over the years. That the backspace key is no more the right soft-key is ok. It took me only five tries to get my e-mail account setup without hitting the abort key (no “Do you really want to abort?” questions ;-) instead of backspace key. But what’s really annoying is that the menu navigation via number keys only works for the first level and no more for all levels. So no more “menu 4 4 4” to switch to manual network selection. It’s also annoying that you (or at least I ;-) can’t enter phone numbers as the recipient of SMS directly anymore, at least those SMS never reach their receipient neither do I get an error message. Same counts for the missing acoustic acknowledgment of locking the keypad. You only hear pressing the first key but not even the second key anymore. And if you press the volume keys on the side of the phone, you also have neither acoustic nor visual feedback if you pressed them hard enough so that the volume changed. The 6310i had visual and acoustic feedback. The alarm clock in the E51 seems to be artifically castrated: After having pressed the snooze button two or three times there is no more snooze button on the right the soft key anymore. With the 6310i you could press snooze as often as you want. Only disadvantage with the 6310i in regards of the alarm clock: the snooze time was much too long (10 minutes)… Oh, and what’s also annoying is that I can’t move over the whole addressbook of my 6310i in one piece but have to send each contact via bluetooth or infrared and then the E51 even get’s the contact names mixed up: ‘Beckert, Axel’ becomes ‘Firstname: “Beckert,” Lastname: “Axel”’… Great! I have to edit nearly all contacts manually… The cut and paste feature helps here, but it takes about one to two dozens of key clicks to copy the whole content of a filed into the clipboard… The E51 can run several applications at the same time and that you can switch between them any time. While that’s generally a nice feature I started using quite soon, it’s sometimes annoying that you have to wait up to a second or so after you’ve chosen some menu entry until you can do anything further. Also the screen often flickers while loading applications, showing them, then showing only the background, showing them again, etc. … but finally I already got used to the new mobile phone so much that I already have the feeling that my old 6310i became more thick since I have the E51. (Won’t think about how thick the about ten years old 6130 feels now compared to the slim E51… :-)

Steve Kemp writes about security issues with C programs [1]. It seems obvious that if you are going to do something that is overly tricky (such as anything related to setuid programs) then you should have a good knowledge of what you are doing. Steve goes a little further and suggests that anyone who doesn’t know C should not package a C program. Andrew Pollock is a Debian developer who doesn’t program in C and yet packages some C programs, he explains why he thinks that it’s correct to forward C coding bugs upstream [2]. In this debate I have more sympathy for Steve’s position. Security is one of the most important things in software that we develop, if you can’t develop secure software then IMHO you shouldn’t distribute any software. Although it should be noted that the two posts in question don’t directly conflict. Steve’s main point (your should know the code well to do something relevant to security) does not directly conflict with Andrew’s main point that a non-C coder can maintain the Debian packaging files and forward bug reports related to C code upstream. In the more general case it’s often impossible to know all languages used in a project. It’s not uncommon for a single project to have core code written in C, a configuration file format (which is a programming language), a Makefile (GNU Make is a fairly complex interpreter), Autoconf/Automake (even more complex tools for creating complex Makefiles, and then some Perl or Python to manipulate input or output data. The SE Linux project has code in all those languages plus the M4 macro language. It seems obvious that in a large project the number of people who are capable of understanding all languages which are used is going to be a small sub-set of all Debian Developers. It also seems likely that someone who knows some of the languages really well may be capable of doing a better job than someone who has a passable knowledge of all of them. For the vast majority of my work in Debian I have been a member of the upstream project in question (for Bonnie++, Postal, Portslave, Maildir-bulletin, and logtools I’m the sole upstream developer). Often I start maintaining a package with the intent of doing the minimum needed to keep it maintained in Debian but then end up doing upstream work, for example I briefly had write access to the CVS repository for pppd when I was maintaining it and I had write access to the KDE CVS repository when I was working on KDE packages (which incidentally was before I became an official DD). When I first started working on the SE Linux project I aimed to merely package the code in question for Debian. I was not planning on spending seven years doing upstream work! When I’m working on a project I spend my time working on the things that most need attention. That often means that I get diverted from Debian packaging bugs (which are often minor issues) to work on upstream bugs. In many ways my work practices make me a Debian user and upstream developer who also does Debian packaging rather than a dedicated DD. This of course does have a detrimental affect on the quality of my Debian packaging work - but overall I believe that it’s best for the users! As an upstream developer who is focussed on Debian there are significant advantages in being a DD. I can immediately upload a new package to Unstable without any delay, and there is the potential to take over a related package (either be given the package or NMU) if it’s the best way to get around a roadblock. Another benefit is that in certain limited situations I can speak on behalf of Debian (in terms of packages I “own”). When it comes to upstream development of SE Linux I can make decisions about how things will be done in Debian and work with other upstream developers to ensure that cross-distribution compatibility works reasonably well. It seems to me that a fairly ideal process for managing Debian development would have the people who are capable of the hard coding doing so and some people who haven’t got specific coding skills working on the packaging. I would be very interested in receiving patches related to the Debian packaging of the packages I “own” (in Debian it’s widely regarded that a man’s package is his castle) so that I can spend more of my time on the C coding. I’m not bothered about NMUs (a Non-Maintainer Upload - is when someone else uploads a new version of one of my packages to fix a bug). If anyone would like to NMU one of my packages they are welcome to do so as long as there is a suitable combination of bug urgency, simplicity of the fix, and lack of response from me. If someone wants to start NMUing my packages to fix bugs reported by the latest version of Lintian in Unstable (Lintian is the Debian tool to automatically check for packaging bugs) then that’s OK. Of course there are a variety of other situations that DDs sometimes find themselves in. There have been situations of overtly hostile upstream developers. I try and avoid associating with people who have certain difficulties in interacting with others. If someone is going to change their license and try to back-date the change or create a license that makes it difficult to distribute modified versions of the code then I’m inclined to avoid even using the software, let alone being involved in developing it. This means that the software that I use in any serious way has reasonable people doing upstream development who welcome new people to join their work.

• [1] http://blog.steve.org.uk/adopt_a_less_marital_tone.html


• [2] http://blog.andrew.net.au/2008/04/12#packging_requirements

Share This