December 21st, 2005
(12:58:04) Me: Your villanelle is nearing completion. It was fun, that's your redemption.
(12:58:25) greenbuttercup: sexcellent. i just check lj.
(12:58:41) Me: I've not posted it yet, so don't yet recheck and fret.
(12:58:55) greenbuttercup: ^checked. i won't for awhile.
(12:59:48) Me: In that case, your internet addiction, I'll not aid. Check before game night so your memory of it won't fade.
(13:00:16) greenbuttercup: good one, and i will
(13:00:57) greenbuttercup: play a nice long game of illuminati for me!
(13:01:22) Me: You'll be there tonight, won't ya? Or are you back home in fake Canada?
(13:01:35) greenbuttercup: i'm back home, i went back last week
(13:02:08) Me: Such a shame! We'll miss you, our sweet. We'll sadly pass the weeks until again we meet.
(13:03:05) greenbuttercup: nice. be sure to speak like that next time game night i'm in SC
A friend of mine recently lost a family member. Someone else posted something that I thought worth responding to. I've quoted the necessary bit (as I did in the post).
Maybe you can find another family member to sit and talk with, to share stories with. If not, well I say we have 2 families; the one we are born into and the one we find. Tell us your stories here, we'd be happy to read them.
Well put. And if nothing else, it'll serve to put those memories in some retrievable form.
I thought about my maternal grandmother on the drive home. She passed away the night after thanksgiving last year. Because she was really the only one left in the family who might have a ghost of a chance of identifying some of the pictures around, my sister would occasionally push her to sit down and go through some of them.
She was never really up to it. It was always too late or some such. I still think about that shoebox of pictures of people likely lost to time now and deeply regret it.
Even if you post them privately, I cannot recommend committing memories of your aunt to a semi-permanent format highly enough. Now's as good a time as any.
Every so often, I feel that Orson Scott Card was right in his Ender's Game series. I've come to the belief that we have a profound responsibility to speak for the dead.
The poetry meme continues. I've nearly completed the villanelle. I feel sufficiently capable of emulating Robert Service for level_head's request. I discovered a few really neat things about the 2.6 kernel, the /proc filesystem, and linux-gate.so.
All in all, I'm having a pretty darn good day!
|Date:||December 21st, 2005 10:22 pm (UTC)|| |
Will you write me a gangsta rap poem? In the style of The Little Prince?
I couldn't possibly refuse, though I'd ask that you post it here
so I don't lose track of it 8)
|Date:||December 22nd, 2005 01:42 am (UTC)|| |
Something you didn't know about kernel-2.6? wow!
/proc is so handy! I got this app called CPUspeed that is very good at setting your cpu's speed (by manipulation of the FSB multiplier) realtime, based on CPU usage, AC adapter status (if on a laptop), and CPU temperature, using an ACPI /proc interface.
hmm... linux-gate.so does look cool, though I'm really not clear on the particular uses of it.
What I specifically learned about proc was /proc/self. You may have noticed that /proc has directories for each pid. It turns out that there's a dynamic link at /proc/self which always points to the directory for your own pid. Thus, you're allowed to play with your memory at the bit level and look at all the scheduling constants on your process.
linux-gate.so is a hack that was put in place to speed up system calls. On x86 this used to all be done with interrupts, but that was too slow. In order to mitigate this, Linus hacked in a dynamic shared object (DSO) that sits at the end of memory (0xffffe000, to be precise. Sign extend that address for larger virtual memories) and appears for all dynamic processes. In that library are three things: sigreturn, rt_sigreturn, and vsyscall.
rt_sigreturn and sigreturn manipulate the stack when a signal handler finish to ensure that the process picks up where it was interrupted (sigreturn never actually returns, it goes directly to where the process was. rt_sigreturn restores context, then returns without restoring the current instruction pointer).
vsyscall is the way any process enters the kernel. Essentially, you push an index and a variable number of parameters on the stack and jump to syscall. syscall works out from sys/syscall.h and the index what you're trying to do and executes accordingly. Moreover, if syscall is interrupted, it'll restart the syscall reliably using a fairly clever trick that Linus dreamt up.
Incidentally, there's 288 of them as of 188.8.131.52. They're all listed in /usr/src/linux/arch/i386/kernel/syscall_table.S.
And if you thought that was confusing, I'll spare you what I learned about the 2.6 kernel ; )