This goes the other way too, of course: good professional graphics applications allow you to select all common operations by just touching particular spots on the graphics tablet so the user does not have to disrupt their workflow by going to the keyboard or other ancilliary device needlessly.
Which is what I think acme does - remove the point/select/execute workflow interruptions by driving all of them to the mouse with a consistent interaction model. Although it relies on the mouse for pointing and buttons for operations, the interaction is substantially (IMO) more useful than the standard mouse interface. It does, however, require more learning to make good use of - both of the interaction, and of the composition-of-primitives approach that characterizes Unix and even more so Plan9.
I agree that laptop "mice" are just plain nasty. I carry a mouse with my laptop, and use it for anything more complex than checking my inbox.
Regarding mouse vs. keyboard efficiency: http://www.asktog.com/TOI/toi06KeyboardVMouse1.htm l is a good starting point on the mouse-speed vs keyboard-speed debate. I cringe every time I have to ^C ^V, and Tog advocates it, but the material on perceived vs real speed is worth looking at.
And I'll add that no amount of slashdot discussion can convince anyone that a radically different interaction style can be more effective. As a mouse-hater in a prior life (and still, when I have to use brain-dead environments like windows and linux that cripple it), the utility of the mouse in acme is *very* much different than you are used to. Having to touch my keyboard or pop-up a menu to cut and paste is simply criminal. Not being able to edit the past text in my command history to form a new command, then sweep to send makes me cry.
It's not a trivial interaction mode to learn, but my text editing/build/debug cycle efficiency is substantially ahead of where I was at with bash & vi.
The incredibly handy feature not mentionned is parameter passing through that click - select some text (say, a function name), and then middle click the word "break" in the window that has GDB running, and before releasing it, chord mouse button one. The function name is passed as a parameter to "break" (by plain text catenation), and then that string is submitted in the gdb window, and you have a break point.
Then once the debugging session stops and gdb says "stopped at somefile.c:43" you right-click anywhere onthe "somefile.c:43" and it pops open somefile.c at line 43. Awfully handy.
It takes a couple years of unix experience to understand how to deal with shell scripts and lots of little commands, and then about 30 days of using acme to be sufficiently sold you'll never go back to vi.
And that's because the so-called "liberal" press is all owned by wealthy conservatives?
go figure. and stuff yourself and your idea of a "liberal" press.
Acme was designed to run on old serial-line bit-blit terminals. It's incredibly conservative with it's redraw bandwidth... Crispest editor I've ever used.
That was my argument for Vi forever. It's now my #2 editor. Instead I use Acme, Rob Pike's editor from Plan9. Tiled windows, click-to-type. No cursor keys, not keyboard shortcuts. But there are a few wins. It really *uses* the mouse. Left click to point or select, right click to "find" where find means opening a file at a give line, or find the text under the mouse in the current file, run through an external processor (the plumber) that lets you write handling rules ( pointing to a word like open(2) recognizes it's a man page, and opens it in a new window). And the middle button executes text. Any text. Anywhere. And by execute that includes editor commands (Get, Put, Look, Snarf, Paste...) as well as external commands (grep, wc, make, etc). You can chord the commands to pass another text selection as a parameter. Button 1 chording makes copy and paste trivial - no keystroke involved.
It took me a couple of weeks to get used to it, but I don't ever want to go back to an editor that doesn't let me turn any random piece of text on my screen into executable functions at a touch.
But it's hard to convince people the mouse is worth it:-)
It may be clear in isolation, but a whole document like that is completely unusable. The reader simply won't put up with it; clarity is partly about the text, but mostly about ease on the reader. If a text doesn't conform to the norm, it becomes difficult to read. Same goes for excessive erudition.
The problem with your premise is that poor grammar obscures meaning. When I have to read a poorly structured sentence a second time, particularly in a technical text, I often lose track of the meaning. And technical text tends to be dense - losing even a sentence or two of meaning can dramatically reduce the utility of the document.
They do a few things in those 8 hour stretches. Some of them I know for sure, others are likely.
1. PVP rankings - it's clear that their system doesn't tabulate PVP rankings on the fly. I suspect the whole ranking system runs as a big select/join over the database of players, and that it just won't run online when the DB is being changed. You could go through the effort to do it, but it's not easy to get right, and this "solution" works now.
2. DB compaction - the back end of these games is a large transactional database, but usally homebrewed instead of using, say, oracle. It's easy to design it so that you need to do substantial database clearing and compaction on a regular basis. Again, you could do this live, but it's harder to get right.
3. Patches and content updates - same thing.
You get a lot of this stuff closer-to-right after your first MMOG - it's a much more daunting problem than it first appears to be.
Hate to remind you, but the majority of casualties in Iraq is to Iraqi citizens, largely due to the total absence of security and stability in their country. Casualties in tanks are few in Iraq.
Or you could just put another gig of ram in your PC. Odds are low that a slow, awkward 256meg of RAM will be useful for anything. Maybe a ramdisk, but even then it's tiny.
You want two phones, plus the radio, so that each is continously transmitting - transmitting is the key part, since that's the only time it's putting out anywhere near the required power. You could use one phone if you had something else to dial to, but with only half the power.
I might try this once I slip into free evening minutes...
No, it doesn't; the ReadyNAS doesn't have the horsepower to transcode on the fly, unfortunately.
What we need to do is get Squeezebox to support AAC.
It does do Ogg though...
I have the ReadyNAS x6, and I love it to pieces. It just sits there and serves my media (runs SlimServer out to my Squeezebox, no more PC involved). It's been up a couple of months with no problems at all, although I'm starting to fill up.
For backups I run some nice Plan 9 magic - the Venti archiving file server. No-hastle incremental backups, snapshots of previous days, identical-block compression, and so on. It's been ported to Unix (and so runs on my Mac), and provides more peace of mind (coupled with the raid) about my data than I thought possible.
They target groups of people who have no direct power to affect the change the terrorists want, hoping that the political pressure will lead to the desired effect. The acts are 'random' in the sense that there it doesn't matter who gets killed, so long as someone does; in many ways it's more important that the acts be random, so that the population can't tell itself 'they only target those people'.
It's difficult to keep in perspective how little damage terrorism does, yet how effective it is at swaying public opinion.
Yes, I agree; but there is *no* tactical gain in blowing up buses, unlike PETA fictionally going after stoat farmers. The gains(?) from blowing up buses is about increasing fear levels throughout to apply political presure. In the later case, it's about getting stoat farmers to stop farming.
Slashdot Mirror
Which is what I think acme does - remove the point/select/execute workflow interruptions by driving all of them to the mouse with a consistent interaction model. Although it relies on the mouse for pointing and buttons for operations, the interaction is substantially (IMO) more useful than the standard mouse interface. It does, however, require more learning to make good use of - both of the interaction, and of the composition-of-primitives approach that characterizes Unix and even more so Plan9.
Regarding mouse vs. keyboard efficiency: http://www.asktog.com/TOI/toi06KeyboardVMouse1.htm l is a good starting point on the mouse-speed vs keyboard-speed debate. I cringe every time I have to ^C ^V, and Tog advocates it, but the material on perceived vs real speed is worth looking at.
It's not a trivial interaction mode to learn, but my text editing/build/debug cycle efficiency is substantially ahead of where I was at with bash & vi.
Then once the debugging session stops and gdb says "stopped at somefile.c:43" you right-click anywhere onthe "somefile.c:43" and it pops open somefile.c at line 43. Awfully handy.
It takes a couple years of unix experience to understand how to deal with shell scripts and lots of little commands, and then about 30 days of using acme to be sufficiently sold you'll never go back to vi.
Please name this magical service that we in the unwashed masses may also benefit.
Love SkypeOut, but it has serious limitations.
And that's because the so-called "liberal" press is all owned by wealthy conservatives? go figure. and stuff yourself and your idea of a "liberal" press.
I'm betting the side with the shortest queues wins more BGs. Practice makes perfect, and getting to play 2-3 times as often will do wonders.
Acme was designed to run on old serial-line bit-blit terminals. It's incredibly conservative with it's redraw bandwidth... Crispest editor I've ever used.
It took me a couple of weeks to get used to it, but I don't ever want to go back to an editor that doesn't let me turn any random piece of text on my screen into executable functions at a touch.
But it's hard to convince people the mouse is worth it :-)
It may be clear in isolation, but a whole document like that is completely unusable. The reader simply won't put up with it; clarity is partly about the text, but mostly about ease on the reader. If a text doesn't conform to the norm, it becomes difficult to read. Same goes for excessive erudition.
The problem with your premise is that poor grammar obscures meaning. When I have to read a poorly structured sentence a second time, particularly in a technical text, I often lose track of the meaning. And technical text tends to be dense - losing even a sentence or two of meaning can dramatically reduce the utility of the document.
They do a few things in those 8 hour stretches. Some of them I know for sure, others are likely. 1. PVP rankings - it's clear that their system doesn't tabulate PVP rankings on the fly. I suspect the whole ranking system runs as a big select/join over the database of players, and that it just won't run online when the DB is being changed. You could go through the effort to do it, but it's not easy to get right, and this "solution" works now.
2. DB compaction - the back end of these games is a large transactional database, but usally homebrewed instead of using, say, oracle. It's easy to design it so that you need to do substantial database clearing and compaction on a regular basis. Again, you could do this live, but it's harder to get right.
3. Patches and content updates - same thing.
You get a lot of this stuff closer-to-right after your first MMOG - it's a much more daunting problem than it first appears to be.
Certainty of being caught is a good deterent.
Prevention works even better.
But punishment satisfies man's need for revenge and so will continue to be the first response.
I said nothing about the cause of the lack of security, merely asserted it's existance.
Hate to remind you, but the majority of casualties in Iraq is to Iraqi citizens, largely due to the total absence of security and stability in their country. Casualties in tanks are few in Iraq.
Or you could just put another gig of ram in your PC. Odds are low that a slow, awkward 256meg of RAM will be useful for anything. Maybe a ramdisk, but even then it's tiny.
Limbo, its language, is c-derived, but safe. The network model makes sense. And it's mature as an embedded platform.
A European or an African swallow? Or maybe an albatross?
I might try this once I slip into free evening minutes...
We already have White Anglo-Saxon Protestant zombie-herding overloads...
No, it doesn't; the ReadyNAS doesn't have the horsepower to transcode on the fly, unfortunately. What we need to do is get Squeezebox to support AAC.
It does do Ogg though...
For backups I run some nice Plan 9 magic - the Venti archiving file server. No-hastle incremental backups, snapshots of previous days, identical-block compression, and so on. It's been ported to Unix (and so runs on my Mac), and provides more peace of mind (coupled with the raid) about my data than I thought possible.
It's difficult to keep in perspective how little damage terrorism does, yet how effective it is at swaying public opinion.
Yes, I agree; but there is *no* tactical gain in blowing up buses, unlike PETA fictionally going after stoat farmers. The gains(?) from blowing up buses is about increasing fear levels throughout to apply political presure. In the later case, it's about getting stoat farmers to stop farming.