Today's xkcd reminds me that about 15 pounds of grapefruit into this year, I tried to calculate how many I could eat a day, if I were to do were peel and eat grapefruit, all day. I may have been trying to figure out if it is possible to live on a pure grapefruit diet. I remember arriving at a figure around 70. My actual daily consumption at the height of grapefruit season is 3 to 5. It's become my favorite winter fruit and quite puts one off nasty sweet oranges. There's a trick to both the peeling and the eating of grapefruit which the xkcd guy has apparently never learned, that avoids the healhful skin and leaves only the delicious tart flavour droplets behind. I'm available for lessons, the first 2 or 3 weeks that the Texas ruby reds are in season.

---

(Of course as wrong as Randall is about grapefruit, he's 5 million times as wrong about a proper tomato..)

Another awards show took place today but nobody is paying any attention to that. All of Hollywoods elite can be found at the King Plaza Buffet in Jersey City for the 80th annual Things Jaldhar Discovered Last Year That Every Else Knew About Already Awards. (Known in the industry as "the Golden Sombreros") Here is a list of the winners. Game: Hungry Hungry Hippos This game is awesome! But don't play with three year olds. They cheat. Book: Discworld series by Terry Prachett When The Color Of Magic came out in 1983, I dismissed it as merely "The Hichhikers Guide to Mordor" but last year I read it again and this time it grew on me. Since then I've been steadily reading the whole series since June at an average of one a week. Music: Rammstein Smell the umlauts! I have no idea what they are actually going on about but this is what Metal is supposed to sound like. Mental Condition: Oedipus Complex All of sudden last October or so, my son started screaming and crying whenever I got anywhere near my wife and he would cling to her like the proverbial limpet. Then three months later, just as suddenly, he stopped. Very strange, not to mention creepy. Linux command: grep --color=auto Everyone knows GNU ls can be colorized but did you know the same is true of GNU grep? I didn't. Why wasn't I informed of this earlier? L. Ron Hubbard Lifetime Achievement Award: Coke Zero I used to drink way more Coke than was good for me so I decided to give it up. Diet sodas don't taste very good so I was resigned to not drinking soda at all. Luckily for me Coke Zero has no calories or sodium but does have caffeine and a taste like actual Coca-Cola. Perfect!

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.

So, MadCoder had doubts about the crazy idea, so I took a little time to do a test with a package I maintain, namely, xulrunner. First, take all the deb files in the history of the package (at least, everything that is available on snapshot.debian.net today).

wget -O - -q http://snapshot.debian.net/archive/pool/x/xulrunner/binary-amd64/Packages.gz gzip -cd > list
awk '/^Filename:/ print $2 ' list xargs -I wget http://snapshot.debian.net/archive/

Next, commit all these in a different repo per package name :

perl -e 'use Dpkg::Version qw(vercmp); sub v my $f = $_[0]; $f =~ s/.*_(.*)_.*/$1/; $f print sort vercmp(v($a), v($b)); map s/^Filename: .*\///; $_ grep /^Filename:/ ;’ list while read f; do
    pkg=$ f%_*_*
    [ ! -d $pkg ] && mkdir $pkg && ( cd $pkg ; git init )
    cd $pkg
    ar -x ../$f
    mkdir data control
    tar -C data -zxf data.tar.gz
    tar -C control -zxf control.tar.gz
    git add data control
    git commit -q -m $f
    rm -rf data control data.tar.gz control.tar.gz debian-binary
    cd ..
done

Finally, evaluate sizes for each package, respectively, of all .deb files, their content imported in git (only the .git directory, including the index ; some space could be gained removing it), and the “optimized” git repository (after git gc, without modifying delta depth or window size, which may even improve the result)

awk '/^Package:/ print $2 ' list sort -u while read p; do
    du -c --si $ p _*.deb tail -1
    du -s --si $p
    cd $p; git gc ; cd ..
    echo
done 17M total
16M libmozjs0d
4.7M libmozjs0d 34M total
31M libmozjs0d-dbg
14M libmozjs0d-dbg 4.7M total
7.1M libnspr4-0d
1.3M libnspr4-0d 9.2M total
12M libnspr4-0d-dbg
2.8M libnspr4-0d-dbg 25M total
28M libnss3-0d
4.6M libnss3-0d 81M total
61M libnss3-0d-dbg
21M libnss3-0d-dbg 15M total
16M libnss3-tools
3.1M libnss3-tools 288M total
265M libxul0d
146M libxul0d 2.0G total
1.8G libxul0d-dbg
1.1G libxul0d-dbg 5.1M total
6.8M python-xpcom
1.1M python-xpcom 2.5M total
5.6M spidermonkey-bin
861k spidermonkey-bin 13M total
14M xulrunner
2.0M xulrunner 3.3M total
5.9M xulrunner-gnome-support
979k xulrunner-gnome-support


So these packages, stored in git, take between 15 and roughly 50 percent of the .deb size, which may be a nice improvement. Il would be interesting to know how these numbers evolve with time. Some files, such as the changelog.Debian.gz files, would also benefit from being stored in plain text instead of gzipped form. Note git gc took a while and a lot of memory for libxul0d-dbg. Also note these don’t include delta files that would be necessary to recreate the original .deb file, but this shouldn’t make a huge difference.

I have been pondering buying an entry level color laser printer, mainly for my dad (Vista) but of course at least bw-text should work with Linux, too. As expected, the situation is slightly worse than I expected.

• The printers come with toner cartridges that only contain a fracture of a real cartridge (33% to 70% depending on the model). And of course the real toner is rather expensive. HP's LJ1600 seems to be the worst offender, at EUR 160 it contains "start toner" worth EUR 151, a full original refill is EUR 318.
• Every single company still has their own home grown version of protocol for host-based printers. And it still changes.
• Most of them have free drivers, however Samsung's color laser printer's use the patent-encumbered JBIG algoritm, so we probably won't have them in Debian anytime soon.
• The only difference between Konica Minolta's 2500W and 2530DL seems to that the latter has got Ethernet in addition to USB. Amazingly however they seem to require different drivers even for USB. The former does not work at all under Linux but the latter is supported by foo2lava.
• An excellent source of information, linuxprinting.org, seems to have lost a little bit of its edge. The information there seems to be slightly dated now. Darn.

I started looking at not low end inkjets, too, The first likely candidate Canon PIXMA iP3500 or iP4500 made a quite entertaining research on the linux side. There are no free drivers and Canon's binary ones are strange. Quoting the wnpp bug:

• The packages are actively developed upstream (good!), but not maintained (what?!): each released version supports the then-current printer models only, and is not maintained after release.
• For a start, there is no canonical english web site for these packages, the URL in the package description is japanese only.

So, I have finally moved my blog to MovableType from Wordpress and a couple of interesting things have happened:

• I've gave birth to my new blog, Infinite Pig Theorem.
• I've started Blog::Normalize as an entirely i-don't-give-too-much-shit-if-people-disagree-so-beat-it-dude project. You can import posts to MovableType from Wordpress as the time of writing which was my whole purpose at first, but then expanded the idea.

It feels good to be back.

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.

I often have a bunch of somewhat crazy ideas, and I don’t have any time available to test or implement them, which is sad. So just in case these crazy ideas would scratch someone’s itch, I’m going to throw them in the wild. I’ve been using git for a few months, now, and used it not only for source code management, but for efficient storage, too. *VERY* efficient. I’ll have to write about that some day. Anyways, while installing pristine-tar, today, I just thought it would be neat to have an equivalent pristine-deb, to store deb files efficiently. I’m pretty sure someone else thought about this possibility, but it’s still better that such ideas come to the ears (eyes, actually) of someone that could implement them. Such a pristine-deb tool could be used to… store packages from snapshot.debian.net. That would reduce the amount of space required for the archive dramatically, IMHO. I’m pretty sure old packages are not requested that much, so they could be generated on-the-fly from a CGI script placed as a GET action, so that urls wouldn’t change. The same could probably be applied to archive.debian.org. It could even save enough space that archive.debian.org could host snapshot.debian.net. But that depends on the average package content and its average evolution, which I have absolutely no idea about. Update: It would also be interesting to have the .diff.gz files in there, too ; it would obviously allow to have an easy view of the contents, such as copyright files, changelogs, and other bits of information available on packages.debian.org. Update 2: Actually, pristine-deb would as easy as storing 2 pristine-tars (one for control.tar.gz and one for data.tar.gz), and a debian-binary file. The .deb can be aggregated with

ar -rc file.deb debian-binary control.tar.gz data.tar.gz

For the last few years I have been actively seeking free hardware to give to members of my local LUG. Whenever a friend or business associate mentions that they are upgrading or replacing computers I enquire what they plan to do with the old ones and request that the old gear be given to me if there are no other plans for it. There is a moderate amount of hardware that I use for my own purposes, but the free hardware that is available is often in excess of my requirements and also sometimes just unsuitable for my use (I am happy to install a second-hand IBM or HP machine for a client but I won’t install a white-box machine). One organisation that I sometimes give computers to is Computerbank [1]. The purpose of Computerbank is to take donations of old machines, fix them and install Linux, and then sell them for extremely low prices to people who can’t afford new machines. It’s been a while since I gave them any computers because for a long time the minimum specs on machines that they were willing to accept were higher than the machines that I obtained. Generally I offer my old hardware to the mailing list of Linux Users of Victoria [2]. I offer not only working systems but also broken systems and other things that might be useless to most people - but are greatly desired by the small minority who can use them. One member of that list wants PC power supplies for repairing other electronic devices, so I collect batches of machines that are broken but appear to have working PSUs and give them to him. I once received a box of free two-button mice. I offered them to LUV members expecting that many people would want one or two for test machines. No-one wanted them for use as mice but one guy wanted all of them to use their sensors in robotics projects. One thing that impresses me is the community spirit demonstrated. Often I will offer some free machines and the first response will be something like “I’d like to take that machine apart for the bits, but if someone wants a complete system please give it to them instead”. There aren’t many occasions when you see someone suggesting that they may not be the most deserving recipient for something that is free! My aims in this effort are to help random Linux users in my area, and to help the environment by reducing the amount of land-fill. My efforts aren’t going to make a significant impact on the environmental situation, but they do make a significant impact on the availability of hardware for members of the Linux community - which seems to be of particular interest to people who want cheap machines for their children or grand-children. I encourage other people to do similar things. One thing that impressed me was the organisation of used hardware gifts at LCA. Near the start of the conference hardware was given away to anyone who put their hand up. At the end of the conference more hardware was given away (I expect it was mostly by delegates who lived locally). It would be good if this idea (which worked so well) was spread to other conferences.

• [1] http://vic.computerbank.org.au/


• [2] http://www.luv.asn.au/

Share This

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.

Yesterday, collectd 4.3.0-1 has been uploaded to Debian unstable. The most important changes since 3.x are (in chronological order):

• the much improved plugin infrastructure offers a lot more flexibility
• the much improved networking code offers a lot more flexibility
• the new bindings to Perl allow plugins to be written in the scripting language Perl
• the new unixsock and exec plugins allow external programs to communicate with the daemon and submit data
• integration with Nagios has been implemented
• support for flexible intervals has been added
• support to read values from SNMP enabled devices has been added
• basic support for monitoring has been added
• many new plugins

See the changelog for details. About collectd:
collectd is a small daemon which collects system information periodically and provides mechanisms to monitor and store the values in a variety of ways. It is written in C for performance. Since the daemon doesn't need to startup every time it wants to update the values it's very fast and easy on the system and allows very fine-grained statistics.

I'm not going to FOSDEM, you bastards !

Every since I found out that the first digits of any credit card denote the issuer identifier (i.e., folks can tell who issued a credit card and what type it is just from the first digit or two) I've been annoyed almost each time I have to input credit card information on the web. Any decent credit card system knows that if a sixteen digit credit card number starts with 4, it's a Visa. And yet, each time anyone buys anything on the web, they must select "Visa" from the drop-down box. On a certain level we all know this; People in stores and restaurants never have to select the type of card before swiping. When I'm feeling generous, I imagine this is so that the credit card companies can give an extra reminder that they only accept certain credit cards -- not being able to select a card type in an "essential" input field constrained to multiple choices is a pretty strong reminder. When I'm feeling less generous, I suspect it might be so that the companies can subtly remind us that they have their own brand credit cards that we might like to acquire.

I’m off to FOSDEM in a few minutes (it’s nearly bedtime, right?), getting the 10:00 Eurostar. Give me a shout if I owe you a beverage or something..

One of the interesting things about Google's Android project is the mix of cultures. There are a number of people like me, firmly grounded in the open source world, who are happy to get something that 1) works, 2) looks to have legs in terms of popularity, and 3) will be open source. Think of a lot of your favorite open source projects when they first launched. "Polished" isn't a word you would probably use to describe them, although it usually happens in later releases (Ubuntu looks better and better, for example). There are also a lot of people who come from a 'commercial' background, who expect to see everything ready and waiting on a plate for them, which isn't a mistaken expectation if you're used to using products from big companies who are staking their reputations on them. They want nice, thorough docs for everything, almost all bugs worked out, and lots of easy to use tools. Android lies in a middle ground somewhere between these two camps, which I think at times makes people uneasy. It's not open source yet. You can't hack it as much as you may want. You can't rebuild it from the ground up. You don't get access to the communication between the developers working on it, and cannot participate in that development. However, there is a promise to open source it that would reflect very, very poorly on Google were it not met and is therefore pretty credible. The developers and many people involved with it certainly seem to "get" open source, and are taking good steps to create a community around Android (a few even hang out in the #android IRC channel on Freenode) that will most likely not take too long to start assimilating interested outsiders once the code is open. In terms of quality, it wasn't bad when it came out, but it was very definitely an "early look", put out there to solicit feedback and change according to it, something that's part and parcel of a release early, release often open source model. On the other side, Android looks to be a big effort from a big company to get into a big market in a big way - it's not a "under the radar" type of strategy that the open source world is often constrained to follow for lack of monetary and marketing resources to do it any other way. This has attracted a number of developers who either don't see or don't really get some of the "open source" aspects of what we have so far: it's still changing! The docs aren't complete! The emulator is still ugly in places! And from their point of view, it must seem odd to getting something that's obviously not a finished product, without crystal clear direction and goals and a roadmap, and without actual hardware only available in the distant (well, in internet terms! - 8 months or so) future. That kind of thing probably isn't done very often in their world, or where it's done, is certainly kept quieter and perhaps restricted to registered developers. They came over to have a look at something that was ready to go, and it isn't, yet. This has caused some disappointment for people who expected to see something ready to go out of the box. Perhaps Google needed to manage their initial communications slightly better in order to manage the second group's expectations more carefully. In terms of us open source folks, I think that what we want is more access, as soon as Google is willing to hand it out. More source code access, but also access to the development process and people. "Real" open source isn't just about the code, it's about being more or less equal participants in a community. Luckily, I think the people at Google get this, which is one of the reasons I'm enthusiastic about Android, even if I wish we didn't have to wait so long for the source code.

What do you do when you suddenly get a free evening? Writing a calendar system seemed the obvious thing to do. Neither Google Calendar nor flat unstructured text files seemed to fit my needs. So I proudly present: AcmeCal version 0.1. The main novelties includes:

• Usability: combines the two greatest user interfaces: CLI commands and $EDITOR
• Simplicity: everything is optional but the start time of an event.
• Scriptability: it is just a couple of simple perl modules
• Readability: events is formatted with YAML

And all that in just under 400 lines of code. As of version 0.1 some important features remains to be implemented, for example documentation. Warning: Neither the comand line interface, nor the perl API, nor plutonium is stable. Download AcmeCal -0.1