I've always been puzzled that, quite often, a package is totally silent for a long while (say a month or two), and suddenly, you get two or three bug reports the very same day, distant from any release or transition to testing. I've seen that mostly with libqt4-ruby and pmount. This seems to be rather general: it really looks like events of our lives don't even remotely follow uniform probabilities. I've had a recent confirmation with ctioga, a project of my own. I just need to decide to release a new version to realize just afterwards that I've got many more features to add (not less than 20 significants commits since the release a week ago !)... Life is not linear ! (and I won't complain).

I like autotools, I use them widely and I'm happy that I understand autotools sufficiently that I can be confident in using them and helping others with theirs. All my own upstream C projects rely on autotools and I have a personal rule that I always preserve make distcheck compatibility during CVS/SVN changes and without fail prior to ALL releases.
Lenny will be the second Debian release with which I've been involved and as I prepare to round on the RC bugs once again, I'm noticing a pattern in autotools bugs from other upstream teams.

1. If more upstream projects enforced rigorous testing with make distcheck, a lot of bone-headed numbskull errors would be prevented in the upstream codebase. Fixing make distcheck isn't that hard because it is a test of the build system files, not necessarily the source code. Once an upstream build is fixed, subsequent make distcheck failures are both rare and serious. Other failures in the test suite should be easier to spot too. The important point is that make check only tests the current build on the upstream system. make distcheck goes a long way to ensuring that the package will build in the same way on lots of systems, including cross builds.


2. autotools expects such fixes to be made upstream and fixing things after the release can be a serious PITA, so fix it before release.


3. The single greatest weakness of make distcheck and autotools in general is bit rot. It is so important for upstream to refresh the autogenerated files on an intermittent basis. With a big development team, this can be easy - especially if new people are regularly joining and building the source for the first time from CVS/SVN. Once that rotation stops, the difficulties of trying to fix the upstream code get more and more noticeable. Maybe one day autotools will fix this and become more resistant to bit rot but, for now, it is a significant problem.


4. As a consequence of file rotation, it is seldom a good idea to keep any autotools generated files in any form of RCS, even distributed ones. This is where I fall foul of many who want to package directly from SVN CVS foo. The mantra of lots of RCS helpers is "everything must be in the RCS" which is just plain wrong IMNSHO. The only things that must be in any RCS are the bits that upstream needs to write. So Makefile.am is, Makefile.in is not. configure.ac is, configure is not. Same for libtool, ltmain.sh, config.* and a host of other autotools generated files. If autogen.sh can generate or symlink them, don't have them in RCS. If, as upstream, you have not had to edit the file or copy it into place using a patch supplied by someone else, it should not be in the RCS. This discipline ensures that when someone starts from a fresh checkout, the build system is refreshed (and is why many autotools upstreams add a "make rcsclean" rule that goes one stage beyond make distclean by going back to raw RCS). If you maintain a helper that is meant to build packages like this, ensure that the helper has support for getting from raw RCS to make distcheck and ensure that the helper uses the tarball created by make dist not one of it's own.

Yes, bit rot is the curse of all software but when combined with the lack of usage of make distcheck prior to upstream falling quiet, I sometimes wonder about the merits of trying to fix bugs in the build system of packages with a most recent upstream release that precedes Etch. I get a real chill thinking about upstream packages with a most recent release that precedes Sarge.
So, if you're working on an upstream project using autotools, just do everyone a favour:

 svn cvs  ci -m "make sure things work"

make uninstall

make distclean

./autogen.sh

./configure --prefix=... 

make

make check

make install

make distcheck

Repeat the last stage until it completes without errors, commit the changes and retest from the beginning.
I'm not proposing something I do not do myself - as above, I do these tests on my own (released) upstreams on a regular basis. I just wish more upstreams would do so too. If every upstream did this prior to that final release, it would be so much easier to do all kinds of cool things with your code, long after you lose interest in it yourself.

Anatomy of a Murder. David Denby put it best:

Otto Preminger s Anatomy of a Murder, from 1959, is still the best courtroom drama ever made in this country, and, in its occasional forays out of the court, among the finest evocations of place an Upper Peninsula Michigan resort area in the off-season, leafless, underpopulated, alcoholic, and forlorn. James Stewart, in one of his wonderful melancholy late performances, plays a former county prosecutor named Biegler, a lifelong bachelor who now spends his time with a non-practicing lawyer (Arthur O Connell) and an unpaid secretary (Eve Arden), who sticks around for the wisecracks. The movie is leisurely, detailed, realistic, intensely companionable; you get a sense of how people exist at the margins of a profession without losing their dignity.

Although there are some distinctions between a murder defense in the 1950’s in the Upper Peninsula of Michigan and modern-day patent litigation, the essence of trial technique is really not all that different. Highly recommended.

Prosecutor: Lieutenant Manion, wasn’t your action against Barney Quill much the same thing as your action against Miller or the Lieutenant you slapped at the cocktail party — all done in the heat of anger, with a willful, conscious desire to hurt or kill?

Defendant: I don’t remember my action against Quill.

Prosecutor: How long had you known your wife was stepping out with Quill?

Defendant: I never knew anything like that. I trust my wife.

Prosecutor: You just occasionally beat her up for the fun of it, I suppose?

Defense Counsel: There has been nothing established to permit a question like that. He keeps trying to insinuate without ever coming to the point. Let him ask the Lieutenant, did he ever beat his wife.

Judge: I will sustain the objection. Do you want to re-phrase your question, Mr. Dancer?

Prosecutor: No thank you, Your Honor. I’ve finished.

Technorati Tags: Otto Preminger, Anatomy of a Murder, David Denby

Share This

About a year ago I stumbled upon this post which mentions the following shell keybindings: M-- for pushd .. and M-= for popd. Since the dash and equal signs are very conveniently placed next to each other, this allows fast directory navigation with accessible keystrokes and is especially convenient to move up in the directory hierarchy. Very neat.

Of course I use zsh and not bash, so I had to "port" this hack to zsh, which resulted in somewhat obscure code compared to the bash version:

function up-one-dir   set -E; pushd ..; set +E; zle redisplay; zle -M  pwd   
function back-one-dir   set -E; popd; set +E; zle redisplay; zle -M  pwd   
zle -N up-one-dir
zle -N back-one-dir
bindkey "^[-" up-one-dir
bindkey "^[=" back-one-dir

Not so pretty, but it works. The only problem is that I do most of my shell interaction through shell-mode in Emacs, not in zle-capable terminals. So I also had to write a shell-mode version, which turned out to be even uglier because I basically had to rip off the shell-resync-dirs code to handle comint interaction and directory tracking. Here it is in all its glory:

(defun ore-shell-dirnav (direction)
  (interactive)
  (let* ((proc (get-buffer-process (current-buffer)))
         (pmark (process-mark proc))
         (cmd (if (eq direction 'up) "pushd .." "popd")))
    (goto-char pmark)
    (sit-for 0)
    (comint-send-string proc cmd)
    (comint-send-string proc "\n")
    (set-marker pmark (point))
    (let ((pt (point))
          (regexp
           (concat
            (if comint-process-echoes
                (concat "\\(" (regexp-quote cmd) "\n\\)")
              "\\(\\)")
            "\\(.+\n\\)")))
      (insert "\n")
      (backward-char 1)
      (while (not (looking-at regexp))
        (accept-process-output proc)
        (goto-char pt)))
    (goto-char pmark)
    (delete-char 1)
    (let* ((dl (buffer-substring (match-beginning 2) (1- (match-end 2))))
           (dl-len (length dl))
           (ds '())
           (i 0))
      (delete-region (match-beginning 2) (1- (match-end 2)))
      (while ( i dl-len)
        (string-match "\\s *\\(\\S +\\)\\s *" dl i) ; pick off next dir         
        (setq ds (cons (concat comint-file-name-prefix
                               (substring dl (match-beginning 1)
                                          (match-end 1)))
                       ds))
        (setq i (match-end 0)))
      (let ((ds (nreverse ds)))
        (condition-case nil
            (progn (shell-cd (car ds))
                   (setq shell-dirstack (cdr ds)
                         shell-last-dir (car shell-dirstack))
                   (shell-dirstack-message))
          (error (message "Couldn't cd")))))))

(defun ore-shell-dirnav-up ()
  (interactive)
  (ore-shell-dirnav 'up))

(defun ore-shell-dirnav-down ()
  (interactive)
  (ore-shell-dirnav 'down))

(define-key shell-mode-map (kbd "M--") 'ore-shell-dirnav-up)
(define-key shell-mode-map (kbd "M-=") 'ore-shell-dirnav-down)

Phew. It's a lot of code for a seemingly simple feature, but the time it saves me probably adds up to a few hours per year, so it's worth it.

A few months ago, I asked a set of questions on development mailing lists of a few GNU/Linux distributions. This resulted in very interesting discussions. As promised back then, all the answers from all distros I contacted can be read on the web or as an mbox file. Also, Freedesktop.org kindly agreed to host a mailing list to ease discussions between distributions, and act as a central point of contact. You can subscribe, and post to distributions at lists dot freedesktop dot org. This mailing list is for people involved (or interested) in the development of distributions. Questions that are on-topic are both technical and social/organizational issues, like:

• How do you achieve graphical boot in your distro? Do you use some kind of dependancy-based or events-based boot?
• How do you package both ruby 1.8, ruby 1.9 and jruby, or handle KDE vs KDE4?
• Do you use a system that gives a limited set of rights to new contributors?

Off-topic stuff obviously include trolling about which distribution is the best one, or user support. Don’t hesitate to forward this announcement to all interested parties. Let’s make this mailing list something useful together! Also, I really apologize for procastinating announcing this list for sooo long. I’m really good at procastinating interesting stuff, it seems.

For quite some time now, I've been running Trac over at software.complete.org. Most of my free software projects -- well, the ones where I actually go to the effort to make formal releases -- have a Trac instance. This Trac instance provides a wiki, bug tracker, downloads area, timeline (with RSS feeds), and VCS integration.

Trac is a nice program, but one thing has bugged me about it all this time:

Every trac instance is its own island.

I have 17 trac instances out there for my projects. To see what bugs are out there on my own server, I have to check 17 websites (or 17 RSS feeds or whatnot). Publishing a new program is not a lightweight process.

So today I started poking around looking for something better. I really like Trac's way of integrating the wiki with the BTS and the commits; wiki markup can refer to a bug or a changeset, and bugs can use wiki markup too.

I looked at Redmine, Mantis, and Roundup, and I also have experience with RT.

Of these, Redmine looks the most interesting. Multiple projects support, per project wiki and forums, gantt charting even, and support for SVN, CVS, Mercurial, Bazaar, and Darcs -- with Git support out there as patches to their development tree already too. Oh, and I saw references to a Trac importer as well. One thing that makes me nervous, though, is that they have no links to sites that use Redmine (except one in the news section), and Google isn't turning up users either. Does nobody use this thing?

What else should I be looking at?

Over on the Git side, I'm still liking Git. I have now migrated several Mercurial projects over to git (see git.complete.org). I am also playing with Darcs to git migration using darcs2git, which also is going well. Sometimes gitk shows a nicer representation of a Git repo converted from Darcs than I was able to get from Darcs.

There’s an interesting discussion about Google Summer of Code going on debian-devel@. The question can be summarized as “Should we allow current Debian contributors to be students in GSOC?“? The GSOC FAQ says:

Google Summer of Code has several goals:

• Get more open source code created and released for the benefit of all;
• Inspire young developers to begin participating in open source development;
• Help open source projects identify and bring in new developers and committers;
• Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think “flip bits, not burgers”);
• Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).

The problem is that those goals are clearly conflicting:

• If you think that “get useful code written” is more important than “get fresh blood in Debian”, it is stupid to choose students that are not existing contributors to Debian. It’s a much better idea to choose people that already know Debian very well, so they will be very efficient.
• If you think that “get fresh blood in Debian” is more important than “get useful code written”, it is stupid to choose students that are already contributing to Debian. You should choose outsiders, of course.

Another problem is that in the past, some students that were also debian contributors had problems organizing themselves: they used some of their GSOC time to work on their usual Debian tasks, leading to results that were a bit disappointing. But it’s possible that this is mainly a management problem (however, mentoring people takes a lot of time, and only students are paid, not their mentors). How do you deal with that in your project?

My FOSDEM talk didn't go entirely as planned. I tried to run a demo of the beid packages, but unfortunately they decided to play up again. This isn't the first time; they sometimes have this. It has something to do with OpenSC or OpenCT, I believe, but it's hard to figure out what, exactly. When I got back at the office with the machine that failed to work properly, and tried again, it did work. Heisenbugs suck. Pun intended. Anyway, since things work now, I prepared a screencast showing off what I wanted to show during the talk; it takes about 8 minutes. I was going to edit the talk to hide the spammer who was DoS'ing my mailserver just as I was trying to send an email out, and perhaps to hide away the long waits at times; but I didn't find an easy way to do so, and I got tired looking. If you're interested, have a look. Also, the screencast doesn't include any sound. This is because I couldn't find any piece of equipment on which istanbul would produce correct imagery (it appears to be buggy on powerpc), where the hardware was fast enough to capture and encode both a video at 1024x768 resolution and sound from the sound card (ruling out "anything", the machine on which I tried to do the presentation at FOSDEM), and on which the microphone would actually work (ruling out the amd64 box that was standing nearby). Since I could at least create a correct movie on the last machine, I just forgot about the sound. Instead, I tried to make the screencast show what was going on, by pointing at important tidbits with my mouse pointer. Which kindof worked, but was not ideal. Oh well.

There is currently a lot of speculation about the future of Windows following the massive failure of Vista in the market. One theory that is being discussed is that Microsoft will cease kernel development and adopt a Unix kernel in the same way that Apple adopted a BSD based kernel. I predict that MS in it’s current incarnation (*) will never do that. Having an OS kernel that enables easy porting of code to/from other platforms is entirely against their business model which relies on incompatibility to lock customers in. Whatever kernel MS use, it has to be incompatible in some ways with everything else. One easy way of achieving this would be to have a shared object (DLL) interface published and have the interface between the libc and other libraries and the kernel be undocumented and ever-changing (simply renumbering the system calls on every minor version increment would be a good start). The DLL interface could then have the complex APIs that MS loves to force on their victims (see Stewart Smith’s post about getting a file size in Windows for an example of the horror [1]). The advantage of this approach would be that MS could cease developing an OS kernel (something that they were never much good at) and concentrate on owning the proprietary DLLs. There would be nothing stopping them from using a Linux kernel for this, as long as they release all source to the kernel they use (including the patch to renumber the system calls) they would be within the terms of the GPL. My specific prediction is that some time between Jan 2011 and Dec 2016 Microsoft will release systems with the majority of the kernel code coming from BSD or Linux as their primary desktop and server operating systems. Could people who disagree please make specific predictions for the future (including dates and actions) so that we can determine who was most accurate. (*) For future incarnations of Microsoft after chapter 11 or being split in the way that AT&T was there seems no possibility to predict their actions.

• [1] http://www.flamingspork.com/blog/2008/02/11/getting-a-file-size-on-windows/

Share This

In 1996 Peter Gutmann wrote a paper titled “Secure Deletion of Data from Magnetic and Solid-State Memory” [1]. In that paper he mentions the fact that the contents of RAM last longer at lower temperatures and suggests that data could be retained for weeks at a temperature of -60C or lower (while 140C causes rapid data loss). The paper also addresses issues of data recovery from hard drives, but given that adequate CPU power for encryption is available recovering data from a disk shouldn’t be an issue unless thee attacker can get the key to decrypt it or crack the algorithm - so disk recovery is not a hot issue at the moment. Recently some researchers at Princeton University have published a paper describing in detail how to chill RAM to make it keep its data after a power cycle and even after being installed in a different computer [2]. This attracted a lot of attention, while Peter’s paper described the theoretical concept (in great detail) the Princeton group showed how to implement the attack using materials that are commonly available. Most of the analysis of this misses some fundamental points. Any suggestion that you can wipe the RAM on power failure or on boot misses the point entirely. If an attacker can chill a DIMM and then remove it from the system then there is no chance for it to be wiped. Maybe if you had security on the PC case to detect case opening (some servers have a basic version of this) such things would do a little good, but it shouldn’t be difficult to bypass in most cases. Another common flawed analysis is to suggest that this is no big deal because sniffing the memory bus has been possible for years. While it has always been possible for government agencies and companies who design motherboards to sniff the bus, for most potential attackers it has been overly difficult. When considering the effectiveness of a security system you should first consider what your threat model is. Who is going to attack you and what resources will they be willing and able to devote to the attack? An organisation that is prepared to use expensive equipment and highly trained people to break your encryption probably has other methods of gaining access to your secret data that are easier and cheaper. The research from Princeton suggests that I could perform such attacks with my spare time and with equipment that is very cheap. I’ve been idly considering doing this to an old PC just for fun! Therefore I have to assume that everyone who has the same amount of skill and money as me can potentially compromise my data if they capture one of my machines. It is still most likely that if anyone steals my laptop they will want to sell it and use the money to buy drugs. I don’t think that I have any data that is anywhere near valuable enough to justify a targeted mugging. But my procedures (in terms of changing passwords etc) in the case of my laptop being stolen now need to be scaled up due to the ease in which data might be compromised. The best way of dealing with this would be to have the decryption keys locked inside the CPU (stored in registers or memory that’s locked in the CPU cache). The possibility of getting a modern CPU to operate at any temperature approaching -60C is laughable, and the CPU is a well contained package that can operate on its own and is difficult to attack. This would make things significantly more difficult for an attacker while requiring little effort (in fact it might be possible to lock data in the CPU cache already in which case a software change is all that is required). Update: A comment by Mike made a good point about CPU cooling. Toms Hardware performed an overclocking experiment (from 3.2GHz to 5.25GHz) and used liquid nitrogen cooling [3]. It might be possible to cool a CPU core to -60C in a reasonably small amount of time. But I still believe that it would raise the bar enough to make it worth doing. Update2: Thanks Jaime for the spelling advice.

• [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html


• [2] http://citp.princeton.edu/memory/


• [3] http://www.tomshardware.com/2003/12/30/5_ghz_project/index.html

Share This

As you probably know (well, in case you read d-d-a (hello man-di)), we got two new people as FTP Assistants. While I disagree with the way it went, it’s a good thing to not have NEW, removals and override changes a (pretty much) one man show. OTOH I am also pretty reluctant to having others do NEW, as the long time I am now doing it makes me feel about it like - well “it’s my baby”, or something like that. It’s just that I processed a lot of packages, rejected even more and (mostly) had fun doing it. (And I hate to share fun, HA :) ). But I understand the need of having more people doing it, so today I gave an introduction to Thomas and Kalle. Now they at least know where to start. And while that took somewhere around 2 hours - its still only an introduction. I bet there will be many more questions when they do more than just reading the large amounts of text I flooded into the ftp teams IRC channel. :) But that should work fine, I am online most of the day - and then there are the other ftpteam-members and ftpmasters in the channel, someone should be able to respond sooner or later. :) And now some real content. The ultimate way to get a totally bug free Debian:

for i in $(dak control-overrides -t dsc -l awk ' print $1 '); do
 dak rm -m "Cleanup" -C package $i
done

Don’t try this at home, kids. (Yes, a nice DELETE FROM $correct_table in projectb also works, but isnt as much fun! The above gets you nice and pretty logs in the removals.txt and also nice and pretty mails to the package address!)

Recently, the EFF reported that the European commission had responded to a request by European Parliament member Satu Hassi about tracking dots in printers. European Commissioner Franco Frattini replied that tracking dots may constitute a human rights violation saying that:

"..to the extent that individuals may be identified through material printed or copied using certain equipment, such processing may give rise to the violation of fundamental human rights, namely the right to privacy and private life. It also might violate the right to protection of personal data."

Intriguingly, the request text includes a mention to and link to the Seeing Yellow project I started last year as an example of the fact that consumers have complained to printer manufacturers and that these complaints have fallen upon deaf ears. Everyone who called their printer manufacturer in response to Seeing Yellow deserves come credit for the raised visibility to the issue that we've created and the set of actions that have brought the issue this far. Please, keep it up! If you've not complained to your printer manufacturer, visit Seeing Yellow and call today.

I was asked for advice from a non-technical person about buying a laptop for their 15yo daughter. They were looking to spend $200 or $300. I suggested that stretching their budget to $500 for a new EeePC would be a better option than the risks associated with a second-hand laptop (laptops are all different in their hardware). I also suggested that waiting a few months to see what happens with the new EeePCs might be a good idea. There are rumours about the development of new EeePC models with bigger screens, this would be a benefit for those who can afford it, and for those who can’t the current model may drop in price. They took that suggestion very well and I suspect that they weren’t planning to purchase in the near future anyway. I asked for advice on the LUV mailing list [1] for further suggestions that I could offer. One suggestion was that larger laptops of a more traditional design have been driven down in price recently and might be worth considering. I will have to mention it, but suggesting that someone who wants to spend $200 should spend $500 seemed enough of a stretch, suggesting that they spend $700 or more might not be taken well. Of course there is the weight issue that Matt raised in a blog post [2]. The last thing I want to do is to convince people not to buy computers for their children! A complaint was raised about the size of the keyboard in the EeePC (personally I wouldn’t want to use anything smaller than the T series Thinkpad I’m using now). In a quick google search the best information I could find about average finger sizes was the Danforth Diamond blog [3] which says that in the US women average a ring size of 6 while men average 10. According to the ring sizing page on the same site [4] that means ring finger diameter of 16.5 and 19.8mm respectively. So it seems likely that given the same level of typing skill an average woman could happily use a keyboard that’s 83% the size of the keyboard that an average man uses. Of course there’s a lot of variation between individuals, for example my fingers are thinner than average and I prefer a full-sized keyboard. One thing I recommend when considering a keyboard (or a laptop) is to type your name a few times quickly. Typing something about a quick brown fox will take some thought, but typing your own name requires no thought so you can concentrate on the feel of the keyboard. Using this method it is very easy to go to a store and determine whether a laptop is likely to suit you. The screen resolution and size is a significant issue, one EeePC owner described it as “too small to do anything useful“. Rumour has it that the next version will have a screen that’s a significant increase in size and resolution. A final interesting comment was about the social aspect of owning a laptop. The suggestion was made that a teenager who owned the smallest (and possibly cheapest) laptop in class might have other kids tease them about it. I will be interested to see comments on this issue, it had never occurred to me that the laptop use in schools would be high enough for the ownership of any type of laptop to be a cause for harassment. Also I’m not sure which would be considered as being of lower status, an old second-hand laptop or a new low-end laptop. I’m pretty sure that owning either would be considered to have higher status than having no laptop. A quick scan of the GraysOnline.com.au auction site suggests that a second-hand Pentium-M laptop (a few years old) could be purchased for about $550 and a Core 2 Duo based laptop might go for about $700. So it seems unlikely that for less than $500 you could buy something suitable for a novice user (something that will just work with recent software). I’m not planning on offering the full IT support package that I offer to my relatives so I can only recommend things that can be self-supported. Of course as the people doing the buying seem to have no definite plans for the use of the computer then anything they buy will fail in some way to meet the requirements that they discover. :-# Update: fixed a bad link.

• [1] http://lists.luv.asn.au/wws/arc/luv-main/2008-02/msg00670.html


• [2] http://matt.bottrell.com.au/item/167/


• [3] http://danforthdiamond.wordpress.com/2005/12/16/guessing-your-girlfriends-ring-size/

Share This

So I have been learning about Git this weekend. It has some really nice-looking features for sure -- some things Mercurial doesn't have.

I was getting interested in switching, until I found what I consider a big problem.

Many projects that use git require you to submit things using git-format-patch instead of pushing/pulling from you. They don't want your merge history.

git-format-patch, though, doesn't preserve SHA1s, nor does it preserve merges.

Now, say we started from a common base where line 10 of file X said "hi", I locally changed it to "foo", upstream changed it to "bar", and at merge time I decide that we were both wrong and change it to "baz". I don't want to lose the fact that I once had it at "foo", in case it turns out later that really was the right decision.

When we track upstream changes, and submit with git format-patch, the canonical way to merge upstream appears to be:

git fetch; get rebase origin/master

Now, problem with that is it loses your original pre-conflict code on a case like this.

There appears to be no clean way around that whatsoever. I tried a separate "submission" branch, that rebases a local development-with-merge branch, but it requires a ton of git rebase --skip during the rebase process.

Thoughts?

Recently, the EFF reported that the European commission had responded to a request by European Parliament member Satu Hassi about tracking dots in printers. European Commissioner Franco Frattini replied that tracking dots may constitute a human rights violation saying that:

"..to the extent that individuals may be identified through material printed or copied using certain equipment, such processing may give rise to the violation of fundamental human rights, namely the right to privacy and private life. It also might violate the right to protection of personal data."

Intriguingly, the request text includes a mention to and link to the Seeing Yellow project I started last year as an example of the fact that consumers have complained to printer manufacturers and that these complaints have fallen upon deaf ears. Everyone who called their printer manufacturer in response to Seeing Yellow deserves come credit for the raised visibility to the issue that we've created and the set of actions that have brought the issue this far. Please, keep it up! If you've not complained to your printer manufacturer, visit Seeing Yellow and call today.

Hello, dear developers. I suppose many of you are currently at FOSDEM, but unfortunately I could not attend the event this year. Here are some news for you anyway! FTP assistants I am very pleased to let you know that yesterday Peter Palfrader (weasel) added Kalle Kivimaa (killer) and Thomas Viehmann (tviehmann) to the list of FTP assistants. I still hope that more people can be added soon to this team, but this is definitely good news. Marketing team At the various conferences I attended I have paid much attention to how other distributions and FOSS projects were promoting their work, and despite us often having t-shirts, stickers and posters like the others, we really miss a few things which would make Debian as appealing as other, dynamic projects. I would like to set up a Debian Marketing Team, whose work would be to organise all the promotional stuff (logos, t-shirt designs, wallpapers, etc.) so that the project can officially endorse good designs, and to make the ultimate decision on visual stuff such as CD covers, splash screens, etc. This team would have official DPL delegation, but I hope that it can also work with non-Debian-developers, as many packaging teams already do, because the non-DDs know better than us how to draw people to Debian. So please let me know if you are interested, even if you are not a DD, and especially if you are not a programmer! I also would like to spend some Debian money on a contest, similar to the FreeBSD logo contest, to create a friendly mascot for the Debian project (in a similar way to the Linux penguin or the GNU gnu) that we can use where the logo is not enough. More on this in a few days. Development news Last month Petter Reinholdtsen (pere) gave some news about his project of improving the init system. This is almost as simple as adding LSB headers to your init scripts, and work is advancing towards this goal, though not as quickly as desirable. If your packages have init scripts, or if you wish to help, I urge you to have a look at the proposal so that we can have it in Lenny. DPL elections The new DPL term is in almost 2 months, but campaign starts next month. I have already stated that I would not run again, and haven't changed my mind. As many, many Debian developers are attending FOSDEM, I hope you can use some real-life meeting time to discuss the people you think would make good DPLs and tell them. Maybe they haven't thought of running (or re-running). Being DPL does have an impact on your real life. If you are still wondering whether to run, or have any personal questions, feel free to ask me, I'll gladly share my experience.

Exactly one year ago today, I wrote about Git, Mercurial, and Bzr. I have long been interested in VCS, and looked at the three main DVCS systems back then.

A Quick Review

Mercurial was, and for the moment, remains, my main VCS. Bzr remains really uninteresting; I don't see it offering anything compelling that Mercurial or Git can't do. My Git gripes mainly revolved around its interface and documentation. Also, I do have Windows people using my software, and need a plausible solution for them, even though I personally do no development on that platform.

Ted Tso wrote his own article in reply to mine, noting that the Git community had identified many of the same things I had ans was working on them.

I followed up to Ted with:

... So if Ted's right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won't be that hard to switch over and preserve history. Ted's the sort of person that usually is right, so maybe I should starting looking at hg2git right now.

So I guess that means it's time to start looking at Git again.

This is rather rambly, I know. It's late and I want to get these thoughts down before going to sleep...

Looking at Git

I started at the Git wikipedia page for an overview of the software. It linked to two Google Tech Talks about Git: one by Linus Torvalds and another by Randal Schwartz. Of the two, I found Linus' more entertaining and Randal's more informative. Linus' point that CVS is fundamentally broken, and that SVN trying to be "a better CVS" (an early goal of svn, at least) means it too is fundamentally broken, strikes me as quite sound.

One other interesting tidbit I picked up is that git can show you where functions have moved from one file to another, thanks to its rename-detection heuristic. That sounds really sweet, and is the best reason I've yet heard for Git's stubborn refusal to track renames.

The Landscape

I've been following Mercurial and Darcs somewhat, and not paying much attention to Git. Mercurial has been adding small features, and is nearing version 1.0. Darcs has completed a major overhaul both of its repository format and internal algorithms and is nearing version 2.0, and appears to have finally killed the doppleganger (aka conflict spinlock) bug for good.

Git, meanwhile, seems to have made strides in usability and documentation in its 1.5.x versions.

One thing particularly interesting to me is: what projects are using the different VCSs. High-profile projects now using Mercurial include OpenSolaris, OpenJDK (Java 7), and Mozilla's projects. Git has, of course, the Linux kernel. It also has just about everything associated with freedesktop.org, including X. Also a ton of Unixy stuff.

Both Mercurial and Git communities are working on TortoiseHg/TortoiseGit types of GUIs for Windows users. Git appears to have a sane Windows port now as well, putting it on pretty much even footing with Mercurial and Darcs there. However, I didn't spot anything with obvious Windows ties in the Git "what projects use git" pages.

The greater speed of Mercurial and Git -- even for pushing and pulling small patches -- likely will keep me away from Darcs for the moment.

Onwards...

As time allows (I do have other things keeping me busy), I plan to install git and work through some tutorials and try to use it in practice as much as possible, to get a good feel for it.

Future

It is beneficial to be using a VCS that is popular, though that is certainly not a major criterion for me. I refuse to use SVN because its lack of distributed functionality makes it too unproductive to be useful. But it looks like Git is gaining a lot of traction these days, especially in Debian circles, which also makes it more interesting.

I notice that Ted did convert e2fsprogs over to git as he said he might, incidentally.

Over the past four years every visit to a doctor or hospital has involved some time spent in a waiting room, in the case of hospital visits it has often been more than an hour waiting. Each of those waiting rooms has had a selection of bad magazines and a TV. If I ever visit a hospital after 8PM then I might have a chance of seeing something that I want to watch on TV, but otherwise it’s all awful. Fortunately there are better things that they could do. It would not be difficult to get a basic PC and install all the content from ted.com (and possibly other sites with quality free content) and have some sort of video juke-box program running. TED not only has lectures about arts and science but also performances by musicians and dancers. The chance that a random person can find something they enjoy in TED’s archives seems significantly greater than the chance of finding something worth watching in the daytime-soap TV segment. But TED is far from the only option available, there are quite a number of free video sites and the ones that include advertising in the video stream would probably be more than happy to have their content copied on to juke boxes.

Share This