Slashdot Mirror

But this isnt hacking!! THIS is hacking. What you're refereing to is cracking.

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.

This is pretty trivial. Zipf's Law is regarded in linguistics as a curiosity rather than a deep result. It doesn't really explain anything interesting about language. Music and language are both more and less similar than both following Zipf's Law suggests. On the one hand, as a previous poster has pointed out, language is meaningful. Music may have an emotional impact, but it isn't meaningful in the sense in which language is. On the other hand, there are deeper similarities in the formal structure, pointed out by Fred Lerdahl and Ray Jackendoff in their 1983 book A Generative Theory of Tonal Music.

Sorry, I think I typed that wrong. It's MIT's Judith Jarvis Thompson, not Johnson.

W

"Thirdly, 60000 miles? Geosynchronous orbit is at 42000km from the centre of earth, how the hell are they going to keep the "weight" where it's supposed to be? Rockets? Unless they manage to keep the centre of mass at 42000 km I don't think it's possible, and you'll end up with 60000 miles of expensive ribbon wrapped around earth (2.5 rounds) and a small crater where the "weight" met earth."

People commonly believe that the center of mass of the elevator has to be at geosynchronous altitude because it is rotating synchronously with the Earth. This idea is simply wrong. For example, most Slashdot readers are currently rotating synchronously with the Earth. Not one of them is at geosynchronous altitude. In the case of the Slashdot reader, he (she?) does not need to be at GEO simply because he is not in orbit. His chair is pushing him up. The elevator, also, is not in orbit, as it is attached on one end to the ground. In the case of the elevator, the ground will be pulling down on the elevator (this is necessary if you want to be able to climb up the elevator into space). So the elevator is not in orbit, there is no reason to expect its center of mass to be at GEO.

But in fact, the idea of its center of mass being at GEO is even wronger than that. Indeed, suppose that the elevator was not attached to the ground. In that case, the elevator would be in orbit, but it would certainly not be a point mass. Therefore, the orbital rules that most people are familiar with (Kepler's laws, etc) do not apply. Because Earth's gravity decreases slower and slower with altitude (it is a convex function), the center of mass would have to be beyond GEO for a geosynchronous orbit. I've got a little more detail on this on my web page.

I have studied neural networks extensively and believe me these do not have the potential to revolutionize anything.
NN are as simplistic & bogus as the next thing. Other methods like Support Vector Machine has shown to be more powerfull. Not to say that there isn't room for improvment or that AI will nerver be fruitfull. Its comming, slowly but surely. here are a few reference to interesting AI research:

1
2
3
4

Brooks did some great insect-level AI. It's purely reactive, with no world model. That was good work, and a reasonable reaction to the logic-based planning crowd then running MIT AI. But then Brooks started going around saying that the reactive model was far more powerful, and started making human-level AI noises. From this came Cog.

When Brooks came by Stanford to talk about his plans for Cog, I asked him "Why don't you go for mouse-level AI", something that didn't seem totally out of reach. He said "Because I don't want to go down in history as the man who created the world's greatest robot mouse". As one of the grad students on the Cog project said, "It just sits there. That's what it does. That's all it does". And, years later, it still doesn't do very much.

The model-free approach is just too dumb. With no world model, you can't get beyond insect-level AI. That approach works mostly for creatures in environments where inertia doesn't matter much. For insects, banging a feeler into something is fine. For large animals, you get bruises or worse. As creatures get bigger, faster, and stronger, they need models with some predictive power, so they can avoid mistakes before damaging themselves. I tell people in academia that you need to be "less formal than Latoumbe (who formerly headed Stanford's robotics operation) and more formal than Brooks". The game development community has absorbed this lesson, but it's only starting to get through to the robotics community.

Raibert's work on legged locomotion was very impressive. I'm very familiar with that work; I've done some improvements on it. Raibert had one great insight - balance is more important than gait. People have been studying locomotion for a century, and almost all the studies center on gait. Raibert realized that balance was more important, and built a one-legged hopper to force the issue.

But, in fact, the way Raibert does locomotion is very simple. There are two controllers, both simple hand-tuned PID loops, and a state machine that swiches between them. This can handle simple locomotion on the flat, and some preprogrammed moves like flips, but it doesn't generalize. I'd expected the adaptive control people to pick up from where Raibert left off, but so far, nobody has really done that.

My insight there was that slip control is more important than balance. On the flat, traction control isn't a big deal, but on hills or rough terrain, traction control dominates balance control. That's what legs are really for. If you add automatic traction control to Raibert's approach, legged running on hills becomes possible. Otherwise, you slip out climbing hills.

Raibert himself left MIT and did a startup company, Boston Dynamics. But they ended up selling products to DoD which are game-like kinematic simulations. They don't seem to stress dynamics work any more.

The MIT Leg Lab was taken over by Gill Pratt, who was more of an actuator and controls guy. He didn't accomplish much. The next head of the Leg Lab was some guy who was into prosthetics. The Leg Lab now seems to be defunct. Their web site hasn't been updated since 1999.

Other sources (MSNBC) have already pointed out that the motives ascribed to the record companies in this article are just not there. Rather, it was a screw-up in their allocation scheme

But when the first shipments began arriving last week, some librarians suspected that the companies -- the Bertelsmann Music Group, EMI Music Distribution, Warner-Elektra-Atlantic, Warner Music Group and Sony Music Entertainment -- were dumping CDs that had been gathering dust in warehouses when they received hundreds of copies of some titles for which there is little or no demand.

The good news is that the mystery has been solved and the source of the overabundance has been determined to be nothing more sinister than a computer-programming glitch that will soon be fixed, law enforcement officials say.

The bad news is that libraries that were among the first to receive their free CDs are now going to have to figure out what to do with all the duplicates.

So, nothing to see here. Just keep moving. [via BoingBoing and my weblog]

If we're beaker, who's Bunsen???

I've recently decided to uninstall SETI and leave the search after staying with it from the begining in '99 because one small graph in an article of Scientific American has kept sticking in my mind. Around 2000-2001 SciAm published an article that included this graph of SETI's search results (negative, natch) for the galaxy.

Even back then you can see that a large portion of the interesting parameter space has been excluded; it's been 3 years and not a peep. SETI's negative result is very, very important but it feels like it's time to move on.

Intrabody Signalling 1995

Can touch this 1996

What someone needs to do is set up a site where people can help fight this crap by supplying references to prior art for bogus patents.

I don't know, I found this that talks about PAN(personal area netowrk) from 1995

sending data through the body has not been acheived before.

MIT did this years ago. It was a cool project, really.

Presumably Microsoft has solved some specific engineering problems.

We've known how to stick electrodes on the body for nearly a century.

They also probably spent a lot of money on solving them.

I can replicate their results in my den with $10 worth of equipment. I doubt they spent much more than this, plus whatever ridiculous salary the "researcher" was paid.

Why shouldn't they be entitled to financial reward?

Because they are an illegal monopoly who continues to press into markets they have no business playing in? And because the idea is frigging obvious?

MIT's Media Lab invented this tech in 1995. Once again, M$ and the US Federal government collude to monopolize innovation developed by another.

Henry Ford invented the automobile

No, Henry Ford invented the moving assembly line, without which the automobile, aircraft, appliances, electronics and computers would still be academic curiosities.

there is nothing great about this country.

You were saying something about ashamed? Most of your neo-socialist wish list mentions food, medicine and housing. You do realize that this country feeds most of the world, right? That this country has the largest per-capita agricultural output in human history, right?

The inventions in this country are the only reason those things can even be addressed. Flight alone makes it possible to get food and medicine anywhere in the world in a few hours. Guess where flight was invented?

THE UNITED STATES OF AMERICA

'nuff said.

If this interests you, be sure to check out Erik Demaine's work at MIT, Issei Yoshino's Super Complex Origami, HOYJO Takashi, Biruta Kresling's Keikki Bamboo folds, Robert Lang's Design Secrets of Origami, Robert Hull's Origami^3 compilation. Not all computational origami looks mathematical but the methods for getting to and end are clearly designed from step one. Quite frankly I understand very little of the math, but I can appreciate the elegance of an efficient fold.

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 [theos.com] 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.

Here's a good link for people who don't know what genetic algorithms are:

Just like the earlier dotcoms, companies are scrambing to make their mark. Some will fail miserably, some will grow to be giants, and some will be successful and be eaten (or destroyed) by the giants.

This is what worries me. With wireless networking, it is possible to build free community networks that span large distances and don't rely on rented infrastructure (phone lines, cable, etc...), except for uplink to the rest of the internet. (For an example of what such a network would look like, check out roofnet)

If a commercial provider can provide "good enough" service for cheap, it removes part of the incentive to create high quality community networks that are free.

-jim

Did it ever occur to them that maybe it is just a really good album and that the people buying it are people who don't steal music anyways?

I haven't heard the Velvet REvolvers, or whatever this band is called, but I want to make one thing perfectly clear -- this is *not* about people stealing music, or even whether "stealing" is the right term to apply to peer-to-peer filesharing. This is about people who have legitimately purchased a product, who are attempting to do something they can legitimately, *legally* do with any other product of its nature (rip it to the hard disk), being prevented from doing so by a program embedded on the CD. I can legally rip any other CD to my hard disk, but because the record companies put their DRM technology on the CD, which I must bypass to rip, suddenly it is illegal for me to rip my own legitimately purchased CDs. I have *lost* the right to rip *my* CDs, even if I'm only going to use them on my own computer. As Prof. Lessig says, code is law. Or, put better than I can by someone upthread, DRM is a folding chair.

If this were anything but a music CD, we would say, "The record company is selling a trojaned piece of software, this music CD with a program on it that installs automatically on 90% of the systems it is likely to be used on and cripples the most people installed, say, a small-time word-processing program and discovered that it screwed up their CD-ROM drive, wouldn't they cry foul? Except it's a music CD, and the record companies are slowly training us to think about music in a manner much different than we think about other forms of information.

I was very suprised that COG was not on either list. COG is doing more for the real advancement of robotics then any of those "celebrity" robots ever will. I mean why should we transfer the cult of personality from hollywood to the realm of robotics?

• $ - CLOS is listed as a separate language. The Common Lisp Object System, as it's name implies, is an object-oriented extension to Common Lisp. Why they thought it was a separate programming language is beyond me.
• $ - No ANS Forth. The ANSI Forth specification was ratified in 1994, and is known as ANSI X3.215-1994.
• $ - No Lisp dialects between 1.6 and Common Lisp. This is an incredibly glaring omission. There were a number of widely used, divergent dialects of Lisp after 1.6, the chief two being MIT's MACLISP and BBN/Xerox Interlisp, both of which were used well into the 80s and had a major influence on Common Lisp, among other languages. This is not to mention the other dialects of Lisp left out (the principal ones I can think of are Portable Standard Lisp, EU_LISP, Le Lisp, Lisp Machine Lisp).
• $ - No ISLISP or XLISP. ISLISP became an ISO standard in 1997, and is a subset of Common Lisp with additions from several European Lisp dialects. XLISP, on which AutoLisp is based, became available for PCs in the late 80s, and due to the popularity of AutoCad was for a time the most widely used dialect of Lisp.
• $ - No StarLogo. StarLogo is a parallel version of Logo which was developed at MIT in the late 90s. It's used in a lot of grade-school computer courses.
• * - Haskell has an arrow pointing to CLOS. Not only is CLOS it's own language, apparently it is also a purely functional one. Again, where this was pulled out of remains a mystery.
• $ - No R^3, R^4 Scheme revisions. PHP has a box for every 0.0.x revision. They could have at least acknowledged the major revisions of other languages (and of course Scheme is not the only language this applies to!).
• $ - No Squeak. Squeak is a derivative of Smalltalk started by Alan Kay and Dan Ingalls (among others) in 1994. Today it is the most popular Open Source Smalltalk.

There are also a lot of languages that can be included, like Carl Hewitt's PLANNER (MIT's precursor to Prolog) and ACTORS (a purely message-passing object-oriented formalism that predated Smalltalk, and had several implementations and a lot of influence on other object-oriented languages).

All in all, I think both charts are pretty lame. O'Reilly should have at least solicited public comments before producing such a factually erroneous telling of history. This is altogether more surprising considering that O'Reilly is not a general publisher but instead specializes (in what they claim are) accurate technical manuscripts.

I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages

The vast majority of Common Lisp implementations have either a native code or through-C compiler, and at least two (Corman Lisp and SBCL) of them only come with a native code compiler.

Objectively, CMUCL can produce flotaing point code at least 5% faster than GCC on a non-trivial (the "Coyote Gulch" ephemeris calculator) benchmark. Of course, bechmarks are objective and misleading, and your assertion was subjective and misleading, and there's plenty of testimony (from real users writing non-trivial applications, not just some random bums paid off by the Scheme Underground) that Lisp is faster than C++.

Scheme seems like it has lost the intelligent simplicity of Python in favour of clumsy "special character" based syntax,

while Common Lisp has many detractors that don't complain much of details. Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?

Of course, your own assertion that Lisp is ugly and slow is stated authoritatively, even while you admit that you've "not coded a line yet," certainly could give someone the wrong impression.

Okay, I'm completely boggled now . . . what exactly are they're trying to accomplish?

DRM is part of a process to break us of the nasty habit of thinking culture is a common good. Like a speed bump, it's not about making us stop; it's about making us recognize that someone thinks what we're doing is wrong. And then using our own naïvité to get us to stop. (Furdlog posting)

For a more elaborate explanation, see DRM Is A Folding Chair

Okay, I'm completely boggled now . . . what exactly are they're trying to accomplish?

DRM is part of a process to break us of the nasty habit of thinking culture is a common good. Like a speed bump, it's not about making us stop; it's about making us recognize that someone thinks what we're doing is wrong. And then using our own naïvité to get us to stop. (Furdlog posting)

For a more elaborate explanation, see DRM Is A Folding Chair

"The postal service is liable for the conduct of its employees."

I thought I'd add a few interesting ideas and resources to this discussion.

Check out the works of Amory Lovins / L. Hunter Lovins / Paul Hawken;
they have an interesting book which can be read free online or be purchased
in print depending on one's desire --
Read 'Natural Capitalism' free online or buy the book!
Read 'Natural Capitalism' free online
Read 'Natural Capitalism' free online

Amory Lovins has a lot to do with the Rocky Mountain Instutute
Rocky Mountain Instutute and there's a lot more information about efficient
technologies and industrial / social evolutions there.

"Natural Capitalism: Creating the next industrial revolution" is all about
paradigm shifts that evaluates efficiency and resource conservation as
being key factors both for environmental reasons as well as economic reasons --
economics is about the market prosperity of the most efficient products and
services, and surely there are disadvantages in inefficient use of one's
inputs.

"Achieve multiple benefits with single expendutures" -- and the book/ebook
is full of really thought provoking and compelling practical paradigms to
illustrate the power of that thinking!

Ok so my next salient point and resource on the subject of power supply efficiency is to look beyond the power supply to the load and realize that
computing itself can be as close to a "zero power needed" technology as one
cares to implement. Current digital circuits waste the vast majority of their
power by irreversably converting 1's to 0's and 0's to ones, basically charging
up capacitors to make a high voltage "1" where there was no voltage before
and then wasting all that energy a bit later shunting it to ground / zero volts
to make a "0" again. This isn't necessary to achieve the computing function!
And here are some interesting readings on that area:

"Reversible Logic" is one such practical approach to it --
Article At MIT

http://www.google.com/search?ie=UTF-8&q=%22rever si ble+logic%22+%2BMIT

And otherwise: Book Info: "Complexity, Entropy and the Physics of Information"
"Complexity, Entropy and the Physics of Information"
a great read on the relationship between information theory, computing,
and thermodynamic entropy's relationship to data entropy, even touching
on how many "bits" of information a black hole must accumulate based upon
the entropy of the infalling matter/energy!

Besides classical circuit theory implementations like "Reversible Logic"
to save power there are very exciting opportunities in other quantum-computing
technologies like "Spintronics" (e.g. using the spin-quantum of currents flowing between magnetized metals / semiconductors to represent "1", "0" or
multi-level logic which is basically related to the way a NMR device gets
its signals):
Spintronics
Google It ...and various other quantum-effect computing technologies.

As for efficient power supplies, how about one that's 99% efficient,
generally non-toxic, cheap to manufacture (actually it's self manufacturing!)
and generates perfectly 'clean energy'?
Wired: Algae based fuel cells!
How about using the same kinds of photosynthesis that every green plant
on earth uses to split Hydrogen apart from Oxygen and create a microscopic
electrochemical fuel cell complete with the option of integrated
efficient 'storage batteries' for holding power when the sun's no

In the Lightweight Languages 2 conference, "Matz," the creator of Ruby, said that Ruby has been accused of being a ripoff of Scheme, and he admitted that it is a ripoff of Scheme.

A chart like this is interesting, and does show some patterns between languages, where did they get their data? Was it fabricated by some person or group of people, based on similarities and temporal proximities of languages?

Computer languages all seem to borrow heavily from each other. No one starts from scratch when building languages; they take the best ideas from mathematics and from other existing computer languages to fit whatever need they are trying to fill.

True, Arc is currently vapor, but GOO, a project in the same vein, is already functional (pardon the pun).

Why can't this fscker wear his glasses properly. You'd think he'd pull enough coin to buy proper reading glasses. Jeez.

When someone from MIT says peer-to-peer is a good thing, he's talking about peer-to-peer as an architecture. He does not mean "KaZaA 0wnz!! fr33 pr0n = 1337!!!!111oneoneone." People are interested in peer-to-peer for reasons other than file-sharing because they're scalable architectures that can handle load balancing very well, and have no central point of failure.

Most peer-to-peer research in universities regards creating better, faster Distributed Hash Tables, or DHTs for short. Typically, for N nodes on an overlay network connected by a DHT, insertion and queries come at log(N) cost. MIT has one of the best, called Chord. Some DHTs are very fragile and their routing topology can "break" when under extreme churn (when a flash of nodes suddenly join or leave the network), or malicious nodes attempt to manipulate other nodes' routing tables by creating fake identities (see the Sybil attack) -- Chord has been shown to be very resistant to both. Other notables are Kademlia from NYU (which is under the hood of eMule), and Pastry from Rice (Microsoft collaborated).

MIT has done some pioneering research in DHTs, and they have a lot of great minds on it. I'm making my own peer-to-peer program (hopefully it will be ready in a few months) and it will incorporate quite a few of the ideas they've developed. One of their ideas that I find particularly interesting (and I think should be incorporated into BitTorrent, because it seems like the perfect application) is called Vivaldi. You can read for yourself on how it works, but when applying it to BitTorrent, basicially the tracker would give you peers it thinks you have a low ping time to, as opposed to a random list which may be sub-optimal.

They're also involved in Project IRIS, which aims to develop a decentralized Internet infrastructure using all the latest DHT technology. It's funded indirectly through -- gasp -- the government via the NSF.

So yeah, don't just think that MIT is jumping on the bandwagon. They've been on the bleeding edge for some time.

- shadowmatter

When someone from MIT says peer-to-peer is a good thing, he's talking about peer-to-peer as an architecture. He does not mean "KaZaA 0wnz!! fr33 pr0n = 1337!!!!111oneoneone." People are interested in peer-to-peer for reasons other than file-sharing because they're scalable architectures that can handle load balancing very well, and have no central point of failure.

Most peer-to-peer research in universities regards creating better, faster Distributed Hash Tables, or DHTs for short. Typically, for N nodes on an overlay network connected by a DHT, insertion and queries come at log(N) cost. MIT has one of the best, called Chord. Some DHTs are very fragile and their routing topology can "break" when under extreme churn (when a flash of nodes suddenly join or leave the network), or malicious nodes attempt to manipulate other nodes' routing tables by creating fake identities (see the Sybil attack) -- Chord has been shown to be very resistant to both. Other notables are Kademlia from NYU (which is under the hood of eMule), and Pastry from Rice (Microsoft collaborated).

MIT has done some pioneering research in DHTs, and they have a lot of great minds on it. I'm making my own peer-to-peer program (hopefully it will be ready in a few months) and it will incorporate quite a few of the ideas they've developed. One of their ideas that I find particularly interesting (and I think should be incorporated into BitTorrent, because it seems like the perfect application) is called Vivaldi. You can read for yourself on how it works, but when applying it to BitTorrent, basicially the tracker would give you peers it thinks you have a low ping time to, as opposed to a random list which may be sub-optimal.

They're also involved in Project IRIS, which aims to develop a decentralized Internet infrastructure using all the latest DHT technology. It's funded indirectly through -- gasp -- the government via the NSF.

So yeah, don't just think that MIT is jumping on the bandwagon. They've been on the bleeding edge for some time.

- shadowmatter

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.

Languages aren't "faster" or "slower"

Thank God, finally someone understands! I was recently benchmarking Turtle Logo against some highly optimized Opteron-specific assembly code for an application that calculates PI to the 400,000th digit.

I was surprised to see that Logo was slower, but I think I just didn't optimize it enough. I am tuning the Logo floating point code right now, and Logo should stomp the hell out of the assembly code "Real Soon Now."

Also, it's not usually scientific, but there's educational, and sometimes interesting, video at C-SPAN / BookTV, but their archive doesn't go back very far.

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.

I'm trying to wrap my mind around what exactly that convoluted mess of an MIT press release is trying to say. If I understand correctly, and someone please correct me if I'm wrong, the system tracks the heads of the people surrounding the display, then projects left-eye right-eye information through an adjustable polarized filter and lense system so that the viewable angle only includes the intended eye. The reason they need such a high refresh-rate is because they want a system that would work with 4 people... 4 people = 8 eyes = 8 times the updates.

In essence, that's very cool. Why couldn't they just say that?

The online world's sheer wealth of informative sites, guides, and peoples rivals any university alone. To use it effeciently for the manner of learning is a different matter altogether. It is easily to be disported at the sundry delights of online porn, the action-packed online FPS, or the vacuum that is Slashdot at times. I obviously do not spend my day here, but when I first came unto this website before I registered it was a portal into the world of Linux which has helped me greatly. Now I would consider it a nexus of the raw talent of a goodly portion of the Linux and even Windows sysadmin, programmers and tech support jockies out there. RTFM is a good reply to many people. When you depend so much on others that you cannot use a book or a website to learn virtually anything conceptually without hand holding, how is that going to affect you in the real world after school? Are you going to be the guy who leans on the cubicle wall every 15 minutes asking him how to use this pointer, fix this tech support problem, or the like? Learning how to learn on your own is the most important thing I learned in school, and that was when I was in 6th grade. Going to class for me is more a social call than anything. I learn alone with source material, why won't people respect that?

I used to be a palm zealot. Great design, initially. 68k, 1 meg of RAM, and always on. Thousands of programs appeared on the net for free. I used it for a calendar, and to schedule appointments, and to keep track of my time, and where I was. I used the address book rather violently -- and picked-up hundreds of contacts (imported from my old Casio BOSS, and collected through the years). I also downloaded neat programs, and experimented with development. Truly a neat system 1997, and ahead of it's time. (Of course, I drooled over the Apple Newtons!)

Connectivity is really the thing for me, being able to transfer data/programs easily, as well as to other people is something I need to do. I admit it, I'm a geek, and rely on this stuff. The Palm's serial port, while great, required a special cradle, and even with two, it's still a pain. Don't get me wrong, AvantGo, and the whole syncing thing is great, especially if you spend time on trains, busses, airports, or meetings. Infra-red is a really great technology, and I'd like to see it's use more widely expanded, to include tv-remotes as well as whatever other standards are out there for transcieving via infra-red (ie IrDA, etc).

Bluetooth really takes the cake on connectivity, except for it's bloated stack, and silly implimentation. Wi-Fi or soft-modem technology would be a great alternative. Using bluetooth, I can synchronize my Nokia 3650 without even taking it out of my pocket - nuts a-frying be damned. This is something far more attractive than even more icky cables, and easier than pulling-out the device and pointing it at something.

Having a Nokia 3650, I take pictures all the time, so it's nice to bluetooth them at my workstation, or drag them from my phone onto my desktop. I can do this while my phone is charging in the other room!

All of the features I used to use my Palm for, work on my phone. Plus, I can take pictures, and make calls. This makes me not wonder why Sony stops making PDAs. Why do we need an additional device? Now, having more computing power, that's one benefit, but for special applications, and extended uses, a full-on PDA might make more sense.

Although i have never programming, my first college leve CSCI class used SCHEME (a direct descendant of Lisp if i remember correctly) as the language.

This language is structed very difficult for a new computer science student to easily understand.

The endless parenthesis does not help either.

And, on top of this, the language is completely dead!

I much rather would have learned an assembly language. This would have given students a better feel for the hardware and would have had useful applications.

There's a famous domed building on the MIT campus, a gymnasium I think

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 [theos.com] 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.

Ummm... You do realize that they are different Dvorak's, right?

The adulteration of orange juice: In 1990 an employee of Sun Up Foods, an orange juice processor, told the Food and Drug Administration (FDA) that the company had set up secret rooms in its facilities to hold tanks of liquid beet sugar, a common adulterant of orange juice.

Why would anyone use rabbit shit in coffee? Chicory is the standard item used to dilute or adulterate coffee.

We can contemplate the Ford Pinto without much further comment.

How about a little Alfatoxin in your peanut butter!

Need a chest X-Ray or a really fast sun tan?

Or maybe you want to take a trip in Sir Geoffrey de Havilland's Comet?

And if you still think that you can consume or use products or services without paying close attention, I have a bridge to sell you.

See patent articles

---

It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA abuse.

Their whitepaper describes a cool S-expression based language (kinda like a blend of HTML and Scheme) that elegantly merges the simplicity of markup languages with the power/complexity of lisp.

Their whitepaper describes a cool S-expression based language (kinda like a blend of HTML and Scheme) that elegantly merges the simplicity of markup languages with the power/complexity of lisp.

One of my professors this semester assigned a project comparing and contrasting the views of Joy, Dertouzos, and Kurzweil. The following articles shed some light about each one's perspective, respectively.
http://www.wired.com/wired/archive/8.04/joy.html
http://www.lcs.mit.edu/about/reason.html
http://www.lcs.mit.edu/about/kurzweil.html

One of my professors this semester assigned a project comparing and contrasting the views of Joy, Dertouzos, and Kurzweil. The following articles shed some light about each one's perspective, respectively.
http://www.wired.com/wired/archive/8.04/joy.html
http://www.lcs.mit.edu/about/reason.html
http://www.lcs.mit.edu/about/kurzweil.html

In an 802.16 setup, the towers don't speak 802.16 to each other; if you're using wireless backhaul it's probably a proprietary protocol.

Mesh networking is great, but 802.11 is totally unsuited to mesh because it limits throughput to 1/7th of the link rate.