[09:17] nice, mounting the tar.bz2 in avfs took ages (>12 hours i think) but now it looks like accessing files in it is not making any noticable cpu load [09:22] and with that http://gamespy-archives.quaddicted.com/forums/ is back (still no nice frontend) [11:55] BlueMax: :D [11:55] wut [11:56] irony. [11:58] also that song is ironic. [12:06] Schbirid: well, unfortunately, it would have needed to completely decompress the bz2, both to determine length and to parse the tar file. It might not have been using an optimal blocksort algorithm (the most compute-expensive part of the bzip2 algorithm) [12:08] o_O How much ram is it using Schbirid ? [12:13] once it has indexed the bz2 blocks and the tar file, cpu usage would be much, much better [12:15] Schbirid: is avfs smart enough to keep the indexing info in a file, so you can remount without the long wait? [12:32] Coderjoe: SmileyG: it wrote some 1G file to /tmp/, pretty sure it does use that only while mounted though. uses about that much ram too. oh look, it is at 100% cpu again :( [12:32] shit [12:33] oh well, as long as the rest of the server does not suffer [12:34] the only way to avoid the massive cpu hit is to cache the decompressed results for a period of time [12:35] there are at least 3 projects named "avfs", ugh [12:35] i noticed [12:35] yeah, that's the thing i try to avoid since hdd is very limited [12:35] http://avf.sourceforge.net/ [12:36] the other day I went looking for it, since you mentioned the bz2 random access support and gave up with the dozens of results I found [12:38] heh [13:20] yay, googlebot is doing ~2 pages per minute [13:33] I think you can give it a crawl delay via robots.txt [13:34] balrog, chronomex, ersi: spread the @? [13:36] better? [13:41] no :( [13:41] :D [13:53] Coderjoe: no, i honestly am happy that it is going remotely quick :) [13:58] i found a video called birth of biohazard [18:24] rdiff-backup really sucks if you move directories around [23:29] I have 79 3 1/2" floppy disks of various software of the time and am wondering what is the best way to rip/backup/recover/archive them to my computer? [23:34] good question [23:34] that can go into sub-questions, like whether they will be readable at all, and whether there's a reason to not just get a 3.5" USB floppy drive and "dd" that motherfucker [23:35] i don't have the answers to those, but they're points of discussion/research [23:36] what are they? FAT disks? [23:38] also, in the case that "dd that motherfucker" looks like a good option, http://www.gnu.org/software/ddrescue/ddrescue.html [23:42] i'd buy a "dd that motherfucker" shirt [23:43] with a little picture of a floppy disk above it [23:43] i think i would too! [23:45] http://archiveteam.org/index.php?title=Rescuing_Floppy_Disks [23:51] if it's just like, plain MS-DOS floppies though (and i do have some kicking around i've been meaning to do stuff with) [23:51] is any of the advanced stuff mentioned there, vs getting a USB floppy and doing a 'ddrescue', overkill? [23:55] why hello gentlemen [23:55] sorry was away.. now reading messages [23:55] no worries, friend [23:56] good evening chronomex [23:56] arkhive: a year or two ago I did a massive copy-that-floppy run [23:56] I had a shellscript that ran dd and asked me what the disk said on the label, putting that in a .txt file next to the image [23:56] also turned the disk image into a .zip [23:57] I don't have the script still, unfortunately ... [23:57] alright [23:57] oh [23:57] if you want to do something similar, I can provide guidance [23:58] sure. [23:58] I am not sure on the condition of the floppy disks [23:58] aye [23:59] you'll soon find out [23:59] heh, pretty much [23:59] chronomex: is dust getting into the disks an issue? and can anything be done about it? [23:59] and I would like to extract all the data from them.. probably both a image copy and a copy of its files