Slashdot Mirror

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.

Sure could, lots of systems are turing complete - I've seen a universal turing machine implemented within Conway's Game of Life. It could do And, Or, and Not and that's all you need.

Also, a lot of seemingly different mathematical systems are interrelated or can be transformed into each other. Look here to see how computation can be expressed within four other ontological frameworks.

Anyway, don't quote me on the above ( :^) this is /. after all) but I know for a fact that what your saying is a valid implementation of a universal turing machine so yes it would compute.

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 formerly acclaimed TCP/IP stack has lagged behind, according to this study.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

Article

He's making a case that Harvard needen't worry about having a balanced enrollment in math or science, because females are too stupid to be in those courses of study.

Every school (especially technology schools) are trying to balance enrollment, but it won't succeed until they try to solove the huge image problem that technology field has. I have seen all the frantic acrobatics that goes on in my own school and still their enrollment was increased by adding non-tech areas (sounds to me as if they are trying to circumvent the balancing by dilution).

More and more people are realizing that it is not just lack of opportunitites, but that engineering field is not attractive or glamourous enough for women.

The Debian Women's page points to an article that makes the observation that women are not properly and positively introduced to engineers (almost all of whom work behind the scenes). Of course, that is not the only problem, but a very important one.

Someone has suggested that there should be hit shows featuring engineers and computer scientists where they are not portrayed as socially inept outcasts. A tech version of 'Ally McBeal', ER or CSI (CSI does not really show the whole spectrum).

Reading this article gave me an idea:

I'm an avid swing dancer. In order to effectively learn new moves, I either have to see a video or have somebody teach me. With the video, I can replay it as many times as I want, but I only get one 2D angle. With a teacher I can appreciate the full 3D movement, but if I try to get them to replay too many times they get annoyed and smack me.

There's things like the Jiveoholic Dance Step Database, which is useful by limited to 2D.

Perhaps motion capture could be the best of both worlds? I imagine it wouldn't be too hard to capture the moves of expert swing dancers, and then have a piece of software to replay their movements in 3D. A user of the software could replay moves to their heart's content, switching to arbitrary angles. If robots like the HRP-2 ever become cheap and flexible enough, such motion capture could even be used to replay moves on the bots.

Some folks at MIT made a very rudimentary "swing dancing" robot arm, which provides swing dance leads. I wonder how long it'll be until we see humanoid robots capable of leading, or maybe even interpreting hand signals from a human and being capable of following.

This isn't really new in any way. MIT has been doing this every January for the past few years.

They've also been doing a lego robotics competition every January as well. This involves electronics (for sensors), programming (robots need to be autonomous), and "mechanical" design (building the actual bot out of legos!).

One particular feature of the game rules is that time is measured by counting executed bytecodes. So we can expect that contestants will aim to produce very efficient code.

Do you know any Java compiler benchmark that compares generated bytecode?

Hey, I had the same idea a few years ago when I read an article on chaffing and winnowing. It turns out there is a filesystem that implements something similar called rubberhose. It doesn't seem to be in development (www.rubberhose.org doesn't work) but this mirror has the last version and readme file that explains the principle.

Here's another program based on rubberhose.

More likely the guy built a $50 webserver also

actually it wasn't a GUY that built this project but a woman, gal, chick, person of the female persuasion.

and something tells me that grad students at the media lab aren't in charge of the web servers...

~fab

It's not the main MIT network we are talking about. It's the Media Lab network, which is somewhat independent from the main MIT network. You can see that from here:
http://mit.edu/maps/networks/mit/mit-topology.pdf
The Media Lab subnet (18.85.0.1/18) uses the e19r2 router (you can verify this with a traceroute), and the media lab network connects to the router via a 100Mpbs ethernet interface.
Also, note that the Media Lab network is not operated by IS (Information Systems). IS is responsible of the main MIT network. The media lab network has its own sys admin.
So it's not the MIT network that's been slashdotted, but it's the Media Lab network.

I think it's worth pointing out that a girl-geek is responsible for this mp3 player creation. The username in the URL is what tipped me off, and the bio page seems to confirm it.

For extra points, anybody want to venture a guess where the name "Limor" originates from?

Nah, it's because we're starting our own companies now :) (ok, ok, not Ivy, but MIT) :P

-fren

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of the 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.

I've been following http://opengov.media.mit.edu/ for a year or more, and it was a brilliant initiative, and pretty smart way to go about things. Sadly updates weren't coming much lately, then the website slowed/disappeared, now I see " opengov is not currently maintained." .. Bummer, I wish this project would be done elsewhere.

The Media Lab was an amalgamation of the MIT Architecture studios and the Computer Science Lab. Both places had used the "playpen" environments since the 1960s. The architecture labs inter-penetrated the top floor of Building 7 Borg infiltrating the Enterprise. People built interconnected, multi-level cubby holes and common areas for their art studios and classrooms.

Many dot.coms adopted this style of goofy shared spaces. You still see this at Google, Pixar, etc.

This atmosphere has recently extended to the newly opened "Dr. Suess" Computer Science Department (Strata) building at MIT. This building looks like a bunch of twisty towers. Theres a lot weird looking offices, common spaces and passage ways. Plus its own gym and cafeteria, so students rarely need to return home.

It seems that this is the latest in a seris of misteps for the Media Lab. A similar effort in India, Media Lab Asia, was wrestled away from the Lab by the Indian Gov't. Then there's also the empty lot next to the building where a new Media Lab was supposed to have been errected some years ago.

I think at the base the problem is that lab's are not just created overnight. It takes years of laboring together (and sometimes years going to school together) before you get a cohesive faculty that can make a lab like this "go."

It is my hope that the Media Lab introspects a bit and stops attempting overly ambitious things and instead does what it's really good at: making cool interfaces between bits and atoms.

An accelometer wouldn't sensibly be used to replace the input style / use context of keypads. (Except perhaps in case of accessibility issues and people with disabilities.)

Instead, novel input techniques have been researched for quite a while. Check out these few example publications:

http://sandbox.parc.com/want/papers/mui-cacm-2000. pdf

http://www.csl.sony.co.jp/person/rekimoto/gwrist/

http://www.csl.sony.co.jp/person/rekimoto/tilt/

http://tangible.media.mit.edu/papers/Graspable_Dis plays_CHI97/Graspable_Displays_CHI97.html

http://research.compaq.com/wrl/projects/RocknScrol l/RocknS.html

Did you do any research on air currents?
Is the Gulf Stream responsible for Europe's mild winters?
Europe is warm because of southwesterly winds from the warm Atlantic. These winds are caused by the Rocky Mountains, which divert warm air flow to the southern U.S. and the air then flows northeast toward Europe. Cold polar air also tends to spill south across central North America.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

The real driving force behind this research is the desire for a nano-enabled soldier of the future. They hope to use these as exo-muscles in combat suits to allow soldiers to literally "leap tall buildings in a single bound."

The MIT Institute for Soldier Nanotechnologies is working on this right now, but they don't see it being available for use for 30 years or so. I recently attended a lecture at MIT entitled "Nanotechnology: From Promise to Profitablility" that was almost entirely focused on military applications.

Amputees will certainly benefit, but that's not why the money is there for this research...

What you stole was the revenue the artist expected from the additional copy of their work that's now in your hands.

One more time, using nice, short words that you'll be sure to understand: Your "stolen revenue" argument is only valid when the person who committed the copyright infringement would have purchased the item legitimately if it hadn't been available to copy illegally. A substantial percentage of the time, this is not the case: if the work weren't easily available in the form of an illegal copy, the person would not have spent the money to buy a legal copy. See, for example, this (PDF), this, and this .

In short, an instance of copyright infringement does not always equal a lost sale.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems.

[...]

Underlying our approach to this subject is our conviction that ``computer science'' is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology -- the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of ``what is.'' Computation provides a framework for dealing precisely with notions of ``how to.''

When I was at MIT (circa 1980) there was a recording studio down the hall from TMRC in building 20 (it was across the hall from an old anechoeic chamber...but I digress). The was pretty much abandoned and used by a small group of students for recording punk demos. The actual studio was isolated from the control room completely...the studio was on springs to completely prevent sound from bleeding through to the control room. The recorder in the control room was an old Ampex rack-mounted 2" 4-track machine...yes, FOUR-track. Recording at 15ips on 2" of tape yielded some incredible sound quality...think about later machines that squeezed 24 tracks of material on the same 2" of tape. In 1981 someone from Ampex contacted us and gave the group a new 1/4" 4-track so they could get the 2" 4-track for their museum. Seeing as how Ampex changed hands since then I wonder what ever happened to those vintage machines.

People used to buy those old Ampex machines just to get the tube pre-amp electronics...nice warm sound, pleasant distortion (when you wanted it), and no harsh digital clipping.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

Not that many sites use kerberos, but mit has had single sign-on with kerberos for quite some time.

Experienced users achieve writing speeds of about 34 words per minute, compared with typical ten-finger keyboard typing of 40-60 words per minute.

Experienced dasher users can peak at 34 wpm.. experienced typists can often peak at more than twice that on a qwerty (not to mention a Dvorak layout). And imagine using Dasher for coding - Dasher works well for writing words, but fails totally with the symbols and syntax used in programming.

Some users might be able to work without a keyboard, but I can't see a future where nobody will want a keyboard...

For all of you looking to reclaim that first programming experience, LOGO is still available. It's been updated a bit: multiple turtles, color, even 3D IIRC. If you head to the link above, you'll see lots of talk about modeling comlex environments and such, but it is really just LOGO with a bunch of MIT geeks writing webpages about using it. ;)

Your link [http://www-swiss.ai.mit.edu/~bob/clarisworks.php/ ] does not show the pretty pictures. Here they are:
http://www.swiss.ai.mit.edu/~bob/clarisworks.php

For LOGO software look here: http://el.media.mit.edu/logo-foundation/products/s oftware.html

Either language would be a fine choice for a first language.

I think Python has a few small advantages. First, there are many tutorials for Python that are aimed at new programmers. Examples include:

• How to Think Like a Computer Scientist
• Python 101
• Learning to Program
• Non-Programmers Tutorial For Python
• The Python tutorial that ships with Python itself (not really for absolute beginners, but this is where I learned Python)
• Plus many others, and I haven't even mentioned printed books.

The other advantange Python has over Ruby is the interactive Python interpreter. I can't explain how fantastic this is. With many other interpreted languages (Ruby, Perl), you really should write your program in a text editor and then run it through the interpreter. This is because the commands you type don't execute until you stop entering your program. The interpreter is not interactive. So every time you want to try something, you have make the change in your text editor and then run it through the interpreter.

Python's interpreter is much nicer to work with. You type in commands, and each command executes immediately. This is very useful when you want to experiment with the language, and is ideal for beginners. I don't know why Ruby's creator didn't include this feature.

Anyway, you'll be happy no matter which language you choose. They are both very nice. You might also consider learning PHP as a first languages. It's nice to be able to view the results of your work in a web browser, and PHP is probably the quickest way to do that. Another good choice for first language is Scheme. Check out the free online book Structure and Interpretation of Computer Programs (SICP). If you like video, there are also some video lectures available.

Either language would be a fine choice for a first language.

I think Python has a few small advantages. First, there are many tutorials for Python that are aimed at new programmers. Examples include:

• How to Think Like a Computer Scientist
• Python 101
• Learning to Program
• Non-Programmers Tutorial For Python
• The Python tutorial that ships with Python itself (not really for absolute beginners, but this is where I learned Python)
• Plus many others, and I haven't even mentioned printed books.

The other advantange Python has over Ruby is the interactive Python interpreter. I can't explain how fantastic this is. With many other interpreted languages (Ruby, Perl), you really should write your program in a text editor and then run it through the interpreter. This is because the commands you type don't execute until you stop entering your program. The interpreter is not interactive. So every time you want to try something, you have make the change in your text editor and then run it through the interpreter.

Python's interpreter is much nicer to work with. You type in commands, and each command executes immediately. This is very useful when you want to experiment with the language, and is ideal for beginners. I don't know why Ruby's creator didn't include this feature.

Anyway, you'll be happy no matter which language you choose. They are both very nice. You might also consider learning PHP as a first languages. It's nice to be able to view the results of your work in a web browser, and PHP is probably the quickest way to do that. Another good choice for first language is Scheme. Check out the free online book Structure and Interpretation of Computer Programs (SICP). If you like video, there are also some video lectures available.

Oh come on, you can't say there are problems with homegrown protocols without pointing people towards Peter Gutmann's comment on penis-shaped sound waves. :-)

I agree with you for the most part, but I think it is worth stating that using SSL/TLS or SSH does not free you from all problems. Secure (integrity not confidentiality) distribution of public keys is still a significant challenge (to be read as "something that's easy to screw up").

Here's three free, current programming environments that are suitable for introducing programming (that no one seems to have mentioned yet.)

1. Design by Number

Created by John Maeda of MIT, this is a very simple graphics-oriented programming language. Maeda created it for artists and there an associated book. Like a sparse Logo, it keeps everything to a bare minimum. Has a web applet that allows interpreted programming to try it out.
DBN web site

2. Processing

DBN is no longer maintained, and a more complex graphics language emedded in Java (with a single-line interpreter for ease of use) has been developed by Ben Fry and Casey Reas of MIT.
Processing web site

3. Robocode

Developed at AlphaWork at IBM, this is a Java environment for programming your own virtual robots that then shoot each other. Has a 2d battle arena in which little tanks move and shoot. (Classic idea, just a nice implementation). You can program as much or as little intelligence as you wish. Designed for teaching Java.
Robocode web site

Really Logo wasn't intended to teach programming (though of course it did that). It was intended to teach math, and algorithmic thinking, and thinking in general. And, paired with the right teacher and an interested pupil, it's really great at that. Without realizing it, a child can end up learning not just geometry (through the turtle graphics), but a lot of pre-algebra. I think programming is a far more accessible way to introduce algebra than the traditional techniques; even young children can understand variables in programs, when the declarative variables that are used in mathematics are much more challenging.

It's also a better language than many of "teaching" languages, like Basic. It's an old-school version of Lisp, with a little tweak to avoid the parenthesis. And don't be fooled by things that call themselves Logo when they are just turtle graphics. Turtle graphics are cool, but just a piece of the equation. (Though not-so-coincidentally, Python has built-in turtle graphics).

If you are really interested in programming as education, I might recommend the book Mindstorms, which is a classic about some of the theory behind teaching with Logo. It's not a practical guide, though many of those also exist.

If you are looking for a Logo implementation, on Windows I would recommend Elica, MSWLogo, and UCBLogo, in that order. On Mac or Linux, you can use UCBLogo, Turtle Tracks (a cross-platform Java implementation), or on Mac one of a number of (rather expensive) commercial Logos. If you are a programmer and feel like fiddling alongside your child, you might try my project PyLogo, which is cross-platform and written in Python, but quite rough around the edges. Or if you want something that is Logo, but pretends to be a general-purpose scripting language, look at Rebol. Or for a slightly-lame but functional embedded robot Logo, Cricket Logo. Or for older people, NetLogo is a massively-multitasking implementation to use to play around with autonomous entities (e.g., ant simulations). NetLogo is kind of the successor to StarLogo.

For more information on Logo, you can look at the Logo Foundation, or get in touch with many helpful users in the LogoForum Yahoo Group.

The authors of HTDP have a Scheme distribution that includes a GUI IDE Called Dr Scheme:

http://www.drscheme.org/

It runs under Mac OS X, Linux and Windows. It has an on-line help system. It is also used in conjunction with the book How to Design Programs (available from MIT on-line: http://www.htdp.org/) , and Structure and Interpretation of Computer Programs http://mitpress.mit.edu/sicp/.

Basic Scheme is very easy to learn. It even makes for easy tranlation from HS Algebra/Geometry/Trig formulas into code. It will quickly teach concepts without having to learn specifics about operating systems or applications.

If you're looking for a job as a programmer (coder), your best bet is to stick with what's popular - Java or one of the .NET languages. If you're looking to learn practice, network with friends/family and find a professional developer that knows some kind of SDLC inside and out and ask them to be a mentor. There is more to software development than writing code (analysis [talking to users], requirements development [talking with users], functional specifications, design, source configuration management [version control, issue tracking, unit, component, system and regression testing, etc.], software metrics [profiling, logging, debugging], QA analysis).

It depends on what your goals are. The simpler the environment is to get started with, the faster your kid will be able to determine if they're even interested. If they eventualy outgrow the environment and there is enough passion, then transitioning to the new environment will be a possibility (not to mention invalueable experience).

- mortis

If by "from the get-go" you mean when it was still called ClarisWorks, I have to take offense (given that I wrote a lot of it). All the reviewers of the early versions, and millions of users, would disagree with you. In fact there are still lots of things you can do with AppleWorks that you can do with no other single program out there.

That said, by the time the name was changed to AppleWorks, the ball had clearly been dropped, and essentially nothing has been done for the past few years. So, dated - yes. Sucked from the get-go - I think (hope) you have a minority opinion there.

Details on ClarisWorks/AppleWorks history here:

http://www-swiss.ai.mit.edu/~bob/clarisworks.php/

Bob Hearn

But preoccupation with entertainment at the expense of real goals is something to watch out for.

Sure, but as you point out, this may not actually be happening in any of the cases that have been raised.

In fact, I think space tourism will make people *more* conscious of the things we ought to be doing in space, and more supportive of them.

Exactly! It's things like this, and even more mundane things, that make achieving our "higher purposes" possible at all.

If anything, beyond the goals of a certain amount of scientific exploration of our surroundings, the NASA model of space exploration has been proven to be a failure, when it comes to giving a larger proportion of the human race a stake in space travel. And it's only when people have a stake that there'll be real incentives and enough support for doing anything beyond trips to examine rocks. You don't necessarily achieve higher purposes by aiming straight for them - you have to build a foundation that will support them, first.

A world full of robot puppies and vacuum cleaners is much more likely to result in useful robotics in the end than working in a pure research lab trying to create intelligent robots from day one. Which is more important: Kismet or Aibo? I'd argue the latter.

Thanks for reminding me... Bruce Sterling's "The Hacker Crackdown", the chapter "$79,499". Though it's not NASA, it might (or might not) also be the incident you're thinking of.

There are lots of people complaining about the pricing -- here's my story with Zipcar in Boston.

My 1992 Saturn was falling apart on the streets -- between snow, getting sideswiped, looking for parking spaces (most people in the city don't have dedicated spots), and the fact that my car was 10 years old and had the usual 10-year-old car problems, it was quite a burden. I estimated that I spent about $150 per month on it all told (maintenance, parking tickets, gas, insurance) -- all so I could drive to the grocery store once a week. So enter Zipcar. They have nice cars (most are late-model VW's -- Jettas, Beetles -- if you want to pay a little more, you can even rent Minis and BMW 7-series cars!), and more importantly, their reserved spots are closer to my house than I was able to park my own car. I donated my piece-of-junk car to charity, canceled my insurance, and signed up. As for the pricing, my philosophy was that if I spent less than $150 per month, I was doing great -- and no headaches of car ownership. At $8.50 per hour, that's over 17 hours of driving -- needless to say, I haven't gotten close to that. If I plan ahead, I can get a normal rental car. I've figured that the break-even point between Zipcar and standard car rental (considering gas and insurance) is about 5 hours.

I also haven't seen it mentioned that Zipcar has agreements with several local businesses and universities. For example, MIT provides spots on campus and waives the application fees for grad students, faculty, and staff.

I think it's great to have a progressive, tech-friendly, environmental company around that actually improves my quality of life and saves me money.

It is possible to run a beowulf cluster on Windows
Pointless exercise, though.

Britain, Canada, Australia, New Zealand, India, Russia and many, many other countries all suffered great losses during WWII. To expect thanks for turning up late is pure arrogance.

---Roughly speaking, there are no expenses.---

Your statements show a very naive, if not completely incorrect understanding of what goes into publishing a scientific journal. There are lots of costs involved, and nearly every journal that exists has a score of paid employees.

---The editor is usually a volunteer---

Not true in most cases. Most journals have a paid full time editor (at least this is certainly the case for biology journals). There is usually an editorial board made up of scientists. These people are sometimes volunteers, but are often paid a stipend for their contributions.

---The editor sends your manuscript to two or three referees, who mark it up and write him a report. He then takes their names off the reports, and forwards them to you, with his decision (usually either ``forget it'' or ``revise and resubmit''). All this is done electronically, so costs are nil.---

First, a decision has to be made as to whether the article is worth reviewing. This is done by the editor who reads the paper and assesses its initial value. If favorable, the paper is then forwarded to reviewers. Due to the large volume of submissions seen by most journals, an administrative assistant usually oversees and tracks this process. Some journals have indeed switched to electronic submission and review systems, while many haven't. Such systems are very expensive to set up, and expensive to maintain. One such system is run by Stanford University's Highwire Press (who also help journals publish online). Care to see how many people they employ?

---Aside from a secretary for the editor (not all publications have this), the only paid employees are the guys who run the printing press and the fat cats who take your checks to the bank.---

Um, no. Most journals have a publication staff. These people are responsible for layout and formatting of accepted articles, reviewing and correcting artwork, copyediting, cover designs, dealing with legal permissions, sending out reprints, and inumerable other tasks. As far as the fatcats go, many journals are run by scientific societies who rely on journal profits to fund community activities like scholarships and meetings (Protein Science is an example). Other journals are published by universities and research institutes, and all profits go into funding further research and support for the scientists working there (MIT Press for example). Yes, there are plenty of Elseviers and other greedy publishing empires out there, but don't tarnish all journals with the same broad brush.

---and in return, the publisher takes the copyright---

Many journals, such as those published by the Nature Publishing Group, give the authors full copyright in return for an exclusive license for the article.

I should have said: "Quantum mechanical effects become significant in the realm of the extremely super small." Likewise: "Einstein's relativity becomes significant in the realm of extremely large values of velocity."

Close but no cigar, BECs (Bose Einstein Condensates), Nonlinear optical systems, and the Stern-Gerlach experiment (which gave evidence for electrons having spin) all occur on scales as large or larger than cell biology. Special relativity depends on velocity but General relativity does not, in fact velocity is a difficult idea to describe in General Relativity and not useful anyway. In full scale General Relativity all you have is spacetime and curvature.

What about: "Look around, and everyone will see that quantum mechanics is not tangible."

I guess the 8 foot tall, 2 ton NMR spectrometer I work on isn't tangible. How about this NMR magnet is it tangible? Of course I guess NMR isn't a quantum phenomenon.

I have not heard about the quantum economic model yet, or social Q.E.D.

Probably because quantum theory refers to a very specific set of axioms which cannot be applied willy nilly. While Darwin's Theory of Evolution likewise refers to a very specific logical framework, the general ideas of competition and selection can be simulated in a variety of other systems hence the proliferation of "Darwinian X" ideas floating around. On the the other hand, quantum statistical phenomena apply only in very specific cases and other than those systems studied by quantum physicists don't appear in economic systems or social interaction networks or other areas in which analogies to Darwinian Evolution can be made. On the other hand, there is a lot of useful work that can be done in applying quantum mechanical ideas to computation.

Operation Fastlink officials seized 200 computers, 30 of which were alleged to have been used as storage and distribution servers containing thousands of copyrighted works, including newly released movies and music. The Justice Department estimated that the seized copyright material alone was worth $50 million.

Let's make UNIX not suck by Miguel de Icaza. Answers this exact question in quite a lot of detail! Try out the UNIX Haters handbook [warning: big PDF] for a more humourous take on things!

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.