One of the things that has bothered me from the first day I learned about the Memory Management in C over a decade ago is how there is no apparently method in C for knowing how much memory is allocated behind a pointer that you are passed. I asked my teacher back in the day how we would prevent stuff from running off of the end of a buffer if we can't find out how big a buffer is and he just shrugged his shoulders and said "very carefully". It is no surprise to me that buffer overflows are by far the most common form of exploit on C based languages. The worst part is that a lot of that could be avoided with one simple function:

int heapsize(void* buffer, void** start);

Passed in your target pointer it would set the start pointer to the start of the buffer and return the length of the buffer in bytes. Now you would know exactly where your pointer is and how many bytes are left. Bounds checking suddenly gets really simple and buffer overflows, while not completely a thing of the past (lazy programmers would never check), appear far less often.

The normal argument against this function is "it's your program, you should know how big the buffers are", but frankly in an age of libraries and team coding this is just not true.

The worst part is that C already knows this stuff. It has to or the "free" command would not work. It is just hidden away and impossible to get at for some reason. Even with the many revisions of C over the years, it seems like this is one feature we're never going to get. I wonder why?

Why in the world does mkisofs have such a crummy method for specifing what files you want burned?

In case you don't know, here's how it works, you specify one or more directories after the options to mkisofs like so:
mkisofs options_here directory1 directory2 etc...
If directory1 contains the file foo and directory2 contains the file bar, your CD will have foo and bar on the root. Directory1 and directory2 are gone.

This design is as frustrating as it is stupid. If you want to burn directories like that you either have to create a third directory and temporarily move them in there, or create symlinks in the third directory and turn on the (unreliable) -follow-symlinks option (hope you don't have any symlinks in those directories that you cared about).

The worst part is, the correct interface is trivial to implement. If mkisofs didn't get rid of that last directory, it would work perfectly. Using the above line you would get a CD with directory1 and directory2 at the root. If you want the old behavior, all you would have to do is explicitly glob the files like so:
mkisofs options_here directory1/* directory2/* etc...
Maybe it's time to pull out the source...

I've had the S-Box (also called the NeoKey) installed in my PS2 for some time now, and there are a few things I need to get off my chest:

• Installation: The first problem was that the documentation was wrong. I apparently have the generation 3 PS2, but it has all of the markings of a generation 1 PS2. When I talked to one of the vendors about it, they said that Sony has been doing that to try to thwart the modchip crowd. Ok, they can't do anything about that. What they could do is actually mention that somewhere. I went to at least a dozen different mod sites and none of them had any sort of waring about that whatsoever. Also, they all appear to have copied the instruction pages from a single source, lock stock and barrell. The originals weren't very good though (the pictures were kinda small and fuzzy). Finally, as for the actual process of installation, it was no too bad, except that the PS2 has an incredibly compact PCB, my pencil tip soldering iron was almost too big for that tiny little patch I had to solder on. I'm also not sure if that USB port will ever be usable again (I suspect not). Fortunatly almost nothing on the PS2 uses the USB port.
• Import/Burned PSx games: The chip works as advertised sometimes, and lets me play DDR on my US PS2, however it is rather flaky, only working about 50% of the time and requiring a reboot the other times. I've found that it works best if you power the PS2 completely off (using the switch in the back) and back on when trying to play an import. It does blink ALL of the time when it is on however, which is rather annoying (fortunatly the light is covered up by the controller plugs).
• Import/Burned PS2 games: there were some conflicting reports on the sites about support for Ps2 games. Apparently you need a Gameshark, and even then you can only play PS2 games that are burned on CDr. I suppose that would be fine for pirates, but all I really care about are import games. I guess I'll just be playing the PSx imports instead. Also, instead of a Gameshark, I already had a Code Breaker. The Code Breaker is apparently not sufficent, as it does not work. Actaully, I havn't had a gameshark to test with either, so I don't know if it works at all.
• Final Verdict: If your soldering skills are only so-so, and you only want to play PSx games, and don't mind a bit of a headache in the install procedure, then this is an acceptable modchip. It is also reasonably inexpensive compared to some of the more full featured mods.