A number of security sites have announced a DNS protocol problem which was discovered by Dan Kaminsky. For example the advisories for Debian are at:

• DSA-1605 glibc - DNS cache poisoning
• DSA-1604 bind - DNS cache poisoning
• DSA-1603 bind9 - DNS cache poisoning

The attack works if the victim machine uses a predictable source port when it makes DNS queries. Thus the current solution to the problem is to try to randomize the source port of the query. Now, the default resolving library that is part of glibc and the resolver that comes with BIND 8 do not randomise source ports and are thus subject to attack. This means that until glibc is patched every machine that uses glibc is vulnerable unless one installs a source port randomising DNS caching resolver on each such machine. Here is what appears to be a simpler alternative:

iptables -t nat -A POSTROUTING -o ! lo -p udp --dport 53 \
    -j MASQUERADE --to-ports 1024-65535 --random
iptables -t nat -A POSTROUTING -o ! lo -p tcp --dport 53 \
    -j MASQUERADE --to-ports 1024-65535 --random

WARNING: The above suggestion may or may not work and may break your machine in all kinds of awful ways! Will someone more knowledgable than me about the various RFC's confirm whether this would indeed be a "quickfix"? Ideally, we should expect a suitably patched glibc soon and that would be a better solution Update: The --random switch only works in Linux kernels with version at least 2.6.22

For everyone at GUADEC, there’s a boat party sponsored by Collabora this evening. Our sponsorship was confirmed after the program was printed so it’s listed anonymously, but it’s mostly sponsored by Collabora, of course with huge thanks to Baris and his team for the organisation, and local sponsors for food and discounted beer. The boat leaves from Kabatas at 9pm today (Thursday). It’s actually pretty close to the 3rd anniversary of Collabora’s incorporation, so I think we could call this our birthday party. :D I gave my presentation earlier today about using Telepathy to make collaborative applications. My slides are available, as well as the apps I demoed, which are the python VNC demo based on telepathy-python’s examples, Elliot’s Tic Tac Tube game, and Guillaume and Alban’s quick hack to Empathy and Vinagre to share your desktop over a stream tube. I was followed up by Senko’s presentation (slides also available) which had an overview of the libraries and APIs currently available to embed Telepathy functionality in applications on the desktop. The talks were all recorded so hopefully some videos will turn up on-line too. Speaking about collaborative stuff with Telepathy, we’re really keen to hear from the authors of applications like Abiword, Inkscape, Vinagre, Jokosher, Tomboy, Gobby, etc, to find out how we can help you integrate with Telepathy, what features you need before you can get started, or just try and convince you that it’s a good idea. :) If you’re at GUADEC, come and grab one of the Collaborans or drop by on #telepathy on FreeNode and tell us what you’d like to do and how we can help. Yesterday after the talks on Soylent and the People project, Travis and I met up with the guys behind the People project (Ali Sabil and Johann Prieur) and some of the Online Desktop team (Owen Taylor and Marina Zhurakhinskaya). We sketched out a way of plugging together Telepathy, People, Soylent and the Online Desktop to deal a lot better with meta-contacts on the desktop, providing “first-class” people objects. It all looks pretty promising and hopefully we’ll all find some time to make moves towards our vision. This afternoon at 3:30pm, Olivier is also presenting our work on Farsight 2, which is really cool stuff and should include some exciting demos of the multi-person video conferencing stuff we’ve been doing. More generally, GUADEC is awesome. I’m having a great time in Istanbul (despite it being pretty hot for a pale-faced Brit like me), and enjoying the sights and sounds of such an interesting city and culture. I’ve caught up with many of the usual suspects (like Lennart, who never turns down the chance to turn up at a conference and sample the local bars and clubs), and had some great discussions.

New status update! Here’s what Aptitude looks like: (more screenshots after the break) I’ve been exploring how the APT libraries work and how to interact with the aptitude back-end and here’s what it can do now:

• Update package lists
• Display package lists
• Basic package search
• Mark packages for install/remove/purge/keep/hold
• Display package actions for execution
• Display conflicts
• Display and navigate between package conflict solutions
• Apply them
• Execute package actions (ie. actually install stuff)

What’s missing:

• A real user interface
• Being reliable…
• Packages dependencies, pre-dependencies, etc.
• Hyperlinks between packages
• Advanced package search
• Tags support (tag clouds ?)
• Linking with interesting data sources like popcon
• A lot of interesting things

Basic functions of a package manager are already covered. We’re still at the APT API exploration phase although we’re almost done with it. I will soon start working on the final user interface and the real code design. The current code is about 2000 lines of hastily hacked together C++ and XML. I’ll have to restart the coding with a more elaborate Object design. Something that will be easier to work with in the future. The code is on http://dev.graffit.net/aptitude/trac. You can try to compile it and play with it. On the other hand I’m going to scrape most of the code soon for the restart so if you’re bored.. A walkthrough and more screenshots after the break. Here’s a walkthrough of what you can do right now:

Max Stotsky reported bug #490000 on Wednesday July 9th. Yet another i18n-related bug for a round number mark: "apt-cache search and ddtp". As bug #480000 was reported as of May 7th 2008, we're still keeping nearly exactly the pace of 2 months for 10,000 bugs, so 60,000bugs a year. Bug #500000 should then be reported around Sept 9th 2008. As a consequence, the candidates for winning the 500000th bug contest are still Miguel Gea or Kartik Mistry. The probability that they win iw now indeed very high as our bug reporting pace is obviously very constant. I will therefore not win the contest (which many people already lost as they predicted dates that are now in the past) See you around September 9th for celebrating Debian having half a million bugs in 15 years.

Like many people, I participated in the Google Android contest this spring, and like most of them, I didn't win, but I did enjoy working with the platform, and am very excited about the idea of an open source mobile platform that's relatively powerful. From the outset, due to the lack of actual source code for a lot of the system, there have been "doubters" about what Google is really up to. I'm not one of them, and am largely ok with their reasons for holding back: I buy their reasoning that the long term benefits of a strong, properly QA'ed launch probably outweigh the possibility of failure that might come from the press and the public at large that doesn't care much about software freedom seeing phones come out with half-baked, early implementations. I think most of us working with Android were ok with that strategy, and the ones who weren't self-selected out of the platform, most likely. However, lately Google has made something of a mess of their communications regarding Android. The problem stems from the fact that they gave an updated version of the SDK only to the winners of the competition, which for a lot of people felt like a bit of a slap in the face: they helped popularize the platform by participating in the contest and writing applications for it, and in return got excluded from the upgrade path. Personally, it's not really any skin off my nose, as I'm sanguine about the Hecl port proceeding apace when the new SDK is public, but I can see that if you were, say, a company porting your app to the platform and now are left behind the competition winners, you might be a bit irritated. The biggest mistake they've made though, is a big lack of communication regarding this business. As I said, I don't really have that much skin in the game, and if they explained in a convincing way why they needed to do things that way, they would go a long ways to allaying the frustrations felt by many. I'm not much of a believer in conspiracy theories and plots, especially where companies are concerned. Inept bumbling is a far more likely explanation in most cases, including this one. What is odd, though, is that Google has a lot of people who "get it". I met Dan Morrill at the Munich Android event, and he definitely gets it. He writes about his frustrations as a developer advocate and all the crazy things people say. Well, one way to reduce the number of batty internet theories (eliminating them is clearly impossible due to the alien mind control rays) is to consistently communicate quality information about what's really going on, something that has been lacking with regards to the SDK question. Here's another Google employee who understands this need to communicate, and apparently does so despite being worried about being "slapped for talking publicy about all this": http://groups.google.com/group/android-developers/msg/244edfad99870c63

But the root of the problem is certainly not licensing but that there hasn't been a new public SDK release since M5, while at the same time a small group of people received updated versions privately. I really don't know precisely why this happened; but I'm sure it has more to do with logistics and reducing the burden of support while we shift priorities (to shipping real devices) rather than politics or any will of our part to "hurt the community" (come one guys, we are not that stupid... !) While others in the team may disagree, I think it was very very unfortunate; some of us are trying to prepare a new SDK release, but it's a lot harder than I can comment on here, so don't hold your breath because it might not happen that soon.

This explains things in part, but still leaves us in the dark, and leaves me with the feeling that someone in power, somewhere at Google, despite his or her clued in colleagues, really doesn't get it with regards to open source. I'm still unconcerned about the Android source code: I think we'll see it, but to be a true open source project, Android will need an open community as well, not one where decisions are taken exclusively at Google, and not even communicated to the development community at large. All in all, this mistake is more molehill than mountain, but however you look at it, in terms of open source, it is a step backwards.

debexpo (Debian package exposition) is a web application that allows one to run a user-friendly public Debian package repository with social interaction that one may be used to from social networking sites. debexpo will be the basis for the mentors.debian.net site but will be useful for others as well. debexpo is the project I am working on for this year’s Summer of Code for Debian under the watch of Christoph Haas debexpo is more than just a web application though. It was based on suggestions by you, and therefore it has some nifty features:

• Uploading is done through HTTP PUT directly in debexpo, and handled immediately. This means that packages can be available within seconds of you uploading the package instead of having to wait for a cron job running an importer.
• debexpo supports plugins for several stages of package life-cycle. The main use of these are for QA purposes on the package, such as automatically running Lintian, checking the watch file, or checking bugs closed actually belong to the package in question, but there is scope for much more. Plugins are easy so you can customize a repository to check for whatever you want. Other cool plugins allow features such as pulling an orig.tar.gz from Debian if it is absent from the upload and not in the repository already. Plugins provide you the option to customize your repository for any purpose.
• Users will be able to have their own personal repository (much like Launchpad’s PPAs) to host binary packages. This is simply achieved by creating a new user, uploading, and adding the appropriate entry to your sources.list.
• Sponsors will be able to tell debexpo what kind of packages he or she likes to see, and a filtered package list will be shown. These kind of filters will include whether it’s a python package, or C library, whether it uses CDBS or straight debhelper, or even whether the maintainer is in the New Maintainer process (this is clearly a mentors-specific feature).
• Packages will be able to be commented on by other users, in the same way as Ubuntu’s REVU tool. This keeps package discussion in one place, and Debian Developers can claim to have uploaded the package. This is useful to stop the scenario of a Debian Developer reviewing a package that has requested a sponsor, and then finding the package has been uploaded already after the initial uploader left no mention of this.
• And more to come.

Development can be tracked through its Trac instance: http://debexpo.workaround.org/, where I invite you to submit tickets or even submit patches! Its Git repository is public: http://debexpo.workaround.org/debexpo.git (and mirrored here). Last but not least, the there is also a low-traffic mailing list. I invite you to try it out, and report bugs. Posting to the list is a great way to get in contact. There is little visible eye-candy in your browser to show for the work so far as nearly all the work so far has gone into the backend. A sneak peek at what it looks like at the moment is available though: As you can see, the theme is somewhat familiar. Hopefully, as the SoC program nears an end, this will be fixed. Oh, and hello: this is my first post to Planet Debian.

Does a GPG pass-phrase provide a real benefit to the majority of users? It seems that there will be the following categories of attack which result in stealing the secret-key data:

1. User-space compromise of account (EG exploiting a bug in a web browser or IRC client).
   
2. System compromise (EG compromising a local account and exploiting a kernel vulnerability to get root access).
   
3. Theft of the computer system while powered down when the system was configured to not use swap or to encrypt the swap space with a random key at boot time.


4. Theft of a computer system while running or that did not have encrypted swap.


5. Theft of unencrypted backup media.

Category 1 will permit an attacker to monitor user processes and intercept one that asks for a GPG pass-phrase as well as to copy the secret key. Category 2 will do the same but for all users on the system. Category 3 will give the potential for stealing the private key (if it’s not encrypted) but no direct potential for getting the pass-phrase. Category 4 has the potential for copying a pass-phrase from memory or swap. I am inclined to trust Werner Koch (and anyone else who submitted code to the GPG project) to have written code to correctly lock memory and scrub pass-phrase data and decrypted private key data from memory after use. But I really doubt the ability of most people who write code to interface with GPG to do the same. So every time that a GUI program prompts for a GPG pass-phrase I think that there is the potential for it to be stored in swap or to remain indefinitely in RAM. Therefore stealing a machine that does not have it’s swap-space encrypted with a random key (which is the most practical way of encrypting swap) or stealing a running machine (as mentioned in a previous post [1]) can potentially grant a hostile party access to the pass-phrase. So it seems to me that out of all the possible ways of getting access to a GPG private key, the only ones where a pass-phrase ones is going to really do some good are categories 3 and 5. While it’s good to protect against those situations, it seems to me that the greatest risk to a GPG key is from category 1, with category 2 following close behind. I previously wrote about the slow progress towards using SE Linux and GPG code changes to make it more difficult to steal the secret key [2] - something that I’ve been occasionally working on over the last 6 years. Now it seems to me that the same benefits can and should be made available to people who don’t use SE Linux. If a system directory such as /var/spool/gpg was mode 1770 then gpg could be setgid to group “gpg” so that it could create and access secret keys for users under /var/spool/gpg while the users in question could not directly access them. Then the sys-admin would be responsible for backing up GPG keys. Of course it would probably be ideal to have an option as to whether a new secret key would be created in the system spool or in the user home directory, and migrating the key from the user home directory to the system spool would be supported (but not migrating it back). This would mean that an attacker who compromised a local user account (maybe through a vulnerability in a web browser or MUA) would not be able to get the GPG secret key. They could probably get the pass-phrase by ptracing the MUA (or some other GUI process that calls GPG) but without the secret key itself that would not do as much good - of course once they had the pass-phrase and local access they could use the machine so sign and decrypt data which would still be a bad thing. But it would not have the same scope as stealing the secret key and the pass-phrase. I look forward to reading comments on this post.

• [1] http://etbe.coker.com.au/2008/02/17/hot-plug-and-how-to-defeat-it/


• [2] http://etbe.coker.com.au/2008/06/06/se-linux-support-gpg/

Share This

• Personal stuff coming up; if you are not that kind of person, please skip :-)
  
• I forgot to say on my previous post about YAPC::NA 2008 that while I was in Chicago, I had the really nice chance to meet Carlo Segre and Dirk Eddelbuettel and enjoy a couple of nice beers with them. Great guys!
  
• I'm probably not attending DebConf this year. It's just too expensive right now and since sponsorship appears to be not enough, chances for me are quite low now. The cheapest I can get from NYC is around $1050/1100, which might be cheap for some folks in Europe which paid the same amount in Euros, but not for me now.
• I'm not attending OSCON neither. I wanted to, I really did, but it'll have to be next year now, because...
  
• On that days, I'll be in Mexico City with Raquel renewing our visas. Almost one year already since we got here, time flies.
• Last Friday (Fourth of July), we were invited by Mike and Rachel O'Connor to a barbeque at their place in Brooklyn. Even though they are veggies, they had some meat sausages and burgers which were great (also the grilled corn!). We watched the fireworks from their roof, which I have to say, weren't as spectacular as I expected, but it was probably because we weren't very, very close to Manhattan or because a big building was blocking our view in front of us, or because of the rain. A bunch of their friends were also there. I enjoyed spending time with them and Mr. Micah Anderson and Sr. Abraham Estrada. By the way...
• There will be a Debian NYC BSP very soon now! Stay tuned! Represent! :P
  
• I've been playing more chess that it should be legal, as some of you may have already realized.
• I gave myself a present and bought a PSP. I now do alley-oops, slam dunks and all kind of dribbles on NBA Live 2008 on my morning commute ;-)
  
• And last; for my personal workstation, I'm trying now Ubuntu Hardy and I'm doing a personal project with Rails. I have to say that even though I had some encountered feelings about both of them, I've been having quite a nice surprise and experience with both.
  

It's now official, we're leaving Lille with my girlfriend and will move back to Paris in around 10 days. That means a new home, but I keep the same job. I'll live again in the 14th arrondissement in a 2 room flat which is about 52 m . My DSL connection should already be up, even though I don't have the flat keys: (too) perfect timing.

As summarized by Ace Suares, to validate my first rough upgrading instructions:

1. Upgrade the packages in the LTSP chroot First become root: sudo chroot /opt/ltsp/i386 Then add the repository, update and upgrade: echo "deb http://ppa.launchpad.net/q-funk/ubuntu hardy main" >> /etc/apt/sources.list apt-get update && apt-get upgrade && apt-get clean APT will inform you that some packages cannot be authenticated. This is normal, since the PPA is not digitally signed. Simply answer Yes.
2. Purge the transitional AMD driver apt-get --purge remove xserver-xorg-video-amd Then, exit the chroot:

   exit

3. Update the LTSP boot image

   sudo ltsp-update-image

   On a 64-bit server, the correct command is:

   sudo ltsp-update-image --arch=i386

4. Profit?

Happy Midsummer, everyone!

When I just started to read planet.debian.org today, I realized that Russel Coker was speaking of an unknown tool to print the UUID, but that Debian version doesn't seem to do that.

It's called fle apparently.
Sadly, an apt-cache showed that there's no package named fle. Then I realized that he was actually speaking of the good old tool called file - with an I between F and L!
Really, I wish the font rendering will improve in Lenny as this was on Etch... sigh

It had to happen sooner or later: The X.org drivers for the old GX1 variants of the Geode chips formerly made by Cyrix and NSC no longer build against the current X.org release. Given the imminent release of X.org 7.4 (server core 1.5), this essentially means that users of older Geodes will have a nasty surprise, the day they upgrade to Ubuntu/Intrepid, which ships with core 1.5. Soon after, the release immediately following Debian/Lenny will be affected too. There is a planned milestone to eventually reintegrate support for older GX1 products into the clean and up-to-date xf86-video-geode framework, but this will unfortunately come too late for those upgrading to Ubuntu/Intrepid, unless... ...unless someone volunteers to copy gx_* files inside xf86-video-geode and graft GX1 support into the resulting gx1_* files. If you have access to Cyrix/NSC GX1 + CS5530 or AMD SC hardware and a reasonable knowledge of the X.org codebase, your contribution would be most welcome.

Someone asked on a mailing list about the issues related to whether to use a label, UUID, or device name for /etc/fstab. The first thing to consider is where the names come from. The UUID is assigned automatically by mkfs or mkswap, so you have to discover it after the filesystem or swap space has been made (or note it during the mkfs/mkswap process). For the ext2/3 filesystems the command “tune2fs -l DEVICE” will display the UUID and label (strangely mke2fs uses the term “label” while the output of tune2fs uses the term “volume name“). For a swap space I don’t know of any tool that can extract the UUID and name. On Debian (Etch and Unstable) the file command does not display the UUID for swap spaces or ext2/3 filesystems and does not display the label for ext2/3 filesystems. After I complete this blog post I will file a bug report. If you are using a version of Debian earlier than Lenny (or a version of Unstable with this bug fixed) then you will be able to easily determine the label and UUID of a filesystem or swap space. Other than that the inconvenience of determining the UUID and label will be a reason for not using them in /etc/fstab (keep in mind that sys-admin work sometimes needs to be done at 3AM). One problem with mounting by UUID or label is that it doesn’t work well with snapshots and block device backups. If you have a live filesystem on /dev/sdc and an image from a backup on /dev/sdd then there is a lot of potential for excitement when mounting by UUID or label. Snapshots can be made by a volume manager (such as LVM), a SAN, or an iSCSI server. Another problem is that if a file-based backup is made (IE tar or cpio) then you lose the UUID and label. tune2fs allows setting the UUID, but that seems like a potential recipe for disaster. So this means that if mounting by UUID then you would potentially need to change /etc/fstab after doing a full filesystem restore from a file-based backup, this is not impossible but might not be what you desire. Setting the label is not difficult, but it may be inconvenient. When using old-style IDE disks the device names were of the form /dev/hda for the first disk on the first controller (cable) and /dev/hdd for the second disk on the second controller. This was quite unambiguous, adding an extra disk was never going to change the naming. With SCSI disks the naming issue has always been more complex, and which device gets the name /dev/sda was determined by the order in which the SCSI HAs were discovered. So if a SCSI HA which had no disks attached suddenly had a disk installed then the naming of all the other disks would change on the next boot! To make things more exciting Fedora 9 is using the same naming scheme for IDE devices as for SCSI devices, I expect that other distributions will follow soon and then even with IDE disks permanent names will not be available. In this situation the use of UUIDs or LABELS is required for the use of partitions. However a common trend is towards using LVM for all storage, in this case LVM manages labels and UUIDs internally (with some excitement if you do a block device backup of an LVM PV). So LV names such as /dev/vg0/root then become persistent and there is no need for mounting via UUID or label. The most difficult problem then becomes the situation where a FC SAN has the ability to create snapshots and make them visible to the same machine. UUID or label based mounting won’t work unless you can change them when creating the snapshot (which is not impossible but is rather difficult when you use a Windows GUI to create snapshots on a FC SAN for use by Linux systems). I have had some interesting challenges with this in the past when using a FC based SAN with Linux blade servers, and I never devised a good solution. When using iSCSI I expect that it would be possible to force an association between SCSI disk naming and names on the server, but I’ve never had time to test it out. Update: I have submitted Debian bug #489865 with a suggested change to the magic database. Below are /etc/magic entries for displaying the UUID and label on swap spaces and ext2/3 filesystems:
The following magic entry will display the UUID of a swap space as well as displaying the label in the same manner as the mkswap program:
# according to man page of mkswap (8) March 1999
# volume label and UUID Russell Coker
# http://etbe.coker.com.au/2008/07/08/label-vs-uuid-vs-device/
4086 string SWAPSPACE2 Linux/i386 swap file (new style),
>0×400 long x version %d (4K pages),
>0×404 long x size %d pages,
>1052 string \0 no label,
>1052 string >\0 LABEL=%s,
>0×40c belong x UUID=%x
>0×410 beshort x \b-%x
>0×412 beshort x \b-%x
>0×414 beshort x \b-%x
>0×416 belong x \b-%x
>0×41a beshort x \b%x The following magic entry will display the UUID and label (AKA volume name) of an ext2/3/4 filesystem:
# ext2/ext3 filesystems - Andreas Dilger <adilger@dilger.ca>
# ext4 filesystem - Eric Sandeen <sandeen@sandeen.net>
# volume label and UUID Russell Coker
# http://etbe.coker.com.au/2008/07/08/label-vs-uuid-vs-device/
0×438 leshort 0xEF53 Linux
>0×44c lelong x rev %d
>0×43e leshort x \b.%d
# No journal? ext2
>0×45c lelong ^0×0000004 ext2 filesystem data
>>0×43a leshort ^0×0000001 (mounted or unclean)
# Has a journal? ext3 or ext4
>0×45c lelong &0×0000004
# and small INCOMPAT?
>>0×460 lelong <0×0000040
# and small RO_COMPAT?
>>>0×464 lelong <0×0000008 ext3 filesystem data
# else large RO_COMPAT?
>>>0×464 lelong >0×0000007 ext4 filesystem data
# else large INCOMPAT?
>>0×460 lelong >0×000003f ext4 filesystem data
>0×468 belong x \b, UUID=%x
>0×46c beshort x \b-%x
>0×46e beshort x \b-%x
>0×470 beshort x \b-%x
>0×472 belong x \b-%x
>0×476 beshort x \b%x
>0×478 string >0 \b, volume name "%s"
# General flags for any ext* fs
>0×460 lelong &0×0000004 (needs journal recovery)
>0×43a leshort &0×0000002 (errors)
# INCOMPAT flags
>0×460 lelong &0×0000001 (compressed)
#>0×460 lelong &0×0000002 (filetype)
#>0×460 lelong &0×0000010 (meta bg)
>0×460 lelong &0×0000040 (extents)
>0×460 lelong &0×0000080 (64bit)
#>0×460 lelong &0×0000100 (mmp)
#>0×460 lelong &0×0000200 (flex bg)
# RO_INCOMPAT flags
#>0×464 lelong &0×0000001 (sparse super)
>0×464 lelong &0×0000002 (large files)
>0×464 lelong &0×0000008 (huge files)
#>0×464 lelong &0×0000010 (gdt checksum)
#>0×464 lelong &0×0000020 (many subdirs)
#>0×463 lelong &0×0000040 (extra isize)

Share This

Some time ago, I added a
Spammers Hall of Shame to my first website, codehelp.co.uk.

"... sites that send me unsolicited commercial email can expect a poison
response. If such companies are arrogant enough to not even read the
contents of this page, then I shall post details of their incompetence
here."

It's not often that I add a new one - generally when the spammer in question tries to claim that it is not spam and pretends to have taken an interest in the site when it is plainly obvious that the About page has been completely ignored. It takes a special kind of idiocy to get onto the list - something that motivates me to a noticeable level of annoyance. The vast majority of spam doesn't come anywhere close. It has to be something that has some indication of being supposedly "customised" for me and my website(s) yet equally takes absolutely no notice of the content of that website, specifically the content explicitly added to About that should have been noticed by anyone with half a brain.

Anyway, my latest poison pen is now available for everyone to see.

True, it gives their spam email a wider airing but it's not as if codehelp.co.uk is anything but a very quiet backwater of the internet so it's not going to affect traffic in any real way. I just get annoyed when idiots who claim to be professionals do not have the simple courtesy of reading.

In a similar tone:
http://qof-gen.sourceforge.net/#free

I think I'm ready to go to Debconf 8 now. Just got the last missing vaccination of ones recommended for visitors of Argentina (link German, sorry). Also signed up for an insurance in case I get sick. Now I just need to prepare my stuff properly and restock some of the drugs I occassionally use, just in case. I still feel a bit inert, but I guess that it will be a nice trip and experience. Thanks to those who made it possible!

I have just been running some ZCAV tests on some new supposedly 1TB disks (10^40 bytes is about 931*2^30 so is about 931G according to almost everyone in the computer industry who doesn’t work for a hard disk vendor). I’ve added a new graph to my ZCAV results page [1] with the results. One interesting thing that I discovered is that the faster disks can deliver contiguous data at a speed of more than 110MB/s, previously the best I’d seen from a single disk was about 90MB/s. When I first wrote ZCAV the best disks I had to test with all had a maximum speed of about 10MB/s so KB/s was a reasonable unit. Now I plan to change the units to MB/s to make it easier to read the graphs. Of course it’s not that difficult to munge the data before graphing it, but I think that it will give a better result for most users if I just change the units. The next interesting thing I discovered is that by default GNUplot defaults to using exponential notation at the value of 1,000,000 (or 1e+06). I’m sure that I could override that but it would still make it difficult to read for the users. So I guess it’s time to change the units to GB. I idly considered using the hard drive manufacturer’s definition of GB so that a 1TB disk would actually display as having 1000GB (the Wikipedia page for Gibibyte has the different definitions [2]). But of course having decimal and binary prefixes used in the X and Y axis of a graph would be a horror. Also the block and chunk sizes used have to be multiples of a reasonably large power of two (at least 2^14) to get reasonable performance from the OS. The next implication of this is that it’s a bad idea to have a default block size that is not a power of two. The previous block sizes were 100M and 200M (for 1.0x and 1.9x branches respectively). Expressing these as 0.0976G and 0.1953G respectively would not be user-friendly. So I’m currently planning on 0.25G as the block size for both branches. While changing the format it makes sense to change as many things as possible at once to reduce the number of incompatable file formats that are out there. The next thing I’m considering is the precision. In the past the speed in K/s was an integer. Obviously an integer for the speed in M/s is not going to work well for some of the slower devices that are still in use (EG a 4* CD-ROM drive maxes out at 600KB/s). Of course the accuracy of this is determined by the accuracy of the system clock. The gettimeofday() system call returns the time in micro-seconds. I expect that most systems don’t approach miro-second accuracy. I expect that it’s not worth reporting with a precision that is greater than the accuracy. Then there’s no point in making the precision of the speed any greater than the precision of the time. Things were easier with the Bonnie++ program when I just reduced the precision as needed to fit in an 80 column display. ;) Finally I ran my tests on my new Dell T105 system. While I didn’t get time to do as many tests as I desired before putting the machine in production I did get to do a quick test of two disks running at full speed. Previously when testing desktop systems I had not found a system which when run with two disks of the same age as the machine could extract full performance from both disks simultaneously. While the Dell T105 is a server-class system, it is a rather low-end server and I had anticipated that it would lack performance in this regard. I was pleased to note that I could run both 1TB disks at full speed at the same time. I didn’t get a chance to test three or four disks though (maybe for scheduled down-time in the future).

• [1] http://www.coker.com.au/bonnie++/zcav/results.html


• [2] http://en.wikipedia.org/wiki/Gibibyte

Share This

My first go at getting Emdebian to run a GUI:


Yes, yes, there are no icons and the touchscreen library doesn't work so
the apps can't start (at least via the screen) but it's a start!

Silver USB cable on the left if ethernet-over-usb (which works fine), on the right is a USB key from which the root filesystem, kernel and modules were installed (not needed for subsequent operation but used for debugging by copying log files to the key etc.).

Stats:
Still too large at over 80Mb installed for a full GUI but that is still
100Mb smaller than a minimal Debian system without any GUI stuff.
Available only for ARM
Tested only on Balloon3 : http://balloonboard.org/index.html
Not installing cleanly at this stage - some fettling is required.

192 packages used.
Linux balloon 2.6.25.2-pxa270 #1 Sun May 18 22:38:11 BST 2008 armv5tel
unknown

ii dpkg 1.14.20em1
ii libgpewidget1 0.115-5em1
ii libgtk2.0-0 2.12.3-2em1

Access:
Ethernet over USB (static IP only at the moment)
USB storage / keyboard
Serial connection
SSH pending

Lots to do to make it simple but at least it works.

I spent a week recently working on the nonfree firmware problem in debian-installer. The problem of course, is that nasty nonfree firmware is needed to use many wireless cards, some other NICs, and some disk controllers, but cannot be included in d-i images. The fix/workaround landed in unstable today. d-i will detect if a driver needs firmware that is not available. It'll then prompt the user to put the firmware on removable media (such as a USB stick, or floppy, or really anything you can plug into a machine without drawing blood). The debian-cd team will be building some zip files and tarballs containing all the firmware that debian ships in non-free. (images here) Extract one of those onto a USB stick (vfat formatted), and you're good to go. The installer will also tell you the names of the firmware files it needs, so if they're some of the ones that Debian cannot even legally distribute (such as the ipw2200 firmware), you can go hunt them down, and dump them onto your USB stick too. The installer can find firmware files loose on the USB stick, or packaged up in a .deb (or .udeb). The firmware will be used during the installation, and also installed into the finished system. So providing it in .debs is cleanest. (BTW, if you package a firmware deb for debian, please avoid putting anything but firmware and documentation in it. These firmware debs are also installed into the d-i environment now.) This could be considered a little clumsy, needing to manually find the bits and put them on a USB stick. I think that people who install Debian frequently will probably end up gravitating toward the "hd-media" installer that boots from USB stick. The firmware can then be put on the same USB stick that contains the installer, and only one thing be needed to install. Still to do: Use discover's capabilities to scan for firmware that is needed by other devices on the machine, that are not needed to install, but can be used later, and install that firmware too. (This will also support installing non-free kernel modules and other such evil.)

Dear Joey, we also had this problem for dpkg, that’s why I hacked the /usr/local/bin/git-commit-notice script that we’re using on Alioth to do something like this instead: It will stop git rev-list each time that it encounters a commit that is available in any of the other branches present in the repository and thus when you merge a branch, you only see the merge commit in CIA. You should also note that the script is smarter as it calls CIA only for branch updates, not for tag creation (and other kinds of updates) where it only leads to strange errors IIRC. Partagez cet article / Share This