Starting June 17, 2004
Dave Winer sendoff dinner, Multics reunion and honoring Prof. Corbato, LZW patent expires, ListGarden RSS Generator
Dave Winer sendoff dinner [link]
There was a dinner last night in Cambridge, Mass., to mark Dave Winer's last Thursday at Harvard. Here are a few pictures:
Multics reunion and honoring Prof. Corbato [link]
Yesterday I attended the Multics Reunion at MIT. It consisted of a symposium during the day and a dinner in the evening honoring the head of the project, Prof. Fernando J. Corbato (known to all as Corby). Multics was a major OS project started in 1965, which influenced many operating systems since, most notably Unix. I worked on it from January 1970 until September 1973. It is where I met Bob Frankston.
The symposium was in the new Ray and Maria Stata Center, a wonderful and breathtaking location. We entered through the Gates Building, the lead donor of which was Bill Gates. (See my photo album from the ceremony sealing the time capsule for that building in 1999.)
The morning talks looked back at Multics, reminisced, and saw what we can learn in hindsight. To learn more about Multics, see the Multicians.org web site.
To me, the most interesting talk was by Paul Karger, now of IBM, based on his December 2002 paper "Thirty Years Later: Lessons from the Multics Security Evaluation". He said that the attacks on computers today are more sophisticated that what they thought even the USSR's KGB would be able to do, and that today's systems are much worse at protecting from them than Multics. In 1972-1974 he had helped the Air Force do a study of Multics (unknown to the Multics people at MIT) by doing "ethical hacking" -- trying to break into the system. (The Air Force wanted to pay Honeywell to beef up the security and were rebuffed because Honeywell thought it was already secure -- they needed to prove otherwise...) He told lots of "war stories" of exploits and mistakes.
Why was Multics so secure? Several reasons, including: Buffer overflows are the single most common source of security vulnerabilities today, but Multics didn't have them. Why: The system was written in PL/I, not C, which handles oversize strings well. The hardware was used (unlike today's x86's) to keep execute bits off on data and to make address overflows fault or wrap back into data and not code or other data. Stacks grew in a positive direction, not negative like today, making it hard to overwrite subroutine return information (the common exploit today). Also, security was a primary goal of Multics, built in from the first -- it was not an option.
Was Multics big? Not by today's standards. The SELinux module (which adds lots of security features to the Linux kernel) is bigger (maybe 2.5x bigger) than the entire 1973 Multics kernel. Windows is much more complicated than that.
The Multics development community, and all installations, had access to the source, most of which was written in PL/I. It was a precursor to the Open Source movement (and included some of their founding members). Even today, most of the Multics source is available online from MIT. (It appears that most of the code I wrote has been rewritten and isn't listed, but I found a comment about keeping in a kludge I'd put in the original code in 1973 using "12/30/99 1859.9 est Thursday" as "end_of_time" for an early personal scheduler called "memo" -- well...I was young...Y2K hadn't happened...)
In the afternoon we heard about current research in Image Guided Surgery. Really cool. Prof. Dennis also gave us the history of Segmentation and the Multics memory system.
We spent a lot of time touring the new buildings. There is no way I can give you a complete feel for this new center with photographs. You just have to find a way to visit the Stata Center if you get to Boston. As I see it, the buildings help you get a feeling of huge diversity (they are anything but regular, in many senses of the word), and help push community and collaboration. All in a small space of a few buildings in the middle of a campus.
Outside -- this is a real, unretouched picture
A lot of very interesting touches: We were told that on one floor, the women's room had lots of stalls while the men's room had very few. On the floor below it is the opposite, encouraging people to go to other floor periodically, avoiding the normal tendency to stay on one floor.
Here's a sign from the men's room explaining how rainwater is used for toilet flushing (not drinking or washing), so don't worry about the "light yellow shade" of the water:
The evening event was a dinner at the Hotel@MIT to honor Prof. Corbato, the head of the Multics project. He was a mentor to most of us, and a friend to all. It was a very warm event. He has made immense contributions to computer science and technology. A graduate fellowship is being established in his honor, and this was the fundraising kick off.
LZW patent expires [link]
As I write this late Saturday night, it is now Sunday in Japan. According to the Unisys web site's "LZW Patent and Software Information" page, "The U.S. LZW patent expired on June 20, 2003, the counterpart Canadian patent expires July 7, 2004, the counterpart patents in the United Kingdom, France, Germany and Italy expire June 18, 2004, and the Japanese counterpart patents expire June 20, 2004." It's over. The inadvertent choice by CompuServe to use LZW compression in the GIF format, followed by the decision to use GIF as the built-in format for lossless image compression in browsers, and then the decision by Unisys to widely charge IT-style prices for use of their patent on LZW, is behind us. (There's material on the web about the issue.)
The problems the entire software industry needed to deal with because of this patent and its relationship to a "can't live without it" format (that incorporated the compression technique at a time when there were no licensing fees) are many. There are lots of stories to be told (that aren't available on the web, yet). There are lots of lessons to be learned. I don't have time to discuss them tonight, but I've had this day on my calendar for a long time. I wanted to mark the occasion of the lifting of an issue that was an expensive, major problem for software product companies. You would think that such companies would have had little problem with a very minor part of their products, but they did.
ListGarden RSS Generator [link]
I'm working on another program in my quest to get back into the swing of programming and releasing products. It's finally ready for testing, though not for formal release. Like ServerTest, it stems from my own needs.
Last year, I wrote a simple RSS feed generator to use for this weblog. Since I use the old Trellix client-side web site creation tool to author this weblog, I needed to use something else to maintain an RSS feed. As I posted back then, I threw together a little Perl application which I've used ever since. Periodically, I've gotten requests from others in a similar situation for a copy. It was never intended for use by others (it needed special setup on a web server), so, I've rewritten it as more polished program.
The program is called the ListGarden™ RSS Generator Program. It creates and maintains RSS feeds. Written in Perl, it runs either locally on a PC (or Mac or Linux box) or on a web server. The user interface is through a browser. When run locally, it does its own HTTP serving. It can upload the resulting XML file to a web server by FTP. It's another step on my road to trying out different UI schemes and development platforms.
Right now I've only posted the Windows client-side ".exe" version in beta form, since that was the easiest to document and the one most in need of external testing. I'll follow it with a normal Perl version (client-side and server-side) next week or so. Based on feedback, I might add some additional features.
The beta version is with a "download for free, don't distribute or modify" license. For the final release, I am thinking about releasing this under GPL, not my "noncommercial free" license. This seems like an appropriate product to experiment with using GPL. I'll write more about that when I do the final release.
I've posted a write up about ListGarden on a hidden page on the Software Garden web site, and it links to a page with download instructions. Let me know what you think.
Read "ListGarden Product Description".
ListGarden only produces RSS 2.0 at this point (as did my original program last year). I figure that should be good enough for now for most aggregators. The only other format I thought about was Atom. The "right" way to do Atom would be to use the XML::Atom CPAN library which is not in most Perl installations, and I didn't want to make the installation process more complicated by requiring that, especially not for a specification that is still "pre-draft".
© Copyright 1999-2018 by Daniel Bricklin
All Rights Reserved.
See disclaimer on home page.