26 Aug 2008 09:56

Why own a Desktop computer?
The thirty-year reign of the desktop computer may be coming to an end. According to various news reports, since about the mid 2000s, notebook (or laptop) computers have been outselling desktops. More surprisingly, perhaps, miniature notebook computers like the Asus EEE PC, with small screens and low-power CPUs that are no more powerful than mainstream CPUs of a half-decade ago are becoming increasingly popular, with a flurry of new low-cost (about $500) models. The reasons are intriguing: few productivity applications such as personal databases, spreadsheets, word processors and presentation tools need more than a small fraction of today's fastest CPUs. Thus the sort of CPU tradeoffs that need to be made to ensure long battery life in a notebook are less and less noticeable in practice. Other tradeoffs are also diminishing in importance: notebook screens can be large and bright, more and more rivalling desktop screens, notebook hard drives can be spacious and increasingly fast, and the rise of USB peripherals has made a portable notebook with a couple of USB ports as easily expandable in practice as any desktop computer. While notebooks are still pricier than desktops, the price difference is steadily diminishing as manufacturing economies of scale begin to weigh in. Even many who are in the habit of using their computer in one spot most of the time are realizing that an external screen, keyboard and mouse can be added to a notebook to make it function as if it were a desktop for general use, but when necessary, the notebook can be used elswhere, providing the convenience of having one's computer along (with all its data and software) when needed, without the fuss of copying data and worrying about different versions of applications. Moreover, notebooks have been improving in those areas where they offer abilities not found in desktops: battery life has steadily increased from the one to two hours common a few years ago to three or four hours. Lightweight notebooks are increasingly available, and not all of them are expensive. Most importantly, various forms of wireless networking are becoming ubiquitous, providing internet connectivity to notebooks without the need for wires. As such, it is no surprise that notebook computers are being widely purchased, and many peoples' first computer is now a notebook, not a desktop.

There are still some good reasons to buy desktops. The lowest-cost computers are still desktops, not notebooks. The very best CPU and graphics hardware is available only for desktops, and many modern games use as much of these resources as they can get. Hence desktops suit hardcore gamers much better than notebooks. Finally, Microsoft Windows Vista generally requires much more CPU and memory than most other operating systems, and the introduction of Vista has put some pressure on computing resources; because of this, some of the less powerful notebooks are now shipping with versions of Linux or with a previous version of Microsoft Windows, such as Windows XP. Nevertheless, it seems clear that given the increasing attractiveness of notebooks in comparison to desktops, a sensible way to approach buying a computer is to simply buy a notebook unless one has some concrete reason to need a desktop.

/it permanent link

Web shell scripting
It is a very handy thing to be able to write a quick script. UNIX and its derivitives have long been superb at making this possible: they possess a great many utilities that are designed to be used both from the command line and within scripts, and they possess shells that have all the control structures one might expect from any programming language. In fact, the traditional UNIX philosophy is to write small programs that do one thing well, and then combine them using scripts into rich and powerful applications. Indeed, the UNIX scripting environment is a rich one. But it is difficult to write shell scripts for the web. The unix scripting environment is designed for files, not web forms, the contents of which are encoded as url-encoded or multipart-encoded data. Hence, while unix shell scripts are sometimes used for web applications (cgi scripts), they are relatively rare, and generally frowned upon. The reason is no surprise: url-encoded and multipart-encoded data is complex to parse, and shell scripts that parse such data using sed, awk, etc. tend to be slow and hard to get right.

But this is easily fixed. If UNIX shell scripts like files, then they should be fed files. Hence I've written a small program (in C and lex), urldecode (ftp:/ftp.cs.toronto.edu/pub/jdd/urldecode) that parses url-encoded and multipart-encoded data, and converts the data into files. No complex file encoding is used. urldecode reads url-encoded or multipart-encoded data, creates a directory, then populates it with files such that each filename is a variable name, and the file contains the variable value. So all a web shell script needs to do to parse url-encoded data is to run urldecode on the data received from a web form, then read the results out of suitably named files. While this is hardly a replacement for PHP or .NET, it does provide a surprisingly simple and straightforward way to script for the web, because it allows all the handy UNIX utilities in the UNIX shell script environment to be leveraged to process web data. That's useful.

/it permanent link

CRT to LCD computer lab replacement: how much of a difference?
We are replacing all the remaining CRTs in our Computer Science teaching labs this summer with LCD panels, a total of 84 units (we replaced about fifty last summer). It's well known that LCD panels generally use less power when displaying than CRTs do, but the question is: roughly how much power/carbon emissions will we be saving through this summer's CRT replacement?

Using a Kill-A-Watt electricity consumption meter, we measured the power consumption of our CRTs (19" Dell P992) and our new LCD panels (19" Samsung 920BM and 22" Samsung 2253BW). When displaying an image, the CRTs draws between 85W and 110W of power, depending on how bright/white the image is. In comparison, the 19" LCD draws 35W of power, and the 22" draws 41W. If we assume an average CRT power draw (when displaying) of 97.5W (the mean), that's a power savings of 62.5W for the 19" LCDs, and 56.5W for the 22". We are replacing 48 CRTs with the 19", and 36 with the 22", for a total power savings of about five kilowatts.

What does this mean over time? If we assume the machines in our labs are displaying for an average of one hour out of eight (our labs are open to students on a seven-day twenty-four hour basis), and if we consider our projected equipment lifetime of four years, this implies about twenty-two thousand kilowatt-hours saved over this period. If we multiply this by a carbon intensity ratio estimate for grid electricity of 0.0453 kgC/kWh, this suggests a savings of about a metric tonne of carbon over the expected lifetime of these LCD panels.

/it permanent link

IT Support and human nature
IT is not about computers, but about people. This may be surprising: after all, when we think about technology, we generally think about equipment, gear, gadgets, code. But this gear doesn't exist for itself alone. Quite frankly, an unused computer is nothing more than a combination of space-heater and white noise generator. The I in IT is information, and that information is generated by, used by, and valued by people. For IT to be effective, it needs to be used effectively. Technology is a tool: powerful and complex, and like all powerful and complex tools, it takes time, effort and a certain amount of talent to learn to use the tool effectively. People are social beings, and so we learn to use tools in a social context: people who "know how" teach and help those who don't. This, broadly speaking, is the logic of IT support, which, ultimately, is a social construct to ensure that those who know how to use IT tools are available to help those who need help to effectively use them.

Human beings live in the tension between the collective and the individual. This is a fancy way of saying that people live by interacting with other people in ways that range from the genuinely interpersonal to impersonal embodiments of complex social constructions. Consider the difference between "I love you" on one extreme and "One Way, Do Not Enter" on the other. Both the collective and the interpersonal elements of human interaction are present in IT support: the nature of the technology imposes the need to interact with complex technical systems, while the nature of the human beings who use the technology requires one-on-one personal interaction. Indeed, IT support fails when it becomes too much like the notion of a "computer centre", too removed from the individual and the person-to-person act of helping and receiving help. But it also fails when it becomes too individualized, because of simple economics: there are many fewer IT experts than there are people in need of their help, and the one-to-one dynamic begins to fail when there are so few on one side of the equation and so many on the other. Effective IT support requires a balance between the two.

One way to maintain this balance, if there is a "critical mass" of IT needs and resources, is to make the commitment to do both at the same time. At the Department of Computer Science at the University of Toronto, we have found an effective way to do this for research computing support. We have a broad and diverse community of researchers, divided up into research groups. They have access to a core IT infrastructure of technical services, equipment and highly skilled staff to run it. But the department also has dedicated IT support staff who partner with specific groups: each group has their own person, their own IT expert, to call upon, and this person knows the people in the group and their research. We call such staff "points of contact", or POCs. Research IT support in the department is not a matter of contacting an anonymous service centre in one's moment of need, in the desperate hope of finding a sympathetic stranger with the requisite skills. Instead, it becomes an interaction between people who know each other, people who have been able to build a trust-relationship over time. Yet the economics of purely individualized support have been overcome: this organization "scales", because POCs do not need to do everything themselves. They and their groups have access to a complete infrastructure that offers common services across the entire department: secure and reliable file storage, web services, email, and more, and the expertise of the skilled technical staff that run it. POCs are freed to focus more fully on the unique, individualized needs of the research groups they serve.

Sounds idyllic, doesn't it? It is, in theory. In practice, there are plenty of challenges. Communication is key: POCs need to communicate well with their groups, and with other POCs and the core infrastructure staff. And the groups themselves need to be responsible for communicating with their POC: in human relationships, even those of IT support, there is both benefit and burden in knowing and understanding the other. A POC who is "shut out" of the research activities of the group is hampered in any effort to provide support that is well-tuned to those activites. That does not mean that poor support will result: even generic IT support, with a human face, can be superior to that offered by an anonymous service centre. But it does mean that the full benefit of having a POC will not be realized. But if a group and a POC fully commit to regular communication, the quality of IT support can be significantly greater than anything from a large service centre, because the POC who is offering that support has the potential to be a creative participant in the group's mission, the very mission that the group's use of IT is intended to serve.

/it permanent link

Blogging: Keeping It Simple
When I decided it was time to start blogging about information technology and information communication issues, I needed to choose some suitable blog software, something that would provide good results but also be easy to use. Open source is preferable. So I decided to do a quick web search and see what I could find. Most blog software seems to be pretty heavyweight: a database on the back-end to hold the blog entries, plus some sort of complex PHP web front end to display them. But this makes no sense to me: why use a database for blog entries? Blog entries are simple bits of text data that are organized in simple ways. There's no need for powerful query languages, transactional locking, and the various good things databases provide. These things are not free: databases have overhead to set up and run - I'm not worried so much about the computational resource overhead, but rather the human overhead: the time and energy required to configure, maintain, and back up databases. Do we really need such a thing for a blog?

Happily, I found blosxom, a piece of open-source blogging software that consists of a simple Perl CGI that uses a simple filesystem backend (a directory hierarchy) to hold all the blog entries. This is a nicely designed piece of software: simple, straightforward, low overhead, and very quick and easy to get going. It's also quite customizable. Clever simplifying details abound: for example, the date of the blog entry is simply the timestamp of the file, you create a new blog entry by simply creating a new file of the right name wherever you wish in the blog directory hierarchy, and writing something into it with your favourite text editor. You can organize your blog entries by topic if you want, and blosxom gets it all right. RSS seems all the rage these days: blosxom does that too: just add /index.rss to the end of the URL. For me, the only annoying bit of this software so far is the spelling of its name: I keep typing "bloxsom" for some reason.

Why is blosxom so good? Because it leverages what is already present on most systems: the filesystem, rather than introduce a complex, powerful and costly tool (a relational database) when it's not really needed. Kudos to Rael Dornfest, who, instead of taking the most popular or obvious approach, took the time to understand the problem being solved and the tools already available to solve it. This is an example of sensible economizing: human time and effort is a valuable commodity, the use of powerful tools (e.g. relational databases) uses up some of that commodity, and so such tools should be avoided unless they are really needed. If you think this sounds a little like "green" or "environmental" thinking, you're quite right: conserving energy to preserve the environment is very similar to conserving human energy to preserve the human environment. Just as the natural environment suffers strains from excessive energy consumption, so the human environment suffers from excessive demands on each person's time and energy. In both realms, economical thinking at design time is a prerequisite to good technology.

/it permanent link