wiredfool

Archive for the 'Old Site' Category

About a Boy

I managed to wade through the lines for ‘Star Wars 32, the search for more money’ to see ‘About a Boy’ last night.

It’s a riot. The entire theatre was roaring at times. Especially at the dead duck incident. Hugh Grant is the perfect ass. (and he has the coolest toys. A g4 cube with apple studio display (15″) and OSX. A perfect modern condo. A tt coupe.)

They captured the feel of the book just perfectly, even better than the rather good screen adaptation of High Fidelity (also written by the Nick Hornby). For one, they actually set it in Britain. And Hugh Grant carries more of the emptiness of being a nobody that just didn’t come through as clearly in High Fidelity.

No comments

Syttende Mai

Happy Syttende Mai! Happy Birthday Grandpa!

Syttende Mai is Norwegian Constitution Day, so that’s kind of like being born on the 4th of July.

*** Osx Crashes.

First time: Hmmm, that’s wierd.
Second time: I bet it’s hardware.
Third time: Time to replace the memory.
Fourth time: Gives me an opportunity to replace the memory during unscheduled downtime.

Of course with os9, you never thought that it was hardware, since there were so many other things that could go wrong.

FWIW, this one of the screens you don’t want to see.

Not the screen you want to see...

No comments

Logging

I [heart] logs. The more the better. when everything is logged, those wierd things that happen leave a foot print. And lots of times it’s obvious.

And if you can find the bug, it’s much easier to fix it.

Wierd beach thingy near Neskowin  (credit: whoever had my camera a couple of weekends ago)

*** Company in need of Clue
(or an entire train)

It looks like eHelp is in a fight with their users, customers and consultants.

It appears that one of their new products was purchased from another company, and in the transition increased in price about 6x. Their user community questions this move, and eHelp strikes back by firing their MVP and Certified Instructors for not toeing a company line.

eHelp meet cluetrain. I think that’s the light at the end of your tunnel.

No comments

SCNS

Whenever I see the SCNS acronym I can’t help thinking of SCMODS. These are just cross wired in my brain. That happens a lot with initials and acronyms for me. Brands get mixed up, domains get crossed. Sometimes it’s even funny.

So to those marketers out there, if you want me to accurately remember your widget, make sure that it’s not confusable with obscure pop culture references. Or the code fragment manager (.cfm).

***Apple

Mmmmm xserve. I want one. Rather, I’ll take two, they’re small. I’ve got a dual 800 as my best server right now. It’s nice, but it’s big. And I’ve got a gaggle of other assorted g4’s hanging around. For what I’m doing, bandwidth to memory seems to be important, as well as the size of L3 cache.

The keys to the xserve are the DDR ram, lots of drives all on different controllers, lots of cache (2 meg per). It’s got bandwidth in all the important places, at least compared to what I’m working with now. Oh yeah, and it’s got a bit of processor too.

I still have a couple of questions about the storage subsystem and how it interacts with the software raid. Specifically, how can I split the 4 drives? 1 system + 3 raid 5? Raid 0+1? If I pull a (failed) drive and put in a spare will it sync up while on line? Are they going to require that I send them my firstborn?

I also find it interesting that it has a basic vga card and 9 pin serial for kvm or serial console access.

No comments

Updates

Sorry to those who’ve tried to log in to this site recently and failed. I did a database transplant on the membership and didn’t get everyone imported into the new system. I think things are working now. At the very least, things are working better than they were.

***Frontier TOC

The next revision to the ftocSuite should put it in the tcp.im drivers table. The functionality is going to be the same, but all of the scripts have been moved around a bit. All of the callbacks are now parsed through the new callback parser that was introduced on Friday. All of the outbound action scripts have been collected in their own sub table. And of course, there is the simple tcp.im interface on top of it all, if that’s all you need.

No comments

tcp.im ideas

a scratchpad, a little bit of a brain dump.

***Notification, The scalability issue

At some point we’re probably going to be limited in the number of instant messages that we can send out.

Im’s are a 1:1 medium, im chat rooms are a many:many medium. In theory, a workgroup could subscribe to a chatroom, and as long as a bot held it open, could participate in a messaging medium where you could sent to all of the members of the room as easily as sending one im to an individual. There’s a little bit of hairy code required to make keep everyone in the room invited, which may turn out harder then just running down the list of people who want notification.

I haven’t seen this call in the api, but I suspect that lurking out there somewhere is a Send Message to all buddies method. That would make subscription lists essentially buddy lists, and once again making notification a single sent message.

***The 2k limit.

Aim has a 2k message limit, but we don’t have to be limited to AIM or other size limited channels. We have http. Aim’s strengths are that it’s a lightweight bus for quick messages between entities that are at unknown locations across the net. The only thing that we do know about them is that they have an open tcp/ip connection to AOL’s servers. this implies that the other end most likely has web access of somr form or another.

We can use an out of band data chunk to makeup for the small size limit, at least when sending from radio or a full peer frontier system with the http server running. We can either: upstream the body/attachment to /upstreamBase/imblobs/string.md5(some unique key) or map a url to the body in the frontier case. The other side would see the “big im rpc” message with the associated url, grab the content, and process from there. The hash is so that we can put content in a directory without having others poking around and having a likelyhood of finding anything. If there’s any response, or after some timeout, the sender can drop the link or delete the upstreamable file.

It’s unclear if we’d want to encode this in a im message or a gotourl message (at least from the aim case)

***Isomorphisims

An aimuser/pw/connection thread is similar to a service in user.inetd. User.inetd opens a listener for connections, IM opens a tcp connection then listens for packets from the AIM server.

The various messages that can be sent across (chat room, im, gotourl, etc.) are similar to the get/post/any methods of the http responder. By this analogy, mainresponder.respond is called by the any method of the default responder, the particular on_im_in method would be called by the im responder that picks up the request.

Does it make sense to design the im responder system so that it assumes that it will be trivial to run more than one resonder on different usernames? Prehaps pointing at a different responder table?

If we want the driver structure to take more than one connection in stride, we’re going to want to pass the address of the connection info so that the send method will be sending from the correct screenname. (eg, send(adrData, username, message)). That change is goign to have to percolate through the entire responder hierarchy.

Alternatively, we could set up a page table for the response, and store the pointer there. Any item that really needed to get to the connection info could get it through the pagetable. Or. If the im system needs it, it could set up the page table before calling into the tcp.im.server method. (this is sort of predicated on the threaded response model.)

***The other methods.

Almost all of the work and talking we’ve done up to this point has been on the on_im_in, do_send_im basis. Simple is good, and there is a lot that can be done with these. The other interesting api areas are in the chatrooms. We can certainly program a bot that will enter a chat if invited, or set up a chatroom and invite others.

3 comments

Updated Frontier-toc.

I’ve updated “Frontier-Toc”. There are some bug fixes and a parsing class for callbacks in this release.

As a demonstration of how to use the system, I’ve got an im-> blog bot (ftocBlogger) that when configured, will route instant messages from an authorized user to your blogger api supporting weblog. You do need today’s release of the ftoc.root. Most of the configuration should be self explanatory if you’ve set up the blogger API before. Oddly enough, There are about as many items of configuration as lines of code.

***Updated

I’ve found an encoding error that was preventing certain common characters (e.g. “) from passing properly, which tended to prevent html from working properly. The fix has been uploaded.

No comments

Mariners Win!

The view from the cheap seats, top of the first inning. Altogether, not bad seats for being in the top 10 rows of the ballpark.

No IM development last night, as I got to see the Mariners try to lose a game to Toronto. When the opposing pitcher walks 3 to load the bases, it helps to be able to manufacture a couple of runs out of it. Same for when he pitches 8 straight balls to open an inning.

No comments

A little gardening

The back raised bed, after planting with strawberries. The left half are tribute, a day neutral variety, the right half are Suskan, a june bearing type. The Tributes are in much better shape.

A little gardening to round out the day. Family and other interested people can check out some more pictures of the new plantings.

No comments

Frontier – TOC

I’ve just released Frontier-TOC, a Frontier/Radio Userland tool that implements one of the connection protocols to the AOL Instant Messenger Network.

This is the first release, and as such is still only interesting to developers. It can be useful for writing chatbots and other automated bits. It is not a full chat client.(At least, not yet)

There is a simple echo bot included with the download so that you can see the basics of how to connect and write an incoming IM handler.

No comments

« Previous PageNext Page »