Search Results: "tar"

17 March 2008

MJ Ray: User-Generated Content Rebellion: First, the Librarians and Scientists?

I've been critical of the almost abusive terms in the user agreements of most user-harvesting-based services (sometimes called Web 2.0) for a while now. There are quite a few services that I simply won't use because their owners want me, all my web "content" (whether explicitly posted to their site or not), my first born child, or similar. There are even more sites where I'm careful not to put much beyond the bare minimum and try to make sure that I keep backups of nearly all of it. Usually that means keeping a copy of the input, as getting my data back out of most sites is a pig. So far, when I've criticised aggressive user agreements, I've felt like a lone voice in the wilderness. It's been heartening to spot two user-harvesting services geting some abuse over the last week or two. First, the Swift online community platform for conferences has been attacked by both David Lee King and librarian.net for its over-zealous user agreement demands. Particularly "nice" is the feature where one rule of Swift club is that you don't talk about Swift club (see last paragraph of David Lee King's post). Swift's owners have responded. I'll watch and see whether it improves enough to get a follow-up post from either blog. Secondly, the Phorm advertising system has faced hard questions from both Open Rights Group and Sir Tim Berners-Lee over its mysterious user tracking. Phorm hasn't yet replied properly about their potential to harvest user-generated content (web histories and so on) without consent, as far as I can see. If you know anyone on Talk Talk, BT or Virgin, tell them to start planning the exit route. If you'd like to refer them to our agency for The Phone Coop that would be great. I suspect the owners of The Phone Coop would get quite vocal if it ever tried to track users like this and a comment on the ORG post suggests someone else has asked Are we seeing the start of a user-harvesting backlash?

16 March 2008

Gregor Herrmann: sunday evening

finally, after waiting for some years, we now get the profil delivered directly to our doorstep on sunday mornings too, instead of stuffed into the mailbox on monday by the regular postal service. it started two or three weeks ago, but today was the first sunday where I actually managed to take my time to read it on the first possible day.

spending two hours in the bathtub with a news magazine that is officially released only tomorrow is a good break between Java packages before & Perl packages afterwards.

John Goerzen: The Power of Love

A few years ago, Elvera Voth, a musician that grew up a few miles from here was back in the area. Her specialty is vocal music, and one evening, she led a hymn sing at our church.

During the event, she talked about how much music can touch the heart. Elvera remembered many years ago that a woman in the church was leaving for a service trip to India. She would be gone for 7 years straight. None of her family or friends would be able to see her during that entire time.

The day she was to depart, friends, family, and church members went with her to the Santa Fe station in Newton, KS. While waiting for her train, at some point, the group started singing. Elvera remembered that they sang So nimm denn meine H nde (Take thou my hand, O Father) and Ich bete an die Macht der Liebe (O Power of Love).

Elvera remembered they sang in the station, and the high, wood ceilings made it sound like the music filled the whole building. I can't think of a better goodbye than that.

Elvera remembered so many details about the event, but two things she didn't remember were who was leaving and what year this happened. So I remembered this story for awhile, but didn't really follow up on it.

Then last December, our neighbor Hildred called. Hildred and her sister live on their old family farm about a mile from us. They're some of the older members of our church, and I believe both of them have lived on that farm their entire lives. Hildred heard that I am gathering photos for a book about the centennial of our church, and she offered to bring some of them over. Knowing that it was cold and dark outside, the roads were snowy, and that Hildred drives a car at least 40 years old (because "Daddy said this is a good car"), I offered to drive to their place. "Oh no," she said, "it's no trouble. I like to get out. Besides, I haven't seen your house since it's been remodeled!" So she came over.

Hildred had stacks of amazing old photos from the church and the community. And she had a stack of photos and letters from India, where her aunt Augusta Schmidt was a nurse for 14 years. She was very proud of her aunt's service to the needy there. I started to put things together in my head and asked her if she remembered singing at the train station when Augusta left for India. "Oh sure," said Hildred, as if everyone knew about that.

So that's how it happened that the "historical moment" on Feb. 10 was about Augusta Schmidt. Each month during church, leading up to our centennial in October, we have a brief time where we highlight some interesting story from the church's past. I happened to mention this one at a historical committee meeting.

So, on that Sunday in February, someone got up and told everyone about Augusta's life. She was born in 1894 and graduated from college with a nursing degree in 1927. She heard about India at a conference, and quickly felt that God wanted her to serve there. She left for India in the fall of 1927, and would serve two 7-year terms there.

She wrote that India was a beautiful land, contrary to things she had heard. The city where she worked (I believe it was Bombay, but I'm not positive) had hallmarks of a wealthy city, such as educational institutions, hotels, etc. However, it saddened her greatly to learn that 80% of the people in the city were homeless and slept on the street. No doubt this played a role in her dedication to service there.

After we learned about Augusta, the choir sang So nimm denn meine H nde -- one of the songs that Augusta heard at the train station back in 1927. Imagine you were there, 81 years ago, seeing a friend off on a trip across continents, not to see her again for 7 years. Then the people there start singing a cappella...

So nimm denn meine H nde
und f hre mich
Bis an mein selig Ende
und ewiglich!
Ich kann allein nicht gehen,
nicht einen Schritt;
Wo du wirst gehn und stehen,
da nimm micht mit.
Take thou my hand, O Father,
and lead thou me,
until my journey endeth
eternally.
Alone I will not wander
one single day.
Be thou my true companion
and with me stay.


You probably weren't there that day in 1927, or even the day in February when the choir sang the song. I wasn't either because I had the flu that day. But I borrowed the cassette recording of that day's service, recorded using the best we have right now -- the wrong type of microphone pointed the wrong way, onto a cassette tape that has certainly been reused way more times than anybody knows.

Click here to listen.

The choir sang the first verse in German, verse 2 in English, and the whole church joined in on verse 3. I'm told there weren't many dry eyes in the church after that. After all, how could you keep a straight face singing "Take, then, my hand, O Father, and lead thou me, until my journey endeth eternally" right after the narrator read about Augusta's retirement and death, saying, "there, I was surrounded by friends, but most of all, by the sovereign love of God who had been with me my entire life."

Postscript

Remember Elvera Voth, from whom I first learned this story? In 1961, she moved to Alaska. Elvera taught at several universities; founded the Anchorage Opera; directed the Alaska Festival of Music, Anchorage Boys Choir, and Alaska Chamber Singers; and there is Elvera Voth Hall at the Alaska Center for the Performing Arts.

But her best work, I think, happened after she retired and moved back to Kansas in 1995. In 1998, Elvera founded the East Hill Singers, a choir composed mainly of minimum-security prison inmates, plus volunteers from the community. Elvera has inspired so many people, taught them that they have value, that they can succeed and make themselves better. One of the said:

Can you imagine what a standing ovation feels like after being told all your life that you are worthless?


And another inmate commented:

It made me feel like maybe I'm not just being punished. I mean, I am being punished for what I did. But being in this program made me think that I can also come out well, better a better person.


It all makes me think. What an amazing thing these two women with love in their hearts have done to make this planet a better place. Is it even possible to do that by using weapons that kill and power to frighten?

As Elvera puts it, "many of the men in prison will be back in the community soon. I'd rather have them as a neighbor with hope in their hearts than with hate in their eyes."

Simon Richter: What is Debian's role?

I must admit that I feel slightly uneasy about this, because it blurs the distinction between maintaining a package and forking it even more than it is already. Some improvements have long been necessary, since we really need to handle more archive formats, or the situation where upstream ships five tarballs and two patches, however I think the quilt support is a step in the wrong direction. There is nothing wrong with quickly fixing a problem in a package so Debian users do not have to wait for the fix to be incorporated into an upstream release; however for that we don't need a sophisticated system to keep patches separate and forward-port them to new upstream releases easily. Let's face it: the quilt integration into the build process exists because we expect to maintain these patches for months. On the other hand, there is an effort to synchronize these changes between distributions. The question to me is: if all the distributions can agree that a certain change has to be made, why cannot this change be committed upstream? Is Debian failing to submit patches, or are our patches just unacceptable because they break every configuration except ours? I can absolutely see the need for a tool to assist in forks, ideally one that will allow us to easily submit these patches to upstream developers easily, and ideally so they can pick them up with a minimum amount of hassle. Now why does this entire discussion sound so incredibly familiar?

Joachim Breitner: The problem with turing complete editors

I was just editing a file with vim and was about to do the same few strokes repeatedly. I vaguely remembered something about recording macros, so I tried it: I pressed q-1 to start recording, did my steps (a yank, a movement, an insert, a paste, a movement), and finished the recording with q. Now I could repeat these steps with @-1.I then noticed that I forgot something at the end (moving the curser to the beginning of the line). I re-started recording (q-1), thought hey, maybe I can insert the old recording here and pressed @-1. Surprisingly, that worked. I added the missing movement and finshed the recording with q.When I then tried to recall these commands with @-1, the editor froze and I was wondering whether the network connection went down (I was working over SSH). But it wasn t, and it dawned me that vim did not insert my old commands when re-recording the macro, but just inserted the call to the macro itself. My text editor was caught in a infinite loop...Not too bad, I just killed vim, did not lose anything and everything was fine. But I think an editor, even vim, should somehow prevent such behaviour.

Daniel Burrows: Apologies for spamming the planet...

I just happened to take a look at the output of a Web log analyzer and noticed a huge increase in traffic yesterday. I thought that was odd, since I hadn't written any new blog posts recently or published new stuff on my Web page. So I took a look at the logs themselves and noticed that a whole bunch of my recent hits listed their referer as planet.debian.net. This is where you start getting a sinking feeling...and yes, when I checked the Planet in a Web browser, sure enough, it looks like my whole blog got dumped out on the Planet. For some reason my own RSS reader didn't pick it up, so I wouldn't even have noticed if I hadn't been checking on my Web server stats. I'm not sure why, but I bet it has to do with the fact that I upgraded ikiwiki yesterday. So if you've seen the new ikiwiki version that came out recently, take a little care when you update and make sure it doesn't impact your RSS feed.

Alexis Sukrieh: The road to Backup Manager 0.7.7

Dear lazyweb, this sunday afternoon, I opened BackupManager’s Bugzilla and started squashing bugs. There was 54 bugs opened that requested a review. 15 of them are now tagged “pending” (meaning they’re closed in SVN and will be shiped with the next release). All of the patches submited - that made sense - were applied, thanks to all the reporters for their help, by the way. So, fear a new release soon…

Adeodato Sim : The X-Collab-Maint header

I’ll blush and admit that I’ve always been a bit of the “my package my castle” type. But things change, and now I feel differently about my packages. I toyed with the idea of adding myself to the low threshold NMU list, but it didn’t make me very happy for several motives: Then there is the collab-maint project in Alioth, which is nowadays intended as a general purpose area for small teams or groups of co-maintainers to collaborate in their packages, without needing to create a full-fledged Alioth project. Every DD and many non-DD have write access to it, but a package being there does not mean that its maintainers want other people to use such write access on their packages. But, alas, there is no standard way of saying that you do want people to make use of that access, and how (of such way could also benefit projects that make use of the Debian acl, to advertise the fact). So, as a first draft to fill in these gaps, I’ve migrated several packages of mine to the collab-maint umbrella, and added a X-Collab-Maint header to debian/control to signal that I’m open to collaborations on them. For me, a header felt the best way to express this information, since it ends up being very accessible (only one apt-cache showsrc away). As Zack points out to me, though, having it in a header doesn’t necessarily mean the source of the header has to be debian/control forever (think e.g. what debtags does) — this leads to interesting possibilities, like changing the policy without an upload, or setting the same policy for a large set of related packages. As for the contents of the header, I think a reduced vocabulary would work best. As a start, this is the one I’ve been using for my packages: Other stuff that’s could be specified includes whether people making a commit should notify the maintainer or not, before letting the upload day count tick. But, if the idea seems worth it, I’m sure we can debate it to death on -project, or something.

Andreas Barth: semantics in ldap - anyone out there?

Ldap seems like a good database to store accounts in: Lots of tools can use it, it's easily integrated into pam, and lots more. But one sometimes just hits borders in the data model of openldap: There are no semantics available. So, let me give you an example. Take e.g. the dnsZoneEntry attribute in the debian.org-ldap. Actually, one wants to allow anyone to write into that attribute in his own entry. But - and that's a big but - one wants to have two additional checks before writing: One is that one cannot claim any dns entry already used by someone else. And the other is that the format needs to comply to specific standards. Now the question is, is there some way to use ldap with more semantics? Or does one need to write ones own backend to do that (and in all the non-plain-db*-backends, it is specified that one needs to write his own authorization code as well). Or some other recommended way to do that? (Or is the only existing incarnation of that ActiveDirectory?) Update: Thanks to Faidon Liambotis I know now about the overlays in openldap. The standard overlays unique and constraint will probably solve the case above - of course, I have a few more complex cases, but that are at least good starters.

Cyril Brulebois: Getting things done

emacs-goodies-el pkg-games pkg-phototools Misc. Of course, that's just an excerpt of the actual todo-list

Steve Kemp: E.T. phone home

I've just finished reading "Don't You Have Time to Think", a collection of letters written to and from Richard P. Feynman. A birthday present from my wishlist. Previously I've read the collection of letters to/from Tolkien. (Several times actually. Very nice collection!) It suddenly struck me that over my lifetime I've probably written <200 letters to people. When I was young I had a couple of pen pals, and when I was entering university I was involved with a couple of play by mail games which involved writing random letters involving strategy & etc. Personal letters though? I've written very few, and I think they've mostly consisted of letters to my partner/partners of the time. (For example Megan went home for a few months at the end of a university year about two months after I initially met her. So there were many letters back and forth. Recently she spent two months working in the USA; counting eggs and avoiding alligators so again there was a flurry of written letters, maybe 20 total during the duration of her trip.) I guess that most of my (hand)written messages to people have been in the form of postcards whilst on holiday. A long time ago I offered to mail postcards to Debian developers. I know I sent at least two, and I received at least one back - but the thing I remember most was exchanging addresses with Amayita and getting into character set issues. Her emails, containing her Spanish address, were difficult to understand as my mutt/console refused to display the foreign character set properly. I can't recall whether she did ultimately receive a card from me, but I'm sure she'll remind me if she did. Anyway I have no resolution, intention, or expectation that I will suddenly start writing more physical mails to people. But I think it almost counts as something we do less of these days. The telephone and internet have become the norm. In some ways this is fantastic. In others it less good. On the left my handwriting is so bad that maybe this isn't necessarily a problem. ObQuote: E.T.

Adrian von Bidder: Adams bler

Another week has been spent in a repetition course in the military. Readers of my blog will know that this means playing poker (I lost about CHF 7 this week — we just play for fun at CHF 5 for 50 chips) and watching movies. Tron and Kill Bill Vol. 1 from my collection, and the extremely funny Adams bler which I didn't know before. The story centers around a neo-nazi serving some time in some kind of rehab in a church where, it is soon discovered, the priest in charge of the whole thing is not that much in charge, even of himself. I'm told that I also should watch I Kina spiser de hunde by the Danish Anders Thomas Jensen (writer and director of Adams bler, writer of In China they eat dogs.) Also recently watched Casino Royale (the recent Bond movie. I haven't seen the 1967 one yet.) and The Gold Rush: the 1942 version with added spoken narrative and music by Chaplin. The DVD does contain the original 1925 silent movie, too, where especially the ending is a bit different. And finally lots of episodes of , ! (Nu, pogodi!), which was the Soviet equivalent to Tom and Jerry (not a clone, it is entirely different.) I can highly recommend this to everybody who likes cartoons.

15 March 2008

Daniel Leidert: Diploma exams are calling: Please read if you want to NMU my packages

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU: GCC 4.3 transition Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug. PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor. gfortran transition Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names. apbs and psicode already have been transitioned. Other bugs Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:
#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’
Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.
#438694: gabedit: Crashes when loading any XYZ format file
Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.
#442223: openbabel: some connect information lost when convert from pdb to txyz
Nothing examined yet to solve this bug.
#464867: extrema: conflicts with psi3 package
Hope, my team will cover this asap.
#465723: mopac7 — please do not use g2c.
There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.
For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622. New upstream releases It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days). In all other cases, new upstream releases should be easier to handle. ITPs All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:
docbook-xsl-ns
See the above note about docbook-xsl and the source package split.
html-xml-utils
Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.
DocBook 5
I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I’m not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.
QA work/fixes Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded. I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

David Moreno Garza: Places I've lived in

Recently, chatting with some folks on the TextMotion IRC channel, I started thinking on the places I ve lived my whole life. From the bottom of my mind, this is a rough list: Such is life :)

Daniel Burrows: Full upgrade and conflicts

Erich Schubert wonders how to improve the handling of conflicts in package managers, particularly in aptitude full-upgrade and apt-get dist-upgrade. From the point of view of the package manager, conflicts are a bit tricky to deal with. The problem is that a conflict only really tells you not to install two packages at once; it doesn't tell you which package should end up on the system by default. Worse, aptitude has two approaches to this:
  • When a package is marked for installation in the visual interface or listed on the command-line, then if Aptitude::Auto-Install is enabled, aptitude will automatically resolve conflicts in favor of that package. The same applies to packages that are upgraded by pressing U or by full-upgrade.
  • When aptitude's dependency resolver encounters a conflict, it considers both resolutions to the conflict to be equally valid. If there are no other reasons to choose one package over the other, it will be unpredictable which one gets removed first, and even when there are reasons to choose, the user may not understand what they are.
I don't think it's possible to always make upgrades predictable. But I think that even just making Auto-Install stick to installing packages and not removing conflicts would be a plus. Installing obvious dependencies up-front is good because it means less work for the resolver and a more predictable starting point. Many trivial dependency problems can even be completely solved this way. But removing conflicts is a lot trickier and should probably kick the problem into the full resolver. Unfortunately, the code enabled by Auto-Install is all deep in the guts of libapt. I've tried to avoid duplicating this code so far, but it does seem like I periodically run into cases where it doesn't do exactly what I need, so maybe I'll have to eventually. :-(

Daniel Burrows: HOWTO convert your Blogger/BlogSpot blog to ikiwiki

Until recently, my blog was hosted on Google's free Blogger service. When I decided to move to my own server and ikiwiki, I didn't want to lose all my old posts. But exporting your blog from Blogger is a bit tricky. In fact, the Blogger page that provides instructions on how to do so starts off by saying:
Blogger does not have an export or download function.
Regardless of what they say, you can cajole Blogger into exporting text for use in other blog systems. Instructions for moving from Blogger to various pieces of software are available out there on the Web, but to switch to ikiwiki I had to tweak them a bit. Here's the procedure I used:
  1. Extract your information from Blogger's clutches and add minimal IkiWiki tags. As in the official Blogger instructions, change your template temporarily. However, instead of using the page template they suggest, use the following template, which you can find as a text file here.
    <Blogger>
    [[meta author="<$BlogItemAuthor$>"]]
    [[meta date="<$BlogItemDateTime$>"]]
    [[meta title="<$BlogItemSubject$>"]]
    <$BlogItemBody$>
    </Blogger>
    <BlogItemComments>
    Comment by <$BlogCommentAuthor$> at <$BlogCommentDateTime$>:
    <$BlogCommentBody$>
    </BlogItemComments>
    
    I recommend saving the file that's produced by this step even after you process it in the next step, in case you discover that you made a mistake.
  2. Split the extracted file into pieces. Exporting your blog using the template above will get you all your blog posts in reasonable Markdown format, with all dates and titles preserved. But they'll all be scrunched into one file. Blogspot also won't interpret paragraph breaks into blank lines, and it inserts strange empty <div> tags all over. So the next step is to split this file into pieces and clean up the HTML. Since I had over a hundred posts, I wrote a Python script to do this postprocessing for me. You can find it here. You can run it like this to output each blog post as a separate file in the current directory:
    /path/to/fixup-blogspot-export input-file
    
    This script makes a few assumptions about its input file:
    1. It assumes that the text [[meta author="NAME']] does not appear at the start of a line anywhere except the first line of a blog post. If you write about MarkDown syntax on your blog, you will run into problems.
    2. It makes a similar assumption about Ikiwiki's date meta.
    3. It assumes that line breaks are expressed using a variant of <br/>, and that <br/> never appears in the text of your blog.
    4. It assumes that the text Comment by does not appear at the start of a line in any post.
    5. It assumes, in general, that no Markdown or Ikiwiki commands appear in the blog text. If any do, you'll have to manually escape them, either before or after running the conversion script.
    All in all, it's probably a good idea to at least skim the output once.
  3. Create a top-level Ikiwiki page for your blog. The Ikiwiki site has instructions on doing this that are probably better than I could write. The most important thing is to use the created-after tag to limit your RSS feeds, so you don't spew new posts all over the planet (pun intended). For instance:
     [[inline pages="./blog/entry/*"
              feedpages="created_after(last_page_of_the_old_blog)"]]
    

Daniel Burrows: Why so few X maintainers?

Andrew McMillian asks why X.org has so few active developers:
[Bernardo Innocenti] did a quick and dirty analysis of Xorg LoC vs Linux LoC, to give a "X codebase is roughly 1/2 Linux codebase" (which surprised me, actually, I'd always thought it was larger) and then a similarly rough analysis that suggests that Xorg has roughly 1/20th of the developer base. To some extent Bernardo's metrics are arguable, but the basic facts are that Linux gets the lions share of the developers. Is this what we should expect? Is this a healthy way for the free and open source software community to support the development of what I personally would like to see as the future desktop base?
There are a lot of factors involved in determining which projects get more attention. I'd imagine that things like the amount of domain knowledge required to contribute a simple patch, the structure of the code, the amount of press that a project and its maintainers get, and the presence (or not) of a charismatic and photogenic leader. You could probably even base your entire academic career on studying this question. But I also think we shouldn't underestimate the impact of paid jobs. Admittedly, I have never asked whether I could get paid before jumping off a cliff and starting a new project. But on the other hand, I now effectively work two jobs and only get paid for one. Most people are not as stupid as me, and will rationally choose to spend their time on tasks that they actually get compensated for. Even people who don't care about being paid will find it difficult to continue contributing over time due to practical issues of their personal life, families, etc, and they won't be able to contribute as much as if they were working full-time. It's well-known in the programming community that if you can hack the Linux kernel, you can pretty much write your own job description [1]. On the other hand, I've never heard that companies are looking to hire skilled X programmers. A quick pair of searches on that font of knowledge, Google, seem to back this up. Compare the results for x programming jobs -"active x" -"OS X" and linux kernel programming jobs[2]. Nothing on the first page has anything to do with being paid to work on X.org, whereas the second search gives me an entire page full of people offering to pay me money if only I knew how to hack the kernel. KernelTrap, a central site for information on the kernel, even has a job board just for jobs related to kernel programming. That's not to say that the X coders don't get paid; I'm sure many of them are compensated for their work on X, and given the level of expertise involved they're probably paid well. Companies that manufacture graphics cards have an interest in employing people to hack on X; Linux distributions and embedded hardware manufacturers also benefit from a better X and strike me as likely places of employment for X hackers. But there doesn't seem to be anything for X.org like the cornucopia of available and well-advertised jobs related to the Linux kernel. Programmers who want to be paid someday will, on average, end up gravitating to the project where the prospects are obvious, not hidden. [1] Note that for the purposes of this discussion, it doesn't matter whether this common wisdom is true. The perception of jobs available in Linux-land will tend to cause people to head towards Linux regardless of whether the jobs exist or not. [2] I also tried x server programming jobs -"OS X", x.org server programming jobs, x server jobs -"OS X", and x.org server jobs without notable success.

David Nusinow: Random Bits

I've been extremely busy with labwork lately, trying to get a second paper ready for submission in the coming months. It's taken an obvious toll on my free software work, but that's life I guess. The upside is that the other night I realized why a year and half's worth of experiments kept turning up with negative results that seemed to contradict our other results. It turns out that this experiment was conceptually flawed, and even though I wasted a year and a half on this I did learn something even from those negative results that should go in to the final paper. I'm actually relieved, because even though I don't have all the data yet I can really see how the paper will end up, so I can start writing soon. Oftentimes knowing why something is wrong so you can fix it is even more important than being right.

I set up an ikiwiki to help organize my lab data a few weeks ago, and it's been a huge win. Joey really did a fantastic job on the program and I can't imagine using a wiki that doesn't share a very similar design for any of my personal stuff. I showed my boss some of my data using it and now he wants me to set up a wiki for the lab. He actually wants me to show off my wiki to give my lab members a feel for the idea. Since ikiwiki doesn't seem to be appropriate for my lab members, I'm going to have to look in to the giant list of wikis to figure out the exact right one for my lab's requirements. This is something I never expected to be doing in grad school.

Because there's no way my brain can go without doing a little bit of programming, I finally sat down and wrote myself a small shell script that lets me grep through pdf's, which is something I couldn't find googling around. If you have a lot of pdf's like I do and don't something like beagle or tracker churning away in the background constantly just so you can search them, this is very helpful. It's obviously very crude, but it gets the job done nicely. It relies on the pdftotext program; hopefully it'll be of use to someone.

I've been digging in to my copy of UNIX Power Tools lately, trying to pick up new UNIX and vi arcana, which is something I haven't made a real serious effort to do in a long time. It's been surprisingly fun to try and replace old habits with things that I know are better but don't use. A good example is that I usually will fire off a new subshell in vim when I should really just suspend vim and use my original shell to save time. Re-examining the basics of how I use the system has been a lot of fun, and has made me a lot more comfortable with the simple day to day tasks.

Pierre Habouzit: a RC Bug a day

keeps the release away. That's why, following Sesse last year, I started to work on (at least), one RC bug a day. If I do that alone, and that no new RC bugs are opened[1], we will release in 460 days; now if 10 DD do the same, it becomes 46 FWIW, today, I made Luk (Claes) reassign and downgrade #470453 and sent a DELAYED/2 NMU for #470002. And you, what did you do for the release ?
Notes [1] har har har

Patrick Winnertz: How to get most spam?

I've created a small contest together with several other guys. We'll try to get as much as possible spams on a emailadress. The people with the most spam and viruses on his emailaccount will win. I think a good starting point is to publish here, we'll see. Some other things which could end in having success are: If you have other ideas how to get as much as possible spam to this address please write a Comment to this post to the Discussion page. Thanks in advance The emailadress which should recieves as much as possible spam is: winnie@qsc218.credativ.com.

Next.

Previous.