Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Decisions and revisions that a minute can reverse

By madams in News
Thu Jun 01, 2000 at 10:26:52 PM EST
Tags: Software (all tags)

There is an adage that says something isn't a mistake until you are given an opportunity to fix it. In modern parlance, we might say that something isn't a mistake until one has the opportunity to undo it. Indeed, the undo function has done wonders for human fallibility. Mistakes can be corrected and wrongs reversed in a heartbeat.

But all is not rosy. In a recent Salon article, Undo me!, Simson Garfinkel explores just what's wrong with current implementations of undo.

Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
Garfinkel points out that in the habitual use of interfaces users can make irreversable mistakes. In his example, he lost the minutes he was keeping while attempting to beam them to someone else. He mindlessly clicked OK button on his Palm Pilot, assuming that the device was confirming that he wanted to transmit the document. Instead, he had clicked the delete memo option. Poof!

The problem, as Garfinkel says, is that the undo function is inconsistent or incomplete across the various levels of an operating system. For example, undoing a Script-Fu in The Gimp does not reverse the entire operation, just the last command in the script. I don't know of any operating systems where a delete file command is undoable without special tools (and even these are not guaranteed to work).

One step to fixing these problems is for OS and application programmers to rework how their undo function works. But the best solution is the most difficult and probably the most unlikely. Undo should be built into the operating system. Actions performed by the OS and applications can be registered as atomic events. All the operations performed by a Script-Fu, for instance, would register as one event. The OS could then keep track of the events and the changes they make to data. However, it is unlikely that such functionality could be built into current operating systems since it changes the way in which applications interact with the OS.

But some actions cannot be undone (reformatting a hard drive and sending an email come to mind). For these, we can rely on old human techniques of shame and humility.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Salon
o Undo me!
o Also by madams

Display: Sort:
Decisions and revisions that a minute can reverse | 37 comments (37 topical, editorial, 0 hidden)
Intresting concept, more write up w... (1.50 / 2) (#5)
by SgtPepper on Thu Jun 01, 2000 at 04:06:58 PM EST

SgtPepper voted 1 on this story.

Intresting concept, more write up would be even better. Perhaps a detailed theroy on the OS mentioned in the article. How it would work, etc.

Interesting, except for the mistake... (1.00 / 1) (#8)
by jhillyerd on Thu Jun 01, 2000 at 04:15:28 PM EST

jhillyerd voted 1 on this story.

Interesting, except for the mistake at the end.

Could a journalling file system be ... (5.00 / 1) (#4)
by marlowe on Thu Jun 01, 2000 at 04:19:27 PM EST

marlowe voted 1 on this story.

Could a journalling file system be leveraged to allow undo of file operations? How about integrating concepts of version control into the file system? With version control, you can undo by backing out versions that you look at, just by editing your view's config spec (Clearcase terminology). And you can undo the undo (meta-undo?) because the newer versions will still exist. Or if putting all this into the file system is too much trouble, we could put it into a library that we could link into applications. Also, we could use a file version attribute to denote discard eligibilty. After all, once the hard drive fills up, we'll have to start deleting stuff for real. And when versions get archived, it would be nice if the file system can "know" which backup set on which tape it wound up on, so restores can be made semi-automatic.
-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --

JFS -- a different level of committment (3.50 / 2) (#16)
by kmself on Thu Jun 01, 2000 at 11:24:12 PM EST

Guy thing, you know.

The way I understand a JFS, its "undo" is an ability to roll back a transaction, though how far back this ability tracks I'm not sure. Essentially the idea is that the state of the filesystem is never ambiguous, and that a partially committed transaction can be rolled back to a known good state. This isn't the same as the ability to roll back to an arbitrary known good state.

That aside, a journaling or transaction based system would respond to most of the issues that Garfinkel raises, though not the way he's suggesting them. This isn't the sort of thing that's built into an operating system, it's a database capability (though it's been argued that a database has many of the same capabilities as an OS, and Oracle's "Bare Iron" or whatever Larry's fetish of the week is would in essence be the OS).

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

Okay, so how about something in between applicatio (4.00 / 1) (#24)
by marlowe on Fri Jun 02, 2000 at 10:03:10 AM EST

Have a shared library that exports a file/version management interface, which applications can then run on top of. This would provide:

1. Versioning
2. Labels
3. A concept of a view, like in Clearcase.

What apps would use this? Pretty much anything that wants to work with persistent documents. But I'd start with development tools, since there the need is most obvious. Have editors and build tools that run on top of this INSTEAD of having a separate version control system. Integration, if done well, can make such operations less clunky and error prone. (Integration done badly is the Microsoft way. I hope everyone can appreciate the distinction. Hint: modularity. Another hint: interface abstraction.)

Oh, and so no one has an excuse to whine about the inconveneince of changing over, make sure there's an automated way to import from everyone's favorite version control systems to this.

--- I will insist on my right to question ---
-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
Re: Could a journalling file system be ... (3.50 / 2) (#25)
by jonr on Fri Jun 02, 2000 at 10:05:40 AM EST

I remember years back, Parc had the "Wall of time" concept. The user could move back (and forth) in time and browse events and documents. Deleted that email from your boss? oops, just go back 5 minutes and there it is. Of course, then your report would be 5 minutes old too. Parc even had the "Wall" look like a wall, with "graffiti" on showing when files are created/editet/deleted, sorta 3D log. J.

[ Parent ]
Re: Could a journalling file system be ... (3.00 / 1) (#33)
by Anonymous Hero on Fri Jun 02, 2000 at 02:11:58 PM EST

No one here seems to be old enough, or even reading alt.folklore.computers -- basically, many operating systems of old did have versioned file systems. I suppose the only such system surviving today is VMS. And file versions are still in the Common Lisp standard :)


[ Parent ]

Interesting and good writeup... (1.00 / 1) (#6)
by puppet10 on Thu Jun 01, 2000 at 04:39:14 PM EST

puppet10 voted 1 on this story.

Interesting and good writeup

I can see where this will lead... M... (3.30 / 3) (#3)
by skim123 on Thu Jun 01, 2000 at 04:43:57 PM EST

skim123 voted 1 on this story.

I can see where this will lead... Micrsoft builds an Undo option into Windows... five years later they are being sued for integrating Undo with the OS! :-)

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum

Recycle Bin? ... (4.00 / 1) (#9)
by pin0cchio on Thu Jun 01, 2000 at 05:55:16 PM EST

pin0cchio voted 1 on this story.

Recycle Bin?

Seriously, Mac OS was the first popular system whose delete file command could be undone. When you drag a file to the (Macin)trash can, it is moved to a temporary folder and not actually deleted from the drive until the user empties the trash can. So good, Windows had to copy it (Recycle Bin).

Re: Recycle Bin?... (none / 0) (#18)
by HiRes on Fri Jun 02, 2000 at 12:17:43 AM EST

So good, Windows had to copy it (Recycle Bin).


wait! before you rate, read.
[ Parent ]

Get it right the first time!... (3.00 / 2) (#11)
by Zach on Thu Jun 01, 2000 at 05:56:41 PM EST

Zach voted -1 on this story.

Get it right the first time!

Anyone who quotes TS Eliot RULES!!!... (3.00 / 1) (#1)
by Paul Dunne on Thu Jun 01, 2000 at 06:39:37 PM EST

Paul Dunne voted 1 on this story.

Anyone who quotes TS Eliot RULES!!!

Naw... (none / 0) (#15)
by kmself on Thu Jun 01, 2000 at 11:17:15 PM EST

...nothing but an old man, a dull head among windy spaces.

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

The last time Garfinkel had a gripe... (2.80 / 4) (#10)
by mr on Thu Jun 01, 2000 at 06:44:58 PM EST

mr voted -1 on this story.

The last time Garfinkel had a gripe I saw was when he complained about how computers (UNIX) could be attacked with a DOS. I make the same suggestion then as now. You don't like how the undo works, re-code it and show us all how it should be done.

<rant>I have had to implement an... (3.00 / 1) (#12)
by semis on Thu Jun 01, 2000 at 07:39:00 PM EST

semis voted 1 on this story.

<rant>I have had to implement an undo functionality into a large piece of software. Inconsistencies are generally because of bad design. From my experience, if you want functional and predictable undo behaviour, it MUST MUST MUST MUST be in the initial design. I had the misfortune of trying to do this to software which initially didn't consider undo's. It wasn't easy. I ended up just serializing the objects on every operation, and reverting to them on "undo". Not nice. </rant>

oops, I meant -1 :)... (3.70 / 3) (#2)
by davidu on Thu Jun 01, 2000 at 08:34:10 PM EST

davidu voted 1 on this story.

oops, I meant -1 :)

Interesting. I think in general dev... (1.00 / 1) (#7)
by DemiGodez on Thu Jun 01, 2000 at 09:51:59 PM EST

DemiGodez voted 1 on this story.

Interesting. I think in general developers need to be more aware of UI issues.

Heh... (3.00 / 1) (#13)
by Ranger Rick on Thu Jun 01, 2000 at 10:41:56 PM EST

Funny how this one sentence jumped out of the page at me:

Although this shouldn't be hard to do in principle, in practice it enforces a discipline that few of today's programmers are up to.

Um... if you don't want to bother with the discipline, what are you doing coding on that app in the first place?!


Palm Undo (4.00 / 1) (#14)
by dmkanter on Thu Jun 01, 2000 at 11:13:38 PM EST

After checking the difference between how the beam and delete functions are handled in Palm OS, beam actually begins beaming memos without a dialogue box, while delete at least asks you to confirm delete. You can also opt to have all deleted memos, todos, datebook, and address entries archived on next sync, which is probably the closest the palm comes to an undo. Using the command shortcuts is also useful because you have the write a graffiti "B" to beam and graffiti "D" to delete. Launcher III for Palm also has the delete and beam a little too close for comfort. I am always I worried I will delete an application rather than beam it to a friend. Perhaps a separate icon for beam and delete might be a good enhancement. Palm OS needs to have a better undo, implemented more consistently across the entire OS while still keeping as much memory available to the user as possible.

Re: Palm Undo (none / 0) (#34)
by fluffy grue on Fri Jun 02, 2000 at 06:24:17 PM EST

Yeah, I immediately noticed that flaw in the rant^H^H^H^Harticle too (that beam doesn't have confirmation). It'd be nice if PalmOS let you recover archived-deleted memos though. Also, he points out that it isn't due to the Palm's limited amount of memory - but it IS due to the Palm's limited amount of memory.

So, how's Hong Kong without me?
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: Palm Undo (none / 0) (#36)
by dmkanter on Sun Jun 04, 2000 at 06:40:51 AM EST

Hong Kong will never be the same

[ Parent ]
Garfinkel's problems (3.70 / 3) (#17)
by kmself on Thu Jun 01, 2000 at 11:41:05 PM EST

I see a number of different problems listed in Garfinkel's story, which are actually quite distinct, though they share one common attribute: data loss.

In his Palm example, the problem IMO is a lack of a more centrally integrated "beam" function. I was listing the killer features of my Palm IIIx to a co-worker. Size/weight aspects blow doors on a paper planner. Cryptinfo knows more about me than I do (secure data/password storage). And beaming rocks.

The problem is that there's no "beam me" button on the Palm. There really needs to be one. And yes, it should have a confirm button, 'coz you don't want to be randomly beaming corporate secrets or your little black book....

Dialogs suck. But how else are you going to talk to people? I prefer the more minimalist (and flexible) interface of the command line, but I build things into my environment -- shell prompt lists userid and host, terminal window ditto, root is bolded -- and sit on my hands before hitting Enter on a lethal command. That's just training (and experience ;-)

Marlowe's journaling file system suggestion (JFS) is good, but JFS is rather more limited than what we're looking for. Rather, what you want is some ongoing versioning system for everything you do. Sort of like saving state within a given application every minute or so, then gradually dropping snaptshots as time passes -- say 60 second snaps for ten minutes, 10 minute snaps for an hour, 1 hour snaps for a day, one day snaps for a week,.... A year's worth of work would be 79 snapshots. In a diff format, the dataload could be manageable.

Garfinkel is dead wrong when he classes this as an OS issue. These sorts of problems are a data management system issue, but that's not a level of complexity you want, or need, to deal with at the OS level. Yes, a system of data storage and versioning, but as an applicaiton layer with which other applications can interface. System-level information itself could be managed through this interface, but as another form of versioned information, not as an OS-level interface.

And so, information becomes timeless, or as Tom Stearnes might say:

After such knowledge, what forgiveness? Think now
History has many cunning passages, contrived corridors
And issues, deceives with whispering ambitions,
Guides us by vanities.

$0.02, less in some markets.

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.

How to create a "Beam Me" button on the (5.00 / 1) (#27)
by sethg on Fri Jun 02, 2000 at 11:35:12 AM EST

Go to the home page and tap "Prefs". Select "Buttons" from the drop-down list in the upper right. Tap the "Pen..." button. You will get a dialog box saying:
Select a feature you can access by dragging your pen from the writing area to the top of the screen.
One of the options on the drop-down list is "Beam Data".

[ Parent ]
Palm rant (none / 0) (#35)
by kmself on Sat Jun 03, 2000 at 09:00:55 PM EST

Ok, I checked into this. "Dragging the stylus" by default provides graffiti help. I didn't even know this was a configurable behavior.

I'll stick to my earlier rant -- beaming is sufficiently key to Palm actions (and something you want to be able to do quickly and simply in many situations) that the functionality should be both standard and very immediately available. The dragging stylus option is helpful, but not quite sufficient IMO -- graffiti help is something you also want ready access to in the middle of composing a note or other entry.

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

Bigger problem than Undo (4.00 / 2) (#19)
by HiQ on Fri Jun 02, 2000 at 04:42:59 AM EST

While this article focusses on the undo feature, it touches upon a more fundamental problem: bad GUI design. As I stated in earlier postings, *all* current GUI's suck! (yes, even the Mac). If you take the Mac, or Windows, or KDE or Enlightenment, they are all based on the same principles.

Inoshiro pointed out a great document about alternative GUI's:   The Anti-Mac interface .
In my spare time, I'm working on a GUI that is based on the same kind of principles as described in this document. Some highlights:

  • No windows - although it's possible to run multiple applications and show these on the screen simultaniously (I'm working on an interface that looks a bit like the computers used in Star Trek)
  • Minimize use of the mouse - use language to control the interface (spoken or command-line)
  • Hide system from user - the user should be able to focus on the job, and not operate a computer (formatting, organizing disks, browsing networks - all these things should be transparent)
  • More intelligence in applications & the OS (users are stupid, let the computer assist a bit more)
  • Etc
Sorry, no workable demo yet, still in design phase.
How to make a sig
without having an idea
just made a HiQ
Could you mock up some screen shots? (4.50 / 2) (#28)
by marlowe on Fri Jun 02, 2000 at 11:52:54 AM EST

That would help give a clearer idea of just where you're going with this.

I never much cared for the messy desk metaphor myself. But whenever I try to come with an alternative, I can never quite envision something that would be an uncontestible improvement. I like full screen. I like taskbars (but not mutiple desktops). But there times when I just want to drag and drop between two windows. Maybe if we had something like the Mac Finder, but all contained in its own full-screen window, which would be underneath the window manager. Think of it as demoting the desktop instead of firing it.

Oh, and try to make this new GUI an X window manager, so we don't have to throw out our old apps. It's okay if every "window" is alway either "iconic" (not shown as such) or "maximized" (using all of the screen that it can). But please don't neglect backward compatibility.

--- I will insist on my right to question ---
-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
Re: Could you mock up some screen shots? (none / 0) (#37)
by HiQ on Sun Jun 04, 2000 at 12:27:27 PM EST

I'm still designing it & philosophizing about it; I do this in my spare time, which is something I don't have a lot of. During the day I am a system architect, and this takes up a bit more than 8 hours a day. But if I'm sufficiently far, I will post an article about it. First comes the design, than I'll try to make a demo first, to see if it all works out. Then, if I still got some breath left, I will try to go for building the darn thing.
How to make a sig
without having an idea
just made a HiQ
[ Parent ]
eliot (2.00 / 1) (#20)
by sar on Fri Jun 02, 2000 at 05:00:57 AM EST

Eliot rocks.
geek poet.

Undo is not a killer-app (3.50 / 2) (#21)
by pacc on Fri Jun 02, 2000 at 07:51:52 AM EST

There are examples of applications with descent undo, take Photogenics which lets you paint an image and then change the brush later to alter the pictures outcome.

This is nothing new, you can define templates in word to later change every subtitle's look, but the problem with word is that it is possible to hardcode styles and even remove template-definition beyond the rescue of an undo. What's really needed is a strict rule that won't allow operations which can't be undone or altered later, but we all know that for example word is designed reversed - with the hard operations as buttons in the GUI and the abstract meaningful operations deeply hidden. Undo is just not a feature you look for when you buy anything.

Squeak does this. I think. (3.00 / 1) (#22)
by saw2th on Fri Jun 02, 2000 at 08:00:27 AM EST

By coincidence I was looking at the squeak smalltalk environment last night.

From the Squeak readme file:

"Image File All of the objects -- classes, dictionaries, windows and other objects that make up the Squeak environment are stored in an image file (this must always be named 'SomeName.image'). For this reason, when you start up an image, everything is right where you left it when you last saved the image.

Sources and Changes For various reasons, the source code associated with the image is stored in two other files. The code of the system as originally delivered (vers 2.0) is stored in the file 'SqueakV2.sources', and the sources for everything done since that time is in the changes file (which must similarly be named 'SomeName.changes').

Storing the source code in a separate file has several advantages. To begin with, if you have been working for a couple of hours, and your dog rolls over the power cord, you will still have a sequential record of all your program edits, and these can be perused and replayed with numerous tools such as changes: post-snapshot log. This feature has also saved many a hacker who got too adventurous in changing the system he or she was using."

The right way to do undo (4.00 / 1) (#23)
by Paul Dunne on Fri Jun 02, 2000 at 09:32:40 AM EST

nvi is the only program I know that does undo the right way. At any time, you can hit `u' to undo what you just did. Hitting `.' after such an undo, undoes the change before that as well. So you can cycle back through all the changes, right back to the original document. If you've gone too far, just undo the latest undo by hitting `u' again. Same principle then applies -- you use `.' to walk forward through your changes to the latest change.

Of course, this doesn't help if you quit nvi and delete the file...

A monumental task (3.00 / 1) (#26)
by Obiwan Kenobi on Fri Jun 02, 2000 at 10:42:47 AM EST

It's apparent that such an undertaking would have to be there from the beginning of the coding process. It would also become such a complete HASSLE. Not to mention the ungodly amount of RESOURCES it would require. Can you imagine an OS that had a simple 25-level undo? Think of everything you could do in twenty-five commands. Delete a file, install a program, uninstall the program, add a device, recompile a kernel, then rm -rf everything. How could an OS recover from that, undo or not? Undo is for people who simply DON'T PAY ATTENTION. If you don't look at what you're doing, you're going to have a lot more problems than what you can or can't undo.
misterorange.com - The 3 R's: Reading, Writing, and Rock & Roll...
Re: A monumental task (none / 0) (#30)
by warpeightbot on Fri Jun 02, 2000 at 12:31:11 PM EST

Darn it, he stole my rant!

One of my biggest headaches as a (very former) VMS sysadm is going around and cleaning up all the old versions of files, often Very Large, that folks would leave floating around on the drives. (VMS, for the uninitiated, has automatic versioning of files) One of the biggest headaches I now have as an applications support critter is old versions of shared libraries floating around on the disks and screwing up my application integration. The idea of an OS-integrated multifarious UNDO operation is so evil even Redmond couldn't come up with it. (Frankly, it smacks of the whole idea of zero personal responsibility that is so prevalent these days, but that's a whole 'nother rant....)

Bottom line is, Simson Garfinkel needs to Get Over It.... or go run Windows Umpteen Zillion, which will probably have that functionality (and his PDA will weigh 45 pounds and have both an air bag and a safety belt in addition to the proximity warning alarm...)

I'd like to find your inner child,
and kick its little ass!
-- Eagles, "Get Over It"

[ Parent ]

Journal Files (none / 0) (#29)
by w3woody on Fri Jun 02, 2000 at 12:01:28 PM EST

But some actions cannot be undone (reformatting a hard drive and sending an email come to mind). For these, we can rely on old human techniques of shame and humility. The thing is, if we only protect actions which are not reversable with a verification dialog box, as those dialog boxes will be rare, they may cause the user to stop and actually read the box. This strikes me as a good argument for using transaction-based processing throughout the entire operating system, with an extensible journaling log file which can be used by the operating system for a system-wide "undo" feature which simply rolls back the log file. I could see how such a feature would be added: each application would register it's actions with a journal API, and would need to provide an "undo" event which would process rollback events from the journal. That way, when the user hits "undo", his actions can be rolled back fairly easily. Further, by keeping this journal API system-wide, actions which affect multiple applications on the same system (such as global cut and paste actions) can be rolled back across those multiple applications in a way that appears "atomic" to the user. But that's just my two cents worth...

I think this IS an operating system level consider (3.50 / 4) (#31)
by Alhazred on Fri Jun 02, 2000 at 01:07:27 PM EST

Think about it. A user's concept of what constitutes a "logical unit of work" which they might want to roll back can encompass a LOT of territory and varies highly with context. When your installing a new RPM going backwards can consist of undeleting files, undoing changes in databases, altering filesystem metadata, etc. On the other hand undeleting a sentence in your word processor is a totally different thing, that involves changing some data in memory. However even in that case some of the changes may be to resources shared with other applications, like the clipboard.

Furthermore in a distributed environment, especially where collaboration is a consideration there are even more issues involved. In that environment we have to start worrying about the SCOPE of changes, and of course the fact that once a change is made to a shared resource that it is quite likely that undoing it would now involve informing other systems of what we're doing. Then we start to deal with race conditions and complex dependency conditions (what happens when you change a perl script, then a guy on another machine RUNS the script, and then you alter it. Should the results of its run on the remote system be altered too?).

And on top of all that there are the considerations involved with advanced forms of storage architecture like hierarchical storage systems. Keeping the logs is going to require a LOT of storage, and managing them is going to require a lot of work too.

All of this militates towards a VERY low level integration of these functions into the operating systems core functionality itself. Nothing short of that is going to do the trick.

Just thinking about this whole thing briefly indicates to me that what would be required is that for every operation performed every bit of data that changes needs to be stored somewhere, and the PERSISTENCE and SCOPE of the change needs to be recorded as well. Then changes need to be grouped into logical contexts which make sense to end users. These logical contexts then need to be ordered together into some form of dependency/scope map which tells us which changes overlap and how, and who needs to know about them and who needs to know if they are reversed.

Overall there is not going to be a perfect solution, but in theory at least a large class of changes CAN be undone. Personally though I won't be holding my breathe waiting for such a major revolution in OS design. At best it will take decades.
That is not dead which may eternal lie And with strange aeons death itself may die.
Security Issues with Super-Undo in the Operating S (4.00 / 2) (#32)
by sjanes71 on Fri Jun 02, 2000 at 01:08:24 PM EST

Some where, some place, the information has to be stored somewhere.

Imagine writing up your résumé and printing it out on your employer's computer. Weeks later, your manager borrows your machine to write up a quick document... and a few minutes figiting with your undostream... your manager now has an excellent reason to make your life a living hell.

Send a quick e-mail to your lover who happens to not be your SO. You might have "taken precautions"... by encrypting your e-mail to (Other)SO, but somewhere lurking on your system is the undostream of hot and heavy virtual breathing that isn't "protected" by your cryptocondom.

Don't get me wrong-- Undo is useful, just make damned sure you make a facility for irrevocably undoing the undostream--- odnu, or odnuing. Odnuing would then become the only operation protected by an "ARE YOU REALLY SURE?" dialog making computers easier to use.

Even then, with odnu, there's still the problem of explaining the 18˝ minute gap in your undostream you'll need to deal with afterwards. :)

Simon Janes
Decisions and revisions that a minute can reverse | 37 comments (37 topical, 0 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!