Seams? I meant chasms.

Microsoft says: Don’t trust Microsoft

(via my O’Reilly blog)

There’s a new security hole in Microsoft software. An ActiveX control, supplied and signed by Microsoft, can run arbitrary programs on your computer. Microsoft has issued a fixed control, but there’s still a problem: sites can request the vulnerable version, and it will be fetched and reinstalled.

Microsoft’s solution: remove Microsoft from your list of trusted providers (if you ever put them there, that is).

It’s tempting just to chortle at this, but it illustrates serious problems with the code-signing approach in general. Way back in January 1997 I wrote that the ActiveX security architecture wasn’t actually a security architecture; at best it’s a blame-assignment architecture. I believe that even more today.

I’ve worked on projects that do code signing. And there are big security holes in the whole process. Think about how organizations work. Too many people will have access to the signing key. Signing becomes part of the automated build process, and it stays there even if security audits fall by the wayside. (Assuming, of course, that there ever were security audits.) You have to be careful with trusting individuals. Why would you ever grant blanket trust to a corporate entity?

Ken Thompson was right. The problem of trust runs deeper than technology.

Journalling is on

I’ve been running OS X.2.2 for over a week, and today I turned on the new journalling support in the file system. Supposedly it’ll slow my system down a bit (presumably just on writes to disk), but I want the assurance that my file system will be OK after a crash.

This morning I was copying something to my iDisk, and it bogged down. I had to get to work, so I tried clicking Cancel, but the Finder was unresponsive. I finally had to just unplug and go.

When I got to work and opened the machine again, things were still stuck. I tried a restart, but 10 minutes into the shutdown process, looking at a machine that wasn’t doing anything, I powered off. The fsck on reboot found a lot of things to fix. I hope all my data is OK, but in any case, it’s time for the safeguard of the journalling filesystem.

Still a few bugs in the system …

(via my O’Reilly blog)

I’ve been amazed at how well Google’s news service works. But no matter how good the technology is, occasional mistakes are inevitable when computer programs try to compile and correlate news headlines from lots of different sources. Today, some of the seams really showed.

In the “Top Stories” section at the top of the page, there’s always a subsection called “In the News” that contains a short list of topical links: topics that seem to be getting a lot of coverage, but haven’t made it to the prestige positions that include headlines and pictures. The links in “In the News” aren’t headlines. Instead, they’re topic keywords that have been extracted from the headlines by the Google software. Things like “Tel Aviv,” “Harry Potter,” and “NATO Summit.”

Today I noticed three topics in particular: “Our Man Flint,” “Magnificent Seven,” and “Academy Award.” It’s clear what’s going on therenews outlets are writing about the death of James Coburn, and Google is picking up on references to his achievements and most famous films in the headlines. But when I clicked on the topics, things got even more interesting.

The page for Our Man Flint was 10-for-10. All the stories were about Coburn. Academy Award was somewhat mixed, since there are other Oscar winners in the news this week.

But I was really surprised when I clicked the link for Magnificent Seven. Just looking at the first ten hits, I learned:

I don’t mean to take anything away from what Google has achieved. All things considered, it works amazingly well. And quite frankly, occasional strange juxtapositions like this can be goodthey add an element of the serendipity that’s present in a real newspaper, where you can occasionally run across a fascinating article that you never would have looked for.

Think about it. I’ll probably watch at least one of those Coburn movies on TCM Sunday night. The story about the horses was interesting, and I was surprised to learn that five years have gone by since the McCaughey septuplets were born. And it’s interesting that the producer of the film and one of its stars died during the same week.

I learned one more thing, too. All of those stories included the words “Magnificent Seven”—most of them in the headline. The name of the film has entered our language. That, in itself, says something about the legacies of James Coburn and Marvin Mirisch.

Agility for students, revisited

Since writing about teaching agility to computer science students, I’ve had a few more ideas, plus excellent suggestions from Patrick Linskey and Michael McCracken.

Patrick’s suggestion (which I can’t believe I didn’t think of myself) is to teach them more about the history of our field. We don’t have to make computer science students scholars of computer history, but we should give them some idea of the rich scope of the topic. Introductory computer courses tend to cover Babbage, Turing, and von Neumann, and then skip straight to Bill Gates. And for most CS students, that’s the end of it.

Michael’s suggestion is this:

… professors often understand the distinction between teaching skills for their own sake and teaching them as applications of more general principles. It’s important to convey that to the students as well. Giving an idea of trends and perspective helps breed the kind of healthy skepticism about tools and paradigms that Glenn mentions.That’s absolutely right. All too frequently I meet young programmers who are confused about thatthey think the particular techniques and tools they were taught are the fundamental things.

Here are the other things I’ve thought of:

  • Computer science students should learn, even as undergraduates, to read technical papers, and how to find them. (I have suggestions for anyone who’s looking for seminal papers that are well written and approachable.)
  • Along the same lines as Patrick’s suggestion: teach them about the great personalities of the field. Knuth, Hoare, Dijkstra, Englebart, Kay, Moore, Cray, Cocke, Hopper, Dahl, Thompson, Ritchie, Kernighan, McIlroy, Bentley, McCarthy, Minsky, Wirth, Steele, and many, many others are important not just for their technical contributions, but also for the color and vibrance they’ve brought to our field and its history. Learning about them and their relationships helps bring our past and present to life.
  • Help students to understand that there are communities of developers that they will be joining, and that those communities are where much of the advancement comes from. User groups, mailing lists, wikis, and blogspace are just some examples. Show students how they can be contributors, not just users.
  • Somewhere, years ago, I heard that one of the characteristics of “the professions” (medicine, law, architecture, engineering, etc.) was that professionals were expected to keep their education current. I have some friends who are doctors, and their homes and offices are always full of current medical journals. I often hear people complain that as a field we are not more “professional,” and yet few programmers take that responsibility seriously. It’s amazing how many programmers with years of experience have never read a book about programming (as opposed to just an API reference or tutorial) since they left school. That ethic of continued self-education should be taught to CS students, if they are to call themselves professionals.
  • Students need to leave school with some knowledge of ideas that are out of the mainstream. ZUIs, magic lenses, pie menus. Plan 9, BeOS. AOP, intentional programming, multiparadigm programming. Mob software. And many, many more.

subscribe via RSS