Search Results: "ron"

6 July 2007

Wouter Verhelst: Beid issues: survey

I've been receiving a number of bugreports, both formal bugreports through the BTS and just people contacting me through regular mail or otherwise, about the packages for the Belgian Electronic ID card that I maintain for Debian. I think I'm starting to see a pattern in the bugs, but I'd like to be sure; and in order to be sure, I'd like for people who use beid on Linux to please send me the following information: I'd appreciate it if people willing to help me out could send me an email with their answers to the above at wouter+beid@grep.be. Thanks. The pattern that I'm seeing currently is that people using the ACR38u chipset (as in the eID cardreaders sold by Zetes and the government) on amd64- or em64t-based machines cannot get it to work. What I'd like to find out is whether it works on other 64bit architectures, and/or whether it is acr38u-specific. Of course, I'm not doing this on a for-pay basis (I 'simply' maintain the Debian packages), so there's no guarantees of me fixing these issues here. Your cooperation is greatly appreciated.

Russell Coker: Robots vs Sheep

Mark Greenaway writes about writes about robots being designed to remove weeds from farms. This seems like a bad idea given that we currently have an energy crisis due to CO2 emissions from power plants causing environment change (including reduced water supplies), and coal and nuclear power plants requiring water to produce electricity (pity about the reduced water supply). Introducing robots that require either electricity of petrol for operation and also maintenance (which probably requires plastic parts on occasion) seems to be more of a problem than a solution. Fortunately there is already work in progress on training sheep to eat weeds. Given that we already raise sheep for wool and food it makes more sense for them to eat unwanted vegetation (weeds in a vineyard is the example given) than to grow grass specially for them. Also Mark says that the recent increase in oil price is not good news. What would be ideal is a slow steady increase in petrol prices that allows individuals and companies to change to more efficient vehicles (smaller and slower vehicles, hybrid vehicles, and more use of public transport) and also allows governments to make changes (such as building new public transport infrastructure). Having the oil remain cheap until it starts to run out doesn’t do anyone any good (apart from the short-term interests of oil companies).

Share This

5 July 2007

Cameron Dale: Simulating DebTorrent

I've been spending some time on the #bittorrent channel on Freenode, to see if I could get any good information from other bittorrent client developers. After some poor initial contact, I did get some good suggestions, as well as some tidbits of information I wasn't aware of. One of the tidbits was that most of the bittorrent client developers frowned on the use of selective downloading for torrents, to the point where some refuse to implement it in their clients (apparently the latest mainline client doesn't even have it, though I haven't checked due to license issues). This concerned me, as the DebTorrent client I'm working on will rely heavily on selective downloading to only download packages to be installed by the user. It's not clear to me that it would be an issue though. I'm sure it will make it more difficult to find a rare package in a large swarm of peers, but that's to be expected, and is nicely solved by using an HTTP download from a backup mirror. This backup downloading could become extreme though, making the bittorrent-like download (peer-to-peer) mostly just an HTTP download (client-server). To see if it will be a problem, I conducted a simulation of different sized swarms to determine the amount of unnecessary HTTP downloading that will occur. First, some assumptions to make the simulation easier: With these assumptions, the simulation becomes quite simple. I used the popcon data to assign packages appropriately to the N peers. The peers download their assigned packages from the C previous peers, if possible, or otherwise by HTTP. I ran this multiple times, varying N and C, and calculating each time how much was downloaded through the debtorrent protocol, and how much through HTTP. debtorrent wasted.png This graph shows the percentage of the total download that used HTTP from a mirror. The optimal line shows the minimum possible (i.e. all peers are connected), which corresponds to only one copy (the first) of every package being downloaded using HTTP. This verifies my previous thinking, which is that fracturing the download population into multiple small swarms results in lots of inefficiencies, and lots of HTTP downloading. All efforts will need to be taken to keep the downloading populations together. (This is especially difficult for unstable, when a new swarm could be created twice a day due to archive updates.) Swarms of 1,000 peers or more seem to be sufficient to minimize the HTTP downloading. debtorrent unnecessary.png This graph shows the amount of unnecessary HTTP downloading that occurred, which is just the difference of each line from the optimal one in the previous plot. This shows the danger of selective downloading, as all of this unnecessary HTTP downloading occurs because the swarm is too big to find peers that have the desired package (they do exist). Fortunately, this unnecessary downloading seems to approach a maximum as the swarm size increases. For the large swarm sizes needed to make the downloading efficient, and assuming a reasonable number of connections of 100 (bittorrent defaults to maintaining at least 40, and large swarms usually means a large number of connections), we can expect to be using HTTP for about 4% of the download. This number is surprisingly low due to the popularity distribution of packages (only rare ones are hard to find, but they aren't downloaded very often). I think 4% is manageable in our situation, given that there is a backup method to find the rare packages, though it does show the need to have that backup method available. This is probably more of a problem for regular bittorrent clients, in which there is no backup method.

Tollef Fog Heen: Making pancakes

Some people on Planet Debian seem to think that using oil for pancakes is a good idea. They really taste so much better if you use real butter (and preferably an iron pan, not a non-stick one). Oh, and a nice receipe, which almost matches another one is: Mix milk and flour, then add eggs last (blends better that way).

Benjamin Mako Hill: DRM-FREE

Just a couple years ago, music and technology companies would advertise their DRM schemes. While these technologies only served to prevent users of computers and consumer electronics devices from doing things, the media and technologies companies tried to spin it positively. Think of all the wonderful media that the music, film, and publishing industries will be willing to distribute to you at the click of a button, they said. All they asked for in return is the keys to your computer and the legal right to attack and sue you if you try to take control. As everyone who purchased iTunes music and made the mistake of buying a non-Apple DAP incapable of reading Apple DRMed music knows, DRM is a bad deal for consumers. Users are always better off with an unencumbered media file. In all the excitement over major label content, some consumers didn't see this immediately. With time though, the inconvenience of a computer that does the Apple and the RIAA wants over what you want hit home. This, combined with activist projects like the FSF's Defective By Design, have turned the tide. The DRM label that used to be a badge of honor is now a stigma that smart companies are going out of their way to avoid. This past weekend, I saw this flier from Calabash Music in the crepe store across the street: /copyrighteous/images/calabash_drm_table.jpg /copyrighteous/images/calabash_music_flyer.jpg The store served a general, non-technical audience. DRM-FREE, it turns out, is a good way to sell music. Not just to geeks but to any consumer who has been stymied unfairly by DRM or knows someone who has. That, it turns out, is a whole lot people. Consumers know what DRM is and they know don't like it. As consumers learn more about DRM, they want to avoid it. Seeing this, the companies that produce DRM are looking for ways to escape. The Apple/EMI deal seems to be an attempt to protect market share that the use of DRM is threatening. Others, like HBO's Bob Zitter, are disingenuously attempting to escape the stigma of DRM by simply rebranding the technology. Of course, DRM suffers from a much more fundemental problem than bad branding. The problem with DRM is that consumers don't like what it does and are only sometimes willing to suffer through it when not given the choice. Increasingly often, as with in the example of the flier I found, consumers have a choice. Things don't look good for DRM. For DRM opponents, the self-defeating nature of the technology is our greatest ally.

MJ Ray: More on Tardorrists

Kevin Mark commented:
"I see--Redarded Terrorist--ok. So this Gareth fellow is making a comparison with smarter, more intelligent terrorist that was the IRA. Which kind of says that everyone should be far less afraid of the current crop of folks and yet the media, as it does so well, inflates their dangerousness for the sake of ... well, beats me. Oh, maybe it help Tony get a job ;-) If the IRA came to the US, what color (or is that colour) code would their activities get on our terror scale as opposed to these Tardorrists?"
How about Emerald Green? More seriously, I think it's entirely fair to suggest we should fear this lot less than the often-USian-funded Provisional IRA, or local groups like animal liberationists. Those didn't just attack the big cities - it was everywhere, an attempt at terrorism. I lived about three miles outside Milton Keynes, then a fairly small midlands city, which was firebombed by both those groups. Ultimately, it didn't work. Most people weren't terrified. We carried on regardless. The government may be over-hyping this threat to ride in a new load of "expensive and ineffective" Security Theatre measures, like ID cards. Some media is sceptical, but the Murdoch-run media is mostly complicit, which is hardly surprising given the historic relationship. We should not let these "tardorrists" change our way of life, yet that is exactly what our spineless politicians seem to be doing. Let's continue as before: beware, but be happy. Update: niq comments:
"Recommended reading: Terry Pratchett "Interesting Times". Written before "9/11" and set in the wrong part of the world, but nevertheless beautifully relevant."

Lucas Nussbaum: How do archive rebuilds and piuparts tests on Grid 5000 work?

With the development of rebuildd and the fact that several people are interested in re-using my scripts, I feel the need to explain how this stuff works. Grid’5000 First, Grid’5000 is a research platform used to study computer grids. It’s not really a grid (it doesn’t use all the classic grid middleware such as Globus). Grid’5000 is composed of 9 sites, each hosting from 1 to 3 clusters. Inside clusters, nodes are usually connected using gigabit ethernet, and sometimes another high speed network (Myrinet, Infiniband, etc). Clusters are connected using a dedicated 1OG ethernet network. Grid’5000 is in a big private network (you access it through special gateways), and one can access each node from any other node directly (no need for complex tunnelling). Using Grid’5000 nodes When you want to use some nodes on Grid’5000, you have to use a resource manager to say “I’d like to use 50 nodes for 10 hours”. Then your job starts. At that point, you can use a tool called KaDeploy to install your own system on all the nodes (think of it as “FAI for large clusters”). When KaDeploy finishes, the nodes are rebooted in your environment, and you can connect as root. At that point, you can basically break the nodes the way you want, since they will be restored at the end of your job. Running Debian QA tasks on Grid’5000 None of that was Debian-specific. I will now try to explain how QA tasks are run on Grid’5000. The scripts mentioned below are in the debcluster directory of the collab-qa SVN repository. When the nodes are ready, the first node is chosen to play a special role (it’s called the master node from now on). A script is run on the master node to prepare it. This consists in mounting a shared NFS directory, and run another script located on this shared NFS directory to install a few packages, configure some stuff, and start a script (masternode.rb) that will schedule the tasks on all the other nodes. masternode.rb is also responsible for preparing the other nodes. Which consists in mounting the same shared NFS directory, and executing a script (preparenode.rb) that installs a few packages and configures some stuff. After the nodes have been prepared, they are ready to execute tasks. To execute a task, masternode.rb connects to the node using ssh and executes a script in the shared directory. Those scripts are basically wrappers around lower-level tools. Examples are buildpackage.rb, and piuparts.rb. Now, some specific details: Comments and questions welcomed :)

4 July 2007

Jeff Bailey: Leif's Dedication


img_8432.jpg
Originally uploaded by jbailey
Photo taken by Alice Robinette
We celebrated Leif's dedication a couple weekends ago on June 17th at the Unitarian Church of Montr al. I got permission from Diane Rollert, our minister, to post the text of it.

(LJ-cut used to keep it from being too long)


Dedication of Leif Alexander Bailey, June 17, 2007

To the Child:
Leif Alexander Bailey, you have come with stardust in your hair, with the rush of planets in your blood, your heart beating out the seasons of eternity, with a shining in your eyes like the sunlight.

Your parents have brought you here to be dedicated, to celebrate the joy they have and to count themselves blessed that you are a part of their family.

As you grow, may you come to love what it is that your parents and this community of Unitarian Universalists value. May you learn to count the number of your days, to weigh their meaning, to gather into your mind the wisdom of your ancestors, to know why we call one thing right and another wrong, and to treasure beauty, mercy and justice in the deepest places of your being.

To the Congregation:
A dedication in the Unitarian Universalist tradition is one of the few sacred rituals we share together as a community. It is a covenant, a promise of love and care, that the entire community bestows upon a child.
Although Leif and his parents are leaving us to pursue new lives in San Francisco, they have chosen to dedicate Leif here in this church that has meant so much to them. Their travels may take them far away, but in this act of dedication today, we will covenant to continue to hold a place of care and concern in our hearts for Leif as he grows. Do you, as this religious community called the Unitarian Church of Montreal, take upon yourselves the privilege and the responsibility of helping to nurture the character and spirit of this child even at a distance?

Congregational Response:
We who are members of this congregation rejoice with this family in the promise of this child. We pledge him now the love and care of this community.

To the Parents:
Angie and Jeff, parents of Leif, please repeat after me this pledge. Leif, we pledge to help you to realize the best that is in you. We will seek, to the best of our ability, to instruct you by our teaching and by our example. We promise to love you with an unselfish love.

To the Child:
Leif, I dedicate you to the service of goodness, beauty and truth. I touch you with this water, which is a symbol of purity, and with this rose which is a symbol of your unfolding life, on your brow, your eyes, your lips, your heart and your hands, that your thoughts, your vision, your speech, your love and your generosity may be dedicated to the care of the earth and its people. We dedicate you that the transcending power of all that is divine may be present in you all your life long.


Closing Prayer:
Spirit of Life and Transcending Source of Love that connects us all, bless this beautiful child Leif this day and all the days of his life. As we rejoice in the promise of Leif s life that stretches out before him, let us remember those no longer with us, especially Leif s grandmother Glennis Bailey who left this earth too soon to meet her grandson, but whose memory and spirit will continue on through him. May Leif continue to serve with strength as his life unfolds so that the richness and wonder of life may be abundantly his. May peace dwell in his heart,and understanding in his mind. May courage strengthen his will and may the love of truth forever guide him.

MJ Ray: Fon goes wrong

Last month, I looked at running a Fon Access Point. I've not done anything more because of debconf and work, and I've since discovered how to access another firmware upload interface on my F5D7630uk4A (double-click the reset button). I see that some Fon users are moving their routers into lakes in protest at the 15-minute anonymous access offers from Fon. Fon know their sales figures better than I do, but it seems like bad business to introduce that 15 minute free access. 3-euro for 24-hours was already far cheaper than competitors like The Cloud. Message board posters already noticed the loss of sales as people exploit the anonymous access. There's over 300 in the protest lake today. I can't blame them - if your network gets abused for bad things like kiddie porn, the possible problems are terrible. I've seen innocent people punished for running insecure systems in the past. One of the most disappointing things is that the Fon workers seem to be near-silent on this. A few sympathetic posts to the boards, but no official statement yet, as far as I can see. So, I'll not be getting a Fon access point while this problem continues and it worries me for the future, but do you know of any alternatives?

MJ Ray: BBC = Bristol's Bad Cycleways

Bristol is my nearest big city. Its council is told by government to cooperate with ours, but I'm not sure that's a good idea for cycle facilities. They build some good on-road stuff, but some of their other stuff seems just plain insane. Now rider md451, who brought us a video of a ride along the Coronation Road shared-use farcility, has posted a picture of Bristol's "densest white paint in one cycleway" award-winner. Incredible.

3 July 2007

Paul van Tilburg: Ruby D-Bus 0.2.0

Arnaud and I finally managed to release Ruby D-Bus “Almost live from DebConf 7” 0.2.0. The release was planned for DebConf 7. However, I didn’t manage to get it ready in between all the talks, meetings, and other social stuff. Ruby D-Bus is an implementation of the D-Bus protocol in pure Ruby. After starting the development in February, it soon became apparent that several other projects were out there with about the same goal, such as Pure Ruby DBUS and R-Bus. Our approach is to have an API that is close to the old Ruby D-Bus bindings. While the other, similar projects seem to have a slightly different goal, we still invite them to come to some sort of merging so that no duplicate effort is put into three or four separate projects with almost the same result. The 0.2.0 release is our first real public release. We have a large subset of the features working and documented. The main focus of this release was to improve the API documentation and the tutorial. The 0.2.0 release is a release for exploratory purposes. We invite everyone interested to have a look at the API and inner works and provide us with feedback and/or patches. This means that the API can still change a bit over time based on feedback and tweaks performed by ourselves. So don’t built a big application on it just yet if you’re not willing to make some changes later on. For more information, see our project (Trac) page.

2 July 2007

Randall Donald: Requirements Engineering for Web Applications

This past week I've been looking at various methodologies for the requirements phase of web application development. I've looked at UWE, NDT, WebML, Design-driven requirements elicitation and OOHDM. My interest in these has been sparked by an opportunity to readdress and better the process at work. My post here is to basically elicit some feedback from others who build web applications for clients in a professional environment and tell me what works for them.

Ingo Juergensmann: Alice ist nicht die nette Dame aus der Werbung

Wie ich bereits letztens beklagt habe, sind Callcenter die Pest des 21. Jahrhunderts.
Heute allerdings wurde dem Ganzen noch die Krone aufgesetzt.

Heute mittag rief mich der Vater meiner Freundin an, da die bei der Telekom-Hotline nichts von einer Bestellung w ssten und der Port ja sowieso noch gar nicht freigegeben w re. Also rief ich (mal wieder) nach Feierabend bei der Alice Hotline an. Komischerweise habe ich da eigentlich auch fast nur Frauen an der Leitung. Aber die heissen in keinster Weise alle Alice, auch wenn Ariane ebenfalls ein sch ner Name ist. Noch st rker bezweifle ich, da die Damen so h bsch aussehen, wie die Alice in der Werbung. Das w rde allerdings die Unf higkeit der Alice Hotline erkl ren, warum die nichts auf die Reihe bekommen. Man kennt ja durchaus den Spruch, wo der Intellekt in ein entsprechendes Verh ltnis zur Qualit t etwaigen Geschlechtsverkehrs gestellt wird. Sei's drum...

Nachdem ich ber geschlagene 10 Minuten a 14 /min auf die Weiterverbindung von der allgemeinen Hotline zur Abteiligung f r die K ndigungen warten musste, erz hlte mir die eher weniger als mehr nette Dame von der Alice Kundenbetreuung, da ja die K ndigungsbest tigung schon l ngst rausgegangen w re. Auf meinen Einwand, da diese noch in keinster Weise bei uns angekommen sei, meinte sie dann, da sie die gerne noch einmal rausschicken k nnte - so wie die gute Dame am letzten Dienstag dies auch schon machen wollte und wo die Best tigung ja dann am n chsten oder bern chsten Tag da sein sollte.
Dieses Mal hatte Alice, ehm, die Kundenveruntreuerin allerdings wohl dazu gelernt, was sie wohl auch aus der allgemeinen Hotline-T tigkeit zu h heren Weihen bef rdert hat - oder war das vielleicht doch nur die Best tigung f r obiges Sprichwort? Na jedenfalls meinte diese "Dame" dann auf meine Nachfrage, wann wir denn wohl mit dem Eingang der K ndigungsbest tigung rechnen k nnten, da sie das blo ins System eintr gt und der Brief dann wohl gegen Ende der Woche verschickt werden w rde.

Nun sollte man sich ja eigentlich als unbedarfter Kunde freuen, wenn ich blo nicht den Fehler gemacht h tte zu fragen, wann denn der Port abgeschaltet werden w rde. Denn das passiert auch gegen Ende der Woche.
Mit anderen Worten: wenn wir die K ndigungsbest tigung von Alice bekommen, brauchen wir sie gar nicht mehr, weil der Port eh schon freigegeben wurde.

Ohja, manchmal f hle ich mich bei Alice auch wie im Wunderland... seufz

Nico Golde: less colors for man pages

I recently wrote how to use terminfo to get colored manpages.
Today ft came up with a nice feature of less which enables you to set termcap colors by environment variables.

Just use
export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'

in your ~/.$SHELLrc to get the same effect without having a terminfo file.

And again for all the people writing "Install most and set it as PAGER", I know about this but using most because it has colors instead of less is just stupid since less has way more features most doesn't have. D'oh this sounds really strange :-)

UPDATE: from strcat's comment. FOO_TERMCAP can be for all programs which compiled/linked with/against termcap. See man 5 termcap for definitions.

1 July 2007

Russell Coker: Committing Data to Disk

I’ve just watched the video of Stewart Smith’s LCA talk Eat My Data about writing applications to store data reliably and not lose it. The reason I watched it was not to learn about how to correctly write such programs, but so that I could recommend it to other people. Recently I have had problems with a system (that I won’t name) which used fwrite() to write data to disk and then used fflush() to commit it! Below is a section from the fflush(3) man page:
NOTES

       Note that fflush() only flushes the user space buffers provided by  the

       C  library.   To  ensure that the data is physically stored on disk the

       kernel buffers must be flushed too, e.g. with sync(2) or fsync(2).
Does no-one read the man pages for library calls that they use? Then recently I discovered (after losing some data) that both dpkg and rpm do not call fsync() after writing package files to disk. The vast majority of Linux systems use either dpkg or rpm to manage their packages. All those systems are vulnerable to data loss if the power fails, a cluster STONITH event occurs, or any other unexpected reboot happens shortly after a package is installed. This means that you can use the distribution defined interface for installing a package, be told that the package was successfully installed, have a crash or power failure, and then find that only some parts of the package were installed. So far I have agreement from Jeff Johnson that RPM 5 will use fsync(), no agreement from Debian people that this would be a good idea, and I have not yet reported it as a bug in SUSE and Red Hat (I’d rather get it fixed upstream first). During his talk Stewart says sarcastically “everyone uses the same filesystem because it’s the one true way“. Unfortunately I’m getting this reaction from many people when reporting data consistency issues that arise on XFS. The fact that Ext3 by default will delay writes by up to 5 seconds for performance (which can be changed by a mount option) and that XFS will default to delaying up to 30 seconds means that some race conditions will be more likely to occur on XFS than in the default configuration of Ext3. This doesn’t mean that they won’t occur on Ext3, and certainly doesn’t mean that you can rely on such programs working on Ext3. Ext3 does however have the data=ordered mount option (which seems to be the default configuration on Debian and on Red Hat systems), this means that meta-data is committed to disk after the data blocks that it referrs to. This means that an operation of writing to a temporary file and then renaming it should give the desired result. Of course it’s bad luck for dpkg and rpm users who use Ext3 but decided to use data=writeback as they get better performance but significantly less reliability. Also we have to consider the range of filesystems that may be used. Debian supports Linux and HURD kernels as main projects and there are less supported sub-projects for the NetBSD, FreeBSD, and OpenBSD kernels as well as Solaris. Each of these kernels has different implementations of the filesystems that are in common and some have native filesystems that are not supported on Linux at all. It is not reasonable to assume that all of these filesystems have the same caching algorithms as Ext3 or that they are unlike XFS. The RPM tool is mainly known for being used on Red Hat distributions (Fedora and RHEL) and on SuSE - these distributions include support for Ext2/3, ReiserFS, and XFS as root filesystems. RPM is also used on BSD Unix and on other platforms that have different filesystems and different caching algorithms. One objection that was made to using fsync() was the fact that cheap and nasty hard drives have write-back caches that are volatile (their contents dissappear on power loss). As with such drives reliable operation will be impossible so why not just give up! Pity about the people with good hard drives that don’t do such foolishness, maybe they are expected to lose data as an expression of solidarity with people who buy the cheap and nasty hardware. Package installation would be expected to be slower if all files are sync’d. One method of mitigating this is to write a large number of files (EG up to a maximum of 900) and then call fsync() on each of them in a loop. After the last file has been written the first file may have been entirely committed to disk, and calling fsync() on one file may result in other files being synchronised too. Another issue is that the only time package installation speed really matters is during an initial OS install. It should not be difficult to provide an option to not call fsync() for use during the OS install (where any error would result in aborting the install anyway).

Share This

Bastian Venthur: Python, os.fork(), webbrowser and debbugs

Gustavo writes about python, it’s webbrowser module, os.fork and parsing bugreports from our BTS via html. This all sound very familiar, so here are some hints from me:

Biella Coleman: The Worst of the Web: Punditry 2.0

Tonight, instead of minding my dinner, which did burn, I was drawn into and extended a pretty fiery IRC conversation on debian-devel on a topic that does not like to die: the merits and demerits of Wikipedia. It is not worth summarizing the conversation here for it followed a pretty predictable arc. There were those who thought Wikipedia was novel and valuable, others who saw it as a pit of bad facts, and inaccuracies and a few others who saw it in ways negative and positive. I found the conversation somewhat ironic, because I usually find myself defending free software to outsiders much in the same way I was defending Wikipedia to free software developers. I tend to be in the camp of admirers, and for many reasons, although, of course, I also was arguing that it is too early to judge the value of Wikipedia as it is in its infancy. Like Debian, since Wikipedia is an institution that has changed *a lot* in its short history, it is hard to make any hard and fast conclusions about its worth, impact, etc, although more modest and qualified claims are certainly in order. The only reason I feel like I can argue anything about Wikipedia is because I am currently reading a dissertation on Wikipedia by Joseph Reagle. He not only has really insightful things to say about the collaborative culture driving the online encyclopedia, but also about the prolific commentary that has closely followed the heels of Wikipedia in the last few years. Just today, he wrote a blog entry entitled, Punditry and The Web 2.0 debate, which so hit the nail on the head on the problems–not with Wikipedia–but with the peanut gallery (commentary) on Wikipedia. As he notes, the problem is often not with the so called correct or incorrect judgments on Wikipedia (or other Web 2.0 phenomenon) but with the very debates themselves, because many of them are built on a shaky foundation of sand, but this punditry, as Joe rightly calls it, is nonetheless worthy of critical examination:
.. while I follow the discussion with interest, I actually don’t find it substantively engaging. Many of the arguments, particularly Gorman’s, tend to be characterized by unsubstantiated claims and the purposeful construal of nuanced issues as extremes — propping up strawmen for subsequent potshots. As I’ve already indicated, while it might bring pundits a sense of righteousness and attention, in the end “Time, not arguments, will utlimately tell.” (And, for this reason I appreciate Larry Sanger’s continuing efforts to implement his vision.)Why, then, do I find this discussion of interest? Punditry, communicative disorders, and history. First, I’m trying to come to an understanding of “punditry,” and I think Gorman’s recent bloggings is an exemplar. My sense is that sometimes people argue for arguments’ sake. That is, even if they genuinely believe the thing they are arguing for, attention, not persuasion, is the goal. (In a sense, perhaps it is a high-brow, and perhaps more genuinely held, form of trolling — another interesting phenomenon.)
While punditry has always existed, there is no doubt that the Internet has accentuated and facilitated this form of (often male) communication and it is great to see someone tackle this topic. Because let’s face it, there is a lot more “garbage” spewing from Web 2.0 or Wikipedia commentary compared to than the actual Wikipedia articles themselves.

29 June 2007

MJ Ray: Sustainability, Search Engine Traffic and free software webmasters

Regular readers may remember that I'm a vocal critic of some search engines and the unreliability of their fast-changing algorithms. One day you're top ten and the next you're gone. If you're building your business on search engine referrals, you're building your castle on shifting sands. SEOBook: Website Sustainability: What Percent of Your Traffic Comes From Search Engines? has good advice:-
"one of the best moves you can make for the sustainability of that site is to lower the percentage of traffic that comes from search"
That's one reason why I'm glad to see the suggestion of etbe: Advertising Free Software Projects - nearly every free software project would be better off improving their web sites, adding cross-links and building more sustainable traffic, instead of wasting resources competing in the Google-ad Games. Unless you've got the thousands of pounds a year that successful AdWords marketers spend, your Google-ad success will probably be short-lived, as people with more money will outbid you for keywords that work. It's even less sustainable than search result traffic, because it's consuming your financial resources as well as your vounteer time. Meanwhile, most free software project webmasters I know are over-stretched, but many wannabe-contributors seem to want to nuke the entire site to rebuild it with their pet tool. Those offers are really about their ego more than helping the project, in my opinion. They want to Get Themslves Noticed, but I've seen far too many unfinished site rebuilds to like those offers. In fact, I don't think any good webmaster would offer a rebuild without the site owner asking for it - even in the rare cases where I really strongly want to restart a site, I explain why and ask permission first, not just wade in with an offer to nuke-and-rebuild. If the site owner says no, I move on: there's no shortage of work here, after all and very few free software projects pay their webmasters. So, if you want to help a free software project, ask their webmasters for suggestions and access to the site source code.

Martin F. Krafft: DebConf7

I am sitting at Frankfurt airport in between flights home from Edinburgh (not anymore, but that's where this post was born). It's been an intense 2.5 weeks of DebConf7, which has been unlike other DebConfs for me in two respects: this was the first time I actually went to DebCamp, the week leading up to the conference, which is designated to teams and individuals with development goals to achieve during the week. And I was also actively involved in the organisation of the conference, which was unexpected, but a very good experience I am not going to miss next year. Well, it wasn't unexpected. When I booked my flights in January, I had decided to arrive a day early and leave a day late to be able to lend a hand. In between then and the conference, my life turned somewhat upside-down and I had forgotten everything about these noble goals of mine. So when I arrived at the conference venue on Saturday morning with thoughts of netconf circling my head, I was surprised to find everyone buzzing about (how na ve of me) and somewhat clueless as to how I should merge in: my wrists didn't really hold up to heavy lifting, and my knee certainly didn't enjoy stairs, of which there were plenty on the way up to the top floor, where DebCamp was taking place. After trying and being mostly ridiculed by the other organisers ("friends"... ha!), I set out to accomplish some other tasks more suited to my bodily condition, such as wiring the hack lab to accomodate 40 geeks for the first week. That took me most of the day, but at least the space was ready for Sunday morning and the official start of the camp. My goal for the week was netconf and I made good progress until I ran into a wall on Tuesday and had to back off and rethink my design. Reinhart Tartler and Enrico Zini dedicated their time to listen to my design and the problems and helped me clear the mess up and helped me reduce complexity and converge on a straight-forward, event-based design. As the newly appointed DebConf press officer and one of the organisation volunteers, I did not get any further for a few days, as I was manning the front desk or preparing and releasing my first press release (with the help of several others), which lead to a lovely story on The Register and doubled the number of attendees that preregistered for DebianDay (which marks the end of DebCamp and the start of DebConf). I blame the geeks in skirts, actually. Silly bunch, but not quite as silly as those attendants who could get a laugh out of the underwear question for two weeks in a row. Up to this point, I had managed to keep a perfect balance between netconf, orga-team, and sleep. So good, apparently, that when the orga-team t-shirts arrived, Uncle Steve made it quite clear that I should be getting one, even though I had spent considerable time on netconf, am sure some of the others must have worked twice the amount, and I was still quite well rested then. But they gave me a shirt and thus I became part of the orga-team. And even though it was rough at times, running around during the day, filling spare minutes with netconf brain-work, and enjoying nights that got longer with every day of the conference, I am glad and proud to be a member of this team now. It took me until after the official start of the conference to return to the netconf code, but with the new design, I got most of the framework to a point where it could obtain static and dynamic addresses from configuration files as well as DHCP servers in time for my presentation on Tuesday (the recording of which shall be linked from the netconf homepage as soon as it's available). Of course, nothing worked on screen in front of the audience, but noone really expected that anyway. and then I took it all apart for further simplification, so by the time night fell, the slides from the talk had already become outdated as I moved to yet another design, which is even simpler and which allowed me to sketch complex scenarios, such as DHCP after WPA. For two days, I made good progress, but the time available for hacking decreased noticeably, as I kept volunteering for more tasks that needed doing, and more and more people turned up. Somewhere in between, Keith Packard took hostage of (and fixed parts of) my broken X40 laptop, but that's the meat of another story. And on some other night, our leader Sam, in his official capacity as DPL, presented me with the instantiation of my innermost desires as consolation for my hosital stay: a pony. Just look at that smile! With 400 attendants, this year's DebConf continued the trend of immense growth of the event, and while it's great to witness this increase in popularity among attendees and sponsors, who make it possible each year to fly more people to the destination, I am also rather sceptical. The problem is less the additional load on the organising team the next 100 people are going to be easier to accomodate than the previous 100 were. It is more that the conference is losing focus. More people make you spend less time with the same folks, and as the number of non-contributors increases, the social element starts to outweigh the technical element. I am not condemning the social element, but to paraphrase the words of my favourite Debian developer, it's painful to come to DebConf or even IRC with a project and questions just to find that the people are generally more interested in being social, even to the point of preventing technical discussions. I realise that this is a sensitive subject as the issue of various cabals keeps coming up frequently and it does not seem right to start limiting the audience to this conference, but unless we consider the matter, DebConf might deteriorate similarly to other conferences, which have enjoyed enormous growth as well before it was too late. I think we must make sure that people understand that we are, after all, a technical project and must not lose touch with out roots. Of course, I may also be overreacting, after a week of intense coding and many other stress factors I continued working hard on netconf and helping with the organisation throughout Friday, briefly taking time off to prepare a presentation on my Ph.D. research, which was very well received, as well as a workshop on Debian packaging with modern (distributed) version control systems, which yielded around a dozen new subscribers to the vcs-pkg mailing list. But now, back to netconf. All things considered, I was making good progress, but not getting netconf into a releasable state just yet. I can parse /etc/network/interfaces files and get data from DHCP servers, even configure interfaces with those, but it's all still work in progress as I have not yet bothered to implement such basics as default gateways or DNS servers. But the framework is in place, and I am very happy with it as everything I keep adding falls into place beautifully. To mark the end of my netconf development sprint at DebConf7, I scheduled a code introduction session on Friday, where around 15 people turned out to get a walkthrough of the code and explanation of some of my design decisions. The session was recorded and will be available on video shortly. I think it turned out to be a very good idea; I found myself intrigued by someone else's code before until that someone took the time to explain what was going on. I sincerely hope that this introduction helps bootstrap a few people's experiences with the code and yields more contributors! Even though we ended almost every single evening of the two weeks in one of the surrounding pubs, the last few nights were definitely the most enjoyable. On Thursday, the local team had organised a Ceilidh with a band teaching us geeks how to dance the Scottish way, and the venue stayed open for two hours longer than before, causing most people to come out for beer or bouncing about. On Friday and Saturday, the folks of InfoSeed let us use their comfy couches (in the basement of the conference night venue) and we chilled to music and massages, while on Sunday, after a very tiresome day of cleaning up, the noticably lesser number of survivors hung out at the Forest Cafe for some so-so live music, few beers, and an early journey to bed, where a Dutch Muppet kept us entertained for at least another hour. The best about Monday, my day of return, must have been that the airline lost my backpack, which saved me from having to lug it around in Zurich, and made for a great moment on the phone with the baggage tracing service, who announced that my bags would be delivered in about 6 hours between 20:00 and 22:00 just as the door bell rang and the courier dropped off my bag. I'll be back in Argentina, unless something goes seriously wrong. And I'll be on the orga-team again. If you guys stop holding your meetings on Monday night. Thanks to everyone who made DebConf7 possible. I am proud to have been able to contribute, but the real work was done by a few others. You know who you are. NP: Solar Project: Five

Lucas Nussbaum: How old are our packages?

Debian’s binary packages are only built when they are uploaded (or when a binNMU is requested, but that doesn’t happen frequently). They are never rebuilt later. This means that some binary packages in etch weren’t build in an up-to-date etch environment, but possibly in a much older environment. Is this a problem? It depends. Old packages don’t benefit from the improvements introduced in Debian after they were built. Like new compiler optimizations, or other changes in the toolchain that could induce changes in binary packages. For example, some files used to be at some place, but are now put at another place. Also, some parts of maintainers scripts are automatically generated, and would be different if the package was rebuilt today. But is it really a problem? Are our packages _that_ old? Also, when a big change is made in the way we generate our binary packages (like Raphael Hertzog’s new dpkg-shlibdeps), when can we expect that the change will be effective in all packages? I went through all binary packages in unstable (as on 24/06/2007) (both main, contrib and non-free packages) on i386. Using dpkg-deb –contents, I extracted the most recent date of each package (which can reasonably be taken as the date of the package’s creation). And here are the results. Most packages are actually quite recent. 9008 packages (43%) were built after the release of etch. And 19857 packages (94%) were built after the release of sarge. But that still leaves us with 1265 packages that were built before sarge was released, and even one package (exim-doc-html) that was built before the release of woody! (the removal of this package has been requested, so we will soon be woody-clean :-) Now, what could we do with this data? We could review the older packages, to determine if: Here is the full sorted list of packages.

Next.

Previous.