Search Results: "nate"

14 August 2006

Neil McGovern: How to set fire to your hard drive

I was off searching for stock photos today on a site called istockphoto when I found my machine grinding to a halt. Thanks to the system load plugin in XFCE, I was able to tell that about half of my 515Mb of swap was being used. This laptop has 256Meg ram in it already, so what could possibly be using up that much memory?

Well, the answer was simple. Firefox. More precisely, the flash plugin for firefox. istockphoto uses a system called sIFR, which replaces text, mostly titles, with little embedded flash objects. More details about this technique can be found at Mike Davidson's blog. Now, it seems that this particular site is titling EVERY headline with a flash object, which is causing firefox to use up about 300Mb of ram. So, I installed Flashblock to remove this memory hogging flash from my web pages. It did indeed free up the memory, and stopped the flash from displaying.

Interestingly, Firefox did not free up the memory it was using until I shut the thing down and started it again. It was suggested that this may be due to the way that firefox has a built in memory cache of pages loaded. After a quick look in about:config, I discover that there is an option, browser.cache.memory.enable that's set to 'true'. However, setting this to false causes work's web page to fail to load at all. Having a look with ethereal, the request goes out, and the text comes back. It just displays about:blank.

So, in summary, if you need to reduce memory requirements, don't use firefox. This would be the favoured option for me, if there was a good alternative that has the Web Developer Toolbar, but unfortunately, there isn't.

13 August 2006

Adam Rosi-Kessel: Return to Traverse City Film Festival

We spent last week at the Traverse City Film Festival in Michigan. This was the second year of the festival as well as our second year attending. Unlike last year, there was no “Freedom Festival” organized by Michael Moore-haters this year. Perhaps they are still recovering their debts from last year, when they lost money and had to stop their showing of “Michael Moore Hates America” after discovering it had inappropriate language for the family audience they were targeting. We saw nine films in just five days — four in one day was our max. (Rachele saw one more — The Beauty Academy of Kabul — that I missed, unfortunately, and we gave our tickets to Jesus Camp to Rachele’s parents.) Our selections were: The one that sticks most in my memory is La Moustache. The essence of the plot is revealed in the first minute of the movie: a man shaves off his mustache. His wife of fifteen years doesn’t notice. In fact, she doesn’t remember he ever had a mustache. While the film starts as vaguely comic, it quickly spirals into a psychic breakdown with a possibly unreliable narrator. It was quite nearly perfect. The beautifully restored virgin print of Monty Python’s Holy Grail was astonishing. The film was shown for free on a large outdoor screen by the lake, and the sound was crystal clear (now in stereo!) no matter where you sat. There are a bunch of scenes everyone always remembers in the Holy Grail. I realized after watching it again that the movie is composed entirely of these memorable scenes. (I had the same feeling watching the Wizard of Oz after a ten to fifteen year hiatus recently.) Finally, Stanley Kubrick’s first film, The Killing (1956) also merits the maximum rating, whatever that is (5.5 stars?). While it lacks the surreal/experimental feel of his later films, Kubrick was already beginning to play with narrative structure and sequencing. The film walks through the events leading to the climax several times, each time from a different character’s point of view. But really it’s just a great heist flick. Mani Haghigi, the Iranian director of Men at Work, had an interesting observation about the festival. Unlike most other film festivals, he, as a director, could just hang out and enjoy the films and the company and not worry about impressing executives and distributors. The festival’s motto is accurate — “Just Great Movies.”

Steve Kemp: As I watched there was another jet of gas

Migration complete! I now have two distinct servers/hosts: Both servers are backed up nightly to a “backup server” hosted in my house (Hostname: itchy.my.flat) via rsnapshot. An interesting few days getting the split to occur nicely, which involved some DNS + Domain Registrar juggling due to obscure reasons. Now that the split has been made I can start working on better caching, and performance tweaks on the d-a.org site. I’m currently investigating the use of fast_cgi, since I think that the code should be simple to modify for this. Otherwise I’m now back in action. I have pending releases of several packages to upload, and a new upstream release of GNUMP3d to prepare.

12 August 2006

Erich Schubert: On onboard graphics,

Daniel Burrows writes "and the built-in graphics card (usually Intel) on the motherboard is just fine for that." I would agree with you, if I had an built-in graphics card with Intel. That is in fact what I'm aiming for for my next laptop. But actually none of the PCs I have in my house has Intel graphics, unfortunately. Intel graphics is pretty much restricted to Core CPUs and Laptops. Which sucks. I wish there would be more "budget" systems with Intel graphics. As you mentioned I don't need high end graphics anyway. I actually don't need high end CPU anyway (power consumption is more interesting, and the value/price ratio). I wish I could have bought a system with Intel graphics, but that would have been twice the price. I wish we had some standard like VESA, just a bit more modern. Like having sane refresh rates for non-TFT screens and maybe some extra acceleration. Oh, and I actually doubt that ATI would give away much secrets if it would allow distributing the existing opensource X drivers. It's not as if the specs of their CPU would be a huge surprise to Nvidia. Some actually say nvidia builds the better graphics cards. And Intel does even give away source code. We're not talking about chip design here, or driver optimizations. Just the plain registers and ports. heck, ATI, Nvidia and Intel could probably even agree on a standard here, except it would mean they'd need to change their drivers and hardware for the next generation with really no visible benefit to them (only to us, we could maybe run the basics with the same driver).

Daniel Burrows: We aren't ATI's market.

Erich Schubert noted that ATI is holding onto their closed drivers. While it's unfortunate, I don't think this should be surprising to anyone. NVIDIA and ATI make their money by selling cards for gamer types, who make an art out of trying to get the latest super hardware to play the newest snazzy games on. They don't give a hoot about source code access -- after all, they're probably running proprietary games on a proprietary operating system anyway.

Free software enthusiasts, on the other hand, spend their free time hacking code and so don't have time to play the massive productions the game industry puts out nowadays; frozen-bubble or Wesnoth are about as much gaming as we have time for. As a result, we can do just fine with a video card capable of displaying Emacs, a couple xterms, and maybe a graphical Web browser -- and the built-in graphics card (usually Intel) on the motherboard is just fine for that. We also tend not to run Windows or OSX, where 99% or so of graphically intensive games come out, so even if we HAD free time for gaming we wouldn't be able to do it on a free system.

As a result, while I'd certainly like to have free ATI drivers, I think it's unrealistic to expect them anytime soon. ATI is a company, not a charity, and they will not provide source code or specs until it will clearly benefit them more than it hurts. If you don't believe me, try walking into your manager's office and saying "hey, I have a great idea! Let's give away all our secrets without any clear way to make money off it!" and see how he reacts. (note that this experiment may not apply to the 1-5% [0] of readers lucky enough to work in academia)

[0] this statistic determined by the HIGHLY SCIENTIFIC method of picking a small number at random.

Martin F. Krafft: The relation between cipher blocks and physical blocks

Many people have responded to my post on encrypted filesystems and power losses; thank you! To clear up the confusion, I decided to write a new entry rather than updating the previous one... I learnt two important things about encrypted block devices, which make me conclude that the addition of encryption does not put your filesystem at jeopardy any more than if it lived directly on the medium. First of all, AES works on blocks of size 128 bits, not 64 bytes, but that's mostly a cosmetic issue with respect to the original blog post. What's more important is that a power loss while writing out a cipher block effectively is the same as a power loss while writing out a physical block to the storage medium: the cipher block is usually smaller than the disk block, and an incompletely written disk block is considered to be invalid. So any incomplete cipher block results in an incomplete disk block, which in turn causes the filesystem to consider the block invalid and try to recover from the journal. What confused me for a long time was the use of chaining block ciphers (see the excellent Wikipedia article for more info). Essentially, block chaining adds security to encryption by making each (cipher) block depend on its predecessor. Great, I thought, so if the first block on disk is corrupted, it'll percolate all the way through the disk and render it all unusable... Well, fortunately, this is not the case... by that logic, a write to the first block would require all remaining blocks on the disk to be recalculated. It is true that cipher blocks are chained, but only within a physical block. This means that a read error on the medium may corrupt a cipher block, which then renders all following cipher blocks contained in the physical block unusable (for they cannot be decrypted anymore). But since the filesystem would already consider the entire block invalid, this does not add to problem. PS: Thanks to Peter Samuelson for (passively) leading me to the light.

Martin F. Krafft: Summer in Limerick

As some of you may know, I am currently in Ireland, spending most of the summer at the Irish Software Engineering Research Centre to get a start on my Ph.D. research. This is the story of how I got here and how it's been so far. In the middle of July, I left my beloved city of Zurich and headed for Dublin. I commenced my stay in "the green country" with a three-day Debian workshop for the Google Europe sysops, which was intensive and yet enjoyable. I had between 4 and 10 participants, and the syllabus was to cover most everything, from APT basics to advanced concepts. That's a lot for three days, and I usually advise clients to consider a five-day or even two-week course instead, but after convincing the organiser to plan for three days rather than just two, I figured I'd be dealing with pretty good people anyway, given Google's hiring standards. I was not to be disappointed. We started the course with installation problems, because the 2.6 kernel install which I suggested could not deal with the SATA driver in the new IBM T43p notebooks which the participants were using. While one guy decided to try a 2.4 install with the IDE-sata driver, I opted to go down the debootstrap route instead, and was especially delighted -- at first -- to learn about a working netboot setup in the Google LAN. My joy vanished when I found the Ubuntu rescue image not to contain debootstrap, so I didn't have much choice but to prepare a root tarball and offer it for wget download. This worked, and after manual tweaking and making the system bootable, running into some issues after inadvertedly upgrading the entire system to the backports.org archive (which still does not offer a proper default pin), we decided to just go with testing and be done with it. I have to say that I really like courses where stuff does not work, as I believe those to be far more valuable to the participants. This time around, it was also the first time (after having taught maybe 60 or 70 courses in total) that I did not let myself get stressed out. Realising this put me in a great mood and made those days even more enjoyable. The rest of the workshop went without further complications, but judging from feedback over cigarettes, lunch, or the evening beer(s), the guys and girls still appreciated it. I have to thank Google and all participants for a great three days of hospitality and challenges, interesting discussions and fun. I really ought to reconsider my decision not to accept their offer for a sysop position... The last day saw me getting sick though, it must have been the air-conditioning. When I reached the hotel after the course, I definitely knew I had high fever and was developing a bad headache and cough, so I didn't get to enjoy a Friday night out in Dublin. Instead, I slept from 18:00 hours until the late morning, when I had to drag myself to the train station to catch the train to Limerick... which was painful, but I managed. Some time in between, I tried out nstx and managed to get a decent SSH connection to the outside world from the hotel room (just don't forget the -a -x flags!). Arriving in Limerick, I registered for the student apartment I had rented and found myself in a small room with a bed and desk, my own bathroom, a common room and kitchen I share with my room mate (whom I barely saw), including a TV, fridge, oven, microwave, and enough "little stuff" to make me conclude that this place was livable -- for 60 /week not a bad deal. I spent most of the weekend sleeping, but it was not until Tuesday that my state had returned to normal. The place also has an Ethernet jack, but that turned out to be unusable as it was (a) behind a fascist firewall, and (b) on the same network as about 40 other users, 17 of which seemed to be running peer-to-peer filesharing clients all hours of the day. In my office at the university, I found myself in the same situation as (a), but at least I managed to install OpenVPN, and dsniff and was thus ready to take back the net in my apartment. I wrote a little script which would (a) spoof ARP replies from the router for all hosts for a few minutes, (b) analyse the traffic it got to identify obvious P2P machines, and (c) proceed to poison their ARP cache every few seconds, effectively shaping their connection. I had to go this way, because tools like tcpnice (part of dsniff) do not work in a switched network very well, and neither did macof. Unfortunately, I lost the script in the recent XFS fiasco, but the major P2P offenders seem to have left anyway. Thanks to OpenVPN, I also got VoIP working and am happily tunneling through the university's proxy (which otherwise would require me to use the SOCKS4 proxy protocol with proxychains, which would be a nuisance). I really don't understand why a university blocks outgoing traffic. Oh well... It's been three weeks since I've come to Limerick, and my feelings are mixed. I've been spending most time in my (temporary) office (pretending to be) doing work, I have not really acquainted myself with the food here, the university campus is filled with hundreds of 14 year old summer school students but nobody of my age, and, well, research is coming along slower than I had hoped. I guess that's normal in a sense, but I also know for sure that I have a lot of work left to do on my discipline. I am a master of procrastination, you see, and Debian is a dangerous drug, a black hole that sucks in your time while it excites your synapses and splashes endorphines all around. But I've not lost my hope at the very least... Thanks for caring.

Evan Prodromou: 25 Thermidor CCXIV

Maj went out for her birthday party with a passel of ladies, so I stayed home and ate pizza and watched Twelve Monkeys with the baby. We had a good time, but as the baby is approaching 1 years old, my going-to-sleep tricks are becoming somewhat outdated. My main way to put the baby to sleep is to walk her from the front door of our apartment all the way back to the laundry room, and then turn around and walk out to the front door again. I sing during the entire process, mostly Neil Young and Johnny Cash tunes, but also a mix of 80s pop, reggae, songs, and goofy children's songs. Really, it's anything I can remember the words to, or that I can bridge over with some ad-libbing. This worked pretty well when she was teensy-tiny, and it's still the best way for me to get her to sleep. But as she's approaching 15kg, it's getting to be a serious workout for me to slog up and down the hallway 50 times belting out Take the Skinheads Bowling at high volume. We have a few baby books on how to get a child to sleep easier, but I've been taking the path of least resistance. I'll probably have to take the plunge and get her to fall asleep in bed soon -- which will probably mean some angry baby moments. Still, putting the baby to sleep is one of the most satisfying things in my life right now -- I highly recommend it. tags:

Programmer hierarchy Luke Welling's programmer hierarchy, based on The Brunching Shuttlecocks' classic Geek Hierarchy, is humorous and accurate. tags:

Tag improvements So, I've made some improvements to the tagging system on this blog. Instead of doing a full-text search at runtime to lookup which pages contain which tag, I instead keep a map of tags to page names in a separate db, and then look up in that index at runtime. The bummer is that I'm not figuring out a way to keep that db up-to-date easily. The best action, of course, would be to have the tags db updated at write time, but I can't figure out how to make that work. I tried it with a write macro, but you can't get the title of the current page with a write macro, unfortunately. I might just add a hook to the commit action -- that's about all I'm coming up with right now. It's annoying that Wiliki doesn't have hooks enabled anywhere. Gar. tags:

Erich Schubert: ATI likes their closed drivers. We don't.

ATI is reported to not plan to release their drivers into OpenSource. Too bad. And I don't plan to buy any more ATI graphics. I'll go with Intel. Actually it would be sufficient if they would release the specifications. We don't really want to see their "patented optimizations" (which probably are just for cheating in known 3D benchmarks anyway, so what would we gain from that?). We'd be happy if we were allowed to distribute the already written independent driver. Which is blocked by an NDA, not by some "patented optimizations". Anyway, I'll buy a new laptop end of this year, and guess what - it will have Intel graphics. They've already released drivers for their next chip to be released. My current laptop, an IBM Thinkpad A31p, has an ATI graphics board. Which is not supported by the ATI driver. Fortunately there is an opensource driver which works fine, with 3D acceleration. Another reason I'm not going to buy any ATI, you never know when they decide to no longer support your board.

11 August 2006

Martin F. Krafft: XFS and zeroed files

Erich complains: "If the file is damaged, just fill it up with zeroes?" (in response to my recent post on filesystem problems). Update: I rewrote the second sentence of the next paragraph (up until and including the footnote) to get things right. Thanks to Russell Cattelan for providing the info. This must be the most misunderstood feature of XFS. What happens is that XFS logs all metadata changes to the journal, except for the inode size, which gets flushed to disk immediately for performance reasons [*]. At this point, the file will actually be a sparse file, which is nothing more than a file whose metadata lists a file as being of a size different than it currently is (I realise the "sparse" does not really apply when the file is "overfull", i.e. when the metadata lists it as smaller than it really is, but I am lacking a good word for that). The disk extents get allocated only when the data actually hits the disk (that's XFS's famous delayed allocation mechanism). If the power fails before the data was flushed to disk and the journal entry cleared, XFS will serve zeroes, rather than the potentially random or sensitive data that is actually on disk. This is a good thing.
[*]since almost every write() changes the file size, it would be a massive performance hit if every size change was logged. However, XFS actually violates its own journaling rules by doing this.
You can run into more or less the same problem with any journaling filesystem; the others just don't serve zeroes. Instead, they give you the data that's physically on the medium. Imagine the situation when the corrupt /etc/motd suddenly becomes a window to your previous /etc/shadow contents... I really prefer how XFS handles that. Sometimes you do get the old data back with the other filesystems, but this is because the filesystems may reuse the blocks of the old file. So it's a trade-off, and your choice between security and, uh, convenience. The only way to protect against this is to use "physical-block journaling" (as opposed to "logical journaling"), which is only supported by ext3 as far as I know (option data=ordered), at a massive performance loss. See this mailing list post by Theodore Ts'o for more info. Thanks to Alceste Scalas for sharing it with me. PS: Thanks to Wessel Dankers and Eric Sandeen for their help on #xfs. Update: Again thanks to Russell Cattelan, I just received word that code has been added to the 2.6.17 kernel which will flush an inode at close if it was truncated at some previous point. This should take care of many of the zeroed-file issues. Update: RazorFS also supports data=ordered. Thanks to Hans Kratz for pointing this out. He also adds some more information, parts of which I've written about previously:
One of the major problems of all journalled filesystems especially on notebooks/desktop machines leading to filesystem corruption is the harddisk writeback cache (enabled by default). With the writeback cache some writes are not immediately written to disk Now if a crash happens some of the data may not have hit the disk. The journalling filesystems however need a way to rely that the certain writes have hit the disk to ensure filesystem consistency. There are two solutons: Enable write barrier support in the filesystems (avalable for ext3 since around 2.6.8, mount option: barrier=1, available for the other filesystems as well now probably) or disabling the write cache altogether with hdparm/sdparm.
XFS supports barriers as well, but unfortunately not yet on non-physical media, like RAID or dm-crypt. ext3 seems to work okay on both. Enable your barriers today!

Erich Schubert: XFS woes

I'm going to join madduck, Gunnar Wolf and Julien with their negative experiences with XFS. The celeron 412 I mentioned before had an XFS filesystem since a few years. It replaced a raisswolffs. It certainly worked better than raiser. But as said, that old machine has been crashing, and when I copied over the data for my dad to his new machine, I noticed that his .gconf file was destroyed by XFS. All 0-bytes, typical for XFS. If the file is damaged, just fill it up with zeroes? I've seen 0-bytes a couple of times before in log files on XFS partitions that were open during a crash. It sucks that gconf didn't keep a backup. Anyway, the .gconf file includes his evolution configuration, amonst other stuff. Thats how we noticed (apart from all other gnome settings being gone, too), since restoring evolution was the top priority item for me. Fortunately, I picked ext3 when setting up the new system. I never had experiences with ext2 or ext3 as bad as with xfs. Or reiserfs, which just trashed the whole filesystem when I ran "reiserfsck". Thats not what a fsck is supposed to do, is it?

Evan Prodromou: 24 Thermidor CCXIV

I said a few days ago that Ross Mayfield had one of the best blogs about wikis and the wiki business. But Eugene Eric Kim gives him a run for his money. EEK Speaks covers in detail a lot of the public and private aspects of wiki going on right now. Of course, I wouldn't paint EEK and Ross as rivals; after all, they won the Web 1.0 pitch contest at Wikimania together. tags:

Victory is mine (I think) For the last few weeks, some of the more advanced features of this wiki have been blowing up with a 500 Internal Server Error, to my great chagrin. I had switched from using CGI to FastCGI for WiLiKi and I'd seen a real improvement in the responsiveness of the site, but these occasional errors were becoming more frequent. I finally hunkered down to figure out the problem. Annoyingly, there was no error output in the Apache error logs, so I guessed that the problem was sooooo bad that the process didn't even get a chance to scream on stderr before dying. I had all kinds of theories about this. Most of the problems had to do with full-text searches of the database, so I guessed that the underlying cause had to do with I/O and concurrency. Gauche has a nice logging facility, so I threw in a lot of logging printf statements (or their equivalent) and isolated the problem to a few calls into Gauche's dbm libraries. Aha! The problem had to be concurrent DB access. I layered on a big slathery scoop of mutexes and locking and other such good concurrency stuff and... the problem was still there. D'oh! So much for my diagnostic skills. I decided to take a step back. After ascertaining for myself that any writes to stderr from within a FastCGI program should indeed show up in the error log -- by reading and by writing a couple of sample programs -- I turned to the debugging tool of last resort: strace. strace logs all system calls by a program, which can be a lot of information. I couldn't, of course, just start my FastCGI program, so I had to strace the entire Apache process, with lots of command-line flags to divvy up the output on a per-process level. Once I had that going, I could kind of see what was going on. My full-text searches were starting up fine, but about halfway through the search they'd get a SIGTERM and terminate. Holy moly! That wasn't an error in my program -- someone was murdering my poor little FastCGI processes. At first I suspected fratricide -- that the processes were terminating each other when they needed the database resource -- but I realized right away how dumb that was. That only left one suspect -- the parent! I dug a little bit into the fcgid documentation, and sure enough, if a process went too long without giving any output, fcgid would terminate it. I upped the time limit for this wait, and now all my search processes are working fine. I'm going to need to start doing something smarter with these full-text searches. I think doing some indexing at write time is the best bet -- that should probably speed stuff up quite well. But for the time being the processes will run, if slowly. The only bummer is now I have to go dig out all the mutex-y lock-y stuff I wrote earlier. tags:

Zak B. Elep: ntfs-3g Love

Yesterday I was back again at the Parish to continue working on arete, the newly-installed Ubuntu Dapper machine. I was back because I had to continue migrating my father’s files from Windows to the new setup, since he wanted to try out Scribus as a replacement for his MS Publisher system for writing the parish newsletter. Anyhow, this reason, coupled with my own urge to seriously try out Ubuntu Dapper (I was running Kubuntu Dapper, doh) made me spend the whole day trying out something new. ;-) As I was looking at Dad’s documents folder, I realized that I had a problem: there are so many files here, some of them sizing up from tens to hundreds of megs (actually, stuff worked on thru the Gimp,) and knowing well that disk drive space was at a premium (arete had an 80G drive, yes, but nevertheless its already cramped,) I simply couldn’t accept copying the files from the XP’s NTFS C:\ to arete’s ext3 /home. Moving wasn’t an option either; although Dad would very much like to try out Ubuntu, he still had some projects (especially the newletter) that needed, uhm, proprietary software to work (sigh.) Thus, remembering that Linux already had some way of reading NTFS partitions, I promptly Googled about it. I also knew that the Linux-NTFS guys (who made the ntfsprogs suite and kernel module) were already working on getting full read/write NTFS support on Linux, but it didn’t occur to me that they were able to get a working implementation done so soon… Enter ntfs-3g: the third generation Linux-NTFS driver. Weighing in at around 550K, this seems to be the one thing that I need for my problem. From the looks of it, ntfs-3g can both read from and write to NTFS partitions, allowing one to create, delete, and update files and directories on the system; it can even allow access to certain metadata that even Windows XP hides from its users. Furthermore, its built from the ground up as a filesystem-in-userspace driver, using the Linux fuse subsystem. It certainly looks very attractive indeed. So, being the sysadmin for arete that I was, I quickly decided to give ntfs-3g a try. After all, it was a simple matter of grabbing the tarball, then reading the README, then doing the three-step tango of ./configure; make; sudo make install, then calling ntfs-3g /dev/hda1 /media/hda1 -o umask=007 as root. Right? Wrong. I quickly ran into a trio of subproblems: first, I needed fuse (>= 2.5.0); the one Dapper had on its official archives was 2.4.2 . So, naturally, I had to make a quick backport of the fuse source from Edgy (2.5.3), but I at this point I ran into the second problem: for Eggy’s fuse to get busted, I needed the new makedev (2.3.1) as well. Forgetting to do apt-get -f install for the moment, I grabbed Edgy’s makedev and proceeded backporting it, which ran me against the last problem: I also needed the newest sysvinit (2.86.ds1). In short, I needed to do a trio of backports first before being able to build ntfs-3g. My own fuse was almost ready to explode. Fortunately, everything went fine after the backports (thank goodness for my being a Debian package maintainer and MOTU,) so I didn’t break my own fuse after all. Soon after, I was reading and writing stuff to and from /media/hda1 without so much as batting an eyelash. Dad was definitely pleased, since that meant that he no longer had to dread the thought of having to maintain two separate document trees and cause him pain and gnashing of teeth. I was glad too, since I no longer had to dread the thought of having to hack on this today, causing me to disrupt my Summer of Code schedule. But, being the packager that I was, I realized that I could make the world a better(?) place by turning ntfs-3g from a regular Joe source to a real Debian/Ubuntu package. While I was happily waiting for ntfs-3g’s build to complete, I happened to pass by a certain HOWTO on the Web using pre-built fuse and ntfs-3g Ubuntu packages. I grabbed those packages, and took a look at them, and while they were pretty much useful, the ntfs-3g package certainly did not look to pass the gold(?) standards of Debian and Ubuntu: the ntfs-3g package was a single binary package, shipping both a shared library and its headers, coupled with the working binaries. It had outdated FSF addresses too, which my bugging Lintian pointed out to me. With some more extra time to spare on arete, I decided to go ahead and build proper a proper source package for ntfs-3g, producing the three binary packages ntfs-3g (containing ntfs-3g and mount.ntfs-3g,) libntfs-3g0 (depended on by the former package,) and libntfs-3g-dev (containing the include headers.) CDBS and debhelper definitely made this easy pickings, and made my life with ntfs-3g easier. And, I’m going to make everyone else’s life with ntfs-3g easier, by making this package available for nit-picking. ;-) I won’t pretend this to be getting into the official Debian and/or Ubuntu archives for the moment, since the upstream authors have explicitly stated that ntfs-3g will be eventually merged into the existing ntfsprogs suite, thereby making my packaging of ntfs-3g obsolete sometime soon; furthermore, the binary packages up there are built against Debian unstable and Ubuntu Edgy, so anyone looking for a Dapper solution can read this post first to avoid reinventing the wheel. But if anyone needs a good solution for NTFS read/write right now (or, if somebody else has time to kill in testing ntfs-3g,) then here’s a good one for you. Caveat emptor!  Ok, next up: finishing my SoC work…

John Goerzen: Whose Distributed VCS Is The Most Distributed?

Lately I have been trying out a number of distributed version control systems (VCS or SCM).

One of my tests was a real problem: I wanted to track the Linux 2.6.16.x kernel tree, apply the Xen patches to it, and pull only specific patches (for the qla2xxx driver) from 2.6.17.x into this local branch. I wanted also to be able to upgrade to 2.6.17.x later (once Xen supports it) and have the version control system properly track which patches I already have.

But before going on, let's establish what it means to be an ideal distributed VCS:


There are also some things that we would generally want:



Evaluation

Let's look at some common VCSs against these criteria. I'll talk about Arch (tla, baz, etc), bzr (bazaar-ng), Darcs, Git, Mercurial (hg), and Subversion (svn) for reference.

1. The fundamental method of collaboration must be a branch
All of the tools pass this test except for svn.

2. Branching should be cheap
Everyone except svn generally does this reasonably well.

The tla interface for Arch had a pretty terrible interface for this, so it took awhile simply due to all the typing involved. That's better these days.

Darcs supports hardlinking of history to other local repositories and will do this automatically by default. Git also supports that, but defaults to not doing it, or you can store a path to look in for changesets that aren't in the current repo. I believe Mercurial also can use hardlinks, though I didn't personally verify that. bzr appears to have some features in this area, but not hardlinks, and the features were too complex (or poorly documented) to learn about quickly.

svn does not support branching across repositories, so doesn't really pass this test. Branches within a repository are not directly supported either, but are conventionally simulated by doing a low-cost copy into a specially-named area in the repository.

3. Merging between branches is intelligent
Arch was one of the early ones to work on this problem. It works reasonably well in most situations, but breaks in spectacular and unintelligble ways in some other situations.

When asked to merge one branch to another, Darcs will simply merge in any patches from the source branch onto the destination which the destination doesn't already have. This goes farther than any of the other systems, which generally store a "head" pointer for each branch that shows how far you've gone. (Arch is closer to darcs here, though ironically bzr is more like the other systems)

Merging between branches in svn is really poor, and has no support for recognizing changesets that have been applied both places, resulting in conflicts in many development models.

4. Inividial changesets should be mergeable without bringing across the whole history
Darcs is really the only one that can do this right. I was really surprised that nobody else could, since it is such a useful and vital feature for me.

Both bzr and git have a cherry-pick mode that simulates this, but really these commands just get a diff from the specific changeset requested, then apply the diff as with patch. So you really get a different changeset committed, which can really complicate your history later -- AND lead to potential conflicts in future merges. bzr works around some of the conflict problems because on a merge, it will silently ignore patches that attempt to perform an operation that has already occured. But that leads to even more confusing results, as the merge of the patch is recorded for a commit that didn't actually merge it. (That could even be a commit that doesn't modify the source.) Sounds like a nightmare for later.

Arch has some support for it, but in my experience, actually using this support tends to get it really confused when you do merges later.

Neither Mercurial nor svn have any support for this at all.

5. Branching preserves full history
git, darcs, and Mercurial get this right. Making a branch from one of these repos will give you full history, including individual diffs and commit logs for each changeset.

Arch and bzr preserve commit logs but not the individual changesets on a new branch. I was particularly surprised at this shortcoming with bzr, but sure enough, a standard bzr merge from a remote branch commited three original changesets into one and did not preserve the individual history on the one commit.

svn doesn't support cross-repo branching at all.

6. Merging preserves full history
Again, darcs, git, and Mercurial get this right (I haven't tested this in Mercurial, so I'm not 100% sure).

Arch and bzr have the same problem of preserving commit logs, but not individual changesets. A merge from one branch to another in Arch or bzr simply commits one big changeset on the target that represents all the changesets pulled in from the source. So you lose the distinctness of each individual changeset. This can result in the uncomfortable situation of being unable to re-create full history without access to dozens of repositories on the 'net.

Subversion has no support for merging across repositories, and its support for merging across simulated local branches isn't all that great, either.

7. It is possible to commit, branch, merge, and work with history offline
Everyone except Subversion does a good job of this.

8. The program is fast enough for general-purpose use
All tools here are probably fast enough for most people's projects. Subversion can be annoying at times because many more svn commands hit the network than those from others.

In my experience, Arch was the slowest. Though it was still fine for most work, it really bogged down with the Linux kernel. bzr was next, somewhere between arch and darcs. bzr commands "felt" sluggish, but I haven't used it enough to really see how it scales.

Darcs is the next. It used to be pretty slow, but has been improving rapidly since 1.0.0 was released. It now scales up to a kernel-sized project very well, and is quite usable and reasonably responsive for such a thing. The two main things that slow it down are very large files (10MB or above) and conflicts during a merge.

Mercurial and git appear to be fastest and pretty similar in performance.

All of these tools perform best with periodic manual (or scheduled cron jobs) intervention -- once a month to once a year, depending on your project's size. Arch users have typically created a new repo each year. Darcs users periodically tag things (if things are tagged as part of normal work, no extra work is needed here) and can create checkpoints to speed checkouts over the net. git and Mercurial also use a form of checkpoints. (not sure about bzr)

Subversion works so differently from the others that it's hard to compare. (For one, a checkout doesn't bring down any history.)

Conclusions
I was surprised by a few things.

First, that only one system actually got #4 (merging individual changesets) right. Second, that if you had to pick losers among VCSs, it seems to be Arch and bzr -- the lack of history in branching and merging is a really big issue, and they don't seem to have any compelling features that git, darcs, or Mercurial lack. #4 was a unique feature to Darcs a few years ago, but I figured it surely would have been cloned by all the other new VCS projects that have popped up since. It seems that people have realized it is important, and have added token workaround support for it, but not real working support.

On the other hand, it was interesting to see how VCS projects have copied from each other. Everyone (except tla) seems to use a command-line syntax similar to CVS. The influence of tla Arch is, of course, plainly visible in baz and bzr, but you can also see pieces of it in all the other projects. I was also interested to see the Darcs notion of patch dependencies was visible (albeit in a more limited fashion) in bzr, git, and Mercurial.

So, I will be staying with Darcs. It seems to really take the idea of distributed VCS and run with it. Nobody else seems to have quite gotten the merging thing right yet -- and if you are going to make it difficult to do anything but merge everything up to point x from someone's branch, I just don't see how your tool is as useful as Darcs. But I am glad to see ideas from different projects percolating across and getting reused -- this is certainly good for the community.

Updates / Corrections
I got an e-mail explaining how to get the individual patch diffs out of bzr. This will work only for "regular", non-cherry-picked merges, and requires some manual effort.

You'll need to run bzr log, and find the patch IDs (these are the long hex numbers on the "merged:" line) of the changeset you're interested in, plus the changeset immediately before it on the same branch (which may not be on the same patch and may not be obvious at all on busy projects.) Then, run bzr diff -r revid:old-revid-string..new-revid-string.

I think this procedure really stinks, though, since it requires people to manually find previous commits from the same branch in the log.

10 August 2006

Erich Schubert: Going AMD64

Up to now, my dad was using my old desktop PC, a celeron 412 MHz (366 overclocked) with Linux. Unfortunately, this trusty companion started to freeze within a few minutes after boot (even in BIOS). So after some 7 years, a replacement was needed. The guys at the computer shop (Computer Gallerie in munich) tried to convince me that nvidia is best for Linux. Basically I followed this recommendation because ATI isn't better, and there are not Intel-based onboard graphics for AMD. And AMD Sempron sounded like the cheapest CPU. And definitely cheaper than an Intel Core... But dudes: Nvidia is NOT included in the kernel. Trust me on that one. Nvidia is non-free, and their drivers most likely violate the GPL. So I ended up buying an ASRock 939NF4G-VSTA mainboard and an AMD Sempron CPU. 1 GB of RAM, an HDD, an okay housing. Just below 400 Euro, that is what I had expected. After some fighting with the hardware (the HDD didn't fit into its slot, I had to bend away some metal. No docs on which way to put the power LED plug on etc.), I was finally able to boot the system. I used todays daily-build of the netinstall CD image for AMD64. I.e. the to-be etch installer. Worked like a charm. After some downloading over my 2 mbit DSL line the system was up and running. Graphics were VESA, as expected. With some fighting with the annoying non-free Nvidia drivers, I had them working, too. Ethernet worked out of the box; I don't know about S-ATA (a driver is loaded though), temperature sensors seem to work, too. Sound doesn't work yet. The snd_hda_intel driver is loaded, however there is no sound to be heard on any of the 7.1 channels. The mixer only shows "Master" and "Capture" volume controls. If anyone knows how to get sound out of a 
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
Subsystem: ASRock Incorporation Unknown device 0888
device, I'd welcome any hints. Kernel is 2.6.17-1-amd64-k8. Maybe I just have to get a newer Alsa with some hardware information on this device? [Update: this is a realtek ALC 888, there is a patch for this to come in 2.6.18...] Anyway, I now have a AMD64 box, and as soon as I've setup some i386 chroot I'll have a useable build-box after all. ;-) And maybe I can do some SELinux testing on it, too. OTOH, I should get myself a diploma thesis topic now, and work on my final thesis.

Julien Danjou: My first experience with python

Today I decided to start learning Python. I am sick of Perl. I used to be quite good but now I totally lost my power and it's too hard to reuse code I wrote years ago, since I barely understand it. To begin, I decided to play with Paramiko, a module for using ssh with Python.
Unfortunately, I was unable to simple use from paramiko import * so I was totally disapointed. Fortunately, a python developer working near me helped me to understand why it did not work. And it was actually a bug :-) which is now reported as #382348. I am very amused by falling on a bug with my first line of Python. But be sure I will continue to use it to develop a little tool for my personnal usage. ;-) I know the pitoon! I know the pitoon!

Martin F. Krafft: Through with XFS

I am through with XFS, once and for all. Well, at least for laptops. I still think it's a good filesystem when you can ensure that the power never goes, and your hardware is reliable, but it's just not adequate for laptops or even desktops. I ran into some serious problems a while ago, but managed to recover. Two nights ago, however, three XFS filesystems on my laptop decided to blow up and left my system thoroughly broken. I guess as the hibernate maintainer, I should really start doing my tests somewhere else than my main system... It all started out with a dist-upgrade and this output: 
dpkg: error processing /var/cache/apt/archives/dpkg_1.13.22_i386.deb
(--unpack): unable to make backup link of
'./usr/share/man/man1/dpkg-deb.1.gz' before installing new version: Unknown
error 990
Looking at /usr/share/man/man1, I started to anticipate the apocalypse: 
# ls -l /usr/share/man/man1
total 7956
?????????? ? ? ?    ? ? ? 7zr.1.gz
?????????? ? ? ?    ? ? ? 822-date.1.gz
?????????? ? ? ?    ? ? ? CA.pl.1ssl.gz
?????????? ? ? ?    ? ? ? Defoma::Common.1.gz
So I look at the log, and amidst kernel oops notices, there's this lovely cookie: 
Filesystem "hda6": Corruption of in-memory data detected.  Shutting down
filesystem: hda6
Filesystem hda6 is /usr, so at that time I figured "it could have been worse", booted to single user, and remade the filesystem with the intention to simply reinstall all packages... when I found /var/lib/dpkg/info to be in similar condition. The rest of /var seemed fine, but I resolved then that there was no hope in reviving this system. Fortunately I brought an external drive that had just enough free space to hold my /home and some other stuff, but since USB is really slow when it comes to shifting large amounts of data, I decided to do something productive in the mean time and to answer some outstanding mails. It wasn't difficult to get SSH back up, so I started to work on a remote machine and used the time efficiently. Some time later, though, I got confused in the mist of screen sessions and was browsing my home directory on the laptop, thinking I was elsewhere (my home directories are mostly synchronised), when I noticed a directory in similar condition as the above. Oh shit. Imagine my pain and fear as I first thought my remote machine was also dying, imagine the sigh when I found out I was on the local filesystem, and imagine the shock when I realised that /home was also affected by the XFS breakage... A glance around /var confirmed that the XFS breakage was actually spreading and had now affected three filesystems on this machine. Fortunately, by that time, I had copied everything to the external drive, and decided to put my laptop and myself to sleep. I woke the next morning to the task of reinstalling the thing and decided to be optimistic about it. After all, a reinstall would mean I could finally try partman-crypto and encrypt my laptop's data to protect against leaking sensitive stuff in the case of loss or theft of my laptop. The installation was not as painless as I had hoped, but that was mainly because I ran into a known problem with the graphical installer and partman-crypto, which does not allow to set up volumes with random encryption keys (e.g. swap; see the forthcoming announcement for the beta3 release of the installer), and a bunch of smaller bugs. I had to restart the installation with the traditional frontend to get what I wanted, but other than that, I was very impressed with what our installer development team has accomplished! And a special round of gratitude to Frans Pop for not losing his patience while helping me on several occasions throughout the process. Now, 24 hours after the incident, I am back to normal with a fresh laptop and no data lost (except for one directory which I pulled from a mirrored remote machine; it had no local modifications (so why did XFS screw it up anyway?)). The fonts are all jaggy, so there's something I have to figure out. All things considered, I am sad to have lost 24 hours, but I can also relax more now, without fear of further XFS breakage or loss of private data. Update: Oh, and despite this, I did choose ext3 for all my laptop's filesystems. JFS was really cumbersome and slow last time I tried it, and I surely would not touch RazorFS after experiencing serious data loss on numerous occasions. Update: Two responses so far. Full ack for Julien (except for him laughing at me), Ingo's post warrants a reply though. First, ext3 is also journaled, and if you're about to say "yeah, but it's a hack on top of ext2, well... ext2 is damn mature, and journaling isn't really rocket science, so that "hack" isn't going to be too complicated. In fact, I like the idea of journaling being an option rather than a built-in feature. Second, of course you're supposed to keep backups. But since you keep backups, my top requirement of a filesystem is not "how to get the data back", but "how to ensure it does not break. If it breaks, I can reinstall and restore from backup, but that's a certain amount of time lost. If it doesn't break, well, that's like stealing a little something back from death then, isn't it? Third, I do follow the linux-xfs mailing list, but so what? I did not have write cache enabled, and I was running the 2.6.17.7 kernel at the time of the mishap. Lastly, you point to "excellent tools" to recover the filesystem. I am not sure how excellent xfs_repair really is when it reports "bad magic number 0x0 on dir inode 4696727" during the run, claims to have fixed it, I mount the filesystem, unmount it, run xfs_repair again and get the same message. No filesystem is perfect, and as we know from Biella's problems (among many others, ext3 is no exception. But we did get her data off! So then it's really an open field again, crap filesystem against crap filesystem. I guess at this point it helps to know that ext3 actually follows VFS semantics, while on XFS, a completed sync() syscall does not actually mean it has written the data to disk (see e.g. #317479). And then there are bugs like #239111... ext3 it is for now. If that let's me down, I'll try JFS. If that fails and noone has actually implemented a proper filesystem, I might have a go myself. Haha. Update: Alceste Scalas adds:
Ingo is right when he says that every filesystem has bugs --- but bugs apart, the design of Ext3 (i.e. its physical-block journaling) makes it a far more reliable choice for desktop and laptop PCs, expecially for people without an UPS. An Ext3 filesystem could only crash because of a bug or an hardware failure, while an XFS filesystem can be trashed even without bugs or hardware failures, due to the unavoidable consequences of a power loss on PC-class hardware.
He also alerted me to this mailing list post, which compares data=ordered journaling of ext3 (which almost noone does for performance reasons) with XFS and RazorFS. Update: You may also be interested in this post. Update: Otavio Salvador points me to this FAQ entry, which SGI must have added very lately. It explains how to deal with the directory corruption that was part of my problem. I guess I would have liked to know earlier, but I consider the outcome with dm-crypt + ext3 a win anyhow.

Filip Van Raemdonck: No free ride

The picture below is a hardware test setup I ran this morning, with an old and discarded motherboard which has a Pentium III CPU on it running at 733 MHz. Since that's still faster than any other system I own save for the ibook (which is a G3 running at 800 MHz), I wanted to see if it was truely broken as reported, or not. The issue, which I actually witnessed before, was that on initial boot it tended to restart up, to a few dozen times. These restarts could happen from early post BIOS stage up to while logging on. Once it had been powered on for a little while, the restarts would usually go away.

Disassemble PC

I assembled any missing parts - video card, memory, and an AT case from which I used the reset button as the power switch to the ATX motherboard - and started by running memtest on it. Which ran just fine for nearly half an hour; but I ran memtest before to try and help diagnose the problem and it had run fine then, too.
So I crossed my fingers and tried running a Linux Live CD from it. Unfortunately, after about half a minute the system restarted once again. The only parts remaining from the original system were the motherboard and CPU, power supply and DVD-ROM (but not the IDE cable). With that in mind, the most likely culprits are indeed motherboard or CPU.

Chances of being able to rescue the parts are nearly nil, but I'm still curious about what could be the actual failing part. Are there any thorough hardware tests around, which could be run (preferably) from bootable CD or floppy?

9 August 2006

Carlos Villegas: Comparing preload 0.4 and 0.2 (SoC 2006)

I've tried preload 0.2 and 0.4 to compare its effects. Unfortunately my results don't hold with the results obtained some blogs ago: preload 0.2 reduced the boot time by 2 seconds. In this occasion, time was even lost (making me remember my first tests). This may be due to some upgrades had been made to sid since.
First I tried preload 0.2 with default with 1 second lost and a modified configuration with no boot time change.
Then I tried preload 0.4 with default and modified configuration both with no time change.
The bootcharts and log file are availabe at the project webpage.
Yesterday I presented a table with hotspots combinates and unlike it was expected, preload may not be helping anymore (preload 0.4 was used).

Martin F. Krafft: At Twelve?

If I remember correctly, then at 12 years of age, I was making my first attempts at chasing girls (mostly to play pranks on them), causing a hell of a lot of trouble in school, smoking and acquiring my first alcohol experiences, hacking on my Mac SE/30, and taking my wonderful mountain bike to places noone had ever gone before. Unfortunately, I did not pay any serious attention to the art of percussion back then, or else I would have maybe... ah, nevermind, no way I would have ever done this (videodownloader.net has links to other formats -- and there is a Firefox extension). I miss my drum kit, which is at this moment a mere 1872.45 kilometres away (or so says map24.com anyway, which is crap and does not give me a way to link to the route from Limerick to Munich, it seems).

Next.

Previous.