atphttpd is another old software application from the my software archives. Its a very simplistic, memory caching web server, back when it was all the rage to develop web servers, especially for performance 
It achieved quite some good benchmarks on a dual Pentium 166 running FreeBSD 3.0 - which should give you some idea of the age of the source.
Software license is BSD based. Feel free to mess with it, but word of warning, its not very good (this was a high-school-era programming project - design is not part of the picture).
atphttpd-04btar.gz
Just a quick update: I’m trying to push IRM 2 first alpha out once I’ve converted over to using Tapestry 5.0.6 (from 5.0.5). I’m finishing up the initial storage manager in the mean time and hope to have something usable soon
Here is a small little security application I wrote about a year ago back in college, for UC Davis’ excellent Computer Security undergraduate class.
Keypass tries to make ordinary passwords “biometric”, using the key push timing (i.e., how long it takes to press one letter after another) as an identifier unique to the user. The implementation works - its in no way bullet proof or optimal of course. Included is a PAM module (in addition to the verify and train programs, and libkeypass) which will work in certain cases. PAM has limits in how the password information is captured - usually the password is captured before Keypass gets invoked (or in cases where Keypass does not have terminal access) so Keypass cannot time the keystrokes. It is known to work as a standard ‘login’ prompt though. SSH logins, even keyboard-interactive, is known not to work. For more details, see the included README.
The license is LGPL 3. I would not suggest using the implementation as is - it can be enhanced greatly, beyond the limits of a few days of development :), but instead use it as a starting point for other biometric password ideas.
Feedback is welcome.
Download:
keypass-8-23-07tar.gz
Just keeping everyone up to date - work on IRM2 is continuing. I’m trying to wrestle the beast which is the abstract storage manager into something, well, more manageable.
In the mean time, a second beta of IRM 1.6 has been pushed to SourceForge. Please test and comment!
So, whats been going on? Well, I’ve moved cities over this past month, and still not totally done, which has put a damper on software development efforts to say the least. I’m going to resume working on IRM1.6 and IRM2 in a short while, once the last big item, the reef aquarium, is moved.
I’m upgrading my humble little living room reef from a 55 gallon to a 90 gallon system, on a nice looking stand. I’ve built a custom acrylic sump (easier than you think) and am still in the process of plumbing it, filling it, etc. Then I get the joy of moving the whole system next weekend from one city to another.
Stay tuned!
We’re just busy wrapping up some silly bugs in the IRM 1.6 codebase and trying to get an RC out the door ASAP.
Stay tuned.
Work is progressing well on an interim release of IRM, to be called 1.6, from the original code base.. This is where most of my development time has been going these past two weeks. This is an effort to provide useful fixes and functionality now, instead of in “the future”. But working on it, despite many fixes from contributors such as Matt Palmer and Martin Stevens, is like trying to tame a beast. But at least we’re making progress 
Feel free to hop on the irm-devel mailing list in order to check out current work, or look at the regulary updated Demo: http://www.stackworks.net/irmdemo/demo/
Login in Tech with the password tech (this is case dependent).
Basic Schema Editor support is now available in IRM 2. Making very good progress so far. Next up will be asset management routines! I’ve been busy migrating servers and trying to squash some IRM 1.6 related bugs. More active work should pick up by next weekend.
Been busy with server migrations. I’m moving from a dedicated server to a much beefier co-located server, and its taking awhile to get all the databases and setups transfered correctly.
Bear with me.
I get the occasional question about someone’s browser being seemingly stuck in “IGB” mode. Usually, its not actually stuck, the user was simply expecting some more graphical pizzaz out of EVE-Central.com.
So, why is the interface so bland? Maintainability is the primary reason. The EVE-Online in game browser is a rather buggy, slow, and temperamental beast. CSS support is worse than Netscape 4, and performance is akin to a Pentium 66 rendering a huge table - it just can’t do it without a week long crunch. Hence all of the market information is limited (only 10 entries or so per table, etc) and no stylesheets or other fun stuff is used.
So why is the main, non-IGB interface so bland too? Primarily for not having to maintain two sets of templates and remembering to update both to fix something or enhance something.
Is it me being somewhat lazy? Yes, of course :). I’ve had some contributions for new designs, which come in all sorts of nice colors and DIVs and Javascript - but didn’t really enhance the datamining aspects of EVEC.
We’ll just call the look the Google 1.0 look and work on adding newer features.
