Slashdot Mirror

Another important aspect of slack pops up in Repenning, Understanding Fire Fighting In New Product Development; without it, the system is unstable against transients that tend to draw resources from upstream development (where they are more efficient) into downstream firefighting (where their benefit is more timely). A death spiral results.

Decent paper. Yes, he tends to belabor points the reader should see coming, and the model is clearly simplistic - but these very points might make it accessible for managers, particularly those still enamored of their MBA degrees.

A quick Google search turns up this MIT site as the first hit, which has pointers to where the program can be found. They're still listing version 1.0 beta 2, not changed since July 11, 1996! (I never saw that much interest in it...) People know there are so many ways to compromise /eavesdrop on a conversation, and a computer (even a laptop) is a bulky way to make a phone call.

(God, look at how much cellphone tech has changed in 6+ years!)

The PGPi site lists a PGPfone version 2.1 (Windows and Mac), but notes that NAI has the rights to it:

"PGPfone 2.x is a commercial product, but NAI has shown no interest in it, so it is probably O.K. to use it anyway."

I think you're right, though. There's OpenSSL -- heck, there's OpenSSH, too! Set up a heavily-encrypted tunnel, run your favorite VoIP program through that. Since you have to worry about your computer being trojan-free in either case (both software and hardware), you can use a program that's a lot more mature than PGPfone.

programming has little use for math.

I am told that the courts are trying to make a distinction between
mathematical algorithms and nonmathematical algorithms. To a computer
scientist, this makes no sense, because every algorithm is as
mathematical as anything could be. An algorithm is an abstract
concept unrelated to physical laws of the universe.

Nor is it possible to distinguish between "numerical" and
"nonnumerical" algorithms, as if numbers were somehow different from
other kinds of precise information. All data are numbers, and all
numbers are data.

I'd also love to learn Japanese (have tried at least once... that and several other languages).

What I was wondering was does anybody see a difference in the ethical situation between sharing copyrighted entertainment works and copyrighted educational works?

In my limited experience I would have thought that companies producting educational course material can not really afford to have their work pirated (at least they don't have the massive buffers of cash and revenue the labels have).

On the other hand there are initiatives like MIT OpenCourseware where anyone who wants to access the material is able to without charge (MIT can probably afford to though...)

Should eductaional products be free/subsidised/supported by the industry etc...

There's a tradition at MIT known as the sodium drop. If it's safe enough for them... :)

Annual Robowar tournament champs

You're right... I actually misread this page which states that MIT is the only educational institution with a Class A. Struck me as odd, but I forgot about the universities that gave their class A space back a few years ago.

Anyone have a list of the original class A grants?

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and after initial successes with the 4.1 BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In that same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Yes, there most certainly are other concepts to be introduced first.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

for distribution of widely needed information such as news?

I've read nearly 100 comments so far and while many mentioned the inherent flaws in the "massive webserver" model we currently use for virtually all web news traffic, no one mentioned the alternatives. For things like news distribution television and radio have an incredible advantage (they don't have to double any output to reach twice as many people as normal) but peer to peer systems would also work wonders in situations like this.

Maybe that is the rationale behind project IRIS, the recent US government backed research into a complete network founded on the peer to peer methodology.

www.newscientist.com/news/news.jsp?id=ns99992861

iris.lcs.mit.edu/

"Personal Area Networks" were hyped in 2000, an article here. If you search the MIT media lab's web site you can find a thesis written on this from 1995!

First, 10 Mbps is possible, but that's getting near the theoretical limit. The datarate is limited by the bandwidth, and the bandwidth is limited by the fact that around 50MHz, the signal wavelength is about four times the size of a person, which means the person turns into an antenna, and the whole system becomes essentially a short range radio.

Second, because these systems operate in the near field, the signal travels through a current loop, and not as plane waves in free space. This means that there has to be some kind of grounding path for current to flow back to the transmitter after going through the person. This is why it works so well to put transceivers in shoes -- the ground path can flow through earth ground (or any conductive material in the floor). For devices held in hands, the very small (femtofarad) capacitance of free space is enough, but the signal does suffer more from noise. Devices in purses, etc. also have this problem, and may have difficulty establishing the ground connection depending on the material the purse is made from and the other objects inside it.

One issue that to my knowledge has not been addressed very well is guaranteeing that the signal is received during--and only during--physical contact. There is a large dependence of signal strength on geometry. The devices I've constructed can communicate when they're brought near (~10 cm) of each other, touching or not. There are a few solutions, such as looking at jumps in signal strength, but they tend to be confused when a person without a transceiver happens to touch the object, and a person with a transceiver is nearby. I'm currently working on this problem for my PhD dissertation, so if you have any good ideas or know of related work, I'd love to hear from you.

If you'd like to read more, the first (and most detailed) publication I know about on this idea was Thomas Zimmerman's Masters Thesis at the MIT AI Lab. You find it here: http://www.media.mit.edu/physics/publications/thes es/95.09.zimmerman.pdf

------
Kurt Partridge
Dept. of Computer Science and Engineering
University of Washington
Seattle, WA 98195

So the first reason for "plan first, then code" is that coding is expensive. That expense represents a risk if you're pursuing an approach that doesn't work out. Throwing away a plan is quicker and less expensive.

The second reason for "plan first, then code" is that a written plan is a clear expression of the ideas in the plan. Code is often not very readable or very obvious, and a large body of code may require weeks or months of study to get all the nuances at work.

There is a hidden disadvantage to "plan first, then code". Remember that we're trying to manage the risk of choosing a dead-end approach, so we want to minimize the investment before the discovery that the approach is bogus. A non-executable plan won't catch all the design bugs. It will only catch the design bugs that you can recognize on inspection of a written plan; the screening process is limited by your own human cognitive faculties.

What if we could write an executable plan, in a language that is clear and expressive, and in which writing the plan is inexpensive? This would be the best of all possible worlds! Luckily you're not the first person to face a daunting software design challenge, and people have been designing languages for exactly these constraints for many years (Python, Perl, Scheme, Ruby, Smalltalk, and others. These languages vary in the expressiveness of their syntax. If you're concerned about the mental expense of coding, you probably will want to avoid Perl (which looks a lot like C) and Scheme (which requires a mental paradigm shift). My off-the-cuff recommendation among these would be Python.

Why not write your final product in one of these easy, inexpensive, readable, expressive languages? Alas, many of them don't have the performance of C or C++. If you're doing something computation-intensive, that matters. But wait! There is another saving grace, called SWIG, a program that lets you glue small bits of C or C++ code into your larger program written in one of the easy languages.

In most computer programs, the performance is gated by a small number of small pieces of the code. Usually, the majority of the code does not have a big impact on performance. If you can identify those small performance-expensive bits, and translate them to C or C++ and glue them back into your program, you get the speed you want, and 95% of your code is still readable and expressive, and easy to change later. The trick to finding these performance-limiting bits is called profiling (see 1, 2, 3).

So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python has lots of great libraries, skim the list of libraries as somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about speed yet. Rewrite as required until you're sure you've got a good design.
3. Use profiling to locate the few small pieces that slow down your program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back into your program.

This is not a a first course in programming. Granted, I see nothing on that page or a click away that would tell you what level course this is, and that is clearly a shortcoming of the page. On the other hand, why did the original poster and michael assume this is a beginning course? I just happen to know it's not because I'm an MIT course 6 graduate, who took 6.170 junior year, a pretty normal place for it in the curriculum.

You want beginners to get a good overview of computer architectures and how they relate to software? Fine, that would be covered quite thoroughly in 6.001 and 6.004.

This is not a a first course in programming. Granted, I see nothing on that page or a click away that would tell you what level course this is, and that is clearly a shortcoming of the page. On the other hand, why did the original poster and michael assume this is a beginning course? I just happen to know it's not because I'm an MIT course 6 graduate, who took 6.170 junior year, a pretty normal place for it in the curriculum.

You want beginners to get a good overview of computer architectures and how they relate to software? Fine, that would be covered quite thoroughly in 6.001 and 6.004.

Play it in Java there.

For those of us under 50, here's some history of the granddaddy of all high-level programming languages.

• [Slightly OT] A BRIEF HISTORY OF FORTRAN/Fortran (very brief)
• Cambridge University Dep't of Engineering's brief history of Fortran

IIRC, my former graduate advisor and professor was on the team that wrote a very early Fortran compilers at MIT in the late 50s, written entirely on punch cards. We've come a long way in ~50 years.

hey,

If anyone has even used the strokes-mode in (X)Emacs, I have taken that to the X level by writing what is a higher-level application of gesture recognition. Consider this:

Why should each application implement gestures differently? For example WM commands (close, kill, iconify, maximize, resize, etc.) apply to all windows. Then, within each application, you might imagine some application-specific gestures. This can all be done at the X level. I decided to take the elisp code that's been doing gestures in (X)Emacs since '97 and ported it to Common Lisp (using GNU CLISP). This implementation if CL is GPL'd, and has an implementation of Xlib (called CLX) that plugs right in.

Anyway, CLISP is just about as portable as gcc is, so the same goes for the CL version of strokes.

What I havn't done, though, is to build a nice GUI for editing all the different strokes bindings for all the applications.

I've been playing with the idea of releasing this for years so that people could control all their applications using gestures. I figured that someone probably has done this (though probably not in Lisp, which is a shame).

Are people interested in X-level gestures?

dave

Wow. I didn't know that the Platonic form of the _volklisch_, tech-chauvinist engineer could actually manifest itself in linear spacetime.

Dude, in case you haven't heard: The world is full of people who more intelligent and full-featured than either of us and who can consequently (a) switch industries and professions with absolute ease and (b) be successful at pretty much anything they put their minds to, including your job. When they want to switch, they simply pop back into college or law school or whatever for a couple of years and come out with a shiny new piece of paper and a shiny new set of interests. These are the guys who didn't OSes in their spare time in high school because they were too busy, say,
playing violin.

I know of couple of this last sort (or more accurately, their downmarket consumer versions) personally, and it is a privilege.

Witness this Andy Warhol classic. Or how about this creative abuse of Google's search-term highlight facility?

Or did you mean email spam?

What's interesting is that these SPAM and spam art links are very similar in overall concept to the cellphone ringer art -- take some banal aspect of modern existance and extrapolate some artistic absurdity from it. I love it!

Although it didn't get wide usage, Emacs used to have (still has?) a "mouse gestures" add-on that allows you to map any unique mouse gesture to a key-sequence (which Emacs can then map to pretty much any command -- including user defined ones).
Always meant to try it out, but never got around to it. Wonder if it's still around?

There are a number of other interesting wireless projects which provide some cool / usefull features to 802.11 wifi networks:

NoCat Networks which implement QoS controls on user traffic giving priority to authenticated users.

Janus Wireless is working to improve mobile IP connectivity and integrated peer network services

IRIS which was mentioned recently and is perfectly suited for integration itno wireless networks for large amounts of reliable, distributed data storage.

MIT's GRID routing project which is probably the most similar.

The really cool uses will come when the integrated peer network / wireless network applications become popular an tandem with pervasive 802.11 deployment in homes and offices.

There are a number of other interesting wireless projects which provide some cool / usefull features to 802.11 wifi networks:

NoCat Networks which implement QoS controls on user traffic giving priority to authenticated users.

Janus Wireless is working to improve mobile IP connectivity and integrated peer network services

IRIS which was mentioned recently and is perfectly suited for integration itno wireless networks for large amounts of reliable, distributed data storage.

MIT's GRID routing project which is probably the most similar.

The really cool uses will come when the integrated peer network / wireless network applications become popular an tandem with pervasive 802.11 deployment in homes and offices.

I couldn't agree more. I've been in the system for years and I've seen many bright people become discouraged with the game and give up. Thank god for MIT's OCW.

Well, substituting vowels isn't a big problem regarding understandability. To say it with Steven Pinker: YXX CXN RXXD WXRDS WXTHXXT VXWXELS.

> there seems that there is plenty of evidence that the Wrights were quite ahead of any competition.

I am not disputing that. I am saying that Santos-Dumont had a much better attitude by sharing what he did, and that served better the world than the Wright brothers secret, proprietary attitude.

> When did 14 bis fly? 1906 or was it 1907?

October 1.906. But the Wright brothers only cared to show their airplanes in Europe in 1.908. By that time Santos-Dumont was already developing the Demoiselle, the first ultralight airplane.

> Patents can be licensed. The Wrights expected to make money from their invention. Is that so bad?

Yes, because patents can, don't need to be licensed. It they were RAND, Reasonable And Non-Discriminatory, it would be much better. But the way it is, they actually managed to forbid other people from flying. That is umititaged evil, and contradicts the spirit of patent law.

> You seem to oppose the idea of patents altogether.

No, but I think the current implementation of the concept is counterproductive. Even at the Wright brothers' time, it encouraged them to do things in secrecy, while Santos-Dumont worked in the open. There should be a provision that provided for patents to be granted only to work done publicly. The way it is, the patenting process is a powerful incentive to delay publication for years.

Also, patents should be always RAND. They should reward the inventor, not the manufacturer or distributor.

> Do you think the patent on public key encryption, let's say, was OK, or not?

Software, processes and methods aren't in the original definition of patents, and have proved to be unmitigated evil. They should be stopped now, and all already granted revoked.

Well, duh! Math is math is math. It's based in fact. You can't change it. It's not like they can decide to teach Lagrange multipliers in one school, and Bazooka Joe multipliers in another. However, there are majors other than Course 18.

It's the professors themselves who have a profound impact at MIT. Where else can you take a Biology 101 course taught by Eric Lander (of the Human Genome Project)? Or how about having Sussman teach your intro CS class? How about an Acoustics class taught by the guy who founded the Bose speaker corporation? And those wankers whining about the Big Dig in another thread today? Perhaps they could learn a few things in one of the classes I took, taught by one of the Big Dig masterminds, Fred Salvucci.

Yeesh.

Well, duh! Math is math is math. It's based in fact. You can't change it. It's not like they can decide to teach Lagrange multipliers in one school, and Bazooka Joe multipliers in another. However, there are majors other than Course 18.

It's the professors themselves who have a profound impact at MIT. Where else can you take a Biology 101 course taught by Eric Lander (of the Human Genome Project)? Or how about having Sussman teach your intro CS class? How about an Acoustics class taught by the guy who founded the Bose speaker corporation? And those wankers whining about the Big Dig in another thread today? Perhaps they could learn a few things in one of the classes I took, taught by one of the Big Dig masterminds, Fred Salvucci.

Yeesh.

Well, duh! Math is math is math. It's based in fact. You can't change it. It's not like they can decide to teach Lagrange multipliers in one school, and Bazooka Joe multipliers in another. However, there are majors other than Course 18.

It's the professors themselves who have a profound impact at MIT. Where else can you take a Biology 101 course taught by Eric Lander (of the Human Genome Project)? Or how about having Sussman teach your intro CS class? How about an Acoustics class taught by the guy who founded the Bose speaker corporation? And those wankers whining about the Big Dig in another thread today? Perhaps they could learn a few things in one of the classes I took, taught by one of the Big Dig masterminds, Fred Salvucci.

Yeesh.

http://web.mit.edu/admissions/www/, maybe?

Every 'java' is replaced by:

"Java(TM) Syllabus Calendar Lecture Notes Assignments Exams Required Readings Related Resources Labs Sections/Recitations Tools Projects"

http://ocw.mit.edu/6/6.170/f01/tools/index.html

adds a little TM symbol to every 'java'.

Results in pages that read like Scientology Fan Fiction

Every 'java' is replaced by:

"Java(TM) Syllabus Calendar Lecture Notes Assignments Exams Required Readings Related Resources Labs Sections/Recitations Tools Projects"

http://ocw.mit.edu/6/6.170/f01/tools/index.html

adds a little TM symbol to every 'java'.

Results in pages that read like Scientology Fan Fiction

In 2001 he shared the Takeda award, with Linus Torvalds, and Ken Sakamura. Stallman's share was worth approximately $268,000.

It says here that Stallman also received the Grace Hopper award from the ACM, in 1991. In 1998 he shared the Electronic Frontier Foundation's Pioneer award with Linus Torvalds. And in 1999 he received the Yuri Rubinski Award. I don't know if these awards have any cash component.

Even though he is not a polished presence, he may be able to supplement his savings with speaker's fees. Google tells me he was chosen for the "EECS CITRIS distinguished series", next month. I wonder whether it offers more than a token honorarium?

This sounds like Microsoft's commonly-touted line: "We didn't drive them out of business. Their incompetence drove them out of business." Is he teaching software engineering or business? He should stick to the former, because he's either inept or well-paid when it comes to the latter.

1.4.1 The Netscape Story

For PC software, there's a myth that design is unimportant because time-to-market is all that matters. Netscape's demise is a story worth understanding in this respect.

The original NCSA Mosaic team at the University of Illinois built the first widely used browser, but they did a quick and dirty job. They founded Netscape, and between April and December 1994 built Navigator 1.0. It ran on 3 platforms, and quickly became the browser of choice on Windows, Unix and Mac. Microsoft began developing Internet Explorer 1.0 in October 1994, and shipped it with Windows 95 in August 1995.

In Netscape's rapid growth period, from 1995 to 1997, the developers worked hard to ship new products with new features, and gave little time to design. Most companies in the shrink-wrap software business (still) believe that design can be postponed: that once you have market share and a compelling feature set, you can "refactor" the code and obtain the benefits of clean design. Netscape was no exception, and its engineers were probably more talented than many.

Meanwhile, Microsoft had realized the need to build on solid designs. It built NT from scratch, and restructured the Office suite to use shared components. It did hurry to market with IE to catch up with Netscape, but then it took time to restructure IE 3.0. This restructuring of IE is now seen within Microsoft as the key decision that helped them close the gap with Netscape.

Netscape's development just grew and grew. By Communicator 4.0, there were 120 developers (from 10 initially) and 3 million lines of code (up a factor of 30). Michael Toy, release manager, said:

"We're in a really bad situation ... We should have stopped shipping this code a year ago. It's dead ... This is like the rude awakening ... We're paying the price for going fast."

Interestingly, the argument for modular design within Netscape in 1997 was driven by the desire to go back to small team development. Without clean and simple interfaces, it becomes impossible to divide up the work into independent groups.

Netscape set aside 2 months to re-architect the browser, but it wasnt long enough. So they planned to start again from scratch, with Communicator 6.0. But 6.0 was never completed, and its developers were reassigned to 4.0. The 5.0 version, Mozilla, was made available as open source, but that didnt help: nobody wanted to work on spaghetti code. So Microsoft won the browser war, and AOL acquired Netscape.

This is not the entire story, by the way. Platform independence was a big issue right from the start. Navigator ran on Windows, Mac and Unix from version 1.0, and Netscape worked hard to maintain as much platform independence in their code as possible. They even planned to go to a pure Java version ("Javagator"), and built a lot of their own Java tools (because Sun's tools weren't ready). But in 1998 they gave up. Still, Communicator 4.0 contains about 1.2 million lines of Java.

You can read the whole story in: Michael A. Cusumano and David B. Yoffie. Competing on Internet Time: Lessons from Netscape and its Battle with Microsoft, Free Press, 1998. See especially Chapter 4, Design Strategy.

Note, by the way, that it took Netscape more than 2 years to discover the importance of design. Don't be surprised if you're not entirely convinced after one term; some things come only with experience.

There are twice as many courses in Ocean Engineering(?) as there are in both EE and CS (which is combined, but they are separate topics that I'm interested in, as are most people here). One of them is surely misplaced in both, this course.

It seems that the lecture videos format (at least for Linear Algebra, which I checked) is Realplayer's. Anyone knows whether it'll be provided in a friendlier format as well?

would be the way IP address have been allocated in chunks to certain holders, forcing the proposal of IPv6 far sooner than it should have needed to be.
Yeah, thats correct. For example, MIT is the only school in the world which has a Class A address, i.e. it has at its disposal 255 cubed addresses. Now does MIT really need that many addresses?

I'm teaching a scientific computing (numerical analysis and programming) course at Duke right now, and I just sent links to a couple of these courses out to my students. Specifically Numerical Methods in Chemical Engineering and Linear Algebra. The former contains some good stuff, including a Matlab tutorial. The latter has Java demos including one showing an idea that I've already has a homework on (SVD). My class is already "paperless", in that the homeworks are all posted online and submitted electronically over email and grades are sent in the form of detailed reports for each student's submitted work. This fits right in with this online-only system.

I'm teaching a scientific computing (numerical analysis and programming) course at Duke right now, and I just sent links to a couple of these courses out to my students. Specifically Numerical Methods in Chemical Engineering and Linear Algebra. The former contains some good stuff, including a Matlab tutorial. The latter has Java demos including one showing an idea that I've already has a homework on (SVD). My class is already "paperless", in that the homeworks are all posted online and submitted electronically over email and grades are sent in the form of detailed reports for each student's submitted work. This fits right in with this online-only system.

• Chord from MIT.
• CANfrom ICSI.
• Pastry/Tapestry from UC Berkeley/Rice.
• Kademlia from NYU.

- Fzz

A quick Google search reveals these tidbits on DHT vulnerabilities:

Two well-known academic DHT projects are Chord and Kademlia.

Kademlia is the basis for VarVar and EDonkey's successor, Overnet. There's an experimental effort to add a Chord-style query routing option to Gnutella, to find exact files over the whole network with far less traffic.

The terms Votester and Vote-ster have been in use for a few years now, and refer to online vote-selling and/or vote-trading services/technologies. There are none currently in existence. But the term was coined to highlight the possibilities and dangers of large-scale vote-selling, or large-scale vote-trading, if voting systems (for public elections) are attached to the Internet.

I first heard Dr. David Jefferson, Chair of the Technical Committee for the California Internet Voting Task Force, use this term back in 2000. Here are links to show the term's usage to date .. National Workshop on Internet Voting (11 Oct 2000), B.K. DeLong's BrainStream (25 Oct 2000), BBC News (28 Oct 2000), David Jefferson Presentation (27 Aug 2001).

Perhaps using some combination of "protest", "protester", and "Napster" would produce a name more closely reflecting the technology this write-up is describing.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were soon nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like a dying empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to the slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were quickly nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like a dying empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover an ugly story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.