So, I'm looking for a job now. My résumé is updated and I've called a few people I know. I'm curious if any of you know anybody.

Here is what I'm looking for:

Ideally someone would point me at an investor who was interested in funding CAKE development for a couple of years with possibly another couple of people. The focus would be on creating a web-service that provided various services for CAKE users, not selling CAKE itself. A business model like LJs is the idea.

Barring that, I would really like to work for a company that wasn't so interested in someone who was capable of cranking out code. I'm not any good at that. I can program well, but I'm not fast, and I'm very cautious about working with a system I don't fully understand, especially if it's not easy to play with and test. OTOH, I am pretty good at talking to people about technical stuff, talking about design, pointing out flaws in designs, and creating new ones. So, a job that focused on the latter more than the former would be good.

And here's a few bullet points:

• Working on code that was going to be published as Open Source code would be a huge plus.
• I know Python and C++ best out of all the programming languages I know.
• I would really vastly prefer working with a POSIX-like environment like Linux. :-)
• I do best when working with systems level software, not UI software

Another entry in the "RAM saver" category, this is one which was mentioned by someone on the #lfs-support IRC channel earlier today.

Although I haven't actually tried it out myself yet, the verdict on #lfs-support was that it's very good, and apparently also very fast and resource-efficient. If you're needing to put together a FOSS desktop environment for an older machine, or just like resource-efficient desktops yourself, you might want to give it a look.

For any of you who don't already know about these, I recently came across this article outlining a number of useful config modifications for Firefox. The main one I was interested in was the "minimise hack," which can radically reduce Firefox's memory consumption while it is minimised. Might be good for people without a huge amount of RAM.

I made this LJ entry recently. If you feel inclined to comment, please do it there. I have anonymous commenting enabled. I always do. :-)

If people would like to get together anyway, despite the cancelled meetup, let's use this entry to arrange a time and place. :-) I was thinking of doing that anyway, and then droleary suggested it as well, so I'm all for it. :-)

I bought a new PowerBook as well, so I'd have a toy for people to ogle. :-)

I'll be working for Amazon in Seattle. I'm going to have to move. So please, people here in Minnesota, sign up for this month's Slashdot meetup so I can say goodbye to you all before I go. :-)

Well, I'm off to my job interview with Bloomberg in NYC. Wheee!

Well, I have a name for my project, and a website. It will be known as CAKE. :-)

I need to set up a Wiki and a mailing list for it, and some other ways of getting feedback from people. I want to build a community around this project fairly quickly as there will be a number of aspects of the project that others would be much more suited to attacking than I.

Well, it's starting to come together a bit, and I'm needing a name. I'm building a protocol in which all objects are named with self verifying names that aren't human readable. Messages are sent to a public key, and are always signed by the sender's public key. Files are named by secure hashes of their contents. That kind of thing.

I have grand plans of using this protocol for email, instant messages, web browsing, remote filesystem and database access, and almost anything else you can imagine. I intend for the basics of the protocol to form a layer above TCP or UDP, though it should be able to be layered inside of almost anything. I intend to write layerings for SMTP/IMAP, and AIM/Yahoo/MSN/ICQ/Jabber (via a gaim plugin).

I have some of the basics working using a mixture of C++ and Python, but it's not quite ready for public consumption. One obstacle is a name. I made a post in my LiveJournal about naming it. I'd like input from people here, if they're interested. Please feel free to make posts (anonymous or otherwise) to my LiveJournal with opinions or suggestions.

I don't consider the non-human readability of the names to be an obstacle. After all, IP addresses aren't particularly human readable either.

Also, if you care to look at the source at it currently stands, it can be found at: http://www.cakem.net/

Subversion is great, and MUCH better than CVS, even though it's still in alpha/beta.

*sigh* The company I used to work for is barely staying afloat. They decided to jettison more development staff today in the attempt. They cut some really excellent people today. They won't be able to move things forward much at all now with so few people. :-(

Oh, well.

If anybody knows someone in MN who wants a really good C++ programmer who also knows enough Unix administration to be a good sysadmin, and who knows Python, Perl, some Java, and a whole slew of other stuff, post them here. :-)

Well, my XML parser understands XML well enough now to turn this:

<fred> <went> <down> <to> <the> <street> </street> <br/> </the> <a><store></store></a></to> </down> </went> </fred>

into this:

<fred>
  <went>
      <down>
        <to>
            <the>
              <street>
              </street>
              <br/>
            </the>
            <a>
              <store>
              </store>
            </a>
        </to>
      </down>
  </went>
</fred>

Yeah, maybe it doesn't seem like much, but in order for the code to do that, it has to understand what a start tag looks like, what an end tag looks like, and what an empty tag looks like. It also has to keep track of the nesting level.

I'm happy about all this because the parser is carefully designed to for two requirements. The first requirement being that it be as fast as possible. The second being that it give me pointers into the original text where the various elements and tags are. The second requirement allows me to cut out or replace pieces of XML documents without altering the parts I'm not changing.

Since the XML messages I'm working with may have pieces that are digitally signed, it is vitally important I leave them exactly as I found them. Any alteration, no matter how slight, would render the signature invalid, and the message would be rejected by the destination. Most XML parsers forget the original document as they construct an internal structure describing the various elements and their relationships that throws away superficial features (like spacing) found in the original document.

Anyway, I'm pleased with my progress. I've had to stop for careful thought along the way to make sure that it was as flexible and fast as possible. I think it'll be fairly widely useful when I'm done.

Despite 8 people claiming they'd show up, only 3 actually did. It was still fun, but still something of a disappointment. Especially after I reserved a table for 6-12 people on Wednesday. :-(

I wish meetup.com had a way of leaving feedback for other people who claimed they would show up.

I'm trying to convince various groups I work with to start using Wiki's to collaborate. They seem like a collaboration method that has an impressive degree of flexibility and open-endedness. It makes them kind of fun to use and quick to create.

I've put up a Wiki for my homepage, and am hoping I get random people writing in it. :-) I should probably stick links to and from Wiki pages to documents in my technical section to try to spark debate and ideas.

I've been discovering how bad XML is for designing protocols. For some non-technical reasons, I decided to design my next protocol in XML, and taught myself a lot about it.

Aside from the bloatedness of a tag system, the main thing about XML that makes it totally unsuitable for protocol design is its lack of a decent way to do enveloping or encapsulation.

Most protocols will carry data that has nothing to do with the protocol. They will be used in some capacity as a transport. XML makes it very hard to design protocols that can do this easily.

Anyway, this is less well written than I hoped, but I think my point is clear. :-)