Older blog entries for ksandstr (starting at number 14)

Free hint: Don't use idempotent_function(foo) in the second part of a for() construct in C (probably applies to C++ as well) if you intend to change whatever it is that foo points to during the loop. You see, the compiler may perform the idempotent_function() call just once, leaving you eating sand if you, for example, chop the last character off the end of the string on every iteration. Ugh.

Not declaring any functions G_GNUC_CONST that take arguments by reference would probably help limit damage here.

Indeed, D. Knuth was right -- premature optimization is the root of all evil.

I've decided that from this day on, whenever someone asks me a trivial technical question I'll just respond with the question "what would Jesus do?". I've determined that this response will have the appropriate weird-out value, having tested (and honed) the technique on several ex-cow orkers. Somehow I get the feeling though that the effectiveness could be improved by making an effort to look more like a stereotypical satan-worshipping death metal enthusiast, but I'm too lazy to try that out.

Hm? What are you still here for? Move on to the next diary entry, nothing else to see here.

Another morning, another sunrise. This one isn't as pretty as the one on the 30th.

reiska is coming along pretty well, considering that I took a day off the project studying Common LISP (prompted by the slashdot.com article). I'm almost done with the datastore design, but I'll need to run some more tests and implement item ordering according to popularity (weighting) before I can use this with Stephen Hazel's libfreenet.

I released the first (and so far only) version of reiska to the public - it's more of a "I'm gonna do a FNP implementation, so I'm releasing early" tarball than anything else, so as released it won't do anything useful. It generated a small flurry of posts on the freenet-devl mailing list, though, some of them suggesting that I use libfreenet for the node-to-node communication (which may be wise, since the protocol has been changed quite a bit for the 0.4 release - or so I've read) and concentrate on the message passing logic, datastore management and client handling in reiska. This approach looks pretty sensible, now that I have a better understanding of the inner workings of a Freenet node.

I whined some months ago how it is fucking hard to get into the Scheme mindset, and my opinion still holds -- expressing iteration with tail recursion may be OK if you're a hard-core theorist who implements every basic algorithm once without doing anything particularly useful with it, but try writing anything really useful without ever using a "while" macro and I'll give you the award for supreme wankerhood (a dried pea and a nut in a tiny cardboard box, if you're wondering).

Common LISP, on the other hand, is beautiful. CLOS in particular. I'd say that CLOS is the best object system I've ever had the pleasure of messing around with. I've had a couple of problems with the "a name may be both a variable and a function" thing as well as remembering to use funcall, but I guess I'll get used to it.

1 May 2001 (updated 1 May 2001 at 02:13 UTC) »

I just wanted to tell y'all that I'm currently looking at the first really damn beautiful sunrise this year. It's all purple and light red and blueish, sunlight reflecting off a thin layer of high clouds. Beautiful.

(also, NP: Lamb - Gorecki (Global Communication mix2))

Having read the slashdot.com article on the pulled SDMI paper, I'm starting to wonder if it would be possible to reduce the information required to remove the watermarks from a SDMI track into a couple of formulas, or a few lines of C/LISP/Haskell/something? If it were, we could distribute PNGs of them, print them on shirts etc, much like the css-auth thing and strong encryption before that. The paper is pretty long for printing on a shirt, after all.

Heh. Now all we need is CipherSaber, only for SDMI. Oh, and they'd need to start actually releasing stuff for SDMI too, for full effect.

Ugh. It's abnormally warm here - about 18C outside. Normally that wouldn't annoy me, but in APRIL? Hell, I don't even have a fresh pair of sandals for this summer.

Reiska continues to grow. I've got a simple dataless "Echo" message going between two nodes. I'll probably add message UniqueID caching at some point and then I can go to work on the actual Freenet message formats and the datastore. I'll also have to test Reiska outside the LAN, to see how it responds to lag. Testing against the reference implementation will have to wait.

The work on Reiska has been interesting so far - it's been so long since I've last written any C for my own projects (mostly I've been using C++ at home, Java at work) that I don't seem to remember any of the signs that the project may be about to collapse. At least the edit-compile-test cycle is pleasantly short (so far).

Lots of time since the last entry... What's even weirder is that I could remember my advogato passphrase and get it right on first try. Whee.

I quit my day job. Unless something falls magically out of the sky, I don't think I'll actively go seeking another job until after summer, unless my boredom counter gets too high. Not that I'd be able to get one anyway with my formal training...

Finally got off my arse and put Freenet on my firewall box. Java sure eats a FUCKING LOT of memory - the poor old ppro/200 (with 54 megs of RAM, running squid, sshd, apache and d.net personal proxy) is swapping like no tomorrow whenever I try to 'ssh' in. 'free' shows that it's using about 50 megs of swap which raises the question "it shouldn't be this slow, should it?"... Oh well. Squid, at least, seems to run happily nevertheless.

After finding out that the freenet reference implementation (Fred) is such a memory hog (I blame Java), I started work on my own Freenet node implementation in C. So far I think I've got the Diffie-Hellman shared-secret thingy going (at least the node talks to another instance of itself pretty well), along with 128-bit Rijndael and 128-bit Twofish (not used) ciphers. (The Rijndael implementation was somewhat broken - the key material length calculations were all wrong and it tried to strncpy() binary data as well. Argh.) I'm calling the node implementation reiska (Reiskahan elää vielä.) - perhaps I'll create a Sourceforge project for it when I get it talking to the reference implementation in a sufficiently clean manner.

What else? Nothing, that's what.

New year's must have been good, since I can't remember anything about it.


I've been thinking about the possibly upcoming new ATA standard with that evil copy control thingy in it, and how Intel, IBM and the rest of those assholes are planning to implement it. I haven't read all of the .pdf files available at the FTP whose URL I already forgot, so don't take this as word of Bob or anything, OK?

So here's what I've come up with:
The 4C Entity consists of four members (at the moment); these are Intel, IBM, Matsushita and Toshiba. (according to the article in The Register).

  • IBM is a known harddisk manufacturer (both ATA and SCSI), so they're probably putting stuff into the new ATA standard (because they know what they're doing in the performance area) and are likely to be the first company to start making the new, evil'n'rude-enhanced HDs. Also, because IBM isn't just a drive manufacturer, they're probably also giving their contribution to the hardware part of CPRM, possibly software as well.
  • Matsushita makes, among other things, CDROM drives. I wouldn't be surprised if they would be the first company to implement ATA6, CRPM and all, in CDROM drives. Other than that, I don't know. Maybe they're also a HD maker.
  • Toshiba not only makes laptops, but from what I can tell, makes their own hard- and CDROM drives for them as well. Thus it would make sense that they would be the first company to start making CRPM-compatible laptops (maybe portable media players as well?).
  • Intel makes both IDE chipsets and other semiconductors. Also, Intel has a product (vapourware, maybe? there's only the HTML brochures on Intel's WWW site) called "Software Security Ifoobar", or something like that (I'm pretty sure that the acronym is SSI, SII or SIS). This software, according to the marketing blurb on the WWW site, installs a number of "software agents" on the user's (or should I say "victim's") computer which, after that, guard each other against integrity violations and do other stuff in the background (like being in semiregular contact with a central server to check for updates, license revocations, key changes, things like that).
    As most of you can tell, this sort of stuff can be cracked by disassembling or run-time monitoring either the installer program, the agents themselves or the player programs. (the communications stream between the central server and the installer/agent programs will probably need to be sniffed as well, but the stream is likely to be encrypted so this step will come after the encryption keys are recovered.)
    There's bound to be a weak link in there somewhere, because the installer is going to be a "trusted binary" in an untrusted environment (i.e. your wind'ohs installation running in a virtualized environment or a good old-fashioned emulator).

I was going to write more on this subject, but I seem to have forgotten what it was that I meant to say. I guess this is all, for now.

I finally got the hang of LISP (and found out that expressing a loop in Scheme as tail recursion makes my head hurt more than a simple (while) function), to some extent. I'm also feeling a lot less pessimistic, although I'm not quite sure why. (could be more exposure to daylight, or something...)

Got back to hacking assembly on the C64 I mentioned in an earlier entry. Now the ROM is copied over to RAM cleanly and removed from the address space so I can take the machine over cleanly and install my own interrupt handling routines (not sure what to do about the NMI interrupt though; it's probably not of much use for what I'm going to do). Good thing that I don't need disk or tape access, the BASIC interpreter or any of the standard KERNAL services, but I still have to write that damn keyboard routine. Funny how when you're writing stuff for a 8-bit computer with a 16-bit address space that the 64 kilobytes of memory just doesn't seem to fill up at all. The current compiled binary uses about 1.5K of ram, including the code (or at least that's what ld65 tells me).
Now I just need to hook the computer to my TV card and sound card line in, with a pc<->C64 cable in between, and I could start running my little experiments with the actual hardware instead of just VICE. I wonder where my soldering iron is.

Work sucked for a week, then got better. Funny what it does when the suits actually start listening to what you think...

5 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!