[null, null, null, null, null, null, null, null, null, null, null, null, null, {"document_url": "http://waynewerner.blogspot.com/2010/", "unformatted_src": "http://3.bp.blogspot.com/_Mn-fd94Top0/TOB5UNoU4zI/AAAAAAAAAB4/VdzxcLNDXCk/s320/audacious-ss.png", "src": "http://3.bp.blogspot.com/_Mn-fd94Top0/TOB5UNoU4zI/AAAAAAAAAB4/VdzxcLNDXCk/s320/audacious-ss.png", "formatted_filename": "audacious ss"}, null, null, null, null, null, {"document_url": "http://waynewerner.blogspot.com/2010/", "unformatted_src": "http://4.bp.blogspot.com/_Mn-fd94Top0/TDi7PLCBjOI/AAAAAAAAABE/LSENxQfNwSs/s320/Photo0002.jpg", "src": "http://4.bp.blogspot.com/_Mn-fd94Top0/TDi7PLCBjOI/AAAAAAAAABE/LSENxQfNwSs/s320/Photo0002.jpg", "formatted_filename": "Photo"}, null, null, null, null, null, null]


Response to a Comparative Study

A study was performed to try to compare vi and emacs, and on the surface seems to be a rather good study, unfortunately the author's bias (or perhaps just ignorance) introduced errors into the study. I will endeavor to expose those errors here. The entire text of the study will be presented, along with any criticisms that I have.


(author: William Knottenbelt - email@example.comfirstname.lastname@example.org)


The editors vi and emacs were compared using a simple time-based
experimental method involving common text manipulations and a post-
test opinion survey by questionnaire. The subjects were twelve
students; six were novices and six were regular users. Significant
objective performance differences were confined to the novice users;
here emacs consistently outperformed vi with respect to time taken to
perform the tasks and the amount of help needed. Subjectively, novices
preferred emacs because of its more predictable nature. Emacs was
therefore the editor of choice for the novice users tested. There
appears to be no advantage for a regular user of one editor to switch
to the other.

We'll see later that the bias/ignorance caused much of the preference for emacs.


A text editor is an essential tool in virtually every computing
environment since a large proportion of a user's time is likely to be
spent in editing documents or writing program code and job control
files. Intense and sometimes emotional "my-editor-is-better-than-your-
editor" debates are common in computer discussion groups. One
perennial bone of contention concerns the qualities of "vi" and
"emacs" - both popular and widely-used UNIX editors. Published formal
studies of text editors [eg. 1] tend to be very complex, and few, if
any, have specifically addressed the "vi"/"emacs" controversy. Other
informal studies on this subject [2] have generally been anecdotal,
reflecting the personal experience of the author, rather than being
objective reviews. This study attempts to compare the performance of
"vi" and "emacs" in our local environment in a simple but scientific


A controlled experiment was determined to be the best means of
objective comparison. The design was in keeping with the limited
resources available so methodology involving in-depth analysis of
functionality and specialized techniques such as real-time keystroke
recording were avoided. Instead, the final design was simple enough to
be implemented by two observers with stopwatches.

Twelve subjects were used in the experiment - six novices and six
skilled regular users. Three of the novices were "non-technical"
novices who had little or no computing experience and no experience of
either vi or emacs; the other three novices were "technical" novices
who had substantial computing experience but little or no experience
of either vi or emacs. Since all the novices had similar experience
with vi and emacs, useful comparisons could be made by testing their
performance with both editors; on the other hand, each of the regular
users was tested only on his/her editor of choice.

Each subject was asked to perform some common text manipulation tasks
on an extract from Sue Townsend's Diary of Adrian Mole. These included
text entry, insertion and deletion of characters, words and sentences,
searching and replacing, and transposition of paragraphs (see Appendix
A for the complete task list, starting text and target text).

All tests were conducted individually on a user/observer basis. The
subject was told that the editor, rather than the subject, was being
tested and that he/she was free to quit at any time if he/she became
uncomfortable. The subject was then given a copy of the task list and
a help sheet containing relevant commands for each editor (see
Appendix B). Each task was explained and questions were answered.
During the observation, the time for each task was noted, as well as
the amount of time spent looking for help and the number of times help
was needed.

Novices used the editors in randomized order (determined by the toss
of a coin) and performed the set of tasks twice so that some idea of
learning curves could be obtained. Skilled regular users were only
required to perform the tasks once.

After completing the tasks, subjects completed a questionnaire asking
them to rate the editors based on six criteria, viz. consistency,
feedback, friendliness, learnability, usability and efficiency. They
were also asked to give details of any problems or frustrations they
experienced, as well as any features they liked (see Appendix E for
the full questionnaire).

Trial runs of the experiment were performed on both editors. No
problems were found with vi and all tasks could be performed
successfully. However, some problems, all caused by terminal
peculiarities, were experienced with emacs. In particular, backspace
did not work, the cursor keys did not work and Ctrl-s could not be
used (it is used for XON/XOFF flow control). Investigation revealed
that the ibm3151 terminals we use are not supported by emacs; when
emacs was run on a more common vt100 terminal, everything worked
correctly. However, emacs on-line help gives full details to enable
system administrators to have emacs support any particular terminal
type without user intervention. So as not to penalize emacs for this
administrative oversight, emacs was minimally customized to emulate a
proper working setup on our terminals. (* the error was reported by
the author and emacs has now been correctly set up for use with our

To statistically compare the editors with regard to the total time
taken to perform the tasks and the time spent looking for help,
appropriate t-tests for dependent or independent samples were applied.



Appendix C contains a complete summary of the times taken to complete
the tasks. The statistical analysis of the results is given below:

| HYPOTHESES | Non. | Tech. | Reg. |
| (Objective testing) | Tech. | Nov. | User |
| First trial: emacs faster than vi | Yes+ | Yes+ | No |
| Second trial: emacs faster than vi | Yes* | Yes+ | N/A |
| Less help required with emacs | Yes+ | Yes+ | No |
| Text entry faster with emacs | Yes* | Yes* | No |
| Text manipulation faster with emacs | Yes+ | Yes* | No |
Non. Tech. = Non-technical Novice + p<0.05 * p<0.01
Tech. Nov. = Technical Novice
Reg. User = Skilled Regular User

The mean improvement in time taken by novices between the first and
the second trials for each editor (expressed as a percentage) was also

| Non-technical Technical |
| novices novices |
| vi 39 +/- 4 % 28 +/- 5 % |
| emacs 27 +/- 6 % 21 +/- 8 % |


Appendix D contains summarised results of the questionnaire. Although
differences in subjective scores were not significant on testing, each
editor came in for some criticism and some praise.


The main difficulties novice users found with vi were:
- editor modes were hidden resulting in apparent unpredictability
- backspace worked only on newly inserted text and did not update
the screen accurately
- using ESC x to delete a character appeared to be unpredictable -
most novices could not apparently tell whether the character
to the left of the cursor or the character under the cursor
would be deleted (see discussion below)
- case-sensitivity of commands caused some confusion
- cursor keys could not be used to get right to the end of a line or
right to the end of a document
- non-technical novices found it very clumsy

Positive features appreciated by novice users were:
- the undo feature
- commands could be backed out of at any time by pressing ESC
- technical novices thought it had potential to be efficient

Regular vi users felt:
- vi was fast, powerful and efficient
- although vi had some "quirks", they were not a nuisance as one
got used to them very quickly
- the command structure of vi was logical and intuitive
- vi's key mapping/macro facilities were very useful
- vi was the standard UNIX editor and was always available; it
should be learned for this reason alone
- vi was, however, difficult to learn; an on-line help facility
was needed


The main difficulties novice users found with emacs were:
- some of the commands were regarded as being unnecessarily
cumbersome, especially for the more complex manipulations
- mistyping commands sometimes resulted in "windows" appearing
which some users had difficulty in getting rid of

- the "modeless" operation (or rather the lack of mode changes)
- the backspace key was consistent in operation; it always
worked and always deleted the character to the left of the
- commands generally did what was expected first time
- technical novices in particular liked the way emacs agreed
with their experience of other editors and word processors,
making basic editing tasks easy and giving the editor a
familiar "feel" ("You don't have to learn what you already know")
- moving around the document was easy - getting to the end of a
line or to the end of the document was simply a matter of moving
the cursor

Regular emacs users felt:
- emacs was powerful and efficient enough for their purposes
- although there were a daunting number of commands and some
commands were cumbersome to type ("escape-meta-alt-control-
shift"), emacs was easily customizable so frequently
used operations could be moved to more acceptable key
- emacs was particularly suited to editing large documents as
it had facilities such as a spelling checker etc.
- emacs was very easy to use and also easy to learn, especially with
the on-line tutorial and help


Emacs appears to be the editor of choice for novices performing the
given tasks. Not only were they able to perform the tasks
significantly faster on both trials with significantly less need for
help, but they also seem to have experienced less frustration.
Novices, especially non-technical novices, had a very mechanical way
of approaching the tasks and disliked having to give special
commands - emacs suited this approach. For example, to add something
to the end of a paragraph, novices generally just tried to move the
cursor there and type. While this worked with emacs, vi would not let
them move their cursor past the last character on a line (some held
down the right arrow key for several seconds, hoping to achieve the
desired effect); eventually they had to consult the help sheet (they
needed ESC a - append to line).

Some apparent inconsistencies in vi's operation particularly
frustrated novices. For example, the backspace key works only on newly
inserted text - many novices expressed dismay that the backspace key
that had worked while they were typing in text suddenly seemed to
cease functioning when correcting other errors. They were forced to
consult the help sheet again; this time they needed ESC x - delete
character. The delete character operation itself seemed to be
inconsistent - users felt they had to guess whether the character to
the left of the cursor or the one under the cursor would be deleted.
This is because vi moves the cursor backwards one space when the mode
is changed from insert to command mode; thus if the user is in insert
mode, the character to the left of the cursor is deleted, otherwise
the character under the cursor is deleted. To novice users who were
unused to these subtleties, however, deletion appeared to be a random
process. By contrast, the operation of backspace in emacs was totally
consistent - it always deleted the character to the left of the

The experiment also served to illustrate the main disadvantage of vi
and the strong point of emacs as far as novices are concerned: the
issue of on-line help. Not only did novices find that they needed less
help with emacs (many did not need any help at all to perform basic
manipulations), but a full tutorial and interactive on-line help is
available; emacs' title screen gives new users full instructions on
how to access these features (as well as how to quit emacs at any
stage). This immediately puts the user at ease and gives him/her a
sense of security. Vi, however, does not provide any on-line help;
system manual pages are generally available but these tend to give
reams of very technically-oriented detail which is mostly useless to a
novice. In addition, most novices are not even aware of the manual
page's existence. All the novices in our experiment encountered
difficulties and required lots of help with vi right from the start of
their tasks; it is therefore puzzling that vi should have no help
facilities. Every editor user must pass through the novice phase; if
the editor seems difficult to use and does not even provide basic help
(like a list of common command keys), the user is likely to abandon
the effort and use another program (if available).

The comparison of the percentage improvement in time between trials
(see objective results) can be used to get an idea of the initial
learning curves of vi and emacs, since time taken to perform tasks is
a good measure of how well the user has learned to use the editor.
While non-technical novices underwent a dramatic time improvement
(39 +/- 4 %) between trials with vi, a more modest improvement (27 +/-
6 %) was noted using emacs. Thus we may tentatively conclude that vi
has the steeper initial learning curve for non-technical novices. The
percentage increases for technical novices were not as striking; a
similar tendency was noted, but uncertainties were too large to reach
any firm conclusions.

No significant difference in performance times was found with regular
users of the editors; this suggests that, with practice, a similar
level of performance can be obtained using both editors. Regular users
of both editors were fully satisfied with their editor's functionality
and efficiency. Regular users of vi, however, seemed to be more
emotionally attached to that editor (ironically, this is possibly
because they had invested considerable effort in learning it and take
pride in their achievement).

I'm not sure if the author understands the definition of the word "ironic". I believe most people would agree that people who spend time to get good at something should have some emotional level of attachment.

It is important to note that while these experimental results strictly
only apply to the specific set of tasks given ie. basic text
manipulation, each editor has advanced facilities for other tasks such
as programming. A non-technical novice, however, is unlikely to
require these features at the beginning of his editing career;
therefore it is reasonable to omit such specialized tasks from his/her
tests. It is also likely that the performance of technical novices
using these special features would be similar to their performance on
basic text manipulation since programming involves similar tasks: for
example insertion and deletion of "text" (code) and moving
"paragraphs" (procedures). This, however, needs to be verified in
further studies.

All subjects used in the study were relatively intelligent, well-
educated university students (selected from various faculties).
Although it would be presumptuous to extrapolate these results to the
general population, it seems likely that with less sophisticated
users, emacs would perform even better relative to vi due to its
novice-friendly nature. Again, this needs to be experimentally


In this study, Emacs was found to be a significantly faster editor
than vi for all grades of novice user attempting the simple text
manipulation tasks given; they required significantly less help and
also felt more comfortable with emacs' uniform modes and consistent
response. Since emacs also has on-line help which is lacking in vi, it
is definitely the editor of choice for novice users undertaking simple
editing tasks. Further work needs to be done on specialized tasks such
as programming and involving a broader spectrum of users.

No significant performance difference was found between vi and emacs
for regular users and both have sufficient power to maintain a
considerable following. Since every UNIX system already has vi, and
many devoted adherents, vi should continue to be available as a choice
to users; there is no advantage for regular vi users to change to


Although the analysis presented here is the work of the author, the
experiment was designed and executed in collaboration with Ms.
Marjolijn Weber, also a third year computer science student at UCT.


[1] T. Roberts, and K. Moran. The Evaluation of Text Editors:
Methodology and Empirical Results; from Readings in Human-Computer
Interaction (edited by B.M. Baeker and W.A.S. Buxton, 1987)
[2] Collected undergraduate studies of vi and emacs (Compiled by E.
Blake, 1991)
[3] K. Gomoll. Some Techniques for Observing Users; from The Art of
Human-Computer Interface Design (edited by Brenda Laurel, 1990)
[4] R. L. Mason. Statistical Design and Analysis of Experiments
(Wiley, 1989)



1. Go to the end of the document and type in the following paragraph:

Joined the library. Got Care of the Skin, Origin of the Species, and a book
by a woman my mother is always going on about. It is called Pride and
Prejudice, by a woman called Jane Austen. I could tell the librarian was
impressed. Perhaps she is an intellectual like me. She didn't look at my
spot, so perhaps it is getting smaller.
2. Correct the three spelling errors in the first three lines of the first
paragraph (one error per line) and remove the extra "Geography" in the
3rd line of the first paragraph.
3. Add the words "About time!" to the end of the second paragraph.
4. Delete the sentence "Time flies like an arrow but fruit flies like a
banana" and re-form the paragraph.
5. Replace all occurrences of "is" with "was".
6. Swap the two paragraphs.
7. Save the file and quit.


Wednesday January 14th

None of the teechers at school have noticed that I am an intellectual. They
will be sorry when I am famouse. There is a new girl in our class. She sits
nixt to me in Geography Geography.
Time flies like an arrow but fruit flies like a banana.
She is all right. Her name is Pandora, but she likes being called "Box".
Don't ask me why. I might fall in love with her. It's time I fell in love,
after all I am 13 3/4 years old.



by a woman my mother was always going on about. It was called Pride and
impressed. Perhaps she was an intellectual like me. She didn't look at my
spot, so perhaps it was getting smaller. About time!

None of the teachers at school have noticed that I am an intellectual. They
will be sorry when I am famous. There was a new girl in our class. She sits
next to me in Geography. She was all right. Her name was Pandora, but she
likes being called "Box". Don't ask me why. I might fall in love with her.
It's time I fell in love, after all I am 13 3/4 years old.



ESC i insert text
ESC $a append text (to end of line)

ESC A would be a more useful and accurate keystroke to perform this task. Evidence of the authors ignorance of full vi features.

ESC J join lines

ESC ^ beginning of line

0 (zero) would be more accurate here as well

ESC $ end of line
ESC 1 G top of document

ESC gg would be better than 1 G

ESC G end of document

Backspace delete character before cursor (only works with
newly inserted text)
ESC x delete character

One of the main criticisms were referring to this particular command - if you compare the emacs command it says "delete character under the cursor", which is what this command will do. I suspect the authors' bias against vi's modes a large part of the problem here. ESC is not a required preface to all commands - it simply removes you from the insert mode. This seemingly minor fact is likely the source of much of the problems found with vi.

ESC dw delete word
ESC dd delete line (puts deleted text into a buffer which can
be restored by pressing ESC "1P)

The 1 is not required to paste/put a line. Capital P is sufficient to insert the line above the current one, while p inserts on the line after.


Just D is all that is needed.

ESC "1P yanks back (restores) text deleted with ESC dd or

Undo would be a more useful command for restoring deleted text.

ESC :%s/

:wq is a more accurate save and quit


Ctrl a beginning of line
Ctrl e end of line
ESC < top of document
ESC > end of document

Backspace delete character before cursor
Ctrl d delete character under cursor
Ctrl k delete to end of line (puts deleted text into a buffer
which can be restored by pressing Ctrl y)
ESC k delete to end of sentence (puts deleted text into a
buffer which can be restored by pressing Ctrl y)
Ctrl y "yanks" back (restores) text deleted with Ctrl k or

ESC x repl str

Many of the concerns cited in this study have largely been addressed with the release of Vim - Vi IMproved.

I am incredibly curious to see a study done following similar guidelines, but using vi with better commands, and with vim. Of course a few more volunteers would be needed...

The main thing this study points out to me is that it is important to get the input of experts from both sides of an issue when designing a study, so as to be an appropriate study.

Questions, comments, criticisms of my criticisms? Leave a comment!

(Disclosure: I used vim in compatibility mode under cygwin to test the commands, but according to the online help, that should make vim run exactly like vi)
Posted by Wayne at 8:35 AM No comments: Labels: editor, emacs, holy war, study, vi, vi vs. emacs

Review - Building the Perfect PC Building the Perfect PC, by Robert Bruce Thompson and Barbara Fritchman Thompson, is the perfect introduction to the world of building your own computer. Whether you're looking for a general purpose computer built mainly for playing Farmville, or you want to build a web server, or a MythTV DVR computer, or you want a system that can play Crysis on max settings, this book will teach you how. The Thompson's introduce you to the world of PC building by explaining why you should want to build your own (and you should!), and then proceed to demystify the process of selecting components and putting them together to build your perfect PC, designed specifically for what you want to do.

Having built my own computers (and having cobbled together a few from various dead PCs), I can say this guide is an invaluable resource. The money that you will save buying an equivalent pre-built PC will probably be much greater than the cost of this book, so if you're in the market for a new PC you should buy this book and build your own. You'll be able to custom tailor your PC to your individual needs and desires, that will be a much better buy than anything you can find pre-built.

Bottom line: You should buy this book if you need a new PC soon.
Posted by Wayne at 7:57 AM No comments: 
An Extension...?

Google has announced that they are extending free calling in Gmail through 2011. I would ask why they are doing this but it seems obvious to me - they haven't gained the market share they're looking for, so by extending the free calling they're looking to garner new customers. Whether that's pulling from competing services such as Skype or Vonage, or introducing new users to the VOIP market.

Of course if you enjoy using Google's services, it's just another reason to love Google.
Posted by Wayne at 7:54 AM No comments: Labels: economics, google, voip


Review - Make: Electronics Make: Electronics, by Charles Platt, is an incredible book for anyone who is curious about electronics. This book guides you through a variety of experiments, beginning with simple experiments like "tasting" electricity and making a battery with lemons, lighting an LED with a battery, and then quickly (but not too quickly!) moving into more advanced topics such as using relays, creating timers, soldering, integrated circuits, electromagnetism, stepper motors, and even some PICAXE programming. It has high-quality color pictures and diagrams, and great explanations.

Make: Electronics blows most other electronics introductions out of the water. I was given a copy of Electronics Projects for Dummies, but that book was so dry I couldn't bring myself to try any of the projects. Charles Platt writes an incredibly informative and entertaining book - if you are looking to buy a beginners guide to electronics, your search is over. If you are buying this book for someone with just a spark of curiosity about electronics (even yourself), after they finish this book, they just may be addicted. This book is excellent - 5/5!
Posted by Wayne at 5:07 PM 1 comment: Labels: book review, electronics, fun


Review: JavaScript: The Good Parts JavaScript: The Good Parts, by Douglas Crockford.

Mr. Crockford writes a fine book for anyone who uses or needs to use JavaScript - ever. He quickly presents his view on JavaScript, that it can be a powerful and expressive language, but that it has some rather large warts. The author quickly leads the reader through an introduction to JavaScript, and shows how to avoid the major pitfalls inherent in JavaScript.

This book is fairly terse and not so much a learn-JavaScript book as it is a guide. The beginner embarking on a journey through the JavaScript jungle should certainly purchase this book as a companion to another more beginner-friendly book, to help clarify (and possibly correct) points being taught. I enjoyed JavaScript: The Good Parts, and recommend it to any one who works with or will work with JavaScript. It will make a big difference. Before taking a look at this book, I certainly would have happily criticized this language, but the author makes several good points and made me reassess my opinion of JavaScript. If I am ever in a position where I develop with JavaScript, you can be sure that this guide will be by my side, helping me to avoid the many pitfalls and use JavaScript to its full effectiveness.
Posted by Wayne at 8:40 PM No comments: Labels: book review, guide, javascript, programming


Password Generator

My older brother first introduced me to the idea of a pronounceable password generator. At one point I took a look at the one available here., and at one point I downloaded the C++ version to try and reverse engineer the generator. Well, fast forward to tonight when I had the opportunity to do so from the JavaScript version into Python. I suspect my engineering may not be quite so perfect, as almost all of my generated PWs start with the letter 'a'. Of course it may be a function of the random number generator. As far as programs go, it is actually fairly simple - the complexity is really in the trigram matrix - which is huge, accounting for about 620 lines. Aha! I found the issue - I was seeding with 12579.0 instead of 125729.0, whoops!

So now it works. Sweet action.

You can see the source here.
Posted by Wayne at 5:21 PM No comments: Labels: generator, password, programming, python, reverse engineering


Review - Buying a Home: The Missing Manual

Buying a Home: The Missing Manual by Nancy Conner
Are you thinking about buying a home? Then this book is for you! Buying a Home: The Missing Manual walks you through everything you need to know about the process of purchasing a home, from selecting a real estate agent, to closing (and even a little beyond). Having started the process of buying a home a few times before, I can honestly say I wish I had this book back then. I would have avoided some of the pitfalls that plagued both of my experiences. I didn't even know the questions to ask, and Buying a Home gave me questions to ask and answers to some questions I didn't even know to ask.

I seriously recommend this book to anyone who is contemplating home ownership - whether you get the digital or dead tree version, if you think you will buy a home in the future, Buying a Home: The Missing Manual is a wise investment. Posted by Wayne at 7:27 PM No comments: Labels: book review, ebook, oreilly


Winamp and XMMS Alternative Posted by Wayne at 3:50 PM No comments: 


Fun with Python

This is really pretty useless... but a great example of something awesome you can do with Python:

It's a waste of time when the math module already contains math.factorial, but it just shows off some of the more esoteric features of Python.
Posted by Wayne at 4:40 PM No comments: Labels: code, factorial, python



Django is a Python-based, Open-source web framework. And it's amazing. I'm currently going through the tutorial, which is fairly well written. There's nothing terribly amazing about the tutorial - it's not super entertaining, but it does present everything you need to get started working with Django, which is an amazing tool. To be fair I haven't worked with anything else like Zope or Twisted, so I don't know if they're any easier/more powerful.
However, Django seems to be real solid, and I'm liking it a lot. Plus did I mention it's free?
Posted by Wayne at 10:54 AM No comments: 
"Saying Goodbye"...

I died a little today when I learned that the Alliance disinterest has defeated the BrowncoatsGoogle Wave.
This makes me super sad, and I wish I could say I'm surprised, but I'm not. Here's why:
1) Awesome hype with too-long beta and too-few invites.
2) Little reason to switch.
First off, I love Google Wave. I was so stoked when they first released it, especially when I finally got my invite. Unfortunately I didn't get any invites initially. This was a problem because I couldn't share my excitement with any friends or family other than to say "This is so cool! ... but I don't have anyone I can use it with..." So that sucked. And when I did get my invites it was only about three of them. Sure, eventually they rolled out tons of invites, but it took a while to get everyone set up.
The biggest problem, however, is that there was really little reason to switch to wave. With GMail, it was compatible with your friends on Linux, Windows - whether they used Hotmail, Yahoo, Eudora, or Pine. But if you wanted to use Google Wave it meant anyone that you wanted to use Wave with had to switch. They had to switch from their email or their IM, and that was the killer. If my email works "okay", and my IM works perfectly well, why should I switch to Wave? For me, because it was awesome, but your average user isn't going to want to switch when everything else works well enough. If they wanted to have better adoption, they should have built-in the ability to send emails and/or IMs. And if they put a link at the end of the email, like "Try Google Wave", then it would have been great advertisement.
Unfortunately there was no such thing, and thus ends Wave, and that's sad.
RIP Google Wave.
Posted by Wayne at 8:39 PM No comments: 
Bad Design 
ThinkPad X61 Tablet and Ubuntu Lucid Lynx | Karol Krizka

Since the Ubuntu Lucid Lynx was released, I've been fairly nervous about upgrading my laptop. It seems that with every update I've had to go through a long, arduous process of finding and reinstalling everything I once had. Especially getting the tablet to work correctly. However, thanks to this post by Karol Krizka, who has an identical laptop to mine, I didn't have to worry too much. He updated his system and tested that everything works out OK. He has even created an autorotate script for our x61 tablets that works wonderfully. I've discovered what seems to be a bug - the auto rotate only rotates into inverted and left modes, whoops! But you can click the manual buttons and that works fine, disabling the automatic rotation.
Posted by Wayne at 6:18 AM No comments: 
A Tablet...

We have already got a tablet and we need no more tablet!

So I've been running Ubuntu 9.04 on my laptop since pretty much the beginning. When 9.10 Karmic Koala was released I almost upgraded, but then I realized I was very near to the end of a semester and what a dumb idea that would be. Especially since I use my laptop for nigh on everything.

But recently I stumbled (or re-stumbled, as the case may be) upon a blog that has some great posts about the x61. It would seem he's got pretty much the same laptop as I have - I'm mainly led to believe this by the fact that he has no touch screen either.

Using this post, I finally got the HDAPS working, back when I was running Ubuntu 9.04.

But now that I'm in between semesters (starting up this Thursday), I upgraded to 9.10 (mainly because Krizka posted about his experience being fairly straightforward). Of course it messed with all my custom tweaks with the tablet rotation, so I had to fix that. Using Krizka's autorotate project I pretty much had no trouble. After getting my hdaps module working again, the autorotate worked perfectly - something I had never been able to accomplish previously. The only problem is that with my previous script when the tablet display was folded down I liked the screen to be inverted - I found that was the best for my use in school. So looking through some of the documentation and inspiration that Krizka posted/provided, and using some of the tools I came up with this result:

I created a python script called "rotate" (you could name it .py if you wanted, but I didn't) and inserted the following:


sudo cp rotate /usr/local/bin/
sudo chmod 555 /usr/local/bin/rotate

After that, I created a file:

sudo vi /etc/acpi/events/swivel-down

into which I put the following (taken from here)

# Called when the tablet screen swivels down
event=ibm/hotkey HKEY 00000080 00005009
action=/usr/local/bin/rotate inverted

And now I have the best of both worlds. When I flip my screen down, it auto rotates to the orientation I like best (and I also have the ability to launch some extra programs if I need (though I think I may have to re-modify the wacomcpl script to automatically launch the config dialog... whoops, forgot to save that customization!)

So, this is really a big "Thank you!" to Karol Krizka
Posted by Wayne at 5:58 PM No comments: Labels: linux, programming, python, tablet, ubuntu


Chrome Trick

Are you such a Google fanboy/girl that you have more than one Google account? If you want to use both of these accounts in Google chrome you will have noticed that it doesn't work, even when opening a new window.
Instead of opening a new window, an incognito window. You'll share cookies etc. between your normal windows, and you'll share between your incognito windows, but you won't share information between normal an incognito.
Posted by Wayne at 5:07 PM No comments: Labels: chrome, tips, tricks
