The RAID is resyncing…

The hard drives have arrived and are now in my machine as a RAID-1 mirror. The mirror is currently resyncing at 50 MB/sec, but I can still work on it — pretty cool!

The original plan was to use the two new disks in a mirror and reinstall Debian on it. But now I’m thinking about simply moving /home to the RAID and then leave the rest of the system alone.

That would make it extremely easy for me to upgrade and reinstallthe system since I would have my important data stored safely away on the RAID. And I don’t have to fiddle around with reinstalling my system right now; I had hoped that Debian Sarge would have been released by now, but they are still working on it.

Unfortunately I wont see any speed gains when I start, say, Emacs, or any other program if they aren’t located on the RAID. So I’m thinking about moving more than just /home to it — according to the FHS (which Debian follows) — I should be able to move at least /usr to it since it is read-only data.

Begone evil spam!

Just three days after installing WordPress my blog has been spammed — I guess that shows how quickly the blog is integrated into bigger blogging community thank to the links from Janus and Kristian and the automatic pinging of several other sites by Ping-O-Matic.

So the world is tuned in… that’s all very well if it weren’t for those pesky spammers! I’ve had seven spam comments already, and it didn’t look like it was going to stop. But with help from Spam Karma I hope to get rid of them. It checks the comment in several ways and deletes it if it determines that it is definite spam. Good comments are let through immediatedly. Comments where Spam Karma is in doubt will be subjected to a captcha test where you have to recognize some letters in an image. That is a really cool feature which should ensure that no automated program can post comments, while still allowing access to real people.

Provided that the commenter gave a valid email address when submitting the comment, he or she can also verify themselves using that. That also means that people with bad sight can get their comments approved even if they cannot use the captcha test.

Visiting Aalborg

I’m visiting my family in Aalborg for a couple of days — when I go to Switzerland next month they wont be just an hours drive away anymore :-)

The plan for this week is to package the stuff in my room and move it up here to my parents. I’ll bring some of it with me to Switzerland, but only the most important stuff. Of course that includes my computer!

Speaking of my computer… I’ve ordered two Seagate 7200.7 SATA NCQ disks each with 120 GB. The plan is to combine them into a RAID 1 mirror so that I will have a reliable place for my photos and other data. In Skejbygård I could just copy my data to my friend Svend’s computer, but that wont work anymore when I’m in Switzerland. And besides: I’ve wanted a RAID system for quite some time now — I believe that the Debian installer can install on a RAID 1 system now.

Parse errors…

While trying to put my PHP tutorial back online I have just spend at least half an hour fighting the markup language! The problem is the lack of tables in [Markdown][].

I wanted a table listing the operators in one column and their meaning in another column — a quite simple talk one would think, and something which I was able to do in PhpWiki with only a minor problem: I could not use || when describing the or operator, since the latter is used in the definition of the table itself.

With Markdown I had to write the table myself. No problem, I’ve written lots of tables by hand! But no, everytime I saved the page the closing table tag somehow disappeared. This messed the page up quite severely.

Next idea: make the table in plain ASCII. It wont be as nice, but it ought to work. But no, even within a code block, where the lines are interpreted literally, I got into trouble. The line with the < ate the following spaces.

These things are what I hate the most with all those PHP content-management systems: they are all so fragile! The parsing done in [Markdown][] is based on regular expressions, and so is the parsing in all other systems I’ve seen. This just doesn’t work reliably — my experience is that you either get strange results like I did, or that you get silly limitations, or you end up with both.

The limitations I’m talking about is when you in PhpWiki cannot apply formatting markup to a link. A quick test to show that it works with Markdown.

I believe that using stronger tools for the parsing would help with these problems — in particular defining a proper grammar and writing a lexer and parser would make things more robust. When people submit a comment with parse errors it would be up to the compiler to flag them as such. It wont be easy to make a compiler with good error-recovery for such a system.

But if it were done, then we would in effect have a system of writing valid [XHTML][] without all the tags — that is a worthy goal! And given such a precise understanding of the structure of the text, one could easily convert it into all sorts of interesting formats such as [LaTeX][] (for later conversion into good-looking PDFs) and ASCII (for inclusion in README files and such).

Looking at the source code for the [GNU][] Flex and Bison tools one sees that they are not exactly trivial to reimplement in PHP — far from it. But I still hope that they will some day either support PHP natively, or that we get another lexer/parser framework for PHP.

Uhh, that was quick!

Just as I have put my site back online and written a single post I see that Janus already has posted about it… impressive! So now I of course just have to try out making a post about his post — using the TrackBack thingy of course!

So far WordPress seems to do what it’s supposed to do: give me a clean platform for writing stuff for the web. I have yet to checkout the post-by-mail feature, but since I like editing my stuff in Emacs I think I might love this thing — for I am of course sending my mails using Gnus from within Emacs :-)