Thanks to hosting my server on xen hosting, Kite will get a faster CPU, and twice as much disk this year as it got last year. And I'll be paying only half what I paid last year.
I can't say enough good things about the little co-op Steve has set up. Ineed, my only complaint after a year of hosting Kite on xen is that I can't yet install my own kernel. But the much nicer hardware than I could afford, the absurdly low price (lower than any other xen hosting I've found), xen's shielding me from server reboots and downtime and general mucking around with nasty hardware and colos, the xen-shell management interface, and everything else, is great.
There's one free slot opening up on the machine. Whoever gets it will be a very lucky person. Everyone who doesn't should consider putting together a system following the xen hosting model.
Say you have a virtual machine at one of the larger hosting companies. You're sharing a system with some unknown number of other users. Wouldn't it be nice to be able to chat with people from the other VMs on the machine? Assume that the hosting company doesn't particularly want you do to this; they prefer you don't know that the machine's CPU is split 30 ways and that you're migrated to a new, random machine every night at 3 am.
I wonder how to accomplish this? The coolest hack would be to frob some kind of available on-machine data source that the other users could watch. This basically requires finding and exploiting a minor security hole, though.
Maybe a centralised registry would be better, if there's some way to uniquely identify a given host machine from inside the VM. Focusing on xen, I think enough data is leaked to make this possible.
- /proc/cpuinfo
- uname -a
- /sys/hypervisor/compilation/*
- /sys/hypervisor/properties/*
This should at least narrow it down to a set of similar boxes at a given hosting company, and then you can start looking at the network..
On a not-unrelated note, this diversidial system is way cool. 300 baud via telnet! I especially like the use of an ipod as a tape drive for booting the Apple IIe.
One of the reasons I was relictant to write a wiki before starting work on ikiwiki was the wiki/blog spam problem. Now that ikiwiki is reasonably mature, it's interesting to look back at how that turned out.
The basic spam prevention mechanism in ikiwiki is the same as the one many wikis use: By default, it requires registration before you can edit a page. This is a pretty small stumbling block for spammers, especially since ikiwiki doesn't bother with email verification. It even prefills the login form with your username and password after you register. It would take about 5 lines of perl to defeat its registration process. Suprisingly, only one spammer has spammed any of my wikis.
To defeat that spammer, I added the most common second layer defense against spam: A blacklist. Again I implemented the bare minimum, a way to blacklist a given user and ask them to "go away". Nothing to blacklist IPs, nothing more complex. That was put in place last October and I've had no problems with spam since. Around the same time, I made a change that I feared might open up a whole new class of spam, when I added openid support to ikiwiki. As far as I know, noone with an openid has tried to spam an ikiwiki wiki yet.
Ikiwiki did grow one other common spam prevention tool. Josh Triplett added support for a user account creation password, so you have to know the password to get an account at all. This isn't used by default though. The only other possibly anyi-spam measure is that ikiwiki does allow locking down pages so only an admin can edit them, or so they can only be edited via commits to a revision control system. I use these methods for personal stuff like my blog, and might have cut down on the incentive to spam. Spamming a discussion page is just not as interesting as adding spam direct to my blog's rss feed.
It seems likely that any new wiki system will have less spam at the beginning, especially if the spammers have to write code to bypass its registration system. That one spammer spparently did so fairly early is suprising. That no others have tried since is also suprising. My ease at blocking the spammer by simply banning them suggests that they were going after the easiest possible targets, and that it's not yet worth their while to work around even the simplest countermeasures. But if so, why did they add support for an entirely new registration system? My guess is that their existing code happened to work with ikiwiki's registration system. (This would take probably 20 lines of perl. ;-)
Of course, there's all kinds of counterspam measures that I could implement if needed. By the way, if you use ikiwiki and have had problems with spam, I'm of course interested in fixing that. It'll be interesting to see when additional measures turn out to be needed, as the wiki and sites using it become better known.
I saw the old house on Haskell St. last week for the first time in forver. I could barely pick it out of the other houses on the block, it's so different now.
I also, conincidentially, studied the haskell programming language a bit. I watched some talks that John Goerzen linked to, and I read several chapters of the "Gentle Introduction to Haskell". Which wasn't all that gentle. :-) I should have put off reading it until after the talks and after reading some other introductory examples.
At least I have some motivation to learn haskell. I could never see any reason
to bother learning python or ruby, since there's so few compelling differences
between them and perl. I had begun to worry that I wasn't learning any new
programming languages, so it's nice to have a new dot on this graph of
languages I've learned since 1990:
If you ever looked at ikiwiki but gave it a pass since plugins had to be written in perl, you might want to look at it again now. Today I added support to ikiwiki for plugins written in any language that supports XML RPC. Ikiwiki's external plugins are just standalone executables, that talk XML RPC on stdio.
I think that works pretty well. The overhead of XML RPC doesn't matter too much in this case, since RPCs arn't done all that often. The entire ikiwiki programming interface is accessible, except for a couple functions that use perl objects. I even added the ability to inject an arbitrary procedure from the external plugin into perl, so ikiwiki can call it like a regular perl function. This can even be used to override one of ikiwiki's functions with a version written in another language. Even parts of ikiwiki that don't use a defined plugin interface, like the RCS modules, can be written in other languages using this.
Now I only have to find time to learn enough haskall so I can write ikiwiki plugins using it. :-)
When you're reporting a bug on a piece of free software, starting it out with the word "stupid" might not be an ideal way to make your bug rise to the top of the priority queue. It's not a nice thing to wake up to, believe me.
When someone has responded to a question you have about a website, pointing you to the page you could not find; mailing them privately with the command "Fix it" might also be less than ideal. Especially when you're just randomly assuming they can "Fix it". Especially when you've not checked to see if it has already been fixed. (Unless you're a pointy-haired boss; then this behavior is expected.) It's not a nice way to end the day.
My inbox is empty. Holger posted a link to this talk which makes some really simple suggestions about how to handle new mail, to avoid letting it rot in the inbox.
It turns out that I was already doing most of them pretty well. For example, offlineimap only downloads new mail every 30 minutes, so I don't constantly waste time checking my inbox for new mail. And I'm pretty good at deleting mail I don't want, quickly sending quick replies to easy mails, and adding calendar entries for time-sensative mails. So my inbox was only 90 messages long..
The main thing I need to improve seems to be getting out of the habit of leaving deferred things to sit in my inbox. I went through and about 80% were mails sent from the Debian BTS. All that stuff is in the BTS, so there's no need to keep it in my inbox. Another 10% should have been in a BTS, but was sent directly to me -- so I put it in the BTS, and removed it from my inbox. I know I'm not the only one with this problem, BTW.
I recommend watching the talk. Thinking about mail in the inbox as only having one of 5 actions you can perform on it (delete, defer, delegate, respond, do) really helps process it quickly.
My inbox is still empty. :-)
The new policy for vim addons on Debian is that the addons should not be enabled by default. You have to install vim-addon-manager and use vim-addons to turn them on.
So while I can apt-get install insecured and the daemon will
automatically be run, I can't apt-get install vim-vimoutliner and edit
.otl files in outline mode by default. Seems weird or backwards, no?
The vim-addons program does solve several problems, like being able to disable addons, or selectively enable addons from vim-scripts. But I've read all the docs I can find about this, and I can't find a rationalle for why the addons should be disabled by default. Seems to me that addons could simply run vim-addons from their maintainer scripts. Any reason not to?
Nothing special about this recipe at all except it rescued an otherwise very "blah" day.
- 4 eggs from a devil chicken (or other chicken you know)
- the smallest yellow squash from the garden (under 5 inches, leave the 3 foot monsters in the fridge), chopped into half-inch half-rounds
- 1/3 a large red onion, chopped
- a few kalamata olives (or other black olives), pitted and roughly minced
- a rather small amount of sharp cheddar cheese, grated
Fry squash in a small amount of olive oil, add onions and brown over medium heat for 5 minutes. Remove from pan, and turn heat high. Wisk together all ingredients, add a little ground pepper, and cook omelette quickly.
Serve with bread (fresh focaccia mmm) and freshly pickled cucumbers from the garden.