This is based on reading When Good User Interfaces go Crufty. I didn't think I'd be able to find a comment again in the discussion.

Saving is now an operation that users care about. It's actually more like committing changes. Users expect, from their computer use, to have the times they saved as times they can revert to (at least the most recent one). But they also don't necessarily have the habit of saving often (and they shouldn't save often, by the meaning they're using; they only should save when they've completed something). The correct behavior is to keep track of changes since the last save and apply the most recent set when the program starts up. You can quit, crash, lose power, whatever, and it will come back where you were. But if you (e.g.) copy the file somewhere else, it won't be different, because you haven't saved it. And there's no need, on a modern OS, to actually ever write the in-progress version with file operations: you can memory map it and the OS will write it to the disk as needed, avoiding the possibility of the program crashing with unsaved work.

While I'm on the topic, undo past saves is a useful idea (as is multiple versions), but it should stick to the session, not to the document. "Sure, I'll delete the secret parts of the document and send it to you." The user-level concept of a file has only a single version, with nothing but the current contents. Everything else is magic that the user expects to be personal.

Programs should quit when you have closed all of the windows, and not at any other time. If each window is a document, it quits when you're no longer working on any documents. If there's a window for other stuff, you'd have to close that, too (e.g., in an IDE, you'd have to close the IDE as well as the documents). You can't close the IDE part unless you're closed all of the documents (although, possibly, if you try to close it, don't use it, and close the last document, it should go away, so you can do things in any order).

Programs which can handle multiple documents should recognize when the program is already running and open the document in the existing program when you open a new document. This is often supported, but not frequently enough that users tend to do it instead of using "Open". Note that this applies just as much to the command line as GUIs; why can't I do "emacs " in a shell instead of ^X^F and then finding the file? (actually, I can. But it was complicated to set up.)

Remembering inodes isn't right, but there's a similar idea: hard links. You have two directory entries for the same storage. Of course, there are a number of questions remaining. If you move your document to a new name and create a new document with the old name, which do you get? This is essentially the situation you get when saving later versions of documents (except that the old version is also removed). Hard links would tend to follow the versions. You probably want to add a flag on files to say that it is "weak", such that, if there are no non-weak links to the file, it goes away, unlinking all of the weak links (unless any of them are open, perhaps); that would let you purge documents which are in the "recent" list but have been removed. It would make sense to have symlinks in your recent list as well, though, so that, if the original is gone but there's a document with that name still there, you get that. (Doesn't help for documents which have been moved and then replaced without notice, though).

I wish people on slashdot wouldn't talk about patents without a basic understanding of how to read a patent. The abstract is an abstract, and is always going to be extremely broad. That's not what the claim is on. Ditto the title. If you can describe your invention in a few words, it's almost certainly obvious.

The patent applies to things under the claims. The claims (and supporting documents) are the important parts. The rest are not really anything more than search keywords.

If you do:
cvs -u -D yesterday today {filename}
cvs will tell you what has changed in that file in the past day.

If you do:
cvs -u -d yesterday today {filename}
cvs will tell you:

cvs diff: I know nothing about yesterday
cvs diff: I know nothing about today

I think this should be song lyrics, but I can't come up with other lines.

(This is a response to an InformationWeek article. I couldn't get the comment system to work, so I posted it here instead, since I'd written it)

I switched to Linux in early '96, when Windows 3.1 wasn't meeting my needs. I think that Linux is a good choice at the point when you're going to have to put in retraining effort anyway. So long as it works, keep the same operating system. But remember that MicroSoft doesn't release new versions of most things; they change enough things that more training is required in order to use anything new.

As you said, the change between Windows 95 and Windows 98 was difficult for some users. On the other hand, since I started using Linux, there has not been a change of that sort to anything I've used, with the sole exception of Netscape.

This isn't to say that the OS hasn't made any progress; it's just that everything I've been used to having continued to work as I expected. All of the progress has been improvements which do not interfere with existing behavior: devices which didn't work now work; the system is faster and more responsive; the graphics have improved.

I think Linux is a good idea because it is Free Software, which means that you'll never have to get a new version of anything unless you want to, and because it has gotten sufficiently advanced that there will probably be ways to do everything your company wants to do. I wouldn't switch anything over to Linux if it is currently working, but I would use Linux instead of a new Windows version on new systems.

Is it just me, or are the ads just like they've always been again? I got the new pages for a bit, and then it went back to the old way.

Maybe it's just the "lite" pages.

So last night I was working on a virtual machine I've been thinking about. I took a "Beta" simulator (for a class at MIT) that I'd written a while ago, and converted it to using structs for values instead of longs. This amounts mostly to tracking down every place that a value is used (in both the simulator and the assembler) and using the value field of the variable, plus dealing more carefully with storage, and also writing functions for dealing with the simulated memory, since that's now more complicated.

I got it all written, and debugged it with some difficulty (as I'd forgotten how most of the code worked, and, when I could understand the code at a glance, I didn't have any larger-scale information, like, say, where I'd put various functions), and actually got it all working exactly like it had been before, except with the ability to eventually attach the information of my choice to every single value in the system.

I added it to my CVS repository. Then I removed a few things that I hadn't meant to add. Then I removed all of the C files. Oops.

I stared at it for a bit, and then copied the emacs backup files over, thinking I'd lost a single revision of each, which wouldn't be that much, since I'd been debugging. I set about redoing all of the remaining modifications.

Turns out that my emacs doesn't overwrite the backup files under whatever circumstances I was in, which meant that the files I had were all the originals. I then proceeded to make the sum of every single change I'd made in the previous 3 hours, by going through each file and changing everything that was not how it should be. In the process I moved and updated a function I had been considering but hadn't changed.

When I tried compiling it, it turned out that I'd forgotten to include a header file in each of the files, and I'd forgotten three ampersands.

I did the whole thing half-asleep (having already been sufficiently sleepy to delete all of the files). It took me slightly more than 45 minutes. I don't really think I could have done it if it hadn't been right after, or if I'd had to do it from scratch. But it was like if I'd taken an exam, and then had to retake it immediately afterwards, and I'd been able to give the answers word for word, except that I forgot to put my name on the pages. This from someone who can't normally remember more than one thing at a time.

It is odd that people think you'd get in trouble in the industry for taking credit for other people's code. At my job, we use CVS, and CVS @author tags give you credit for any code you modify. Of course, CVS (w/ emacs) will do things like color your files based on who wrote the current version of each line.

#!/bin/bash
# Add a file to HP/UX /var/log/omena
if grep -i 'hp/ux' `uname`; then
mv /var/log/omena /tmp/omena
for i in `cat $1`; do if [ `cat $1 /tmp/omena | grep -c $i` = 1 ]; then echo $i >> /var/log/omena; fi done
fi

Linux is like, for example, CRT technology. It's not a product; it is a technology which is in a part of products available from a number of sources. It is provided by a community of researchers, who work on the improvements they or their employers consider important.

Linux, itself, is not user-friendly; it is full of exposed wires and dials, like a CRT. Of course, you can get a case which has plugs in the back and knobs and buttons on the front: the system libraries and system utilities.

With these, you have a system which is about the equivalent of a monitor; it is reasonably friendly and easy to use, but it doesn't do anything in particular. Next you need stuff to attach to it: more libraries, standard programs, desktop environment, etc.

The user-friendliness work that's being done now is as related to Linux as VCR interface design is to CRT technology. MicroSoft essentially only sells the equivalent of TVs with integrated VCRs; Linux proper does, in fact, compete with Windows, but only with a relatively small part of it, and that is not the part that users interact with directly. And it is not, by itself, a product, so it is not marketted, nor is it (by itself) even useable by anyone but serious hobbyists. Of course, its features matter to the end user, much as the end user cares about picture quality and interference with a TV. It will not "go out of business" or "fail"; rather it may go unused for certain applications.

The real question people mean to ask is: will anyone even produce desktop software using Linux that will become widely-used? My guess is that, before MicroSoft's grip on computer users is loosened that much, the desktop metaphor will be dead. At some point, some other pattern of interaction will come into style, and MS will find that most of Windows and their other software is now outdated.

I am designing for the case where every user has a "home" machine, which has the user's files as well as the applications the user wants to use. An individual user might have multiple home machines, but has a separate identity for each. Users are sitting at either the home machine or a remote machine.

All of the configuration should be on the home machine, because the user is likely to sit down at a new remote machine frequently (i.e., go to a friend's house, and log in from there). The home machine should, however, be able to chose different configurations based on the remote machine in use, since a user will likely want a different UI depending on the speed of the connection, the capabilities of the remote machine, etc. Remote machines should be identified both individually and by negotiated features.

The interface layer will present to the application a set of capabilities which may be used. Without some capaibilities, the application may refuse to run (without graphics, an image viewer will not work), may run with limited functionality (an image editor might still let you scale or crop an image unseen), or may simply skip using the capabilities (an HTML viewer will use a label instead of graphics, or just ignore sounds).

The interface layer is intended to be "narrow", such that relaying instructions over a network connection is quick. This means both that simple commands must remain simple (e.g., "display this text"), and that a "smart" implementation must be able to indicate its cleverness (e.g., if multiple independant buffers are supported on the remote end, the application must be able to use this to switch between buffers without repainting each one).

I wish the W3C would quit breaking HTML. You'd think they'd do sensible things like not deprecating all ways of achieving a semantically meaningful effect. I just ran into this issue:

You used to be able to have an ordered list which started at whatever value you wanted. This is important if, for example, you're listing items which are in a zero-based array. Conventionally, HTML lists start with 1, so a list of items in an Java array really needs to have the starting number set; otherwise it is misleading.

Here is what the HTML 4 specification says about this situation: "Deprecated". Nevermind that this has a semantic meaning, is the only way to continue a list across intervening text (as is the standard format for, say, the field of linguistics), and cannot sensibly be done with stylesheets.

It is particularly odd that the W3C seems to do a good job with many of their standards, but their most heavily-used standard is regularly broken, such that it totally fails to serve its original purpose and cannot be used in the ay it is intended.

"Frodo, where can Gandalf be? He should be here by now."
"It seems odd that he'd disappear on a ten minute walk. Wait, do you think he meant 'Bree', with two 'e's?"
"But that's a third of the way to Rivendell! And there's a perfectly good inn right here in Hobbiton!"
"But I don't think Gandalf likes soft cheese. I think he wanted us to leave the Shire."
"Leave the... hey, look at that big guy in a black cloak. I wonder if he'd like some cheese."

Did other people notice previously that Frodo got the Ring from Bilbo on his birthday?

It would be really amusing if, after a while of being faithful to the world and to the story, and movies suddenly entirely diverged, while remaining faithful to the world.

The Company gets to Lothlorian as expected, Frodo offers the Ring to Galadriel... and she takes it and crushes Mordor.

Then the second movie involves the forces of good, including reformed orcs and trolls and the Brown Riders, fighting the dark elves of Loth Morgul and The Dark Lady.

Then the third movie involves getting the Ring, now recovered, through Mordor with just about everyone on the side of good from the previous movie trying to take it for themselves.

The current situation in academia is silly. People write papers, which may be of variable quality. In order to weed out bad ones, and, more importantly, fix ones that have problems, they are reviewed by anonymous other people in the same field, who point out problems and suggest changes. Then they are published in journals, which are read by people in the field. After this, the journals end up with the publication rights. This made sense when only journals could easily publish things, so neither the author nor the peers would have much use for the publication rights anyway. But now it is easy to publish things yourself, so the main work the journals do that the authors cannot do easily is arranging the peers.

I would like to set up a P2P system for this task. An author would submit a paper to the system, which would randomly chose reviewers, who would then get the paper and a psuedonym for giving responses. Reviewers, either anonymous or not, could sign statements about the paper which include system-wide reasons the paper is worthwhile (e.g., "This paper is correct", "This paper is inspirational", "This paper should be considered"). Once the anonymous review period had ended (either the deadline passes or all of the reviews have been submitted for a final version), the paper is published if it meets the publication criteria; it has attached the system-defined signed statements which demonstrate it as worthy of publication, and thus appear on people's lists of new papers. People could also add statements saying what they think of the paper, so that other people could essentially search for the papers a given author likes.

It would be easy to have a web-of-trust mechanism for the creation of accounts which can publish papers, can be chosen as reviewers, and can make statements in their own name. The anonymizing protocol doesn't have to be particularly robust, since the authors tend to not want to know who the reviewers are, and could probably figure it out by analyzing the style if they wanted to. The protocol would presumably avoid giving a paper to its own author, or someone from the same organization.

It seems like it would be possible to do all this with a relatively simple web+P2P app. I may sit down and write something of the sort at some point.