Blog Refactoring

Software has to change, or it will become less and less useful[1]. Because of these changes, its design deteriorates[1]. Frequent refactoring prevents this deterioration[2], and thus allows the software to easily evolve further[3].

As software evolves, so does this blog. After about twenty posts, the problems of its structure became obvious. Thus, I spent some time refactoring the categorization scheme, re-tagged all posts and seperated categories from their archives.

I like the result. Neither semi-duplicate nor fuzzy tags. The tag cloud is clear and concise, and now it reflects the contents of this post very well.

If this should blast your feed reader, I'm sorry.

---

Footnotes

1. These are natural laws of software, first formalized by Lehman and Belady around the 1980's.
2. Or rather, undoes it soon after the problem is noticed.
3. Because maintainability and extensibility is much higher in well-factored than in interdependent spaghetti code.

Ikiwiki

Finally, I don't have to write this blog by hand anymore.

Ikiwiki is a flexible and powerful wiki compiler. It is completely filebased, uses the revisions control system of your choice as backend and integrates well with your already existing project. There are various plugins, making it usable for issue tracking, blogging and various other tasks. See their homepage for further information.

The concept behind ikiwiki is really powerful, but, unfortunately, since it integrates very well with other software, its implementation suffers on traditional operating systems. However, it is still much better than other software available.

As you can see, I've already switched. This blog runs in passive mode, since I don't have the possibility to install the ikiwiki software on this server.

Blogging in HTML

Before even publishing this blog, I switched from plock to handwritten XHTML.

No big deal, but no features either. This is a temporary solution until plock outputs valid and proper XHTML -- or until I have written a better alternative.

This blog, plock, and python distutils madness

Over the past few years I've learned quite a bit. Most of it boils down to criticism on traditional software because of insecurity, low usability, missing concepts and consistency, elitism and various other ills. Add a couple of program or operating system crashing bugs to the already large list of pitfalls and the only thing you can rely on is that you will primarily be fighting against the system instead of using it to get work done.

This blog is primarily intended to document my experience with such software. The goal is to not only criticize an isolated piece of software because it is somehow "weird" or "buggy" but to also look at the whole picture and to analyze the causes.

Traditional operating systems are obsolete -- and so is third party software that sticks to those standards or even worsens them.

I'm still on my way to (re)learn software and operating system design -- Unix and Windows hell has ruined so much. So this blog is also about the stuff I'm learning; about ideas, concepts or even projects that could lead to software that is user-friendly, more flexible and powerful, and reliable.

The software I'm using is plock (git://r0q.ath.cx/plock.git). On installing it, I've been bitten by another one of the bugs I described above.

I successfully executed setup.py, an installer of Python's distutils. But on running plock, I got "no module named plock". Turns out python's distutils will naively install the software with roots current umask. Publicly installing data using private permissions is a really good idea.

The default umask on a "secure" operating system like GNU is 022, meaning everyone can read root's files if the chmod is not changed after or on creation. But if you're sane, you might want to change it to 077, denying access for everyone but the owner. This should, of course, not affect software that is installed system-wide.

To top off that dumbness, python prints an error message that is just wrong. The module is there, but not accessible. 404 != 403.

It seems that not many care for the umask defaulting to insecure, otherwise this bug in python's distutils should have been noticed prior release.