Yesterday, I said that I consider windowtitlebars as user interface elements and think it's sensible to ask ifthey're useful for any particular interface. As you might have guessedfrom what I've written , Idon't consider consistency between programs to justify bad interfacesin things that I use a lot, and so I'm perfectly willing to eliminatetitlebars on some of my windows if they're not justified.

So, are they justified for me?

In my environment, there are a

I mentioned in yesterday's entry that Iincluded the window's titlebar in my little screenshot of xrun becauseI considered it part of the program's interface. When I wrote that itwas a quick aside, but in thinking about it I think that this is veryclose to being my defining view of when window titlebars are worthwhile.

In many environments, window titlebars are not optional; you just don'tget to turn them off on Microsoft Windows or Mac OS X (at least not asshipped

Sometimes I use a machine so often that tools like pyhosts and dmenu just aren't fast and convenientenough. For instance, I do most of my work on one of our login servers(which one doesn't matter), so with my habit of disposable windows I am forever opening and closingterminal windows and so on.

My main tool for dealing with this is a simple program called xrun (which was originally written by Mark Moraes). Xrun puts up a grid oftext labels, each of which

My home Linux machine has a little problem in thatit's still running Fedora 8 and I now really want to upgrade it. (I wasquite enthused about Fedora 13, but I am now somewhat less enthused about Fedora 14.)

Now, I will admit that the real solution is to buy more or less all ofa new machine to replace my now four and a half year old and slightlyflaky hardware, install Fedora whatever on that hardware, take it home,and copy all of my

A while back I wrote about the myth of a completely shared knowledgebase across sysadmins . Well, there's a mirrorinverse of this myth: the equally persistent idea that you can be acompletely isolated individual sysadmin, tucked into your own silo andworking purely on your own responsibilities. This is the universe inwhich a multi-sysadmin group has the mailer person, the DNS person, thefileserver person, and so on, and no one has to spend any time tryingto bring other people up to speed

In light of Phil Hollenback's reply to my earlierentry on this topic, I need to write some morewords.

First off, I entirely agree with Phil that a wiki engine can do a decentjob of generating blog-style syndication feeds; all you need is to havea full text feed of recently created pages and you're basically done.Category or hierarchy based feeds are useful but optional.

(Making the whole thing efficient is only a small matter of programmingand data storage, and for even

One of the things that I am trying to do now with the web applicationI'm building is to think about howpeople may misunderstand and misinterpret it.

When I create a system I know how it's supposed to work and be used todo particular things, and I write the code and create the interfaceto fit this. Of course, how to use the system is clearly obvious tome. But it's not necessarily clearly obvious to other people, and so Ineed to turn a sceptical

It's always a humbling experience to realize that you've made a terriblemistake when configuring a program, even when it only really affectsyou.

Once upon a time, I was building and thus configuring my first MH setup. MHputs each message in its own file and normally 'removes' messages byrenaming them by putting a prefix character on the front; this lets yourelatively easily un-delete messages for some amount of time if you madea mistake in removing them. When you are configuring MH

You can argue that in many ways it is basically a tossup between the blog approach and the wiki approach to writing for the web and that you might as well use whicheverone you want to adopt, whichever one fits your particular style ofproducing content. (Given real blog usability youcan certainly argue that a blog's chronological ordering is unimportantand a wiki's greater internal links are highly useful.)

However, the blog approach does have at least one significant advantageover the wiki approach: blogs have figured