EGOPOLY

Greasemonkey is a FireFox extension that lets you make personal hacks of web pages you visit, just-in-time.

This is so cool, I have to find out more. There is a nice little document here.

Joel on Software has a nice learning document about setting up a small multi-machine web hosting environment. Almost everything he says corresponds to my own experience.

I’m most interested in the article for his comments on the Dell DRAC4 remote management feature. We have to make a decision on that for our data center at kayak.com. Right now we have Raritan IP KVMs, and since we are about to move from 45 up to 90 machines or so, avoiding additional raritan expense would be nice.

Applying the first patch to Tiger (10.4.1) crashes my Aqua emacs build. I’m working on a new one. WTF?

I had to rebuild from source, then had to fight stupid OS X package manager for hours and hours. Then stupid Fink ncurses library kept infecting my build. Argh! Anyway, here is a new build that should work with 10.4.1: EmacsInstaller.dmg

In my previous diatribe on this topic, I suggested that:

1. Spam is a problem.
2. The AOL Buddy system is widely used.

Now, I know these are radical insights, even for
one who rules as much as I do, but just take them for granted
for the purposes of this article. Got it? Awesome.

The big idea is to take insight number 2, and solve insight number
1. The short version of this idea is:

Turn the AIM network into a global pay-for-use email system that
almost every internet user will join.

All kidding aside, I think this is probably a shocking, if not
laughable idea on the surface. If you just spewed your coffee on you
new LCD screen, sorry. I’ll wait while you get a paper towel.
Alright, let me explain how this actually could work.

As with any network, the hard part is getting it started. Nobody
want to join a private email system if nobody else is on it. This is
the first good feature of AIM: pretty much everybody is already on it,
at least in that they have two critical pieces. First, they have a
screen name with a password. Second, and more important, they have a
buddy list of people they want to communicate with.

What is missing is a way to leverage that those two incredibly
valuable assets into the email. If my buddy is not on line, I can’t
reliable send her a message through AIM. Furthermore, AIM messages
are, by their very nature and intent, ephemeral. An email message is
(usually) a semi-prepared “letter,” while an IM is a phrase that
either begins or is part of a conversation.

AOL could take the approach of building email-like semantics
into the AIM client. So you cold select a buddy and say “compose
email” and invoke a window that would look very much like an email,
write it, and send it. This, however, would be a monumentally stupid
approach. First, it would require writing and distributing more client
software, including both the ability to send and read all the AIM
email messages flying around. Second, it would leave users with two
separate email clients: Outlook or whatever and the AIM email
client. Finally, it leaves out the oddball users on Macintosh and
Linux, and would require somebody writing software for those
platforms.

My suggestion is to avoid writing any client software at all. AOL
should create two services.

First, an SMTP service that requires
user authentication to send messages: this service would take the AIM
user name and password to accept messages for delivery. Email messages
from any mail client (such as outlook) would be addressed to
so_and_so@aim.com. This SMTP gateway would take the authenticated AIM
screen name of the sender, check to make sure that the sender was on
the the recipients buddy list, and only then deposit the email
message in the inbox of the recipient. If you try to send a message to any other address, or are not on the buddy list, then you get a standard bounce message with the appropriate explanation.

This leads us to the second service, a POP/IMAP service. Just as
with the SMTP gateway, it is authenticated by the AIM screen
name/password. Any email client could be used. The cool thing is
that for the inbox in question, the user could be assured that all
messages were from pre-authorized buddies. There is no way for anybody
else to send email to their AIM inbox. This is the entire value
proposition to the end user. As long as this is true, the AIM inbox is
a special email hotline that I can always trust has relevant messages
for me. I would be willing to pay for that, and I think a lot of other
people would also.

Now that we have the technical implementation described, the really
tricky part is building the network of users. AIM (and other IM or
social networks) generally have spread because they are free. One
could take various “free for a while” or “limited use” free versions
in the AIM email network. But I think those would not work so well. In
the “free for a while” model, you get the user revolt and bad feeling
when you start charging for something that was free. In the “limited
use” model, you basically artificially fail to deliver messages based
on some usage level. An important component of any email service is
reliability, and the message that “hey we are reliable, but only if
you pay” is not very consumer-friendly. More importantly, this
service is so freaking valuable it should not have that value eroded
by being free.

I suggest that the sending side of the system be free. Any
AIM user should be able to send an email message to an AIM user who is
email-enabled. And that’s the hook: the person who is experiencing
the pain, is the person who is receiving all the spam, and wants their
buddies to be able to communicate with them on a separate
channel. This it the pay service: an AIM inbox that only your pals can
leave messages in, that you can read through any email client (or, on
an AIM webmail site, of course) is only $19.95 per year. Or maybe
$9.95. And, yes, per year. Remember, we’re trying to build a
network here, and low barrier to entry is the key. Think about it:
100 million AIM users, that’s some pretty good cash. And once users have
a payment method set up with their AIM account, think what else you could do:
iTunes or other product purchases from the AIM client ads, etc.

Remember when I said modifying the AIM client would be monumentally
stupid? That was mostly for effect. To get the network started and
growing, of course the AIM clients would need to be modified. First,
any AIM user who was inbox-enabled would have a special indicator
(similar to video/audio chat indicators today.) That way, their
buddies would know they could send them an email. Also, if you send an
IM to a buddy who is inbox-enabled, even if they are offline, you
should always have the option of sending the message (or whole chat
transcript) to their inbox, so they can read it later on their email
client. And, whenever an AIM user sends such a message, they would be
sold on how to both set up their email client to send SMTP email to
their buddy, and how to get their own inbox.

Another upsell method would be used for those people who set up SMTP
outboxes on their email clients (which is free). When they set up the
account, they would enter full settings for the SMTP and POP server,
username and password. But if they aren’t paying members of the
network, they can’t receive mail. That POP mailbox would have one
canned message that would keep appearing, once a week or once a month,
which basically is the marketing campaign for why they should cough up
the $10/year to get the inbox. Sort of a “if you lived here you’d be
home now” thing, for those of you who drive through Leverett Circle on
Storrow Drive in Boston.

The other obvious upsells are on the bounce messages you get if you try to send a message to a non-inbox-enabled user. These would be standand bounced email messages, but would include a link to instructions for getting your buddy to sign up. “Sign up for AIM inbox dude, I want to send you messages!”

Finally, once the network is rolling, there are corporate sales you could make, creating meta-buddy groups that would allow delivery between departments or even companies that establish email trust relationships.

There are a few more details in this thing, but there it is, on a
silver platter. Hey, AOL, feel free to send me a check for $47 million
once you achieve creation of the largest private communications system
in human history.

In Tiger, each of the dashboard widgets is its own process. I had always been running close to the ragged limit of processes before, and dashboard put me over the top. Apparently there is a simple kernel parameter to increase the process limit.

Here is what you need in your /etc/sysctl.conf. (Or something like this. Maybe you need more, or not so much. This works for me, with 2GB of RAM.) The default Tiger values were (oddly) 532 and 100, respectively:

kern.maxproc=2048
kern.macprocperuid=512

And here are the commands you can run to update these parameters without rebooting:

% sysctl -w kern.maxproc=2048
% sysctl -w kern.maxprocperuid=512

You then also have to increase the limits on various daemons (in particular, WindowServer) to allow your user processes to exceed the default shell limit of 100. This is dangerous to do, but it does work. Detailed instructions are at macosxhints.

Thanks to Joseph Scott for writing about this on his web site! He rules.

Everything was going swimmingly on my foolish, headlong migration to Tiger until I tried to run the Aqua version of emacs. It wouldn’t even start. After some grunging around, and some help from Derek, I have a build that is working.

The secrets are:

1. Fetch the latest version of emacs from CVS.
2. configure with “–with-carbon and –without-x”

My build is in progress. I’m keeping my fingers crossed.

Update: Yay, it worked. Here it is: EmacsInstaller.dmg

ArsTechnica has an excellent, in-depth technical overview of Tiger. Included are interesting details and tutorials on file metadata and ACLs.

(this entry generating a lot of comment spam, so I’m closing it.)

I had this shareware app called DoubleCommand which does all kinds low-level keyboard remapping (using kernel extensions.) I used it to disable the CAPS LOCK key which my clumsy fingers always graze. (The CAPS LOCK key is, IMO, a stupid anachronism. I mean, who uses it, really? Besides BIFF.) So it’s broken, and the news that it’s broken until further notice is sad.

I have Virtual PC, so I can run Windows 2000 and do horrible things like run Internet Explorer to test web sites. It’s complaining about the network virtual switch driver not working.

Something on my machine is using a bit more VM than usual. I keep hitting the process/VM limit, somewhere around 22GB. I think it might be the Dashboard widgets, each of which has a pretty fat (250MB) VM footprint. Ugh.

I was really bummed out when I ran “java -version” on Tiger and it was still 1.4.2. I mean, what the hell? The two things I cared about in Tiger were Spotlight and Java 1.5. (Yes, I am a big nerd.)

Anyway, it turns out it’s not quite done. If you want it, get it at the apple developer download site. It’s still beta, but I don’t care. I just need it to mostly work so I can develop on my Mac and deploy to Linux.

So far I’ve upgraded three of my four Macs to Tiger. No major problems. They include a 500Mhz G4 Cube, an 800Mhz Powerbook G4 and my 2x2Ghz G5. I started with the slowest computer and have just finished the fastest.

In general, I am very happy that there is little in the way of gratuitous cosmetic changes. When I sit down and look at the screen, I would not even really realize anything was different. The only things I can see are the little apple menu icon in the upper left, which is bluer, or something; and the spotlight icon in the upper right (which of course isn’t there at all in panther). I’ve already found some documents I had completely forgotten about.

Spotlight is pretty great. I’ve been jealous of my friends who have installed google desktop search on their Windows machines, but that’s all over now. It takes a while to do the initial index, over an hour beyond the install of Tiger.

Dashboard is the other feature that is nice. It’s a blatant, heinous rip-off of Konfabulator, but it’s executed a little better. I never really got into Konfabulator, but I can see myself using Dashboard quite often.

My one complaint is that the integrate Tiger Sync (which replaces iSync) is a little sketchy. I’ve already had several odd error messages like: “an inconsistency has been detected. We recommend you re-sync from a Mac with good contact data.” Yikes. I haven’t lost any data, though, so it’s not horrible. The Sync is quite slow, but I’m hoping it’s because everybody is upgrading this weekend and trying it for the first time.