Older blog entries for ksandstr (starting at number 8)

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.

[groan]

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...

After studying lisp & scheme with the aid of librep and the documentation available, I have come to the conclusion that breaking the habit of "hmm, I think I could shave off a cycle here, maybe avoid a branch there" and thinking about things as mathematical functions instead of a list of statements is PRETTY FUCKING HARD. It looks like I've spent the last 5 years of my programming time concentrating on stuff that isn't relevant because the program would spend 99% of its time elsewhere. Or maybe it's just laziness manifesting itself in reluctance to write the rest of the program. Lack of self-discipline would probably be one reason, too.

Or maybe I'm just feeling pessimistic, as usual, or something. Dunno. I guess I should put more effort into finishing distance/evening school and then going on to study computing science or something that would give me an actual education instead of "I've poked this and this and this and this and hacked this and this and this and this". The downside would be that at the current rate, I'm never going to finish school and that even if I do, formal education would still kill the fun in hacking... So maybe I'll just use books as a substitute, or something.

Damned if I remember who said it first, but HTML really needs a <RANT> tag.

Hacking

Bought an old C=64 "home computer". Old model no less, with older version of the kickass SID chip. No PSU or cabling, just the keyboard-and-mainboard-combined bread-box unit, which doesn't bother me one bit since I only need a second C64 for spare parts (in case I happen to fry the CIA or the SID chip while connecting the audio-out to an amp).

I'm planning to do some assembly hacking on it, maybe write some software to drive a small LCD panel (1 or 2 rows or so), possibly some small music experiments with the SID. I'll definitely experiment with blowing a new ROM for it :-) Since I don't have a PAL monitor (or room for one, for that matter), I'll have to do the programming bit on my PC and run tests using VICE. Which isn't a problem either, since VICE seems to do a decent job emulating a serial port. The only problem is that LCD panels with a serial interface cost an arm and a leg...

Hacked a simple vblank interrupt yesterday, but I suspect that it won't provide enough precision to play music with, so maybe I'll implement the BogoMIPS loop in 6510 asm next ;-)

Life

Did I hint that I have one? I don't. Kaapo & Attila (our two budgies) are happy, considering that the days are getting a lot shorter than they were in June. Not that you're interested, anyway.

Tech

Ack. Found out that I've been neglecting my own projects and spending way too much time thinking about work stuff on my own time. Must fix soon.

Ended up IDLing a half-assed replacement for the CORBA event service and implementing an Observable mixin class using omniORBpy. Learned along the way how to use Anys with the CORBA python binding (assuming that omniORBpy's interface is compliant enough...). Now I just have to write it again in C++ just so that I can write implementations for Observable-compliant classes in it. Ugh. The transition from Python is going to be rough.

Still no viable Python bindings for ORBit in the debian unstable tree. Sigh.

Life

Still don't have one.

Ugh. I probably shouldn't be writing this, but what the hell. Being tired and having missed about 18 hours of sleep during the last 7 days gives a good excuse to rant mindlessly.

So, it's been precisely one month since my last diary entry. Whee. Nothing much has happened at work, but still I'm feeling overworked, underpaid and severely irritated.

omniORB3 looks pretty good. Shame that there aren't any debian packages available that I know of. The Python binding for omniORB also looks pretty damn convincing; at least for purposes of rapid prototyping. I've had some misgivings about the python interpreter's habit of keeping reference counts of python objects (thinking that it'd be slower than the mark-and-sweep GC commonly used in JVMs), but after running some tests using a CORBA object factory server written in python I can say that no, python doesn't seem to leak memory provided you do things the proper way (i.e. paranoid del's in the main program and such). Besides, it seems that a group of, say, 10 python statements would do a lot more than 10 statements of Java, let alone C++.

I still don't understand why it was so important to have strong typing in Java. Since most JVMs do a good bit of checking and validation and other things to java bytecode before execution, I wouldn't imagine that it'd be a big problem to do some crude type resolution in the bytecode validator. To me it looks like Java combines the disadvantages of both strong typing (which tend to make the average non-trivial line of code longer than 80 columns [casting, methodsThatAreWrittenLikeThis, ...]) and a bytecode compilation pass (loss of meaningful source code as well as the information contained therein that would give a smart JIT compiler an edge).

Looks like this diary entry became a rant about my pet peeves regarding Java. Oh well. Time to catch some shut-eye. (also, it looks like I kept the promise I made earlier on, the one about ranting without focus...)

Aww crap. Looks like nymia went ahead and commented the "getting rid of files" article to the same effect that I would have. Saves me the trouble, though. The comment also reads much better than the incoherent drivel I would've spewed forth :-)

Since I'm probably going to write stuff about my current research[1] and other interests, I might as well start right now...

Spent a few days (the 19 and 20th days to be precise) studying omniORB. It's funny how the version 2.8.0 Debian package is in non-free when the newest version is licensed under the GNU licenses; I ended up removing the debian packages and compiling it by hand. Looks like they have made lots of improvements (POA, many CORBAservices, other neat and 2.2-compliant stuff), which is nice.

I also spent a few hours today (aug 26th) fruitlessly trying to install orbit-cpp, just to see if it was the better choice for my purposes. Couldn't get it to compile a POA-compatible servant so either I'm not paying enough attention and botched the installation at some point (which is likely), or I've laid my dirty paws on pre-pre-pre-alpha software. Anyway, even if I can't use orbit-cpp right now, I figure that if I write my servants for the POA, they ought to port to the future orbit-cpp system with minimal pain. I'd really like to use ORBit since

1. it's used by the GNOME people, So It Has Got To Be Good,
2. that also means continued development and
3. I like the idea that there's only one set of libraries providing ORB functionality in my system most of the time.

Perhaps in time orbit-cpp will also mature and grow some of the standard CORBA services (you know, LifeCycle and its brethren) and all that stuff. In the mean time, omniORB looks like the ORB of choice for me, both philosophically and technically.

[1]Code word for "what I'm currently poking because I can't think of a better way to spend what little free time I have"