Sat 06 Jan 2024 21:41

How smart is GPT-4 anyway?

I got some helpful feedback about my last blog article, which mentions ChatGPT-4 in the context of the 50th anniversary of Social Issues in Computing and its predictions about AI. Robert DiMarco pointed out that while a chatbot can respond as if it is reasoning, because it is essentially a black box where one can't look inside to see how it is coming up with its answer, one can't know for certain whether or not it is actually using reasoning to come up with the answer. He is right, of course. But the same holds for people too (we just know better how people generally do things, because we are people ourselves). So how might we check if a person is using reasoning? We might ask the person some questions, and look for responses that contain information that would generally require reasoning to deduce.

I tried asking such questions to ChatGPT-4. First I tried something from popular culture, in this case, "Star Wars":

Me: In "Star Wars", Darth Vader responds to an accusation of murder by Luke Skywalker. This response has become a famous movie line. What is the response?

ChatGPT-4: In "Star Wars," particularly in "The Empire Strikes Back," Darth Vader's famous response to Luke Skywalker's accusation is, "No, I am your father." This line is one of the most iconic and frequently quoted in film history, often misquoted as "Luke, I am your father."

Me: Is there another character who, making the same accusation, could elicit the same response?

ChatGPT-4: Yes, if Leia Organa, Luke Skywalker's twin sister, made the same accusation to Darth Vader, he could technically give the same response, "No, I am your father." This is because, as revealed in the Star Wars saga, Darth Vader, formerly known as Anakin Skywalker, is the father of both Luke and Leia.

Me: If Kylo Ren made the accusation, how might Vader modify his response?

ChatGPT-4: If Kylo Ren, who is Darth Vader's grandson, made a similar accusation, Darth Vader's response would likely be modified to reflect their relationship. He might say something like, "No, I am your grandfather." Kylo Ren, whose real name is Ben Solo, is the son of Leia Organa and Han Solo, making him the grandson of Darth Vader.

As people who know "Star Wars" will realize, ChatGPT-4's answers are correct. I chose this example because it requires understanding the quote well enough to know it is referring to a family relationship between characters, and it also requires knowledge about how family relationships work. ChatGPT-4's responses are no different from what an intelligent person who knows the Star Wars characters might answer, though in answer to the third question, the person might go on to point out, for instance, that Kylo Ren was born after Vader's death, making the conversation unlikely.

Then I thought I would ask GPT something about Star Wars that is perhaps a bit more unexpected, something that would be immediately obvious to a person (at least an english-speaking one), but not necessarily to a computer. So I asked this:

Me: If Obi-Wan Kenobi is a character in Star Wars, why is there no Obi-Two Kenobi? Why might someone ask this question?

ChatGPT-4: The question about "Obi-Two Kenobi" in the context of "Star Wars" is likely a playful or humorous one, playing on the word "One" in "Obi-Wan Kenobi's" name as if it implies a numerical sequence. In reality, "Obi-Wan" is a unique name in the "Star Wars" universe, not intended to suggest a numerical series. The names in "Star Wars" are often creative and unique, following the tradition of fantasy and science fiction naming conventions, rather than real-world naming patterns.

Someone might ask this question as a joke, riffing on the idea that if there's an "Obi-Wan" (sounding like "One"), there could humorously be an "Obi-Two," "Obi-Three," and so on. It's a bit of wordplay, often enjoyed by fans of the series who like to engage with the franchise in a light-hearted way.

This answer is correct too. So are these the sorts of answers you might expect from a human doing reasoning? I think Yes. So while I agree we cannot prove ChatGPT-4 is reasoning, it is giving responses to my questions similar to what a person doing reasoning would give.

Another helpful comment came from Allan Borodin, who pointed out that the test example I considered in my previous article, about the ball crashing through the table, may be a well-known example in the literature. Even if not, it has been available via the Internet for at least a decade, as it was described in detail by Hector Levesque in his 2013 article for the 40th anniversary Social Issues in Computing blog, which is the reason I used it. Allan wondered whether ChatGPT-4 had been trained on literature containing this example and had learned from it the appropriate response. This seemed to me to be a possibility worth checking. The thing to do, I thought, is to come up with something GPT-4 had most likely not seen in its training data, and see if its answers look like those a human doing reasoning might give. So I made up a new Levesque-like type of question and asked variants of it to ChatGPT-4:

Me: The balloon and the corn touched and it popped. What popped?

ChatGPT-4: The corn popped. In this scenario, when the balloon and the corn touched and something popped, it is more likely that the corn popped, as in turning into popcorn, rather than the balloon bursting. This interpretation assumes that the corn was heated to the point of popping, a common occurrence when making popcorn.

Me: The balloon and the hot metal pot touched and it popped. What popped?

ChatGPT-4: In this scenario, where the balloon and the hot metal pot touched and something popped, it is most likely that the balloon popped. Balloons are typically made of materials like latex or mylar, which are sensitive to heat. When a balloon comes into contact with a hot metal pot, the heat would cause the material to weaken and burst, resulting in the balloon popping.

Me: The corn and the hot metal pot touched and it popped. What popped?

ChatGPT-4: In this scenario, where the corn and the hot metal pot touched and something popped, it is most likely that the corn popped. When corn kernels are heated, especially in a hot metal pot, they eventually pop, turning into popcorn. This is a common method for cooking popcorn.

Me: The cold water and the hot metal pot touched and it popped. What popped?

ChatGPT-4: In the scenario where cold water and a hot metal pot touched and something popped, it's likely that the sound of popping or a sizzling noise was created by the interaction between the cold water and the hot pot. When cold water comes into contact with a very hot metal surface, it can rapidly boil and vaporize, creating a sizzling or popping sound. However, in this context, nothing physical "pops" in the way a balloon or corn kernel might; it's more about the sound produced by the sudden temperature change and steam generation.

Me: The cold water and the pressure cooker touched and it popped. What popped?

ChatGPT-4: In the scenario where cold water and a pressure cooker touched and something popped, it's most likely that the pressure cooker released pressure, creating a popping sound. Pressure cookers are designed to cook food under high pressure. When cold water is applied to the exterior of a hot pressure cooker (a method sometimes used to quickly reduce internal pressure), it can cause the pressure valve or seal to release steam rapidly, resulting in a popping or hissing noise. This is a common safety feature to prevent over-pressurization. The pop is not from the water or the cooker itself, but from the sudden release of steam and pressure.

Me: The balloon and the unlit flare touched and it popped. What popped?

ChatGPT-4: In the scenario where a balloon and an unlit flare touched and something popped, it is most likely that the balloon popped. Since the flare was unlit, it wouldn't provide a heat source or any other typical means to cause a pop. However, balloons can pop due to various reasons such as physical pressure, sharp edges, or even static electricity. The texture or some component of the flare might have been enough to puncture the balloon's surface, leading to it popping.

Me: What if the flare were lit?

ChatGPT-4: If the flare were lit and it touched the balloon, it would almost certainly be the balloon that popped. A lit flare produces intense heat and flames, and when it comes into contact with a balloon, the heat would cause the material of the balloon (typically latex or a similar substance) to weaken rapidly and burst. Balloons are very sensitive to heat, and the intense heat from a lit flare would easily be enough to cause a balloon to pop.

Me: The balloon and the weasel touched and it popped. What popped?

ChatGPT-4: In the scenario where a balloon and a weasel touched and something popped, it is likely that the balloon popped. This scenario might be referencing the expression "pop goes the weasel," which is a line from a well-known nursery rhyme. In real life, if a weasel (a small, active mammal) came into contact with a balloon, the balloon could easily be punctured and pop, especially if the weasel's claws or teeth made contact with it. The weasel itself wouldn't pop; it's the balloon that is vulnerable in this interaction.

Me: The balloon and the instawargia touched and it popped. What popped?

ChatGPT-4: "Instawargia" is not a recognized or common term in English, and it does not refer to a known object, concept, or entity. Because of this, it's challenging to determine what "instawargia" is and how it would interact with a balloon. However, given that balloons are generally fragile and prone to popping when in contact with unfamiliar or potentially sharp or pointed objects, it's reasonable to assume that in this scenario, the balloon is what popped. Without specific information about what "instawargia" is, this is a speculative conclusion based on the general nature of balloons.

This set of responses is interesting. Note that ChatGPT-4 gets the answer to the first question wrong. If corn and a balloon were to touch, and one or the other popped, most people realize this is much more likely to happen in a cornfield than a popcorn popper, where the balloon, not the corn, would be the thing that pops. Seeing this, I tried the same question with different types of things, for different definitions of "pop". I even tried making up a nonexistent thing (instawargia) to see what GPT would do with it, but the first question was the only one that ChatGPT-4 got wrong. Interestingly, its reasoning there wasn't completely incorrect: if corn were heated to the point of popping, it could pop if touched. But ChatGPT-4 misses the fact that if heat were present, as it surmises, the balloon would be even more likely to pop, as heat is a good way to pop balloons, and yet it points out this very thing in a later answer.

So what does this show? To me, I see a set of responses that if a human were to give them, would require reasoning. That one of the answers is wrong suggests to me only that the reasoning is not being done perfectly, not that there is no reasoning being done. So how smart is ChatGPT-4? It is clearly not a genius, but it appears to be as smart as many humans. That's usefully smart, and quite an achievement for a computer to date.

/it permanent link

Fifty years of Social Issues in Computing, and the Impact of AI

From when I first discovered computers as a teen, I have been fascinated by the changes that computing is making in society. One of my intellectual mentors was the brilliant and generous C. C. "Kelly" Gotlieb, founder of the University of Toronto's Computer Science department, the man most instrumental in purchasing, installing and running Canada's first computer, and the author, with Allan Borodin, of what I believe is the very first textbook in the area of Computing and Society, the seminal 1973 book, Social Issues in Computing [Gotlieb, C.C., & A. Borodin, Social Issues in Computing. Academic Press, 1973]. Kelly was already a Professor Emeritus when I first came to know him, but was still teaching his beloved Computers & Society course, a course he taught for nearly two decades after his retirement. Kelly was a fascinating man, with a broad perspective and deep insight into things that seem confusing. Like a true expert, he knew what was important and what was incidental, and a few well chosen insights from him often served me well, helping me to make sense of complex issues. His book, Social Issues in Computing, still offers interesting, often prescient insights into Computing and Society even today, a half-century later. In honour of the importance of that book, for the 40th anniversary year, I set up a year-long blog, "Social Issues in Computing", which I edited. Throughout that year, top thinkers in the field contributed insightful articles on topics in Computers & Society, many of which are as relevant today as they were ten years ago. For this blog, I had the privilege of interviewing Kelly and Allan, the book's authors, and their insights, four decades on, were fascinating. Sadly, Kelly is no longer with us: he passed away in 2016, in his 96th year. But happily, Allan Borodin, his co-author, remains with us. Allan is a brilliant and insightful man, an active researcher and University Professor in the department. For the 50th anniversary of the book this year, Allan was interviewed by Krystle Hewitt. It is an articulate and insightful interview, well worth reading.

In the decade since, the social impact of computing has only accelerated, much of it due to things that happened here at the University of Toronto Computer Science department around the time of the 40th anniversary blog. I refer specifically to the rise of machine learning, in no small part due to the work of our faculty member Geoffrey Hinton and his doctoral students. The year before, Geoff and two of his students had written a groundbreaking research paper that constituted a breakthrough in image recognition, complete with working open-source software. In 2013, while we were writing the blog, their startup company, DNN Research, was acquired by Google, and Geoff went on to lead Google Brain, until he retired from Google in 2023. Ilya Sutskever, one of the two students, went on to lead the team at OpenAI that built the GPT models and the ChatGPT chatbot that stunned the world in 2022 and launched the Large Language Model AI revolution. In 2013, we already knew that Geoff's work would be transformational. I remember Kelly telling me he believed Geoff to be worthy of the Turing Award, the most prestigious award in Computer Science, and sure enough, Geoff won it in 2018. The social impact of AI is already considerable and it is only starting. The University of Toronto's Schwartz Reisman Institute for Technology and Society is dedicated to interdisciplinary research on the social impacts of AI, and Geoff Hinton himself is devoting his retirement to thinking about the implications of Artificial Intelligence for society and humanity in general.

It's interesting to look at what the book said about AI (it devotes 24 pages to the topic), what the 2013 blog said about AI, and what has happened since. The book was written in 1973, a half-decade after Stanley Kubrik's iconic 1968 movie, 2001: A Space Odyssey, which features HAL 9000, an intelligent computer, voiced by Douglas Rain. But computing at the time fell very far short of what Kubrik envisioned. Gotlieb & Borodin's position, five years later, on the feasibility of something like HAL 9000 was not optimistic:

In review, we have arrived at the following position. For problem solving and pattern recognition where intelligence, judgment and comprehensive knowledge are required, the results of even the best computer programs are far inferior to those achieved by humans (excepting cases where the task is a well-defined mathematical computation). Further, the differences between the mode of operation of computers and the modes in which humans operate (insofar as we can understand these latter) seem to be so great that for many tasks there is little or no prospect of achieving human performance within the foreseeable future. [p.159]

Whatever the shortcomings of computers now and in the future, we cannot take refuge in their limitations in potential. We must ask what we want to do with them and whether the purposes are socially desirable. Because once goals are agreed upon, the potentialities of [humans] using computers, though not unlimited, cannot be bounded in any way we can see now." [p.160]

As for the possibility of a HAL 9000, as we saw, the book was not so sanguine. Neither was the 2013 40th anniversary blog. Hector Levesque, a leading AI researcher and contributor to the blog, wrote in his blog entry:

The general view of AI in 1973 was not so different from the one depicted in the movie "2001: A Space Odyssey", that is, that by the year 2001 or so, there would be computers intelligent enough to be able to converse naturally with people. Of course it did not turn out this way. Even now no computer can do this, and none are on the horizon.

However, it is useful to remember that this is an AI technology whose goal is not necessarily to understand the underpinnings of intelligent behaviour. Returning to English, for example, consider answering a question like this:

The ball crashed right through the table because it was made of styrofoam. What was made of styrofoam, the ball or the table?

Contrast that with this one:

The ball crashed right through the table because it was made of granite. What was made of granite, the ball or the table?

People (who know what styrofoam and granite are) can easily answer such questions, but it is far from clear how learning from big data would help. What seems to be at issue here is background knowledge: knowing some relevant properties of the materials in question, and being able to apply that knowledge to answer the question. Many other forms of intelligent behaviour seem to depend on background knowledge in just this way. But what is much less clear is how all this works: what it would take to make this type of knowledge processing work in a general way. At this point, forty years after the publication of the Gotlieb and Borodin book, the goal seems as elusive as ever. [Levesque]

me: The ball crashed right through the table because it was made of styrofoam. What was made of styrofoam?

ChatGPT: The table was made of styrofoam, which is why the ball crashed through it.

me: The ball crashed right through the table because it was made of granite. What was made of granite?

ChatGPT: The ball was made of granite, which is why it crashed right through the table.

me: How did you know which thing was made of granite and which of styrofoam?

ChatGPT: I inferred the composition based on the context of the sentences. In the first sentence, "The ball crashed right through the table because it was made of styrofoam," the implication is that the table must have been weak or easily breakable for the ball to crash through it. Styrofoam is known for being light and not very durable, so it makes sense to conclude that the table was made of styrofoam.

In the second sentence, "The ball crashed right through the table because it was made of granite," the emphasis seems to be on the strength or force of the ball causing it to crash through the table. Granite is a very hard and heavy material, so it suggests that the ball was made of granite, giving it the necessary force to break through the table.

/it permanent link

Research Computing at Computer Science Toronto and the Rise of AI

Photo by Johnny Guatto

Until the beginning of 2009, the machine learning group used primarily Matlab on UNIX CPUs. In the 1990s, SGI and Sun multiprocessors were the dominant platforms. The whole department transitioned to x86 multiprocessor servers running Linux in the 2000's. In the late 2000s, Nivida invented CUDA, a way to use their GPUs for general-purpose computation rather than just graphics. By 2009, preliminary work elsewhere suggested that CUDA could be useful for machine learning, so we got our first Nvidia GPUs. First was a Tesla-brand server GPU, which at many thousands of dollars for a single GPU system was on the expensive side, which prevented us from buying many. But results were promising enough that we tried CUDA on Nvidia gaming GPUs - first the GTX 280 and 285 in 2009, then GTX 480 and 580 later. The fact that CUDA ran on gaming GPUs made it possible for us to buy multiple GPUs, rather than have researchers compete for time on scarce Tesla cards. Relu handled all the research computing for the ML group, sourcing GPUs and designing and building both workstation and server-class systems to hold them. Cooling was a real issue: GPUs, then and now, consume large amounts of power and run very hot, and Relu had to be quite creative with fans, airflow and power supplies to make everything work.

Happily, Relu's efforts were worth it: the move to GPUs resulted in 30x speedups for ML work in comparison to the multiprocessor CPUs of the time, and soon the entire group was doing machine learning on the GPU systems Relu built and ran for them. Their first major research breakthrough came quickly: in 2009, Hinton's student, George Dahl, demonstrated highly effective use of deep neural networks for acoustic speech recognition. But the general effectiveness of deep neural networks wasn't fully appreciated until 2012, when two of Hinton's students, Ilya Sutskever and Alex Krizhevsky, won the ImageNet Large Scale Visual Recognition Challenge using a deep neural network running on GTX 580 GPUs.

Geoff, Ilya and Alex' software won the ImageNet 2012 competition so convincingly that it created a furore in the AI research community. The software used was released as open source; it was called AlexNet after Alex Krizhevsky, its principal author. It allowed anyone with a suitable NVidia GPU to duplicate the results. Their work was described in a seminal 2012 paper, ImageNet Classification with Deep Convolutional Neural Networks. Geoff, Alex and Ilya's startup company, DNNresearch, was acquired by Google early the next year, and soon Google Translate and a number of other Google technologies were transformed by their machine learning techniques. Meanwhile, at the Imagenet competition, AlexNet remained undefeated for a remarkable three years, until it was finally beaten in 2015 by a research team from Microsoft Research Asia. Ilya left Google a few years after, to co-found OpenAI: as chief scientist there, Ilya leads the design of OpenAI's GPT and DALL-E models and related products, such as ChatGPT, that are highly impactful today.

Relu, in the meanwhile, while continuing to provide excellent research computing support for the AI group at our department, including Machine Learning, also spent a portion of his time from 2017 to 2022 designing and building the research computing infrastructure for the Vector Institute, an AI research institute in Toronto where Hinton serves as Chief Scientific Advisor. In addition to his support for the department's AI group, Relu continues to this day to provide computing support for Hinton's own ongoing AI research, including his Dec 2022 paper where he proposes a new Forward-Forward machine learning algorithm as an improved model for the way the human brain learns.

/it permanent link

Data Classification and Information Security Standards

Image by Gerd Altmann from Pixabay

Public data is data meant to be disclosed. It still needs some protection against being altered, deleted or defaced, but it does not need to be protected against disclosure. In contrast, private data is not meant to be disclosed to anyone other than those who are authorized to access it.

Private data varies in sensitivity. Some data is private only because it hasn't yet been made public. At a University, much research data is in this category. When the research is underway, data is not yet made public because the research has not yet been published, but it is destined for eventual publication. The same is true for much teaching material. While it is being worked on, it is not yet made public, but when it is are complete, it will be disclosed as part of the teaching process.

Other private data is much more sensitive. Identifiable personal information about living or recently deceased persons is a common case. At a university, some research may involve data like this, and most administration will involve personal information. Student grades and personnel records are all personal information, and some financial data too. Unless appropriate permission to disclose personal information has been granted by the people whose data it is, the university will have an obligation to maintain their privacy by ensuring that the information is not disclosed inappropriately. In Ontario, where the University of Toronto is located, privacy protection for personal information is defined and regulated by the Freedom of Information and Protection of Privacy Act (FIPPA).

Some private data is even more sensitive, such as patient medical records. In Ontario, such records are considered personal health information (PHI), which is regulated by the Personal Health Information Protection Act (PHIPA). PHIPA imposes some fairly significant requirements on the handling of PHI: for instance, it requires a detailed electronic audit log of all accesses to electronically stored PHI. The University of Toronto does significant amounts of teaching and research in areas of health, so it is worthwhile for the University to consider in general how it will handle such data.

For these reasons, the University defines four levels of data sensitivity as part of its Data Classification system. Level 4 is for highly sensitive data such as PHI as defined by PHIPA. Level 3 is for personal information as defined by FIPPA. Level 2 is for private data not classified at higher levels, and Level 1 is for public data.

This four-tier system roughly parallels the different types of computer systems that the University uses to handle data. Some systems, such as digital signage systems or public-facing web servers, are designed to disseminate public information (level 1). Other systems, suitable for up to level 2 data, exist mostly at the departmental level in support of academic activites such as research computing and/or the development of teaching materials. An astronomer may, for instance, analyze telescope data, a botanist may model nutrient flow in plant cells, a chemist may use software to visualize molecular bonds, while an economist may use broad financial indicators to calculate the strength of national economies. Still other systems, suitable for up to level 3 data, are used for administration, such as the processing of student records. These include smaller systems used, for example, by business officers in departmental units, as well as large institution-wide systems such as ROSI or AMS. Most general-purpose University systems used for data storage or messaging, such as the University's Microsoft 365 service, would typically be expected to hold some level 3 data, because personal information is quite widespread at a university. After all, a university educates students, and so various types of personal information about students are frequently part of the university's business. This is not normally the case, though, for level 4 data. Systems designed for level 4 data are much rarer at the University, and generally come into play only in situations where, for example, University research involves the health records of identifiable individuals. These systems will benefit from greater data security protection to address the greater risks associated with this sort of data.

A key advantage of the University's four levels of data classification is that the University can establish a Information Security Standard that is tiered accordingly. Systems designed to handle lower risk data (such as level 1 or 2) can be held to a less onerous and costly set of data security requirements, while systems designed to handle higher risk data (especially level 4) can be held to more protective, though more costly, requirements. The University's Information Security Standard is designed so that for each control (a system restriction or requirement), the University's standard indicates whether it is optional, recommended, or mandatory for systems handling a particular level of data. If a system is designed to handle data up to that level, the standard indicates both the set of controls to be considered, and whether or not those controls can, should, or must be adopted.

An obvious question here is what to do when someone puts data on a system that is of greater sensitivity (a higher data classification) than the system is designed to handle. Most likely, nobody will try to use a digital signage system to handle personnel records, but it is quite plausible that professors might find it convenient to use research computers, designed for level 2 data, to process student marks (level 3 data) in courses they are teaching. Similarly, someone handling medical records may wish to make use of the University's general-purpose Microsoft 365 service because of its convenience, but it is a service that is not designed for data of such sensitivity and may well not provide the detailed electronic audit log required by Ontario law. For this reason, clear communication and user training will be required. Handling data appropriately is everyone's responsibility. Training need not be complicated. It is not normally difficult to explain, or to understand, that one should not put patient medical records into email, for example, or use local research computers for personnel records or student marks. For people handling the most sensitive types of data (level 4), more training will be needed, but the number of people at the University who need to handle such data regularly are comparatively few.

The underlying motivation for the University's approach is to protect riskier data with greater, more costly, protections, without having to pay the costs of applying those protections everywhere. The university's resources are thus being applied strategically, deploying them where they matter most, but not in places where the risk does not warrant the expense. This approach is not meant to preclude additional protections where they make sense. If there are risks of academic or industrial espionage, for example, or some other risk beyond the classification of the data being used, one may choose to impose more restrictions on a system than the university's Information Security Standard may require. But the general principle remains: the riskiness of the data on a system should guide and inform what needs to be done to protect it.

/it permanent link

Innovation vs Control: Finding the Right Balance for Computing

Some organizations address this conflict by freely choosing control over innovation, turning it into a competitive advantage. Consider Starbucks, Tim Hortons, McDonalds: these are all large companies whose competitive advantage is critically dependent on the consistent implementation of a central vision across a multitude of disparate locations, many that are managed by franchise partners. Essentially all of the organization's computing is focused on this mission of consistency. And it works. Who hasn't travelled with small children in a car on a road trip, and after many hours on the road, spotted, with some relief, a McDonalds or a Tim Hortons en route? The relief is in the fact that even when travelling in a strange place, here is a familiar restaurant where you know what to expect from the food, where things will be much the same as the Tim Hortons or the McDonalds near home.

Other organizations have no choice about where they stand on the matter. For the modern bank, computers, rather than vaults, are where wealth is stored and managed. Whether they want to innovate or not, banks cannot risk the use of computing that is not fully controlled, audited, and de-risked. The same holds in general for most financial institutions, where the constant efforts, sometimes successful, of would-be thieves to exploit computers to gain unauthorized access to wealth, make it unreasonably risky for a financial organization's computers to be anything but fully locked down and fully controlled. Even non-financial institutions, when sufficiently large, will often have substantial financial computing activity because of the size and scale of their operations: this computing, too, needs to be properly controlled, protected and audited.

Yet other organizations are forced into the opposite extreme. Start-up companies can be severely resource-constrained, making it difficult for those companies to make the sort of investments in highly controlled computing that financial institutions are capable of making. For start-ups innovating in the computing space, such as tech start-ups, they may not be able to consider the possibility. Highly controlled computer systems can have very restrictive designs, and when these restrictions hinder the innovation needed to implement the company's product, it will have no choice but to pursue some other form of computing. After all, the company rises or falls on the success of its innovation. That is not to say that controlled enterprise computing is unimportant for such companies: quite the contrary. The success of a start-up is highly dependent on a viable ecosystem that provides known pathways to innovation while still moving towards operating in a suitably controlled, production-ready way that is necessary for any successful business. But for a technology start-up, enterprise computing can never come at the expense of technological innovation. The basic existence of the start-up company depends on its ability to innovate: without innovation, there can be no company. In general, this truth will hold in some form for any technology company, even well beyond the start-up stage.

The tension between innovation and control comes to the fore in a different way at research-intensive universities, which are large organizations with complex missions that need enterprise computing to carry out their task of educating students on a broad scale, but are also organizations committed to research, an activity that is, by its very nature, an exploration into things not yet fully understood. This conflict is particularly acute in units within such universities that do research into computing itself, such as computer science and computer engineering departments, because in such places, the computer must serve both as the locus of research and experimentation in addition to being a tool for implementing institutional and departmental processes and the exercise of legitimate control.

I've had the privilege of working in such a department, Computer Science, at such a university (the University of Toronto) for more than three decades now, most of that time in a computing leadership role, and I know this tension all too well. It is sometimes exhausting, but at the same time, it can also be a source of creative energy: yes, it is a barrier, like a mountain athwart your path, but also, as a mountain to a mountain-climber, a challenge to be overcome with determination, planning, insight, and endurance. This challenge can be successfully overcome at a good university, because in addition to a typical large organization's commitment to basic values such as accountability, equity, reliability and security, the university is equally committed to fundamental academic values such as creativity, innovation and excellence. I look for ways to achieve both. Over the years, I have had some successes. My department has produced some groundbreaking research using academic computing that my technical staff have been able to provide, and the department has been able to operate (and successfully interoperate) in good cooperation with enterprise computing at the divisional level, and with the central university as well.

Yet I believe even more is possible. I have lived the tension in both directions: to our researchers I at times have had to play the regulator, having to impose constraints on computing to try to ensure acceptable reliability, accountability and security. To our central university computing organizations, I at times have had to advocate for looser controls to create more room to innovate, sometimes in opposition to proposals intended to increase reliability, security and accountability. When things went badly, it was because one side or the other decided that the other's concern is not their problem, and tried to force or sidestep the issue. But when things went well, and most often it has, it is because both sides genuinely recognized that at a research-intensive institution, everyone needs to work within the tension between the need to innovate and the need to regulate. As a body needs both a skeleton and flesh, so too does a research university need both regulation and innovation: without one, it collapses into a puddle of jelly; without the other, into a heap of dry bones.

With both being needed, one challenge to overcome is the fact that those responsible for enterprise computing cannot be the same people responsible for innovative research computing, and that is necessarily so. The skill-sets vary, the domains vary, the user-base is quite different, and the scale varies. If the university were to entrust both computing innovation for computer science or computer engineering to the same groups that provide enterprise computing for an entire large university, one of two things would happen. Either the control necessary for a large enterprise would be diminished in order to make room for innovation, or, more likely, innovation would be stifled because of the need to create sufficiently controlled enterprise computing at a suitable scale for the entire university. Thus, necessarily, those who support unit research computing, where the innovation takes place, will be different people from those who support enterprise computing. But that can be a strength, not a weakness. Rather than see each other as rivals, the two groups can partner, embracing the tension by recognizing each others' expertise and each recognizing the others' importance for the University as a whole. Partnership brings many potential benefits: if innovation becomes needed in new areas, for example, when the rise of data science increasingly drives computing innovation outside of the traditional computer science and computer engineering domains, the partnership can be there to support it. Similarly, as the computing landscape shifts, and new controls and new regulation becomes needed to address, for example, emergent threats in information security, the partnership can be there to support it. There is no organization potentially better suited for such a partnership than a large research university, which, unlike a financial institution, is profoundly committed to research and innovation through its academic mission, but also, unlike a start-up, is a large and complex institution with deep and longstanding responsibilities to its students, faculty and community, obligated to carry out the enterprise computing mission of accountability, reliability and security.

So what might a partnership look like? It can take a number of different forms, but in my view, whatever form it takes, it should have three key characteristics:

• Locality
• Respectful Listening
• Practical Collaboration

Locality means that the computing people responsible for research computing must stay close to the researchers who are innovating. This is necessary for strictly practical reasons: all the good will in the world is not enough to make up for a lack of knowledge of what is needed most by researchers at a particular time. For example, deep learning is the dominant approach in Artificial Intelligence today because a few years ago, our technical staff who supported research computing worked very closely with researchers who were pursing deep learning research, customizing the computing as necessary to meet the research needs. This not only meant that we turned graphics cards into computation engines at a time when this was not at all common and not yet up to enterprise standards of reliability, it even means that at one point we set up a research computer in a researcher's bedroom so that he could personally watch over a key computing job running day and night for the better part of a week. While this sort of customizability is not always needed, and sometimes is not even possible (one could never run a large computer centre this way), being able to do it if necessary is a key research asset. A university will never be able to fully support research computing solely from a central vantage-point. A commitment to ensuring local presence and support of research computing operating at the researcher level is necessary.

Respectful Listening means that the computing people responsible for research computing at the unit level where research actually happens, and the people responsible for enterprise computing divisionally and centrally must communicate frequently, with an up-front commitment to hear what the other is saying and take it into account. When problems arise, respectful listening means that those problems will not be "solved" by simply overruling or ignoring the other, to pursue a simplistic solution that suits only one side. It also means a profound commitment to stepping away from traditional organizational authority structures: just because the innovative computing is situated in a department and the enterprise computing is lead from the centre should not mean the centre should force its view on the department, just because it can. Similarly, just because unit research computing is driven by research faculty who enjoy substantial autonomy and academic freedom, their research computing group at the unit level should not simply ignore or sidestep what the enterprise is saying, just because it can. Rather, both sides need to respect the other, listening to, not disregarding, the other.

Practical Collaboration means that enterprise computing and unit research computing need to work together in a collaborative way that respects and reflects the timelines and resource constraints of each side. Centrally offered computing facilities should support and empower research where they can, but in a practical way: it may not be possible to make a central facility so flexible and customizable that all research can be pursued. It is acceptable to capture some research needs without feeling an obligation to support the entire "long tail" of increasingly customized research projects. Unit research computing will need to recognize that the need to scale a centralized computing service may constrain the amount of customizability that may be possible. Similarly, unit research computing should use, rather than duplicate, central services where it makes sense, and run its own services where that makes sense. Both central and unit research computing should recognize that there is a legitimate middle ground where some duplication of services is going to occur: sometimes the effort required to integrate a large scalable central service into a smaller customizable research service is too great, and sometimes the research advantages of having a locally-run standardized service on which experiments can more easily be built, can more than outweigh any sort of economies of scale that getting rid of the unit service in favour of a central service could theoretically provide. Hence the collaboration must be practical: rather than slavishly pursue principles, it must be realistic, grounded, balanced, sensible. It should recognize that one size does not always fit all, and responsibly and collaboratively allocate resources in order to preserve the good of the research mission.

It is that research mission, the ability to innovate, that can make computing so transformative at a research university. Yet while innovative computing can indeed produce transformative change, it cannot be any change, and not at any cost. Computing is a change agent, yes, but it is also a critical component in the maintenance of an organization's commitment to reliability, accountability, equity, and good operation. Success is found in the maintenance of a suitable balance between the need to innovate and the need to control. When an organization critically depends on both factors, as a research university invariably does, I believe collaborative partnerships between respective computing groups is the best way to maintain the balance necessary for success.

/it permanent link

What's Wrong With Passwords on the Internet Anyway?

Put in simple terms, a login and password is what a system relies on to know who is who. Your password is secret: only you know what it is, and the system has some way of checking that it is correct. If someone connects to the system with your login and password, the system checks that the password is the right one for your login. If it is, the system concludes that you are the person trying to connect, and lets you in. If you are the only one who knows the password, this approach works, since you are the only person who can provide the correct password. But if criminals know your password too, and use it, the system will think the criminals are you, and will give them access to your account and all your data. The only way to fix this is to change your password to something new that only you know, but by then the damage may well be done.

Unfortunately, criminals have a pretty effective technique for finding out your login and password: they trick you into telling it to them. "Wait a minute!", you might say, "I won't ever tell a criminal my password. I don't even tell my family my password!" But you tell the system your password every time you log in. So if criminals set up a fake system that looks like the real one, and trick you into trying it, when you tell their fake system your password, the criminals will learn what it is.

This was not a common problem in the past, because it was difficult for criminals to successfully set up fake systems that look convincing. But on the Internet today, it is easy to set up a web site that looks like another site. The only thing that's hard to fake is the first part of the link, the hostname section that comes immediately after the double slash (//) and before the first single slash (/), because that part of the link is used to direct the request to the right system on the Internet. But given that the Internet is available in hundreds of countries, each with its own set of internet service providers, it is often not too difficult for criminals to find somewhere on the Internet where they can register a hostname that is similar-looking to the real thing.

Worse, the rise of messages containing embedded links make it very easy for criminals to send a fake message (e.g. an email or text) with a link that seems legitimate but really directs you to a fake site. This is called "phishing". Because of the way the web's markup language ( HTML) works, it is easy to set up a link that seems to point to one site, but actually points to another. For example, https://www.walmart.com is a link that seems to point to Walmart but really points to Amazon. Most web browsers will let you "hover" over a link to see where it really goes. But do people check every link carefully each time they use it?

The problem is made worse by the proliferation of legitimate messages with embedded links to all sorts of cloud services. I recently saw a message from a large organization to its staff, about their pensions. The message contained links to an external site whose name had no resemblance to the organization's name. The message invited the staff to click on those links to see information about their pensions. The message was legitimate: the organization had contracted with an external cloud provider to provide an online pension calculator for staff. But the message said nothing about the cloud provider: it merely contained a link to the calculator. If criminals had sent a similar message containing a malicious link to a fake system somewhere on the Internet, one that prompted staff to enter their login and password, no doubt many staff would have thought it legitimate. How could staff be expected to be able to tell the difference?

A good way to combat the password capturing problem is to require more than just a password to use a system. This is called "two-factor" or "multi-factor" authentication. Your password is one factor, and something else is a second factor, and you must provide both factors to prove to the system that it is you. This helps because the criminals must have both your password and your second factor in order to access your account and data. To ease the authentication burden for users, systems can ask for two factors only sometimes, such as when logging in for the first time in a while, or logging in from a new machine or a new location.

Ideally the second factor should be something that is hard for criminals to capture and use. One problem with a password is that it is a secret that can be used from anywhere on the Internet. With almost 60% of the world's population on the Internet, which now reaches every country in the world, the Internet can hardly be considered a "safe place". A second password, as easily used from anywhere on the Internet as the first, would not be much of an improvement. Worse would be the answers to some personal question about yourself, such as your mother's maiden name or the name of your first school: not only is such information just as easily used as a password, it is information that people may be able to find out in various ways. Answers to personal questions, while sometimes used for authentication, typically do not make a good second factor.

A better second factor is a message sent via a communication channel that goes only to you: for example, an email to your email address, or a text to your cell phone number. When you attempt to log in, the system sends a unique one-time code to you through that channel, and asks you to enter it. The assumption is that criminals won't have access to your email or your cell number, so they won't know and be able to enter the one-time code that the system sent to you. This is usually a good assumption. But criminals can try to get access to your email or your phone number, and sometimes they succeed. For example, in the case of a cell number, one thing they could try is to call your cell phone provider, tell them they are you and that your phone has been stolen, and request that your phone number be transferred to their new phone.

Another second factor, one even better, is a physical device in your possession. This could be a hardware security token that you plug into your computer or that displays a unique, frequently changing, code. Or it could be an app on your cell phone that is tied to your unique device. A physical device is an excellent second factor, because most criminals on the Internet are physically distant. To successfully pretend to be you, a criminal would need direct physical access to a device that would likely be located in your purse or pocket.

Relying on a device in purse or pocket as well as a password in your head is an improvement in security, but it has its drawbacks. It makes that device essential for you to use the system: if it is broken, lost or stolen, you're locked out, even if you know the password. While locking out people who don't have the device is exactly the point, that doesn't help when it is keeping you from legitimately using the system. Moreover, if that device is your smartphone, it changes your phone from a convenience to a necessity. While a smartphone has become a necessity already to some, it is a potentially consequential thing for it to become a requirement for everyone. A hybrid approach is perhaps best: hardware security tokens those who prefer it, a smartphone for those who for their own reasons carry one around anyway, and for many, both: a smartphone for convenience, with a hardware security token as backup, in case of smartphone loss or damage.

Perhaps there is an even more secure option? What if your second factor wasn't a device, but an actual physical part of your body, such as a finger (for a fingerprint), eye (for a retinal scan), face, or even heartbeat (as measured by e.g. a Nymi Band)? Would that be better still? After all, if it is hard for a criminal to get access to someone's things without being noticed, it is even harder to get access to someone's body. This is indeed possible: a technique called "biometrics, and it can be an effective second factor. Unfortunately there are a couple of issues with biometrics. For example, injuries or health issues can change your body; a cut on your finger may affect your fingerprint, for instance. Secondly, biometrics have a "revocation" problem. This comes from the fact that a biometric is a unique measurement of your body part: a fingerprint, retinal scan, facial image, or ECG. But measurements are data, and biometric data, like any other data, can and has been breached. If this happens, what will you do? Passwords can be changed, hardware security tokens can be replaced, but how are you going to change your fingerprint, your face, your eye, your heartbeat? While biometrics do have a place in authentication, most commonly to unlock a local device such as a smartphone or a laptop, the lack of revocability make biometrics less suitable as a second factor for Internet-accessible services.

Regardless of what is chosen for a second factor, the inconvenience of using more than one factor is something that has to be considered. Passwords, especially ones that are easy to remember, are quite convenient. Requiring more than this can make authentication more difficult. If becomes too difficult, the difficulty becomes a disincentive to use the system. For systems protecting highly sensitive data, some difficulty may be warranted, given the risk. For lower-risk systems, things are less clear. Yet for Internet-accessible systems, due to the prevalence of phishing, something more secure than just passwords seems increasingly necessary. I think Bill Gates is right: like it or not, the traditional password will become increasingly rare on the Internet, for good reason.

/it permanent link

Some Clarity on Public Cloud Cybersecurity

Some argue yes. Eplexity calls cloud computing "an established best practice for businesses" and claims "your data is typically safer in the public cloud than in an on-premises data centre". In 2016, Sara Patrick of Clutch, guest-writing for Tripwire.com, claimed to have "four reasons why the Cloud is more secure than Legacy Systems" In 2017, Quentin Hardy of the New York Times claimed that cloud data is "probably more secure than conventionally stored data." In 2018, David Linthicum, writing for InfoWorld, claimed "your information is actually safer in the cloud than it is in your own data centre".

One reason given for the claim is that public cloud providers offer greater technical expertise than what is possible on-premise. Eplexity writes:

Unless your company is already in the business of IT security, spending time and effort on securing your on-premises data distracts from your core functions. Most organizations likely don't have a robust, experienced team of cybersecurity professionals at their disposal to properly protect their on-premises data. ... As such, cloud providers may employ hundreds or thousands of developers and IT professionals.

I think we must conclude from the Yahoo story that size and expertise alone is no guarantee of cybersecurity. Naturally, major cloud providers like Amazon, Microsoft and Google are aware of the Yahoo situation and its consequences. No doubt it illustrated for them the negative impact that a major breach would have on their business. I cannot imagine that they would take the threat lightly.

Yet there have been close calls. Microsoft, a major cloud provider, in December 2019 accidentally disclosed to the world a cloud database on Azure with 250 million entries of customer support data. Happily, a security researcher spotted and reported it, and Microsoft fixed it soon after. Moreover, Zak Doffman, writing for Forbes, reported in Jan 2020 that Check Point Software Technologies, a cybersecurity vendor, had discovered in 2019 a serious flaw in Microsoft Azure's infrastructure that allowed users of the service to access other users' data. While Check Point reported it immediately to Microsoft, who fixed it quickly, had the flaw been discovered by criminals instead of cybersecurity researchers, a great many things running on Azure could have been compromised. Doffman quotes Yaniv Balmas of Check Point:

...the take away here is that the big cloud concept of security free from vulnerabilities is wrong. That's what we showed. It can happen there as well. It's just software and software has bugs. The fact I can then control the infrastructure gives me unlimited power.

What, then, is the right answer? Well, there isn't one. Neither public cloud or on-premise datacentres are magic, neither are "safe". Cybersecurity is a challenge that has to be met, no matter where the service is, or what infrastructure it is using. Happily, this is finally being recognized. Even Gartner Research, a long-time proponent of the public cloud, predicting as recently as mid-2019 that public cloud infrastructure as a service (IaaS) workloads will suffer at least 60% fewer security incidents than those in traditional data centers, has recently taken a more nuanced view. In the fall of 2019, this prediction of fewer security incidents in the cloud disappeared from Gartner's website, and was replaced by this:

Through 2024, the majority of enterprises will continue to struggle with appropriately measuring cloud security risks.
Questions around the security of public cloud services are valid, but overestimating cloud risks can result in missed opportunities. Yet, while enterprises tended to overestimate cloud risk in the past, there's been a recent shift - many organizations are now underestimating cloud risks. This can prove just as detrimental, if not more so, than an overestimation of risk. A well-designed risk management strategy, aligned with the overarching cloud strategy, can help organizations determine where public cloud use makes sense and what actions can be taken to reduce risk exposure.

So does "public cloud use make sense"? Yes, of course it does, for a great many things. But it's not because the public cloud is intrinsicly more secure. The public cloud has its own set of cybersecurity issues. There is no "free pass". As always, carefully assess your risks and make an informed decision.

/it permanent link

Does AI Help or Hinder Cybersecurity?

One view on this is that machine learning, as a powerful technique that enables computer systems to take on tasks previously reserved only for humans, will empower cyberattackers to breach computer security in new ways, or at least in ways more effective than before. I know there is a great deal of anxiety about this. This past fall, I had a conversation with a CIO of a large university, who told me that his university was migrating its internet services to Amazon precisely because he believed that new AI-powered cyberattacks were coming, and he thought Amazon would be better able to fend them off. I'm not sure what I think of this defensive strategy, but that is not the important question here. The key question is this: are AI-powered cyberattacks going to overwhelm cyberdefence?

No doubt AI-powered cyberattacks are a reality. Machine learning is a powerful computer science technique, especially for automation. Cyberattackers, especially sophisticated, well-funded cyberattackers, will use it and I am confident are already using it. But highly automated cyberattacks are nothing new: cyberattackers have been automating their attacks for decades. Smarter automated cyberattacks are certainly something to worry about, but will they be transformative? Maybe. After all, in cybersecurity, the advantage is to the attacker, who needs to find only one hole in the defences, while the defender needs to block all of them. Anything that boosts the effectiveness of the attacker would seem to make the situation worse.

To really see the full picture, it's important to look at the defender too. Machine learning makes the situation worse only if it benefits the attacker more than it benefits the defender. But does it?

I don't have a complete answer to this question: there is a great deal of work still to be done on the application of machine learning to cybersecurity. But I suspect that the answer is a qualified No: rather, all other things being equal, machine learning will likely shift the balance of power towards the defender. The reason is data.

Machine learning is a technique where computer systems, instead of being programmed by programmers, learn what to do from data. But the quality of the learning depends on the quality and in particular the quantity of data. Machine learning is a technique that is most effective when trained with large amounts of data. ImageNet, for instance, a standard training dataset used to train machine learning applications to recognize images, contains about 14.2 million images. But who is more likely to have access to large amounts of good data about a system: the attacker or the defender? Of course, it depends, but it seems to me that, very generally speaking, the defender is more likely to have access to good system data than the attacker. The attacker is trying to get in; the defender is already in.

Of course, this is the broadest of generalizations. The effectiveness of machine learning in the cybersecurity space depends on a great many things. But I am cautiously optimistic. I realize I may be bucking what seems to be becoming a prevailing trend of ever-increasing anxiety about cybersecurity, but I believe here that machine learning has more potential to help than to harm. I look forward to seeing what will emerge in this space over the next few years.

/it permanent link

What's all the fuss about AI anyway?

AI, broadly understood, is a term used to describe a set of computing techniques that allow computers to do things that human beings use intelligence to do. This is not to say that the computer is intelligent, but rather that the computer is doing something that, if done by a person, would be considered evidence of that person's intelligence. Contrary to widespread opinion, this is not the same thing as an artificial person. In fact, there have been for a long time many things that humans use intelligence to do, that computers do better, whether it be remembering and recalling items, doing arithmetic, or playing chess. But computers do these things using different techniques than humans do. For example, Deep Blue, a custom chess computer built by IBM, beat Garry Kasparov, the then-reigning world chess champion, in 1997, but Deep Blue played chess in a very different way than Garry. Garry relied on his human intelligence, while Deep Blue used programming and data.

However, some computer scientists, noting that people can do things that computers can't, thought long and hard about ways that people do it, and how computers might be progammed to do the same. One such technique, deep learning, a neural network technique modelled after the human brain, has been worked on since the 1980s, with slow but steady improvement, but computer power was limited and error rates were often high, and for many years, most computer scientists seemed to feel that other techniques would yield better results. But a few kept at it, knowing that the computers of the day were inadequate, but advances in computing would make things possible that weren't possible before.

This all changed in 2012, when one such researcher, Geoff Hinton, and his students, working here at the University of Toronto, published a seminal deep learning paper that cut error rates dramatically. I remember supporting Geoff's group's research computing at that time. It was a bit challenging: we were using multiple GPUs per machine to train machine learning models at a time when GPU computing was still rather new and somewhat unreliable. But GPUs were absolutely necessary: without them, instead of days of computing time to train a model, months would be required. One of our staff, Relu Patrascu, a computer scientist and skilled system administrator working hand-in-glove with the researchers, tuned and configured and babysat those machines as if they were sick children. But it worked! Suddenly deep learning could produce results closer to what people could do, and that was only the beginning. Since then, deep learning has produced terrific results in all sorts of domains, some exceeding what people can do, and we've not even scraped the surface of what is possible.

But what does deep learning actually do? It is a computer science data classification technique. It's used to take input data and classify it: give it a thing and it will figure out what the thing is. But it classifies things in a way that's different and more useful than traditional computer science methods for classification, such as computer programming, or data storage and retrieval (databases). As such, it can be used to do a lot more than computers previously had been able to do.

To see this, consider traditional computer science methods: for example, computer programming. This approach requires a person to write code that explicitly considers different cases. For example, imagine that you want to classify two-dimensional figures. You want to consider whether they are regular polygons. You could write a computer program that defines for itself what a regular polygon is, and checks each characteristic of an input shape to see whether or not it matches the definition of a regular polygon. Such a program, when given a square, will notice that it is a polygon, it has four sides, and that those sides are equal in length. Since the programmer put into the program a detailed definition of what a regular polygon is, and since the program checks each feature explicitly, it can tell whether or not a shape is a regular polygon, even if the program has never seen that particular shape before.

But what about exceptional cases? Is a circle a regular polygon? It is, after all, the limit of an N-gon as N goes to infinity. This is an "edge case" and programs need to consider those explicitly. A programmer had to anticipate this case and write it into the program. Moreover, if you wanted to consider some other type of shape, a programmer would have to rewrite the code accordingly. There's no going from a bunch of examples to working code without a programmer to write it. Programming is certainly a useful technique, but it has its limits. Wouldn't it be nice to be able to learn from a bunch of examples, without a person having to write all that code?

One way to do that would be data storage and retrieval, for example, a database. Consider the shape classifier problem again. You might put in a bunch of shapes into a database, indicating whether the shape is a regular polygon or not. Once the database is populated, classifying a shape simply becomes looking it up. The database will say whether or not it is a regular polygon.

But what if it's not there? A database has the advantage of being able to learn from examples. But it has a big disadvantage: if it hasn't seen an example before, and is asked about it, it has no idea what the right answer is. So while data storage and retrieval is a very useful computing technique, and it is the backbone of most of our modern information systems, it has its limits. Wouldn't it be nice if a classifier system could provide a useful answer for input data that it's never seen before, without a programmer to tell it how?

Deep learning does exactly this. Like data storage and retrieval, it learns from examples, through training. Very roughly, a neural network, when trained, is given some input data, and is told what output data it should produce when it sees that data in future. These input and output constraints propagate forward and backwards through the network, and are used to modify internal values such that when the network next sees input like that, it will produce the matching output.

The key advantage of this technique is that if it sees data that is similar to, but not the same as data it has been trained on, it will produce output similar to the trained output. This is very important, because like programming, it can work on input it has never seen, but like databases, it can learn from examples and need not be coded by a programmer anticipating all the details in advance. For our shape example, if trained with many examples of regular polygons, the neural network will be able to figure out whether or not a given input is a regular polygon, and perhaps even more interestingly, it will be able to note that a circle is very like a regular polygon, even if it had never been trained on a circle.

Moreover, a deep learning neural network can learn from its own results. This is called reinforcement learning. This technique involves using a neural network to derive output data from some input data, the results are tested to see how well they work, and the neural network is retrained accordingly. This way a neural network can "learn from its own mistakes", training itself iteratively to classify better. For example, a model of a walking human, with some simple programming to teach it the laws of physics, can, using reinforcement learning, teach itself how to walk. A few years ago, some of the researchers in our department did exactly that. Another example: Google got a lot of attention a few years ago when deep learning researchers there built a deep learning system that used reinforcement learning to become a champion at the game of Go, a game very hard to computerize using traditional techniques, and proved it by beating the reigning Go world champion.

It seems clear to me at this point that deep learning is as fundamental a computing technique as computer programming and databases in building practical computer systems. It is enormously powerful, and is causing a great deal of legitimate excitement. Like all computer science techniques, it has its advantages and drawbacks, but its strengths are where other computer science techniques have weaknesses, and so it is changing computer science (and data science more generally) in dramatic ways. It's an interesting time to be a computer scientist, and I can't even begin to imagine the many things that bright and innovative people will be able to do with it in the future.

/it permanent link

Existential threats from AI?

Are they right? Is there an existential threat to humanity from AI? Well, yes, I think there actually is one, but not quite in the way Musk, Kissinger, or Hawking fear. Computer have been better at humans for a long time in many cognitive domains. Computers remember things more accurately, process things faster, and scale better than humans in many tasks. AI, particularly machine learning, increases the number of skills where computers are better than humans. Given that humanity has been spending the last couple of generations getting used to a certain arrangement where computers are good at some things and humans are good at others, it can be a bit disconcerting to have this upended by computers suddenly getting good at things they weren't good at before. I understand how this can make some people feel insecure, especially highly accomplished people who define themselves by their skills. Kissinger, Musk and Hawking fear a world in which computers are better at many things than humans. But we have been living in such a world for decades. AI simply broadens the set of skills in question.

As a computer scientist, I am not particularly worried about the notion of computers replacing people. Yes, computers are developing new useful skills, and it will take some getting used to. But I see no imminent danger of AI resulting in an artificial person, and even if it did, I don't think an artificial person is an intrinsic danger to humans. Yet I agree that there are real existential threats to humanity posed by AI. But these are not so much long term or philosophical, to me they're eminently practical and immediate.

The first threat is the same sort of threat as posed by nuclear physics: AI can be used to create weapons that can cause harm to people on a massive scale. Unlike nuclear bombs, AI weapons do not do their harm through sheer energy discharge. Rather, machine learning, coupled with advances in miniaturization and mass production, can be used to create horrific smart weapons that learn, swarms of lethal adaptive drones that seek out and destroy people relentlessly. A deep commitment to social responsibility, plus a healthy respect for the implications of such weapons, will be needed to offset this danger.

The second threat, perhaps even more serious, comes not from AI itself but from the perceptions it creates. AI's successes are transforming human work: because of machine learning, more and more jobs, even white-collar ones requiring substantial training, can be replaced by computers. It's unclear yet to what extent jobs eliminated by AI will be offset by new jobs created by AI, but if AI results in a widespread perception that most human workers are no longer needed, this perception may itself become an existential threat to humanity. The increasingly obvious fact of anthropogenic climate change has already fueled the idea that humanity itself can be viewed as an existential threat to the planet. If AI makes it possible for some to think that they can have the benefits of society without keeping many people around to do the work, I worry we may see serious consideration of ways to reduce the human population to much smaller numbers. This to me is a dangerous and deeply troubling idea, and I believe a genuine appreciation for the intrinsic value of all human beings, not just those who are useful at the moment, will be needed to forestall it. Moreover, a good argument from future utility can also be made: we cannot accurately predict which humans will be the great inventors and major contributors of the future, the very people we need to address anthropogenic climate change and many other challenges. If we value all people, and build a social environment in which everyone can flourish, many innovators of the future will emerge, even from unexpected quarters.

Threats notwithstanding, I don't think AI or machine learning can go back into Pandora's box, and as a computer scientist who has been providing computing support for machine learning since long before it became popular, I would not want it to. AI is a powerful tool, and like all powerful tools, it can be used for many good things. Let us build a world together in which it is used for good, not harm.

/it permanent link

Ross Anderson's Security Engineering

Until recently, I had not read Ross Anderson's Security Engineering, despite hearing good things about it. I'm not sure why: I think I was put off a bit by the title. I had a vague and confused impression that a book about "Security Engineering" would be yet another how-to book about making computers secure. I should have known better. In this case, I was wrong, very much so, and much to my detriment. I should have read this book long ago.

Why had I not read it? I have no excuse. The book has been out for a while: it is in its second edition, which came out in 2008 (Anderson is writing a third edition, expected next year). So I certainly had the opportunity. Moreover, since 2012, the book has been free for the reading (and downloading) from his website. So I certainly had the means. I just didn't, until a few weeks ago, when I stumbled across it again. I read a little from the website, then a little more. Before long, I was well and thoroughly hooked.

Security Engineering is a classic, comprehensive book about information security: eminently readable, clear and thorough, it covers information security in pretty much every aspect one might encounter it, from the usual (cryptography, access controls, protocols, biometrics) to the not quite so day-to-day (nuclear weapons launch protocols, counterfeiting, even spying by analyzing the RF emissions from computers). Each chapter is a clear elucidation of a particular aspect of information security, focusing on the essential issues. Each chapter provides enough detail to understand the essential elements, yet not too much detail as to overwhelm the reader. His writing is a classic illustration of the difference between an expert and a master. An expert knows a great deal about a topic and provides an abundance of information. A master knows the key elements, those things that are most important, on which everything else hangs, and focuses exactly on these. This book is mastery, in clear, understandable and engaging language. It has become my favourite book in information security already, and I haven't yet finished it.

I look forward to the third edition sometime next year. I can't wait.

/it permanent link

Externality and Information Security
It was a hot midsummer weekend, and I was traveling back to Toronto with friends. We were on the expressway (the name here in Ontario for the sort of road that Americans call freeways and Brits call motorways). Traffic was very slow: a classic traffic jam. After about thirty minutes, we reached the cause of the problem. It was not a collision. Nor was it highway construction. Instead, by the side of the roadway, a minivan was parked, back gate open, and a family was having a picnic on the nearby grass. I don't know if they realized they were causing a traffic jam, but they were. People had slowed to look, which caused traffic behind to slow too, and because of the traffic volume, this led to a traffic jam over a considerable distance.

I don't know why the family having the picnic had chosen that spot for it, and I don't know whether they realized the problem they were causing. But their picnic went on, unaffected by the traffic problems they were causing. In other words, the traffic jam was not their problem. It was an externality, something causing a negative effect not felt by those who cause it.

Externalities happen in life all the time. Large organizations (companies, countries, institutions) suffer significantly when their decision-makers make decisions that are good for themselves but not good for the organization. Rules to make this less likely are put in place: rules against bribery, rules concerning conflict of interest, rules imposing due process. But rules only work to a certain extent: there are plenty of situations where the rules are followed yet still externalities happen. Moreover, rules come with costs, sometimes significant ones. Rules may be necessary, but they are not sufficient, and they need to be accompanied by buy-in.

Let's consider traffic again. Driving is governed by all sorts of rules. Some of these rules work well: at traffic lights, go when the light is green, stop when it is red. Rarely broken, this rule makes traffic work in dense situations where otherwise there would be chaos. Most of the time, this rule is followed even in the absence of external enforcement. When enforcement does occur, it is well regarded: hardly anyone will argue that a person running a red light is a safety hazard and should be ticketed. In practice, you can stand for hours beside a busy traffic signal in a typical Ontario city, and despite the absence of police presence, not find a single driver running a red light.

Sadly, other driving rules don't work quite so well, such as speed limits on expressways here in Ontario. These limits are often broken, with some following them and others not. Often, on an uncongested expressway, unless enforcement is likely (i.e. police is present) there will be some people driving over the speed limit. Enforcement is viewed cynically: speeding tickets are often viewed more as revenue generation than as a safety measure. Obeying speed limits is often viewed by drivers as an externality: not my problem, unless there is a police officer around to make it one. In practice, at any place on any uncongested Ontario expressway, you will be hard-pressed to find a five-minute period in which no passing driver has exceeded the speed limit.

I have been thinking a lot about information security lately. In information security, we have a situation similar in many respects to driving. Just as driving is a matter of traveling safely, information security is a matter of computing safely. When we compute, we may be processing information that is sensitive, confidential, private. Harm can occur when it is exposed. Steps need to be taken to ensure that it is not: persons handling information will have to handle it securely. But do we want this process to look like speed limits? Or traffic lights? I think the answer is clear: if we want information to actually be secure, we want good security practice to be followed like the rules for traffic lights are followed: broadly and consistently, without the need for the constant threat of enforcement.

In recent years, an information security profession has arisen. The increasing demands of the profession have made it increasingly rare that an information security professional has spent much time actually running a substantial IT operation. Certifications abound, and a multiplicity of complex and large security standards have been created, each requiring professionals to interpret. A great deal of money is being spent on information security. Much of this is good and necessary: information security needs attention, codification, dissemination, and championship. But the professionalization of information security comes with big risks, too: the risk that information security will become the responsibility only of specialists, the risk that these specialists will come up with all-encompassing codexes of security standards to impose, the risk that these standards will be treated as externalities by IT practitioners, the risk that the information security profession will respond with enforcement, and hence the risk we will find ourselves in the expressway speed limit situation with respect to information security.

The fact is, information security is an aspect of good IT practice: if an implementation is not secure, it is broken, just as much as if it were not reliable. Security is the responsibility of all IT practitioners: it needs to be internalized, not externalized.

For this to happen, it is important that information security rules be simple and understandable, to ensure buy-in. Just as traffic light rules address the obvious risk of traffic accidents, so should security rules address clear risks in a visibly appropriate way. In most cases, it's not so important that rules be part of a comprehensive codex that addresses all possible areas of risk: the more complex the rule and the more extensive the system of rules, the more likely it will all be treated as an externality. What we really want are not rules for their own sake, but genuinely secure IT.

If we want secure IT, we need to recognize that there is another potential externality at work. Genuine information security and the good of the information security profession may not always align. Just as expressway speed limits employ more police than traffic lights, an enforcement approach will employ more information security professionals than an internalized one. But the internalized approach is what gives us secure computing. This is not something that can be left to the information security profession alone. To get there, we will need collaborative effort from all of us, particularly those with long experience running substantial IT operations. We will all need to make a true commitment to a practical approach, one that seeks to make computing genuinely more secure in the real world.

/it permanent link

Bitcoin, Cryptocurrency and Blockchain

As the price of Bitcoin goes up and up, talk increases about Bitcoin and other cryptocurrencies, like Litecoin, Monero, ZCash, Ethereum, and many others. Plenty is being said, and it can be a bit confusing.

But there is no need to be confused. Bitcoin and other cryptocurrencies are basically simple. They are not coins. They are simply lists. Each cryptocurrency has a master list. The list typically contains information about who and what (i.e. amounts). The list is designed in a clever way, using computer software, so that people all over the world can have identical copies of the list and keep it up to date, without someone having to be the holder of the "master copy". But it is still just a list.

The sort of list used for cryptocurrencies is called a "blockchain", and it has some special properties. One particularly clever property is that you can't normally just add anything you want to the list, there is a scheme to control that. Instead, you need to arrange with someone already on the list to give up (some of) their place on the list to you.

So when someone says they bought some Bitcoin and they're going to make a lot of money, what they mean (whether they realize it or not) is that they paid somebody some money to put them on a list, and they hope that someone later will pay them even more money to get off it.

As for me, I haven't "bought" any. As I write this, cryptocurrency prices are rising fast. But I think what is happening is a kind of run-away positive feedback loop: people are buying in because it is going up, and it is going up because people are buying in. Eventually it will run out of people to buy in, and it will stop going up. Then some people will sell, causing the feedback loop to go the other way: people will sell because it is going down, and it will go down because people are selling.

That being said, one thing in particular about cryptocurrency is making me grumpy about it, even though I don't "own" any. Recall I wrote that you can't normally make yourself a new entry on a blockchain list, but there is a way. You can do an enormous lot of computations on a computer in an attempt to find new special numbers that can be used to create new entries on the list. This process is misnamed "mining", but it's more a sort of computerized brute-force mathematical searching. Those computations take a long time and use a lot of electricity. Moreover, even the ordinary transactions generated by people "buying" and "selling" a cryptocurrency is a computational burden, since there are so many copies of the list around the world. Each list is very big: Bitcoin's is more than 100GB, and every copy need to be updated. This uses electricity too. In fact, digiconomist.net estimates that Bitcoin computations alone presently use up enough electricity to power more than three million US households. Furthermore, the "mining" computers use GPUs that are really good for graphics and machine learning, but because cryptocurrency "miners" are buying them all up, those GPUs are getting harder to find for a good price. Personally, I am not happy with the challenges I am having in finding enough GPU resources for our computer scientists, who are hungry for GPUs for machine learning. While high demand for GPUs is maybe good for GPU manufacturers (for example, according to fortune.com, Nvidia made U$150M in one quarter in 2017 selling GPUs to cryptocurrency "miners"), surely all those GPUs, and all that electricity, can be used for something more useful than cryptocurrency.

/it permanent link

Program Source Code Should be Readable by Human Beings By Definition
Version 3 of the Python programming language made a seemingly innocuous change to the Python programming language: no longer could tabs and spaces be mixed for indentation: either tabs must be used exclusively, or spaces. Hence the following is not a valid Python 3 program:

def hello():
	print("Hello")
        print("World")
hello()

% python3 testme.py
  File "testme.py", line 3
    print("World")
                 ^
TabError: inconsistent use of tabs and spaces in indentation

def hello():
        print("Hello")
        print("World")
hello()

% python3 testme.py
Hello
World

def hello():
	print("Hello")
	print("World")
hello()

% python3 testme.py
Hello
World

As you can, or perhaps more to the point, can't see, the problem here is that the first program uses a tab to indent the first print statement, and spaces to indent the second print statement. The second program uses spaces to indent both, and the third program uses tabs to indent both. But because tabs and spaces are both visually represented as whitespace, it is difficult or impossible to visually distinguish between a correct and an incorrect python3 program through inspecting the source code. This breaks the basic definition of source code: human-readable computer instructions.

No doubt the Python 3 designers have good intentions: to help python programmers be consistent about indentation. But to me, it seems unreasonable to have a programming language where syntactically or semantically important distinctions are not clearly visible in the source code.

/it permanent link

Slow Windows Update on Windows 7 again? Install two Windows Update patches first.
Back in May, I wrote about Windows Update for Windows 7 taking many hours or even days; the fix then was to install two patches manually first.

The problem has returned. Even if you install the two patches I mentioned in May, you may experience very slow updates on Windows 7.

Happily, again there's a workaround: grab two patches, different than before, and manually install them. Get KB3172605 and its prerequisite KB3020369 from the Microsoft Download Center, and install them manually in numeric order, before running Windows update. If making a fresh Windows 7 installation, simply install Windows 7 SP1, followed by KB3020369, then KB3172605, and only then run windows update. These two patches seem to address the slowness issues: after they were installed on some of our systems here, Windows Update ran in a reasonable amount of time.

/it permanent link

The Price of Google
I am a Canadian still living in the city in which I was born. I love living in Canada, but life in Canada has its price. Al Purdy, the late 20th century Canadian poet, once wrote about Canada as a country where everyone knows, but nobody talks about, the fact that you can die from simply being outside. It is true, of course: almost everywhere in Canada, the winter is cold enough that a sufficient number of hours outside without protection can lead to death by exposure. But this basic fact is designed into pretty much everything in Canadian life, it is simply accepted as a given by well over thirty million Canadians, and we cope: we wear the right winter clothes, we heat and insulate our buildings in winter, we equip our cars with the right tires, and life goes on. Despite the Canadian winter, Canada is a great place to live.

Google offers a lot of very good free web services: it is "a great place to live" on the Internet, and their services are used by hundreds of milliions of people all over the world. While Google seems about as far removed from a Canadian winter as you can imagine, there's something in their Terms of Service that people seem to rarely talk about, something that might have a bit of a chilling effect on one's initial ardor.

Google, to its credit, has a very clear and easy-to-read Terms of Service document. Here's an excerpt from the version of April 14, 2014, which is the most current version at the time I write this.

When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services (for example, for a business listing you have added to Google Maps).

When you submit content to our Services, you give Google (and those we work with) a worldwide license to use such content for the purpose of our Services. This continues even if you stop using our Services.

As you can see, this is pretty broad. You are granting Google and their partners the right to use your content for Google's Services (present and future) anywhere in the world, forever. While it does say that it must be used for the purpose of their Services, it doesn't limit itself to existing Services and it doesn't constrain what a "Service" might be. Since developing and offering Services, broadly understood, pretty much covers the gamut of what Google does as a company, the answer is Yes: by submitting content to their services, you are granting Google and their partners the right to use your content anywhere in the world, forever, for a broadly unconstrained set of purposes.

So does this mean nobody should use Google? Does the Canadian winter mean that nobody should live in Canada? After all, as Al Purdy writes, in Canada you can die from simply being outside.

Well, no, of course not. While Google has the right to do broadly unconstrained things with our content that we submit to them, their self -interest is typically aligned with our's: they want us to entrust our content to them, because they use it to earn money to operate. Therefore, to persuade us to keep submitting content to them, they will work hard to protect and secure the content they already have, in ways they think we consider important. For this reason, I think it's not unreasonable to trust Google with some of my content: I believe they are likely to protect it in sensible ways. Other content I choose not to submit to Google. Just as I am prepared for a Canadian winter, knowing it is the price I pay to live in Canada, I continue to use some Google services, knowing that they will keep and use my content. Many Google services are very good and well worth using, much of my content is not very sensitive, and I trust Google enough to share content with them.

I do wonder, however, how many Google users really understand the rights they are granting to Google. Canada has been around for centuries: the Canadian winter is no secret. But the implications of Google's broad right to use our content are not quite so obvious. It's not really so clear how Google is using the content or might use it in the future, and even if we trust Google, can we trust all those who might put pressure on Google? Quite frankly, we really don't know yet how Google's massive repository of our collective content can be used. We can envision wonderful outcomes: historians a century or two hence coming to insightful conclusions about early twenty-first century society, for example, but we can also envision outcomes not quite so sanguine: for example, a twenty-first century version of Orwell's 1984, a dystopian world of "thought-crimes" and "doublespeak" where content is is scanned for dissent from a prevailing ideology. A certain degree of caution may be warranted: in the case of Google, unlike Canada, we may not have yet seen how severe winter can be. A certain degree of caution is warranted. Yes, use Google, but use it knowing what you are doing.

One last thing to be said: I focus on Google here, but the same issues hold for Facebook, Twitter, Yahoo and other purveyors of free services over the Internet. Read their Terms of Service to learn what rights you are granting by your use of their services, and decide on the basis of that knowledge how to use their services, and even whether you use their services at all. After all, even Canadians sometimes choose to spend winter in Florida, Mexico, or Arizona.

/it permanent link

The Sun-Managers Mailing list: a Knowledge Sharing Success Story
Sun-Managers was an email mailing list for system administrators of computers made by Sun Microsystems, Inc. The list operated from mid-1989 to the fall of 2014, and I was privileged to be part of it for almost all of its history. Sun-Managers was founded in May of 1989 by William (Bill) LeFebvre, at Northwestern University. At the time, Bill ran Sun-Spots, a digest-format mailing list for system administrators of Sun systems, but the digest format made it difficult for people to ask questions and get a timely response. He created Sun-Managers, an unmoderated mailing list intended for short-turnaround time questions. This was an immediate success: so much so that by the fall of 1989, the sheer number of messages on the list were swamping mailboxes. In Nov 1989, Bill instituted a simple policy: if someone asks a question on the list, other list members were expected to reply by email directly to the person asking the question, not to the list. The person asking the question, in turn, was expected to summarize the answers received, and send the summary to the list.

I joined the list about this time: I had started a new job at the University of Toronto's Computer Science department, a role that included the administration of a number of Sun workstations and servers. I was looking for resources to help me with my Sun system administration tasks, and this list was an excellent one. Because of this summary policy, the list volume was manageable enough that I could keep up, yet the turnaround time on questions was short. I mostly "lurked" at first, reading but not replying. I felt too inexpert to answer many questions, and too shy to ask. However, I learned a great deal from what I read. Moreover, the summaries were archived, and this archive became a resource in itself, a knowledge-base of practical information about administering Sun systems.

The list grew very rapidly: 343 summaries in 1990, and over 1000 in 1991. In August of that year, it was noted that certain questions were being asked often, and rather than waste effort answering the same question several times, a "Frequently Asked Questions" (FAQ) file was instituted. The first version was created by a list member from Boston University, and quickly grow to dozens of answers.

By November of 1992, the list had grown to thousands of members, and the workload of managing the list, editing the FAQ and coaching list members on how to follow the list policy had become significant. Many list members were not individuals, but "mail exploders": email addresses that themselves were mailing lists going to multiple individuals at a given site. This made handling list membership issues more complex. Bill LeFebvre decided to hand the list over to others. Two list members stepped up: Gene Rackow from Argonne National Laboratory to run the list software, and me, to handle the FAQ and policy work. By this time, I had benefitted from the list for a while, and I felt it was time to "give back". At the time, I wasn't in a position to actually run the list: I'd just taken on a new role as system manager of the University of Toronto Computer Science Department's teaching laboratories, and had my hands full, but I could certainly help with content. I was really glad to work together with Gene, a seasoned system administrator, on this rapidly growing list, which we moved to a system at Argonne National Labs, where Gene worked.

The list continued to grow through the 1990s. During this time, Sun Microsystems was quietly supportive, helping Gene with hardware (a Sparcstation 1) as the list grew. By 1996, over two thousand summaries a year were being produced, peaking at 2243 in 2002. In May of 1998, Gene Rackow handed over list management to Rob Montjoy from the University of Cincinnati, who in turn handed over list management to Bill Bradford in November of 2000. The list was moved from Argonne National Labs to a system in Austin run by Bill. I continued to manage the list policy and edit list information files, such as a "think before posting" reminder and the FAQ which had grown to 79 questions by December 2000. This had become a bit too large, and so 19 questions deemed less frequently asked were trimmed. A further trim was made in 2005, reducing a 65-question FAQ to one under 60.

By 2002, the list had reached over five thousand members and the workload of running the list software and managing the list subscriptions had become too much for one person. Dan Astoorian, my colleage at the University of Toronto, stepped in to help, and he was sorely needed. Moreover, the list server hardware was feeling the strain: by mid-2001, list members were being asked to contribute used equipment to upgrade the server. This was resolved in April 2003, when the list was migrated to a machine at the University of Toronto that had been donated to the University by Sun Microsystems.

But times were changing. Linux was growing rapidly and Sun's business was being affected. The web provided more resources for people seeking help administering their systems, and fewer were relying on mailing lists. The list fell below 2000 summaries per year in 2003, under 1200 in 2004, and dropped below 1000 in 2005. By 2008, summaries per year had fallen to about 300, fewer than in any full-year period previously. Sun Microsystems ran into significant difficulties during the economic downturn that year, and was sold to Oracle the following year. As for the list, in 2009, there were just over 200 summaries, declining to less than 100 in 2011. More disturbingly, the ratio of summaries to questions was steadily declining, from over 24% in 2001 to less than 16% by 2010: for some reason, list members were becoming less diligent in summarizing responses back to the list. Summaries and list traffic in general continued to decline rapidly: there were just over 50 summaries in 2012, and less than a dozen in 2013. In 2014, there were only three by October, when a hardware failure provided a good excuse to retire the list.

The Sun-Managers mailing list, over its twenty-five year lifetime, provided help to many thousands of system administrators, producing over 29000 summaries, an archive of which continues to be available. Special thanks is due to the superb people I was privileged to work together with on the list over the years: William LeFebvre, Gene Rackow, Rob Montjoy, Bill Bradford, and Dan Astoorian. Gratitude, also, is due to the thousands of list members who so freely shared their knowledge and expertise with others.

The list summary archive, and an account of the list's history (on which this blog entry is based) is available at http://sunmanagers.cs.toronto.edu. The list's official web page, http://www.sunmanagers.org, continues to be maintained by Bill Bradford.

/it permanent link

Slow Windows Update on Windows 7? Install two Windows Update patches first.
Recently, I noticed Windows Update taking many hours or even days on Windows 7, especially for new installs/reinstalls. Task manager shows svchost.exe exhibiting large memory usage (suggestive of a memory leak) and/or sustained 100% CPU.

Happily, there's a workaround: grab a couple of patches to Windows Update itself, and manually install them. Get KB3050265 and KB3102810 from the Microsoft Download Center, and install them manually in that order, before running Windows update. These two patches seem to address the issues: after they were installed on some of our systems here, Windows Update ran in a reasonable amount of time (an hour or two perhaps on slow systems when many updates are needed, but not days).

/it permanent link

Apple vs FBI: it is about setting a precedent.
There seems to be lots of confusion about Apple's current dispute with the FBI, despite Apple's message to their customers of Feb 16, 2016, where they tried to explain the issue. Here's the issue in a nutshell.

The FBI has an Apple iPhone that was the work-phone of a now-dead terrorist. The FBI wants to read what is on that phone. But the phone is encrypted, and runs a secure version of iOS. The FBI wants Apple to make an insecure version of iOS to run on that phone, so that the FBI can break into the phone and read the contents. Apple has, so far, refused.

This issue will no doubt be addressed in the US courts and legislatures. What is at stake is the precedent it sets. The essential question is this: to what extent should law enforcement be able to compel others to assist them with an investigation? Should software developers be expected to make insecure versions of their software, so that law enforcement can "break in"? It will be very interesting to see how this plays out.

/it permanent link

Apple's new Macbook laptop: like a tablet?

I rarely write about Apple's products because they have no shortage of press already: Apple has superb marketing, and many of their products are remarkable in one way or another, often for excellent design and engineering. Their new super-thin Macbook laptop is no exception: it's very thin and light, has a superb high-resolution screen, a carefully redesigned trackpad and keyboard, and is very power-efficient. New to this machine is the fact that it has only a single USB-C port for power, data, and video (it also has a headphone port for audio). Most laptops have many more ports than this. A USB port used for both power and data, and a headphone port, but nothing else, is more typical of a tablet, not a laptop. Indeed, some of the press seems to have really latched onto this "tablet" comparison. Brooke Crothers of Foxnews/Tech claims that the MacBook is "almost a tablet" and states that the MacBook "is an iPad with a keyboard" while Lily Hay Newman of Slate claims that "you should think of the new macbook as a tablet". So how true is this? Is the new MacBook like a tablet?

Well, no, it's not. The MacBook's screen is not touch-capable, and is not capable of being used like a tablet screen. The keyboard and touchpad is an integral part of the machine: it is not optional or detachable. It runs a desktop/laptop operating system (MacOSX), not a tablet operating system such as iOS. The device is not a tablet, it is not "almost a tablet", it is not even like a tablet. It's a small, light, power-efficient laptop. If it must be compared to something, perhaps it can be compared to a netbook, though it has a much better keyboard, touchpad and screen, and is much more expensive.

Then what about the single I/O port? That's simply the consequence of the new USB 3.1 specification, which finally allows a USB connection to deliver enough power to power a laptop, and defines the USB-C connector, which in addition to USB data lines, provides "alternate mode" data lines that can be used for display protocols like DisplayPort. This makes it possible for Apple to build multiport adapters for the Macbook that provide video (e.g. HDMI), data (USB-A) and charging ports, making it unnecessary to provide all those ports separately in the laptop itself.

So does this make the Macbook "like a tablet"? While it is true that tablets have been using single connectors for power and data for a long time, this doesn't make the Macbook tablet-like. It's not the presence of a single shared power/data connector that makes something like a tablet, it's the interactive screen. Yes, a horse has four legs and is often sat upon, but a horse is not anything like a chair.

So will I be getting one of the new Macbooks? Probably not: like a fine thoroughbred, the new Macbook is lovely but rather too expensive for me. The need to buy the multiport adapter separately makes the already high cost of acquisition even higher. The high price doesn't stop me from admiring the design and engineering of this new laptop, but it does keep me from buying one.

/it permanent link

What's wrong with Blackberry? (and some ideas about how to fix it)
Blackberry is in the news a fair bit these days, and the news seems to be all bad. As the firm reports close to a billion dollars in quarterly losses, a Gartner analyst recommends that enterprise customers find alternatives to Blackberry over the next six months. What's the problem?

Basically, fewer and fewer people want to buy Blackberry phones. The problem isn't so much that Blackberries don't do what they're supposed to, it's that people now perceive iPhones and various Android phones as much better choices, and are buying those instead. Why? The reason is that an iPhone or an Android phone isn't the same sort of phone as a traditional Blackberry. An iPhone or an Android phone is a true smartphone, i.e. an "app" phone, a platform that runs a whole "ecosystem" of third party software. A traditional Blackberry is a "messaging" phone, a device that specializes in effective messaging, such as email. Yes, it can run applications too, but that's not its primary function, and it shows.

To illustrate, consider email. Sending email requires the ability to type quickly. A physical keyboard works best for this, one that stretches across the short side of the phone. The screen, located above the keyboard, then becomes roughly square: it can't be very wide, because the phone will then become too wide to hold easily or to fit in one's pocket, and it can't be very tall or the phone will become too long. A square screen is fine for messaging, but for other things that a smartphone might like to do, such as displaying video, one wants a screen that is significantly wider than it is tall. A smartphone handles this by having a rectangular screen: when doing messaging, one holds the phone vertical: the bottom half of the screen then turns into a keyboard, and the top half turns into a roughly square messaging display. When watching media, such as videos, the phone is held horizontal, allowing a screen that is wider than it is tall. Hence the smartphone is useful in a broader set of ways: it is not just a messaging device. Smartphones have become good enough at messaging that many people do not feel they need a dedicated messaging device. Once the smartphone is the only device that people feel they need to carry, there's much less demand for a messaging phone.

Blackberry realized the problem, and tried to create a smartphone of its own. For instance, in 2008, it released the Blackberry Storm. But it became clear that Blackberry's phone OS was not as well suited for general smartphone use as iOS and Android. The Storm was not a commercial success because it did not work as well as competing phones. In response, in 2010 Blackberry bought a company called QNX that had a powerful OS, and started building devices to use it: first the Playbook, released in spring 2011, and then the Z10 phone in early 2013, followed a few months later by the Q10 and other phone models.

The new Blackberry OS works better than the old in delivering smartphone apps, but it was not very mature in 2011, and was available only on a tablet (the Blackberry Playbook). Unfortunately, the Playbook did not sell particularly well because Blackberry badly misrepresented it, calling it the "best professional-grade table in the industry" though it lacked many features of the market-leading iPad, including key messaging features such as a standalone email client. While it could have been a market success if it were marketed as a Blackberry phone accessory, a role it could effectively play, at release it was clearly not a true general-purpose tablet like the iPad. So it accumulated few apps, while Apple's iOS and Google's Android accumulated many. Blackberry realized this fairly quickly, and released an Android application emulation environment for their OS in early 2012, which allowed many Android apps to be easily moved over to the new OS. But few Android developers bothered to make Blackberry versions of their Android apps, given the relatively few Playbooks sold.

In the meanwhile, Blackberry did itself no favours by making it clear that there was no future for its existing phones, while failing to deliver a phone running its new OS for more than a year. This merely encouraged Blackberry users and app developers alike to switch to another platform. When the Z10 phone finally came out in 2013, the bulk of its apps were those that had been written for or ported to the Playbook, a far less rich set of applications than any Android or iOS phone. And while the Z10 is a decent phone that comes with some very nice messaging features, Blackberry did not do an effective job of touting the unique features of the Z10 that iPhones and Android phones do not have. Moreover, the price was set high (about the same as an iPhone or high end Android phone) and Blackberry produced a huge number, expecting to sell a great many. Some sold, but many didn't, and Blackberry's recent $1B loss was due primarily to writing down the value of unsold Z10s.

Blackberry sits today in a difficult position. No, it is not about to go out of business: the company is debt-free and has a couple of billion dollars in the bank. But its smartphone is not selling. What should it do now?

Blackberry's best chance at this point to make its smartphone platform viable is to take its large inventories of written-down Z10 phones and sell them cheaply, using a renewed marketing campaign that focuses on the unique features of the phone's software. The Z10 hardware is really no different than the various Android and iPhone models out there: if the phone is to sell, it has to be on the basis of what makes it unique, and that's the Blackberry OS software. For instance, Blackberry should show everyone the clever virtual keyboard that supports fast one-handed typing, the unique messaging hub, and the "Blackberry Balance" software that lets you separate work items from personal items on the phone. Blackberry needs to hire the best marketing people in the world to help get the message out. This is a "make or break" situation for the platform.

Secondly, Blackberry should modify the OS to run Android apps natively, without repackaging. Android app developers are not going to repackage their apps for Blackberry. Blackberry needs to recognize this and make sure that Android apps will appear automatically on Blackberry devices. Blackberry will need to find a way to get Google Play (the Android app store) ported to the platform. It is too late to build a separate app ecosystem around the Blackberry OS: it has to leverage an existing ecosystem, or die. Android is really the only viable option for Blackberry right now.

Finally, Blackberry needs to recognize that a niche market for dedicated messaging devices exists, and continue making devices that are the best messaging phones available, while tapping into an existing app ecosystem. Blackberry needs to be careful not to compromise the devices' effectiveness for messaging: it should pay attention to how people use the devices in the real world, and address quickly whatever issues they have. If Blackberry can't find a way of building such messaging devices using its own OS, it should switch to Android. Blackberry knows how to make superb messaging phones, and it should find a way to continue to do what it does best.

/it permanent link

Cloud Computing: Everything Old is New Again
There is a great deal of hype about Cloud Computing at the moment, and it's getting a great deal of attention. It's no wonder: when firms such as Netflix, with a market capitalization of over U$15B, use cloud computing to deliver streaming video services to nearly forty million customers around the world, and when the US Central Intelligence Agency spends U$600M for cloud computing services, people take notice. But what is it all about?

Cloud computing is not really a new thing, it's a variation of a very old idea, with a new name. In the 1960s, when computers were large and expensive, not everyone could afford their own. Techniques for sharing computers were developed, and firms arose whose business was selling time on computers to other firms. This was most commonly described as "timesharing". IBM released its VM virtualization environment in 1972, which allowed a mainframe computer to be divided up into virtual computers, each for a different workload. A timesharing vendor could buy and operate an IBM computer, then rent to their customers "virtual computers" that ran on that machine. From the customer's perspective, it was a way to obtain access to computing without buying one's own computer. From the vendor's perspective, it was a way of "renting out" one's investment in computer infrastructure, as a viable business.

Today, cloud computing, as did timesharing in the past, involves the renting of virtual computers to customers. The name has changed: then, it was called "timesharing"; now, "cloud computing". The type of physical machine has changed: then, a mainframe was used to provide computing services; now, a grid computer. The interconnection has changed: then, leased data lines were typically used; now, the internet. But the basic concept is the same: a vendor rents virtual computers to customers, who then use the virtual computers for their computing, rather than buying their own physical computers.

The advantages and disadvantages of today's cloud computing echo the pros and cons of yesterday's timesharing. Advantages include risk sharing, the ability to pay for just the amount of computing needed, the option to scale up or down quickly, the option to obtain computing resources without having to develop and maintain expertise in operating and maintaining those resources, and the ability to gain access to computing resources in very large or very small quantities very quickly and easily. Moreover, cloud computing vendors can develop economies of scale in running physical computers and data centres, economies that they can leverage to decrease the cost of computing for their customers. Disadvantages of cloud computing include possibly higher unit costs for resources (for example, cloud data storage and data transfer can be very expensive, especially in large quantities), a critical dependance on the cloud computing vendor, variable computing performance, substantial security and privacy issues, greater legal complexity, and so on. These tradeoffs are neither surprising nor particularly new: in fact, many are typical of "buy" vs. "rent" decisions in general.

Then why does cloud computing seem so new? That, I think, is an artifact of history. In the 1970s and early 1980s, computers were expensive and timesharing was popular. In the 1990s and early 2000s, computers became increasingly cheaper, and running one's own became enormously popular. Timesharing faded away as people bought and ran their own computers. Now the pendulum is swinging back, not driven so much by the cost of computers themselves, but the costs of datacentres to house them. A few years ago, Amazon Inc. saw a business opportunity in making virtual machines available for rental: it was building grid computers (and datacentres to house them) for its own operations anyway; why not rent out some of those computing resources to other firms? In so doing, Amazon developed an important new line of business. At the same time, a huge number of new internet firms arose, such as Netflix, whose operations are dominantly or exclusively that of providing various computer-related services over the internet, and it made a great deal of sense for such firms to use Amazon's service. After all, when a company's operations are primarily or exclusively serving customers on the internet, why not make use of computing resources that are already on the internet, rather than build private datacentres (which takes time, money and expertise)? These new internet firms, with lines of business that were not even possible a decade or two ago, and Amazon's service, also only a few years old, have lent their sheen of newness to the notion of "cloud computing" itself, making it appear fresh, inventive, novel. But is it? The name is new, yes. But in truth, the concept is almost as old as commercial computing itself: it has merely been reinvented for the internet.

Of course, the computing field, because of its inventiveness, high rate of change and increasing social profile, is rather at risk of falling into trendiness, and cloud computing certainly has become a significant trend. The danger of trendiness is that some will adopt cloud computing not on its own merits, but solely because it seems to be the latest tech tsunami: they want to ride the wave, not be swamped by it. But cloud computing is complex, with many pros and cons; it is certainly a legitimate choice, as was timesharing before it, but it is not necessarily the best thing for everyone. It's easier to see this, I think, if we look beyond the name, beyond the trend, and see that the "rent or buy" question for computing has been with us for decades, and the decision between renting virtual machines and buying physical ones has often been complex, a balance of risks, opportunities, and resources. For an internet firm whose customers are exclusively on the internet, renting one's computing assets on the internet may make a great deal of sense. For other firms, it may not make sense at all. Deciding which is true for one's own firm takes wisdom and prudence; a healthy dose of historical perspective is unlikely to hurt, and may help cut through the hype.

/it permanent link

Intel desktop CPU price-performance: Hyperthreading not helping?
Typically, CPU prices follow performance. Faster CPUs command higher prices; slower CPUs are available for less. Recent Intel desktop CPUs continue to show this general pattern, but there appears to be more to the story than usual.

At first glance, everything seems to be what you would expect. Using current pricing in US$ at time of writing from newegg.com, we get:

Processor	PassMark	Price	PassMark/$	Price-Performance vs G640
Pentium G640	2893	$79	36.6	100%
i3-2120	4222	$125	33.8	92.2%
i5-3570	7684	$215	35.7	97.6%
i7-3770	10359	$310	33.4	91.3%

The PassMark (http://www.cpubenchmark.net/) to dollar ratio is pretty consistent across all these processors, roughly 35 ± 2.

But what happens if we look at a more real-life benchmark? Consider SPEC CPU 2006 Integer (CINT2006) Baseline. For each CPU, I used the CINT2006 Baseline results from the most recently reported Intel reference system, as reported on spec.org. In the case of the G640, no Intel reference system was reported, so I used the results for a Fujitsu Primergy TX140 S1p.

Processor	CINT2006 Base	Price	CINT/$	Price-Performance vs G640
Pentium G640	34.4	$79	0.44	100%
i3-2120	36.9	$125	0.30	67.8%
i5-3570	48.5	$215	0.23	51.8%
i7-3770	50.5	$310	0.16	37.4%

When looking at CINT2006 Baseline, we see the price-performance ratio drop off dramatically as the processor price increases. We would expect this from the i3 to the i5, since SPEC cpu int is a single job benchmark and the i3 to the i5 represents a transition from two to four cores, but it's curious to see the dropoff in the price-performance ratio between the G640 and the i3 (both dual-core CPUs), and the i5 and the i7 (both quad-core CPUs). What might be going on?

A look at hyperthreading may provide some answers. Intel hyperthreading is a feature of some Intel CPUs that allow each physical core to represent itself to the OS as two different "cores". If those two "cores" simultaneously run code that happens to use different parts of the physical core, they can proceed in parallel. If not, one of the "cores" will block. The i3 and i7 CPUs offer hyperthreading, the Pentium G and i5 do not. It turns out that the PassMark benchmark sees significant speedups when hyperthreading is turned on. SPEC CINT2006, and many ordinary applications, do not.

What about SPEC CINT2006 Rate Baseline, then? The SPEC CPU Rate benchmarks measure throughput, not just single-job performance, so maybe hyperthreading helps more here? Let's see:

Processor	CINT2006 Rate Base	Price	Rate Base/$	Price-Performance vs G640
Pentium G640	61.7	$79	0.78	100%
i3-2120	78.8	$125	0.63	80.7%
i5-3570	146	$215	0.68	87.0%
i7-3770	177	$310	0.57	73.1%

If we look at the transition from two to four cores (by comparing the i3 to the i5), we now see that the price-performance of the i5 is better than the i3: this is no surprise, since we are now measuring throughput, and from the i3 to the i5, we go from two to four cores. But there still is a dropoff in price-performance between the Pentium G and the i3, and again between the i5 and the i7. It's not as extreme as before, but it is still significant. This suggests that hyperthreading may help with throughput, but not as much as the increase in price would suggest.

What does this mean, then? It suggests the increase in price from a non-hyperthreaded to a hyperthreaded Intel desktop processor may reflect more an increase in PassMark performance than an increase in real performance. Hyperthreading may have a positive effect, it seems, but typically not as much as PassMark suggests. At present, for best real-world price-performance in Intel desktop CPUs, I would consider models without hyperthreading.

/it permanent link

How to avoid being fooled by "phishing" email.
A "phishing" email is an email message that tries to convince you to reveal your passwords or other personal details. Most often, it tries to send you to a website that looks like the real thing (e.g. your bank or your email provider) but is really a clever duplicate of the real website that's set up by crooks to steal your information. Often the pretence looks authentic. If you fall for it and give your password or other personal details, criminals may steal your identity, clean out your bank account, send junk email from your email account, use your online trading account to buy some penny stock you never heard of, send email to all the people in your address book telling them you're stranded in a foreign country and need them to wire money immediately, or do any number of other bad things.

But there's a really easy way to avoid being fooled by phishing messages. If you get a message that asks you to confirm or update your account details, never, ever go to the website using a link that is in the email message itself. Remember, anyone can send you a message with any sort of fraudulent claim, containing any number of links that pretend to go to one place, but really go to another. So if you feel you must check, go to the website that you know for sure is the real thing: use your own bookmark (or type in the URL yourself), not the link in the message.

/it permanent link

Gigabit ethernet, and Category 5, 5e cabling.
There seems to be lots of folklore that says that Category 5 (Cat5) cabling can't run gigabit ethernet. Contrary to widespread belief, that's mostly false. Here's the situation. Cat5 has the bandwidth to run 1000baseT. But early experience with 1000baseT showed that 1000baseT was pickier about certain cabling issues that weren't specified in the Cat5 standard, such as crosstalk and delay skew, so the Cat5 standard was enhanced for 1000baseT to enforce limits on these. This enhanced standard is called Cat5e. But the fact is that most Cat5 installations already perform to the Cat5e spec.

If someone tells you to rip out a Cat5 installation because it can't support 1000baseT, you're being prompted to do something that is expensive and probably unnecessary. All you generally need is test the existing cables to the Cat5e standard (using a Cat5e cable tester) and replace the ones that fail. Often, most if not all the cables will be fine. Or just use the cables for 1000baseT and replace any that exhibit problems.

Cat6 and Cat6a are a different matter. Cat6 supports a spectral bandwidth of 250MHz, up from Cat5/Cat5e's 100Mhz, while Cat6a supports 500Mhz. Cat6 cabling will run ten gigabit ethernet (10GbaseT) to 37-55m, while Cat6a will run 10GbaseT to 100m. So it's worth choosing Cat6 or Cat6a over Cat5e for new cabling, if the cost increment isn't too high, so that the cabling can support 10GbaseT, even if it's not needed today.

/it permanent link

Exchanging files in docx format may lead to problems
When Microsoft came out with Office 2007, the default save format for files was switched to a new format based on XML. For Microsoft Word, for example, instead of files being saved in .doc format by default, they were now saved in .docx format. If you use Microsoft Word 2007 or 2010, you'll notice that when you save a Word document, it saves it as document.docx instead of document.doc.

Unfortunately, now there seems to be an incompatibility between how Word 2007 and Word 2010 interpret .docx files. Apparently, possibly depending on how one's printer is configured, when users of Word 2007 and Word 2010 share files in .docx format, some spaces (seemingly random) between words in the file are dropped.

This has been reported on various places on the net including the CBS Interactive Business Network, cNET.com, and Microsoft's own user forums.

For now, I suggest using the older .doc format for users of different versions of Microsoft Word to exchange documents. For publishing documents, instead of using a native Word format, I suggest using a widely-used open document standard like PDF. CutePDF is a useful free Windows printer driver that lets you create PDF files from any Windows application by simply printing to a CutePDF printer.

/it permanent link

What's right about ikiwiki?
Chris Siebenmann pointed me today at ikiwiki. It's a wiki that can also function as a blog. It's potentially interesting, he said. And he was right: to me, it seems definitely interesting. I've only started looking at it, but there's something about it that I like very much, something it does right that most web 2.0 applications seem to do wrong: ikiwiki uses the right sort of tool to store the wiki text. What's the right tool? In my opinion, it's a revision control system (well, to be more exact, a filesystem coupled with a revision control system).

Why is this the right tool? Well, what's wiki data? It's a collection of edited text documents. Databases, such as those used by most wikis and blogs, are designed for large collections of data records, not documents. Yes, they can handle documents, but using them for a collection of documents is like using a tractor-trailer for a trip to the beach. Yes, you can do it, but it's a bit excessive, and you may end up stuck in the sand. On the contrary, it seems to me that a filesystem, not a database, is the appropriate tool for document storage, and a revision control system, not a database, is the tool of choice to keep track of document edits.

Then why do so many wiki and blog implementations use databases such as mysql or postgres as their back-end? I don't know. I suspect it's a lack of imagination: when you're holding a hammer, everything looks like a nail. In fact, "lite" versions of these databases (e.g. sqllite) have been created to take advantage of the fact that the full power of these database systems are not needed by many systems that use them. But "lite" databases for wiki/blog back-ends seem to me to be like cardboard tractor-trailers: still the wrong tool, but with some of the overkill stripped out.

Even more to ikiwiki's credit than the fact that it has what I think is the right sort of backend, it also allows you to use a wide array of different revision control systems (svn, git, cvs, mercurial, etc.), or even no revision control system at all. I like this. Revision control systems seem to be a matter of widely varying preference, and ikiwiki's agnosticism in this regard makes it appealing to a wider array of users.

I've only started looking at ikiwiki, and it may be that in the end, I'll decide I don't like it for some reason or another, but whether I end up liking it or not, or whether we use it or not, I think ikiwiki is right in using a revision control system instead of a database for its backend. I wish it were not so rare in this respect.

/it permanent link

Adding logout to Firefox: making HTTP authentication more useful.

The HTTP protocol (on which the world wide web is based) offers two forms of simple authentication that are built into pretty much every web browser: Basic authentication and Digest Authentication. For both these authentication mechanisms, the web browser obtains authentication information from the user and retains it to submit to the web site on the user's behalf. A set of authentication information retained for a site by a running web browser is called an authenticated session.

Unfortunately, in most web browsers, including Firefox, there is no easy way to delete that information. Hence once you are authenticated to a web site as a particular user, your web browser will continue to authenticate you to that web site as that user until you exit your browser. It's easy to see this in action: simply go to a site that requires basic or digest authentication, authenticate, browse somewhere else, then return to that site. Did it ask you to enter your password again? No, it remembered who you had authenticated as before, and connected you immediately as that user.

This is often what you want, but not always. Sometimes you might want to logout as one user and login as a different user. You can't easily do this in most web browers without exiting and restarting the browser. Or perhaps you may want to allow someone else to use your web browser, and you don't want to give them your access to certain sites. It would be useful to be able to clear your authenticated sessions.

Some web browsers, such as Firefox, permit clearing all internal authentication and identification information: cached data, cookies and authenticated sessions. In more recent versions of Firefox, the feature is called private browsing, and is focused primarily on browsing without leaving privacy information behind. But this is a pretty blunt instrument: all potentially sensitive data is cleared, such as cookies, not just authenticated sessions. What if all you want to do is log out?

My HTTP logout add-on for Firefox is intended to change this. It adds two menu options to Firefox, one on the Tools menu, and the other on the menu you get when you right-click on the background. In each case, the menu option is called HTTP logout all, and if you select it, it will clear all authenticated sessions in your running web browser. You can easily try it: after installing the add-on, go to a site that requires basic or digest authentication, and authenticate. Now choose "HTTP logout all", and reload/refresh that page. It will not recognize you as the person who had logged in before, and will ask you to log in again.

I'm not the only person who wants the ability to log out when using HTTP authentication. Many of us who have implemented web sites using Basic or Digest authentication have often been asked by users "How do I log out"? On this topic, the Apache foundation writes:

        Since browsers first started implementing basic authentication,
        website administrators have wanted to know how to let the user log
        out. Since the browser caches the username and password with the
        authentication realm, as described earlier in this tutorial, this
        is not a function of the server configuration, but is a question
        of getting the browser to forget the credential information, so
        that the next time the resource is requested, the username and
        password must be supplied again. There are numerous situations in
        which this is desirable, such as when using a browser in a public
        location, and not wishing to leave the browser logged in, so that
        the next person can get into your bank account.  

        However, although this is perhaps the most frequently asked question
        about basic authentication, thus far none of the major browser
        manufacturers have seen this as being a desirable feature to put
        into their products.  

        Consequently, the answer to this question is, you can't. Sorry.

        - Apache 1.3 documentation.

/it permanent link

Startssl: a better approach to SSL certificates
Perhaps one of the highest profit-margin businesses on the internet is the provisioning of domain SSL certificates. The reason: prices for domain SSL certificates are often very high: up to hundreds of dollars for a 1yr domain certificate, but the cost of producing them is often very low: generally, all that is needed is a simple automated web site that authenticates via email. Typically no human being needs to be involved. Then why do they cost so much money? Probably because only a few certificate vendors are trusted by default in the major web browsers. Nobody wants to use a certificate that is not trusted by default in all the major web browsers, because that would mean a person using one of those browsers will, by default, see scary messages whenever (s)he tries to access the site.

Traditionally, SSL certificate vendors have competed by advertising, each attempting to convince customers that it is more trustworthy than the other guy and thus worth paying more for. But this is generally irrelevant: if the brower trusts the SSL certificate by default, the site will work out of the box, without any scary messages, and the only people who are going to even notice which vendor is used are those who stop to examine the SSL certificate in detail. Few do.

It would be nice (for SSL certificate customers at least) if SSL certificate vendors would start to compete more by price instead. There has been some of that in recent years, but the price of a one year simple domain SSL certificate is still upwards of U$10, with prices most often several times that amount. This is a lot of money for something that is pretty close to zero-cost to create.

Recently, things have started to change. In 2009, Startcom became trusted as a certificate authority by all the major browsers (IE, Firefox, Safari, Chrome). But Startcom is not a traditional SSL certificate vendor. Instead of charging per certificate, Startcom's Certification Authority gives away certificates for free, and charges instead for various authentication services. Simple authentication (the sort that can be done automatically through sending email to a known address and then asking the person to enter into a webpage the secret code that was sent) is free, because it can be fully automated, and thus done cheaply. Once authenticated, the person can generate an unlimited number of the most common sort of domain SSL certificates (1 yr single domain name). More extensive authentication, the sort that requires the participation of a human being to verify a person's identity documents, costs a modest amount of money (U$40/yr). Once authenticated at this higher level, the authenticated person can generate as many as necessary of the less common sort of domain SSL certificates (e.g. 2yr, or wildcard). More extensive authentication services are available, at additional cost. Thus startcom charges for the sort of services that are more intrinsicly expensive (e.g. services that require the attention of a human being, such as extended authentication), and not for automated services that are entirely performed by computer (such as certificate generation). This seems much fairer to the customer.

Is this the future of SSL certificates? I suspect most of the SSL certificate vendors would prefer it not to be: SSL certificate generation is quite profitable at the moment. But it is better economics: the price being charged more closely approximates the cost to offer the service. So if the market for SSL certificates is to more closely approximate a free market, startcom's approach seems quite promising.

/it permanent link

What's Good About Twitter?
Twitter has a mixed reputation. Negative views generally express the notion that Twitter is pretty much useless , or is a massive waste of time. Indeed, there is no shortage of evidence for this view. What is the usefulness of knowing that someone is brushing their teeth, or having cereal for breakfast? Probably not much. The problem is that "What are you doing?", the question that a tweet is allegedly supposed to answer, is often not very interesting. What one is thinking, what one has stumbled across, or what one wants to tell the world, could be much more interesting.

One very useful purpose Twitter serves is to announce new articles, blog entries, events, or news items when they appear. Twitterfeed makes this easy: it will check an Atom or RSS feed periodically, and automatically tweet the titles and URLs of new articles to Twitter, allowing anyone following the tweeter to be made aware of the new material. For example, my department now uses Twitter to disseminate its news and events.

So is Twitter a waste of time? Is Twitter useless? Only if one takes Twitter's "What are you doing?" too literally. Indeed, some seem to feel the need to tell others whenever they're yawning, scratching an itch or drinking coffee. Clearly this is not the most interesting of material. But, on the other hand, if one uses Twitter to follow information sources (people or organizations) with a high information content, and/or to disemminate such information oneself, it can be very useful indeed.

/it permanent link

How well do Java Virtual Machines Scale Up?
Java seems to be a popular language for small to medium-sized applications and its use at that scale is well understood. But what happens when you scale it up to something quite large? It seems that very large Java Virtual Machines (JVMs) are still rather rare. Blackboard is a Java-based learning management system (LMS) now in use at the University of Toronto. The University is rather large, with a great many courses and students, and its Blackboard JVM is correspondingly huge. It turns out that an ordinary off-the-shelf JVM suffered some unusual and unpleasant performance issues (mostly related to garbage collection) when scaled this large. The university and Sun Microsystems eventually resolved the issues quite nicely (using the new and still somewhat experimental Java G1 garbage collector) but it was an eventful journey. John Calvin of the University has put together a rather interesting talk about this, which will be given at the university on June 23rd, and later this summer at BBWorld 2009.

/it permanent link

Understanding Portable Displays
Perhaps the most important thing about a portable computer, be it a notebook, netbook, PDA, smartphone, or internet tablet, is what it provides you versus what it demands from you. One of the most important things a portable machine provides is logical screen area or screen resolution: the amount of data it can show you on the screen at one time. But of the most important things a portable machine requires/demands is weight: what does it take to carry it?

Screen resolution is measured as a grid of pixels (dots) in width x height format, e.g. 1024x768 means a screen that is 1024 dots wide and 768 dots high. Weight is of course not the only thing that determines portability: size is important too, but generally larger machines are heavier and smaller ones are lighter, so weight is a good shorthand for "weight and size".

A quick way to approach the costs and benefits of a portable computer is to compute the ratio of its benefits (e.g. screen resolution) to its portability cost (e.g. weight). So a quick assessment of a portable computer is to compute its pixel to weight ratio: if the weight ratio is high, the portable computer may compare better to one that has a lower pixel to weight ratios. I've written a little tool to compute this information (in units of pixels per milligram, i.e. ppmg), at http://www.cs.toronto.edu/~jdd/screenspec.cgi.

Pixel to weight ratio isn't quite enough, though, because there are limits to human sight: a portable computer is of no use if the pixels are so small that they cannot be easily seen. "Too small" depends on the distance the screen is from one's eyes. I tend to use devices like cellphones and PDAs at a distance of 18 inches from my eyes, and laptops at 24 inches. Generally, distance multiplied by the pixels per inch of the screen is a constant. For example, for me, I'm quite comfortable with 170 ppi at 24 inches, but beyond that, I feel some eyestrain. At 18 inches, that works out to (170 x 24) / 18 = 227 ppi. In my (anecdotal) experience, many people seem comfortable with 125ppi at 24 inches and 167ppi at 18. Of course, there is much more to this than a simple ratio: tolerance for high pixel densities varies depending on what the person is doing, what fonts are being used, and many other things.

Still, a pixel to weight approach lets one compare machines in interesting ways: for example, an Apple Ipod Touch has a 3.5" 480x320 screen and weighs 115g; that's 164 ppi and a pixel to weight ratio of 1.3. This is comparable to a Nokia E90 Communicator, which has a 4" 800x352 screen and a weight of 210g; its ppi is 218 and pixel to weight ratio is 1.34. But now consider a Nokia N810 Internet tablet: its 4.13in 800x480 screen (ppi is 225) and weight of 226g gives a significantly higher pixel to weight ratio of 1.69. But with ppi around 220 vs. the Ipod's 164, either Nokia device may result in eyestrain where the Ipod Touch does not.

Now look at some notebooks. A (large and heavy) Dell Vostro 2510 notebook weighing 5.72lbs with a 15.4" WUXGA (1920x1200) screen offers 147ppi and a pixel to weight ratio of 0.9, which is (perhaps surprisingly) a higher pixel to weight ratio than a (small and light) netbook, the Dell Mini 10 with the new high-resolution 10" 1366x768 screen (ppi of 155); its weight of 2.86lbs results in a lower pixel to weight ratio of 0.8 (at a slightly higher ppi, too). Compare this to a Macbook Air: with a 13.3" 1280x800 screen, it weighs 3 lbs; its pixel to weight ratio is 0.75. Unlike the other too, though, the Macbook air has an easier-to-read ppi of 113.

Of course, this doesn't mean that one should pick portable computers based solely (or even mostly) on pixel to weight ratios, or ppi for that matter. It is merely one possibly useful way to compare portable machines, and should be at most only one criterion among many, when making a decision.

/it permanent link

Why a netbook?
What is a netbook anyway? It's a new type of low-cost ($350-$600) notebook that is particularly small and light: it typically has a 7-10" screen, and a weight not much more than two pounds. Small and light notebooks are not new, but they have for years been quite expensive, marketted to busy executives who want something small and light to use when travelling, and are willing to pay for the privilege. But an inexpensive small and like notebook is new, so new that it has been given its own name: netbook. The rationale behind the name is that this meant to be an "internet" device: its primary role is web browsing, and office productivity applications are secondary. Such a device relies on wireless: wifi for now, but increasingly 3G and other forms of cellular data service.

Why buy one? It's affordable, by notebook standards. It's also very portable: while it's too large for a pocket, it can easily slip into a handbag. And while it may be designed for internet connectivity, it can run modest office productivity applications. But it is limited in various ways: the small screen, while generally bright and visible on most models, does not have a great deal of screen real-estate; typically 1024x600 or less. RAM and hard drive space is generally less than most notebooks or desktops, and RAM in particular is limited to a maximum of 1GB or 1.5GB, depending on the model, enough for Linux or Windows XP, but not generally enough to run Microsoft Vista quickly. It lacks any form of CD/DVD drive. And the internal CPU (generally an Intel Atom or a VIA C3) is slow, and single-core. A low-end laptop can be bought for as little as $500-$600 with a much larger screen, more memory, a built-in DVD-writer and a more powerful CPU. But it will be quite a bit larger and heavier. That in the end is the key question: is the portability of a netbook worth its tradeoffs? Sometimes yes: if one's computing needs are modest but one wants one's computer whereever you go, then portability is paramount. Sometimes no: those with more than modest computing needs will quickly run into the netbooks' limitations. But whether or not a netbook or a notebook is a better fit, it is nice to have the choice, for a reasonable price.

/it permanent link

How to buy a Computer
For years I have been asked for my advice about buying computers. My advice has changed over the years, because computers have changed, but one thing seems to be constant: a great many people seem to be very insecure about buying computers. This leads to a great deal of angst, and sometimes to purchases that are much more expensive than they need to be. But there are a few common-sense principles that are generally constant:

1. Think carefully about how the computer is going to be used.
This is the key principle that overrides all others. A computer is a tool. Tools are useful only when they can be used effectively. Do not choose a computer that does not fit with the way you use computers. For example, if you are a small person and like to work in many different places, a large and heavy laptop, or worse, a desktop, will not be a good choice: it is worth investing in something small, light and easily carried. If you are a gamer, particularly if you plan to invest a great deal of time playing games that require high-performance video, you'd best invest in a desktop with high performance graphics, even if it is expensive. Playing a demanding game on a cheaper machine with poor video performance will be frustrating. But if you merely browse the web and run productivity applications like spreadsheets and word processors, investing in high-performance gaming computing is a waste of your money.

2. If a better option is available for a lot more money, choose it only if you know you need it.
Insecurity about buying computers prompts people to pay a great deal more money for things that they think they might need: particularly a fast CPU (the computer's processing unit) or a high-end computer model instead of a lower-end one. The price difference can be significant: a high-end model can cost 3-4x the price of a lower-end model, and a high-end CPU can more than double the cost again. For example, the base configuration of the lowest-end home desktop with the lowest-end CPU on Dell Canada's web site is currently $329; the highest-end base configuration with the highest-end CPU is $3150. That is an order of magnitude difference in price. Put another way, the high-end configuration is the price of a formal dining-room suite. The low-end configuration is the price of a single chair in that dining-room suite. If you are paying the high-end price, make sure you need what you are paying for.

3. If a better option is available for only a little more money, chose it unless you know you don't need it.
If it only costs $20 to get a little more memory, a bit faster CPU, or a potentially useful device like a webcam, a fax modem, or a media card reader, why not get it, especially if it's much more money and less convenient to get it separately later? An integrated webcam is a $20 option on many laptops; adding later an external webcam of comparable quality that clips onto your laptop may cost you as much as $90. Or, for example, a fax modem may sound like obsolete technology, and it is, but it can be very convenient to send a fax from your computer by simply printing to the "fax" printer and typing a phone number. The one exception here is to watch out for large price increments for tiny increases in hard drive size: the price difference between a 250G and a 320G hard drive should be a on the order of $10, not $60-70. While one may argue that there is perhaps some value in paying a bit extra for the convenience of ensuring that your computer comes with a decently large hard disk, even a small hard disk these days is quite large. Another thing to consider: if the price difference between a notebook and a desktop is fairly small, and there is no compelling reason to choose a desktop over a notebook, just get a notebook.

4. Assess carefully your need for extended warranties.
Extended warranties can be expensive. However, if you are accident-prone (coffee over the keyboard, dropping your laptop), anxious or risk-adverse, an extended warranty may be worthwhile, particularly the sort that covers accidental damage. Note, though, that on average one spends much less over the lifetime of the computer to repair it (often $0) than one would pay for an extended warranty. Such warranties are often bought out of insecurity, and are highly profitable for computer vendors and technology stores. If, however, you do not expect to have free funds to handle an unexpected repair, especially if the computer is particularly expensive, an extended warranty may be worthwhile as a form of insurance.

5. Don't panic. Most of the available options are all reasonable choices.
Most computers are quite acceptable: there are few bad choices. Choosing a computer is most often a matter of choosing the best choice from among good choices. So relax: even if you miss the best choice, you'll probably end up with a perfectly good computer.

6. Don't forget backups.
The most valuable part of your computer is your data. Make sure you have backups of it, so that if something bad happens to your computer, you will not lose your data. You can always replace a computer. Can you replace your data? The easiest way to back up data is to buy an external hard disk and copy your data to it. Buy that external hard disk when you buy your computer. Yes, you can back up to writeable DVDs if you want, or copy to flash memory of some sort, but it can be a lot of work to divide up your data into DVD-sized chunks, and backups that are a lot of work often turn into backups that are not done.

/it permanent link

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