I suspect I will need to dive into the template files for ikiwiki to make more progress.

I am still quite disappointed.

I would really like to see this, and read/write shared mmaps (for spamprobe and similar) to be supported in fuse file systems (and naturally gluster in particular).

As we are now looking at using qpsmtpd for auth and greylisting, it is entirely feasible to put qmail behind it instead of postfix, and to ditch mailman in favor of ezmlm. I am thinking that this might be the best way to go, particularly now that there is a route forward for qmail. One of the flaws in it has historically been that its development simply does not move, at all.

For this reason I am thinking that I would look at netqmail and not qmail itself, as there are more developers for it.

Vincas suggested OpenAFS, which seems similar to the glusterfs that I have been working with some. These offer a client/server model, more like an nfs replacement than an actual file system. This could work well, though it is not quite as clean, to my mind, as ocfs2. Since we are already using ldap, synchronizing UIDs isn’t a problem, so file permissions should work fine with either, or even with nfs.

OpenAFS has the advantage of having debian packages. One thing to keep in mind is that Dan dislikes it, though I do not know why. He’s certainly come down against some worthy software, while liking some less capable software, but on the other hand, his impressions are often sound.

Glusterfs is newer, and does not yet have real debian packages, though there are packages from a third party that the gluster guys have included in their wiki. On the other hand it has Dan approval. I am not really sure how which would make a more stable platform for us.

That is neither here nor there though. While I was converting, I came across a number of small but indicative things that lead me to believe that the administrators employed by the customer whose servers I was converting are in fact incredibly incompetent. Gah, that was a bad overly clauseful sentence.

Anyway, while nothing I found makes things certain, it was, as I said, certainly indicative. Today, I wake up, and they are complaining that files are missing from a vhost that I did not touch. At all. Sure enough, the file system is mounted but the files themselves are not there.

Looking in history, I cannot prove that they ran the rm -rf themselves. The alternative is that they were hacked. Either way, it feels like a sort of bitter “I told you so” moment, because yesterday I spent a few minutes complaining to Dan about the state of the converted machines, and suggesting he contact the customer about it. I do not think the customer realizes how incompetent his administrators are, nor that he has enough technical skills to interview a system administrator adequately. As a good business partner, I personally feel we owe it to this customer to have given him a heads up. And Dan might have done so for all I know.

Still, it is deeply ironic that we have had a catastrophe the very night after I warn Dan that they are asking for one.

bah.

Still, despite knowing exactly how reasonable Google is being, I am annoyed at the error. What makes it worse is that there’s no good way to report this new road to Google, or at least not one that is readily evident from their Maps website. If I were a business, I could report my location to them, but a new residential street.

It took me longer than it should have to track down what was up. The problem was that when I delete a quote (which I have done a few times, because there have been times I have entered in one poorly), it does not backfill the quote ID number. So my quote database goes 1 4 … 17 18 20 … 102. The plugin, when it goes to display all quotes, does an sql query to get all quotes into a single array, which it then counts. Naturally enough, as you can infer from the above, it finds 99 quotes. It then iterates from 0 to 100, attempting to find a quote for each $i. If there is no quote at a given $i (such as $i=2), it skips it. It gets quote 100 because it increments $i after the test but before it tries to pull the quote. But it misses quotes 101 and 102 because $i is now larger than 99.

The solution is to have two iterators, both of which start at 0. Iterate $i from 0 to 99, when you reach $j = 99, stop. Inside that while loop, there was already a test for an empty quote, have that increment $j instead of $i. Then make sure you increment $j after a successful query after displaying the relevant quote. If you increment it too early, you’ll skip the quote you just found. If you fail to increment it, you will find the same quote repeatedly. This way $j will grow faster for $i, with the difference between them at any given time being equal to the number of deleted quotes that have been reached at that point of the process. So that when $i = 99, $j = 102. Then all the quotes display.

He had to expect that he would be sued, the idea that they would see this as a reason to give him a job is ludicrous. That being said, I agree with Mr. Kravets that the idea that the DMCA considers this hacking a program to circumvent copy protection is worrisome. I should have the right to delete anything on my computer without fear of suit.

This has been an interesting process, fraught with much trouble. I think we now have all of server1′s content migrated over to the various vhosts that are replacing it, and are finishing up the final few tasks that remain. It remains to be seen how much work it will be to get my family seeing, as nearly as possible, the same mail setup they previously saw.

It is in question because I have chosen to force the use of Maildir for the inbox, while I allowed debian’s default /var/spool/mail/ mbox to remain unchallenged on server1. I believe the version of pine I installed will handle the resulting setup adequately, but, as I said, time will tell.

It also remains to be seen how well this solution scales. The host it is on is significantly beefier than server1, so it should handle the schierer.org load without much trouble, though it might take some tweaking of the various vhosts to get resources allocated appropriately. Vincas and I would like to see it be able to grow significantly beyond schierer.org though, and to take on much of the work our joint boxen are currently hosting. Again, time will tell how well it works.

If all goes well, we will almost certainly make the other box a xen host also.

Returning to the topic at hand, I found that I had to remove the gnome python desktop stuff. Since nothing appeared to depend on it, I assumed that it must be something I installed by mistake, and removed it.

Then I go to see if gramps is installable yet. A significant number of ports have been upgraded since I last tried, so this is a reasonable experiment. What is the first package it pulls as darwinports tries to install it? Metacity.

Again, I do not use metacity at all. Gramps runs just fine on my linux desktop. Metacity is clearly not a dependency of gramps. Why is it being pulled then?

The problem with many GNOME programs (of which gramps is one), is that the authors consider the case of using the software with something other than the default GNOME environment as an afterthought at best. Thus to require a window manager for a graphical program makes some sense. But I do not use that window manager, and any of a number of other ones work perfectly well with gramps. So why in the world must I have metacity? Only because the authors of GNOME are infested with a lets-take-over-the-world attitude.

Those of us developing gaim are not like that. We know full well that gaim is not and never will be the best client for everyone. That is why we are working on the core/ui split, so that others can write their own interface, one that better fits their needs, without duplicating all of the work that goes into making that interface run. Open source is, or at least should be, about choices. We ought not to forget that.

Unfortunately this conception of email is utterly wrong. Worse, everyone who is actually understands how email works knows this. That our users do not is in some cases an example of willful ignorance and in others a failure on our parts. Most people using email never had any real explanation of it, only in a few cases has its relationship to postcards been explained and ignored.

For this reason, a good number of computer people use the PGP^[2] or GPG^[3] (equivalent, compatable systems created by different groups) to encrypt their email. A smaller group, not fully trusting that system, but wanting equivalent privacy, use Tiger Envelopes.^[4] Either of these provide reasonable levels of privacy, effectively enclosing your email in an envelope.

Without that, your email really is like a post card, and when stored on a server that is not your own, why should you expect that no one else would read it? You do not have that level of control or security when it comes to real post cards. People need to learn this. They could handle encryption, it really is not that hard, especially in the relatively non-authenticating forms (that is, forms of encryption that ensure that only you and the sender can read something, but do not tell you who the sender is).

Ignorance is no excuse. For reference, my public key is here.

After a couple false starts involving the bash for loop (which I still think could solve the problem), and a quick glance at the find man page, I produce the one line result.

find /home -type d -mindepth 1 -maxdepth 1 -exec tar cvf {}.tar.gz {} ';'

I like mutt. I really do. Ever since Mr. Ethan Blanton introduced me to it, it has served me well. Recently though I started using Mail.app, the OSX mail client, for my personal mail. I made this change in part to be able to decrease my reliance on gmail and similar for the odd html formatted mail that I want to read, in part for the ease of setup, and in part because the thought of setting up a mail server to send mail from on my laptop is daunting. I do not trust darwinports to get things right and work consistently all that much, nor do I wish to compile and maintain postfix myself. This is after all why I use debian on my other machines: to be able to ignore the software that I do not want to actively track and know the details of myself.

But I find myself on OSX for my laptop. I want to use Quicken, and I want to be able to run the Rosetta language software, even though I do not in fact do so nearly enough to actually make noticeable progress. It also does not hurt that Civilization, about the only computer game I’ve remained significantly attracted to since graduating, runs on OSX. So I find myself leaving mutt some.

Having done so, I can see some other gains. I have address book integration, which is nice. So I can, in a theoretical sense, see that if integration between a real address book and an email address book is nice, it might be nice to add in the IM contact list into the mix. After all, most of the people on the buddy list for my personal accounts are also in my address book.

Which brings me to gevolution. I have disliked evolution every time I have touched it. It is big, consuming more memory than I like. It is fragile, crashing more than I am willing to put up with in a mail client. Mail.app’s handling of threading is poor, evolution’s handing is (or at least was) worse. Additionally, it pushes me more towards GNOME, and I really do not like the GNOME Desktop Environment.

I appear to not be particularly alone in this dislike of evolution. As a result, the gevolution plugin, originally written by Mr. Christian (ChipX86) Hammond, is rather neglected. Mr. Hammond left the project with gevolution in a rather unfinished state, which should not be taken as a detraction from him: most of gaim was then and is still in an unfinished state. That does not hide the reality though that gevolution, like the rest of gaim, needs a significant amount of Tender Loving Care, but unlike the rest of gaim, is not significantly likely to get any.

It is very nearly abandoned code. As such, it is becoming increasingly fragile, and its flaws are going largely unfixed. When I see this sort of code, my reaction is that we should drop it. Yes, some users like it, but it is causing problems that we do not intend to invest time fixing. If someone really likes it, they can of course check out an old version of gaim, rip that code out, and make it compile as a 3rd party plugin.

This temptation grows with every bug report I see that ends up being traced to the gevolution plugin. Bugs about not being able to add or remove buddies, or about slowness, or inexplicable crashes. What is the solution here? I am not sure.

I have always a little bit contemptuous of true forks, because they have consistently been started by users who clearly have no clue how much work we put into gaim. Precisely because they were unprepared for that level of effort, these forks have quickly failed.

A libgaim based “fork” would be a different matter entirely. It would not, in fact, be a true fork at all, and to call it one is to utterly mistake why we worked so hard to split gaim into a UI and a library, into “gaim” and “libgaim.”

We want there to exist other interfaces. You want an interface that integrates with GNOME to a significant degree? GREAT! Grab libgaim, and even grab our existing Gtk UI if you like any aspect of it, and write one. You want an interface built to fit in with KDE? Awesome, grab libgaim, break out your QT API reference, and get busy. OSX? I personally think Adiumx does a reasonable job, for all I have a few differences of opinion with them, but hey, if you do not want to help them with their libgaim based efforts, write a second (or third, considering Proteus) one. Dissatisfied with wingaim? I sincerely hope that someone will write a better UI for windows users than we provide.

The point here is that we have what is (in my opinion) one of the best back-end code bases available, with better (though far from perfect) protocol support than most other projects have been able to generate. Why should that effort be duplicated? It represents 2/3rds of the necessary code to run a successful IM client project. That is a ton of effort essentially being wasted when we duplicate it over and over again. Effort that we believe could be better used to make more things work for more users.

But while it is clear that supporting the varied protocols requires a huge chunk of very similar code, it is far from clear that it is possible for any one interface to fully please all users. I go so far as to argue, consistently, that it is in fact impossible for any given interface to be the best for everyone.

The only reasonable way to approach this then is to enable people to write interfaces that meet their needs while avoiding the duplication of effort that starting from scratch entails. This requires libgaim, or at least some equivalent. We here in gaim could never support the N interfaces that we foresee, or at least hope to see, eventually existing. But now we will not need to. The source is there for your use, grab it, and lets see what you can do with it, what sort of interface you design. I wish you the best of luck!