1. The kcore_hdr_t is written by savecore using libkvm.
2. The German owns the zebra.
2007-12-31
2007-12-30
On the importance of punctuation
Just now I was reading a slashdot article where a bunch of people where whining about some links or other being to some site called “myminicity”. Several mentions of that name later, it finally dawned on me that it was not, in fact, a compound of the usual English state-of-being suffix -ity and some hypothetical trendy nonsense word(s) I hadn't heard of yet (cf. “meme”); but, rather, was to be read as the words “my mini city”.
(I still don't know what the thing actually is, because I don't care.)
If only people had decided to use hyphens when gluing words together for domain names, then I wouldn't have to occasionally waste valuable seconds wondering WTF some string of half-pronounceable letters is supposed to be. (They also wouldn't run the risk of an unfortunate powergenitalia incident, but how often does that happen?) Ah well.
(I still don't know what the thing actually is, because I don't care.)
If only people had decided to use hyphens when gluing words together for domain names, then I wouldn't have to occasionally waste valuable seconds wondering WTF some string of half-pronounceable letters is supposed to be. (They also wouldn't run the risk of an unfortunate powergenitalia incident, but how often does that happen?) Ah well.
2007-12-27
The Sound of Silence
Let's say you have a video file of some sort with no audio stream, and a device that plays video files but can't handle ones with no audio. And you want to use the command-line tool ffmpeg, because you already have a script set up to use it to do whatever transcoding, but for the slight problem of sound.
Maybe you don't, but I did. Know that ffmpeg can take multiple input and/or output files and shuffle them around, in addition to decoding/encoding them. Know also that ffmpeg is documented in a manner both voluminous and not terribly approachable.
The wrong thing to do is to try to figure out how to extract the length of the video track and generate that many audio samples of silence. But, if one hasn't noticed the right part of the man page, this may be what one tries to do. (I did.)
The right thing to do is to use the -shortest flag, which directs ffmpeg to stop whenever any input stream reaches its end, rather than when all inputs are done. Some of you may be (but probably none of you are) thinking of various versions of the Scheme procedure map and their behavior on lists of unequal and/or infinite length, recently a point of contention in the discussion leading up to R6RS. And what is Unix if not a platform for stream processing? (Don't answer that.)
Thus: -f s8 -i /dev/zero -shortest, placed either before or after the regular input file, depending on whether input that does have audio should be silenced or not, respectively.
It's a not entirely inelegant solution to a mildly ridiculous problem.
Maybe you don't, but I did. Know that ffmpeg can take multiple input and/or output files and shuffle them around, in addition to decoding/encoding them. Know also that ffmpeg is documented in a manner both voluminous and not terribly approachable.
The wrong thing to do is to try to figure out how to extract the length of the video track and generate that many audio samples of silence. But, if one hasn't noticed the right part of the man page, this may be what one tries to do. (I did.)
The right thing to do is to use the -shortest flag, which directs ffmpeg to stop whenever any input stream reaches its end, rather than when all inputs are done. Some of you may be (but probably none of you are) thinking of various versions of the Scheme procedure map and their behavior on lists of unequal and/or infinite length, recently a point of contention in the discussion leading up to R6RS. And what is Unix if not a platform for stream processing? (Don't answer that.)
Thus: -f s8 -i /dev/zero -shortest, placed either before or after the regular input file, depending on whether input that does have audio should be silenced or not, respectively.
It's a not entirely inelegant solution to a mildly ridiculous problem.
2007-11-13
Quod Erat Covered-In-Bees
Trying to prove something in Coq is like operating a large, fly-by-wire bulldozer. On the one hand, you have to figure out what to shove where, or how to program the machine to do the shoving for you. On the other hand, you can use your superior human pattern-recognition skills to avoid driving into obstacles, and if you do get stuck, you have at least some chance of figuring out how to extricate yourself.
Trying to prove something in ACL2 is like imperiously proclaiming, “Robot servants, hear my command!” and then they run out into the junkyard picking up stuff and moving it around. And if you're lucky, and the task you've given them simple enough, they get the job done for you while you sit back on a lounge chair sipping a strawberry daiquiri. But if that's not the case, they run around doing exactly the wrong thing, until either they explode messily of their own accord or you call in an airstrike. And then you get to examine the flaming wreckage to figure out what went wrong, and what helpful hints you might be able to offer the robots next time.
Trying to prove something in ACL2 is like imperiously proclaiming, “Robot servants, hear my command!” and then they run out into the junkyard picking up stuff and moving it around. And if you're lucky, and the task you've given them simple enough, they get the job done for you while you sit back on a lounge chair sipping a strawberry daiquiri. But if that's not the case, they run around doing exactly the wrong thing, until either they explode messily of their own accord or you call in an airstrike. And then you get to examine the flaming wreckage to figure out what went wrong, and what helpful hints you might be able to offer the robots next time.
2007-11-09
This Morning's Compiler Meditation:
translating Knuth's “man or boy” test from ALGOL 60 into C, by reifying the activations as structs and closure-converting the call-by-name thunks. Like this.
I considered trying to run it by hand instead, but that would certainly take a lot of paper, and also as Knuth himself apparently failed in that task, I thought perhaps not.
I considered trying to run it by hand instead, but that would certainly take a lot of paper, and also as Knuth himself apparently failed in that task, I thought perhaps not.
2007-10-29
My Parity Iz Pastede On Yay
Sun's ZFS, to hear some people tell it, is the last filesystem anyone will ever need. It slices, it dices, and so on. Why, its magical powers are so great, it can give you all the advantages RAID-5 (or -6) without any of the historical drawbacks!
Except that it doesn't. Give you all of the benefits of RAID-[56], that is. In order for RAID-Z to do its thing, each filesystem block has to be divided into stripes independently. Which is great if you're dealing with a large file divided into 128kB blocks. And not so great if you're dealing with a single 5kB file that's been scattered across 10 data disks, one sector to each. Now you have to do I/O operations on all 10 disks to read the file back (and 12 to write it in the first place, assuming the use of double-parity raidz2), whereas with a conventional RAID with a more reasonable stripe size, it would take only one.
And that's the tradeoff. It might not sound like much, but it's a really big deal if you're trying to store mail in the Maildir format (one file per message!), or any other workload with a lot of small files and random access. System administrators dealing with such things may take to talking about “spindles” as an attribute of a disk array, as metonymy for the rate at which it can handle random I/Os. As in, the mail fileserver has been slow lately; looks like it needs more spindles. So you add disks to it, even though you have plenty of space free. Because it's all about how fast you can move the physical heads around.
In this light, what RAID-Z does is takes all of your disks and turns them into one spindle. Burning half the blocks to do mirroring instead doesn't sound so bad now, does it?
Except that it doesn't. Give you all of the benefits of RAID-[56], that is. In order for RAID-Z to do its thing, each filesystem block has to be divided into stripes independently. Which is great if you're dealing with a large file divided into 128kB blocks. And not so great if you're dealing with a single 5kB file that's been scattered across 10 data disks, one sector to each. Now you have to do I/O operations on all 10 disks to read the file back (and 12 to write it in the first place, assuming the use of double-parity raidz2), whereas with a conventional RAID with a more reasonable stripe size, it would take only one.
And that's the tradeoff. It might not sound like much, but it's a really big deal if you're trying to store mail in the Maildir format (one file per message!), or any other workload with a lot of small files and random access. System administrators dealing with such things may take to talking about “spindles” as an attribute of a disk array, as metonymy for the rate at which it can handle random I/Os. As in, the mail fileserver has been slow lately; looks like it needs more spindles. So you add disks to it, even though you have plenty of space free. Because it's all about how fast you can move the physical heads around.
In this light, what RAID-Z does is takes all of your disks and turns them into one spindle. Burning half the blocks to do mirroring instead doesn't sound so bad now, does it?
2007-10-28
Thank you, SGI.
Not only can XFS be resized online, but that works just as well on the root filesystem.
Well, after I symlinked /dev/root to the correct device, because Linux still uses the ridiculous archaic SunOS-ism of having mount and unmount and df update and consult the regular file /etc/mtab instead of just asking the kernel, like any sane system would do.
And thus the kernel's filesystem table (readable at /proc/mounts, in the same format as mtab, even) winds up with a bunch of useless junk in it, which probably wouldn't be put up with if people actually had to look at it all the time.
Anyway. Being able to xfs_growfs the root filesystem and have it (mostly) just work is a refreshing change from certain other filesystem features; e.g., on Solaris 9, UFS snapshots' being forbidden for the filesystems holding / and /var, because it's necessary to briefly disable writing, and I guess that might deadlock or something.
Well, after I symlinked /dev/root to the correct device, because Linux still uses the ridiculous archaic SunOS-ism of having mount and unmount and df update and consult the regular file /etc/mtab instead of just asking the kernel, like any sane system would do.
And thus the kernel's filesystem table (readable at /proc/mounts, in the same format as mtab, even) winds up with a bunch of useless junk in it, which probably wouldn't be put up with if people actually had to look at it all the time.
Anyway. Being able to xfs_growfs the root filesystem and have it (mostly) just work is a refreshing change from certain other filesystem features; e.g., on Solaris 9, UFS snapshots' being forbidden for the filesystems holding / and /var, because it's necessary to briefly disable writing, and I guess that might deadlock or something.
Subscribe to:
Posts (Atom)
