Slashdot Mirror

One of the reasons it would be difficult/messy to extract the fuel from the pebbles is that the pebbles are not entirely fuel. The pebbles are made up of thousands of "microspheres" in a graphite matrix, each about a millimeter in diameter. Each microsphere is composed of a sphere of low-enriched uranium dioxide surrounded by a layer of graphite buffer, a layer of pyrocarbon, a layer of silicon carbide, and another layer of pyrocarbon. The idea is that these are the first barrier to prevent the escape of fission gases. The pebbles are really a second fission gas barrier, and they have been tested to very high temperatures without failure. For a description of the pebble geometry, visit the link below.

http://web.mit.edu/pebble-bed/presentation1_files/ v3_document.htm/

There is an excelent article on pebble bed reactors in wikipedia. Briefly, the idea is credited to a German physicist Rudolf Schulten. General Atomic is building one in Russia (link). Also there was a project at MIT under Andrew Kadak, but the website, gives an impression that the work did not go far.

But you could send several thousand rovers for the cost of sending one human, and the rovers can stay longer.

The combined cost of Spirit and Opportunity was $820 million dollars.

The potential cost of a manned mission to Mars, using off the shelf technology and launching today: $20 billion dollars.

Which means you can send 48 rovers similiar to Spirit and Opportunity to Mars, with the same payload.

The "rovers being able to stay longer" is a somewhat unqualified statement at the moment. Sure, they have each lasted a year on the surface. It's up in the air whether they will both last another year or not however.

Humans would be forced to stay on the surface of Mars for roughly 2 (Earth) years, until conditions to launch are optimal again.

Regardless, it is technically "cheaper" to send Rovers, but a human on the ground can do so much more.

(Then again, I might be saying this coming from a geology background. I want to be on the ground, physically looking at the rock, breaking it apart in my lab, creating thin sections and examining the mineral content. Right now, all we can do with the rovers is look at pictures and analyze spectrographs... and dig a few inches into the ground. Please, what is beneath all that sound? What is the bedrock composed of. Etc...).

Anyway, for those who haven't read it, I highly recommend Dr. Zubrin's book, The Case For Mars

1. Was a great way of dealing with relational data
2. Would have to await much larger scales of integration before becoming practical.

Fortunately there is at least a little ongoing research.

The beauty of these processors is they integrate memory with computation so that the massive economies of scale we witness in memory fabrication apply to computation speeds as well so long as we can move toward relational rather than function computing as a paradigm. Fortunately this appears to be supported by the study of quantum computers, however those computers may never see the light of day for more fundamental reasons.

For those who don't get the joke, look here.

Let me tell you the story
Of a man named Charlie
On a tragic and fateful day
He put ten cents in his pocket,
Kissed his wife and family
Went to ride on the MTA

Charlie handed in his dime
At the Kendall Square Station
And he changed for Jamaica Plain
When he got there the conductor told him,
"One more nickel."
Charlie could not get off that train.

Did he ever return,
No he never returned
And his fate is still unlearn'd
He may ride forever
'neath the streets of Boston
He's the man who never returned.

Now all night long
Charlie rides through the tunnels
Saying, "What will become of me?
Crying "How can I afford to see
My sister in Chelsea
Or my cousin in Roxbury?"

Charlie's wife goes down
To the Scollay Square station
Every day at quarter past two
And through the open window
She hands Charlie a sandwich
As the train comes rumblin' through.

As his train rolled on
underneath Greater Boston
Charlie looked around and sighed:
"Well, I'm sore and disgusted
And I'm absolutely busted;
I guess this is my last long ride."
{this entire verse was replaced by a banjo solo}

Now you citizens of Boston,
Don't you think it's a scandal
That the people have to pay and pay
Vote for Walter A. O'Brien
Fight the fare increase!
And fight the fare increase
Vote for George O'Brien!
Get poor Charlie off the MTA.

Chorus.

The song is so catchy, it's a shame the guy didn't get elected. Or maybe not, or we'd have elections with theme songs. Wait, we do. Crap.

Numbers are not supposed to be patentable either. US Patent 5373560 was registered by a member of the League for Programming Freedom in order to demonstrate how easy it is to obtain a frivolous software patent.

Almost 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 C++/Java interface goes both directions -- C++ calls Java or Java calls C++. The usual way is that you write a program in Java, and you use the JNI to call down to C++ to get at some low-level/system-level function -- SWT does their native widgets this way.

I have in mind writing the application in C++ using the Windows API (the application is already written that way) and using Java for plug-ins, extensions, numerical processing modules and saving GUI migration for last. One, this is a way of incrementally migrating to Java. Two, it is doing the non-GUI code first, and identifies as much of the app as non-GUI and portable that can be split off. Three, the Java class and JAR files seem like a better kind of DLL -- think of them as platform-portable DLL's that are much less bulky than C++-generated DLL's under Windows.

As to being able to do this in C#/C++, if you write the main app in C#, calling C++ DLL's, COM objects, or ActiveX controls is a piece of cake. Calling C# from C++ is clunky. The C# object has to publish itself as a COM object/ActiveX control and you have to go through some song and dance to register it to make it available that way. Bet it is no big deal having done it once, but every time I get the feeling to do this, I read the long instruction list and decide to lie down until the feeling passes.

As to comments by others that unmanaged C++ calling C# is, I don't know, evil or something, if that is evil than every unmanaged Windows app that doesn't use .NET is equally evil. But if you accept a place for unmanaged Windows apps, there is no difference between calling an unmanaged DLL and calling a managed DLL -- there is no added security lapse for doing this.

By the way, what got me started on this is that you can pretty easily call Java from Matlab -- I think Matlab is a pretty good scripting environment for Matlab because you can create instances of any Java class and invoke any of their methods without needing a static main() method as a Java program entry point. Well what Matlab can do, any C++ program can do the same through JNI.

of John Maedas work (hes been doing this for over 20 years now):

http://plw.media.mit.edu/people/maeda/
http://www.maedastudio.com/index.php
and this book is great:
http://www.amazon.com/exec/obidos/ASIN/0847822958/ 104-9636841-3703163

That's become a standing joke, but don't let a quick laugh prevent you from learning the true lesson of that botch up: that management attitutudes can kill missions, and the mantra of cheaper, faster, better cut too deep into the bone: see James Oberg's great article on the subject.

I remember taking Java my senior year, and hearing they were going to be replacing C++ with Java as "the language" at the school, and I was horrified for those poor freshman. It was bad enough starting off with C++.

Every computer engineer who goes into development should start off with a certain book from the MIT Press. Codemonkeys can skip this stuff, I suppose, but not straight to Java!

I do like his vision of robots run amok trying to destroy humanity a la Will Smith, though. There's some good thinking.

Naturally it was used for many 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.

You should understand that the patent system cannot operate in the fine-grained discriminatory way you would wish it to. There are ethical and practical reasons for this which you ought to be able to figure out if you think about it a little.

Also bear in mind that the patent system is a macro-economic instrument of policy with a broad but specific purpose: to promote progress in the sciences and the useful arts - not to reward people who have brilliant ideas - and that patents are not granted for ideas but for inventions (a very important distinction).

Now you can see why the inevitability of the existence of patents on obvious, trivial and broad inventions in any workable patent system is a well understood phenomenon and deemed an acceptable nuisance in some (investment eating) fields of technology, and it should also be clear why certain whole fields of endeavour have historically been excluded from patentability.

Specifically, mathematics has always been excluded and your example of the RSA algorithm is a classic demonstration of how the extension of patentability to the software field has made a mockery of the hitherto rational and careful practices of legislators and Courts in containing the patent system to the fields in which the damage it does is (possibly) an acceptable trade off.

The RSA algorithm did not take years to come up with - it took me about 30 seconds to come up with it once I'd read the lemma that is it's foundation, and the same would be true for anyone else. In fact the lemma itself is not something that would necessarily take a competent mathematician years to come up with but that is beside the point - the computerisable algorithmic expression of the lemma is an utterly obvious non-invention. Patentability of algorithms means patentability of computational mathematics, and that is - to me and many others - wholly unacceptable.

It gets confused while reading Marvin Minsky, takes a left turn to Minsky's Burlesque, and military hilarity ensues.

No. Its more complicated than that.

A patent only grants the right to exclude others from practicing the invention and does not affirmatively grant the right to practice the invention, a patent is not considered a monopoly right.
IBM, for instance recently opened 500 pantents for OS developers.
Read their pledge. They agree not to assert any of their patents.

It is true though, that a lot of open source advocates are fervently against patents. And Michael G. Kaplan might after all, decide to charge for this ISACS thing. But, I repeat, just because its patented doesn't mean it cannot be open sourced.

Giving people the resources is a good thing, you never know what could come of it. Perhaps this might be of help.

And the OP is probably talking based on the wind-up radio idea, which I think is a good way to think, especially when you consider how cut-off some parts of the world are from civilization.

Have a look at the orbital mechanics - you can raise or lower your orbit by changing your speed a little. That's a mostly-scalar operation. You go up and down, but stay in the same orbital plane (please forgive the obvious simplification.) Now think of your orbital path in terms of the velocity vector. Rotating your orbital plane 90-degrees, for example, requires that you reduce your vector velocity in one axis to zero, while raising the vector velocity in the perpendicular axis to the original amount. So, how much energy did it take to get your original vector velocity? That's right, the whole launch amount. So to turn 90 degrees, you'll need two complete launches worth of fuel and expendibles. That's oversimplified too, because you need to haul that two-launches-worth of booster and fuel up with you in the initial launch. The Rocket Equaiton makes that scenario prohibitive.

Similarly, hauling the rescue capsule around on every frickin' launch has similar implications. It's tremendously wasteful to haul extra weight around "just in case."

I'd propose a "tow truck" kind of solution. To pose an analogy, how often do you use the spare tire in your car? Maybe never? (Automakers won't sell a spare-less car mostly due to negative market perception.) If you don't have a spare tire, what will you do? You'll get on the cell phone and call a tow truck. (I realize you can't just pull over to the curb in space, but bear with me.) The cell phone and tow truck represent elements of a repair (i.e. rescue) infrastructure we have in place. The better the infrastructure, the less you need to haul around the materials to be self-sufficient. I'd rather see a Delta 4 Heavy (or equivalent) equipped with a Crew Extraction Vehicle (CEV.) Yep, it's a capsule that fits a crew of N in horrible discomfort just long enough to return them to earth. I'm thinking extreme Spam-in-a-Can. They wedge inside however they must. There will be rudimentary water and food aboard - think a couple of bottles of Aquafina and some granola bars. They soil their undergarments, if necessary. A shower will be waiting for them when they return. Feces washes off.

The "infrastructure" part involves doing all the pre-flight coordination with the manned mission, and would require that the tow truck could be prepped and launched within 2 days or so of declaration of an emergency. Since it's on the ground, the CEV only has one orbital insertion to deal with. It'd need to mate up with the manned mission, but that's part of the infrastructure too.

Since the CEV is unmanned on launch, it can be configured to use solid boosters. That's going to mitigate liquid-fuel handling issues. It also mitigates flight profile problems - high G-loading tends to do bad things to ugly-bags-of-mostly-water. But the meatbags don't board the CEV until it's already on-orbit, so you only have the human-friendly (re)-entry profile to deal with, right?

The Crew Return Vehicle (not to be confuced with my CEV, above) is a boondoggle. Passengers are seated in relative comfort. They get all sorts of space to move around. The CRV even has wings and a pilot. And it's supposed to be reusable. What a bunch of crap. My CEV, on the other hand, is horribly cramped and has exactly one job to do - return the crew to earth safely. Once. Period.

In writing this, I'm thinking that "tow truck" is the wrong term. The CEV is more of a taxi. We abandon the original damaged spacecraft.

Granted, it has limits but the tech hasn't come out of the shop enough to be really explored- http://web.media.mit.edu/~jpatten/audiopad/ There have been several like it in the last few years with lots of neat uses- mostly design your own interface on the fly or planning /flowcharting apps.

I find it sad that all we can do today is sit on our asses and do 'research' into the past instead of building the future. When I look at the sad, limp, life- and passion-less state of today's "research" (no revolutions whatsoever in 40 years), I just feel like we have lost something in our culture.

All models that are capable of reproducing the last 1000 years or so of climate fail to reproduce the recent global temperature increase (the 'hockey stick') unless they include the effects of human CO2 emissions.

It has been shown that all it takes to produce a graph similar to the famous hockey-stick graph is random data because the mathematics used in that analysis are flawed. I believe this was even mentioned on /. earlier, but here is the article.

That the recent uptick is due to human CO2 is no longer an area of dispute (amongst those researchers with some grasp on reality, who actually know something about the subject, and are capable getting published in respectable peer-reviewed juornals, anyway. Supermarket tabloids and AM radio shows may not agree...)

This also is simple bullshit. The so-called consensus is a political invention. There is a great deal of debate over whether or not global warming is caused by human activity. Unless of course you want to tell me that the staff of MIT's Joint Program on the Science and Policy of Global Change is not qualified on the subject. Here's a summary report that contradicts your assertions pretty nicely. Some quotes:

There has been no certain demonstration of global warming due to accumulating greenhouse gases in the atmosphere. Rather, the entire subject is on the political agenda because scientists have forecast that there will be warming if gases produced by human activities are allowed to continue to accumulate...

...the evidence is not clear-cut. There are large uncertainties in the interpretation of the evidence, first of all about the basic conclusion of a demonstrable anthropogenic "fingerprint"...

Thus, both the evidence of change and the risks involved are characterized by high levels of uncertainty...

Note that this is not a paper simply bashing the claims about human activity causing global warming. It is an excellent paper discussing the theories, the uncertainties, the political process in the U.S., and the international process. I simply lifted the above quotes out of context to highlight the uncertainty. Yes, the paper is a bit old--but since then there have continued to be highly-distinguished scientists pointing out that science has in fact not established that human activity is causing global warming. It is a leading theory, but there are alternative theories that are also very viable.

Let me just get in one last dig at the hysterical greens on this. Here's an article about an incident where an MIT professor of meteorology and atmospheric sciences disputed the conventional opinions we all read in the papers. Now check out this hilarious quote:

Oliver Bernstein '03, student chair of the Environmental Conservation Organization, was not convinced: "It was upsetting to see someone who is that qualified using pretty advanced science to try to disprove global warming..."

Think about that for a minute. It is "upsetting" to hear a highly-qualified scientist use "advanced science" when discussing our knowledge of global warming??? Are you familiar with the meaning of the word "dogma"??? Think about it!

This is a good example of traditional social patterns showing up in science and confusing the issue. Here's a good article about Richard Lindzen's take on the subject. You can find his papers and testimony before the Senate on his website at MIT.

See also Rufus's speech on ideas vs. beliefs in Dogma.

Whois is "Domains by Proxy", so that's not immediately helpful.

BatMax, Inc. is a valid Florida corporation, but their mail drop is "WORLD CORPORATE SERVICES, INC., 2665 S. BAYSHORE DRIVE, SUITE 703, MIAMI FL 33133". Again, not too helpful.

The USPTO shows a trademark for BatMax: "BatMax Corporation, Suite # 3A, 9250 West Bay Harbor Drive, Bay Harbor Islands, FLORIDA 33154". That's a condo in Colony Bay Harbor Condos. It's a small residential building, and doesn't look anything like the "picture of BatMax skyscraper headquarters" on their web site. The building pictured on the web site is Espirito Santo Plaza in Miami, which is still under construction although partially occupied.

From a BatMax press release, we get a name: Alain Aisenberg, and a phone number, (305) 865-1400.

We find Alain Aisenberg talking about BatMax on an MIT mailing list.. There, he gives his cell phone number.

A public records search finds that name in Miami, and gives us enough information to run a background check.

But I'll stop there.

Bah, and here I thought it meant this...

What's next - google hires a plumber - the end of IT as we know it?

No... It's perfectly obvious what that would mean:

http://web.media.mit.edu/~paulo/courses/howmake/ml fabfinalproject.htm

Have you read it???
Because it says no such thing. It does NOT state that "it was COMPLETELY LEGAL to download and make available for download, a song, or a movie, or software for which you have not paid for", not even close. All the ruling states in that case was that copyright infringement can not be prosecuted under the wire fraud statute.

Read more.

An interesting article, but the principle is hardly new. Paul Webb first proposed the MCP suit in the late 1960's. The Wiki entry http://en.wikipedia.org/wiki/Space_activity_suit has links to the original 1968 and 1971 reports and is worth reading.

The suits are interesting but not perfect. You apparently have to prebreathe and use low air pressure (in the helmet). Then there's the twin items of protecting the crotch and providing sanitary 'facilities' for astronauts stepping out for more than an hour or two.

Other items that some people have commented on could actually be fixed quite easily. Radiation protection and micrometeorite armor could be provided by a coverall worn over or strapped to the inner pressure suit (imperial storm trooper armor?). Because the coverall doesn't have to be airtight its tolerances (and costs) can be a lot lower. tactically placed holes in the coverall would allow tubes from the PLSS through. The hard torso would, if used at all, only be used to carry the PLSS since the suit appears to do all the pressure support.

Space.com and the base article appear to have left out the most important link of all of this. http://mvl.mit.edu/EVA/biosuit.html has more pics and more technical data.

I doubt that suits like this would initially be used for any kind of space tourism. For that the ability to adjust and resize a suit, as can be done with the current EMU suits or with a fully rigid hardsuit design, is probably more important. A modular suit, especially a hardsuit, would bring the price down a lot. A commercial operator might also like a hardsuit's zero-prebreathe capability.

A non-spacegoing but interested Coward.

Human skin is actually a surprisingly strong pressure barrier. The conterpressure suit can be an open weave with up to millimeter sized openings. The biggest problem is figuring out how to keep pressure on the concave areas such as under the arms and behind the knees. An advantage of counterpressure suits is that a tear in the suit doesn't result in catastrophic pressure loss. It only causes injury to the area of the tear. Another problem with them is getting them on and off. It would be like putting super tight pantyhose over your whole body. (not that I know anything about that)

Here are some papers on counterpressure suits:
http://mvl.mit.edu/EVA/BioSuitDJN_Nov03.pdf
http://spacecraft.ssl.umd.edu/publications/ICES02- 2311.pdf
http://mvl.mit.edu/EVA/NIACPhaseIReport.pdf

Human skin is actually a surprisingly strong pressure barrier. The conterpressure suit can be an open weave with up to millimeter sized openings. The biggest problem is figuring out how to keep pressure on the concave areas such as under the arms and behind the knees. An advantage of counterpressure suits is that a tear in the suit doesn't result in catastrophic pressure loss. It only causes injury to the area of the tear. Another problem with them is getting them on and off. It would be like putting super tight pantyhose over your whole body. (not that I know anything about that)

Here are some papers on counterpressure suits:
http://mvl.mit.edu/EVA/BioSuitDJN_Nov03.pdf
http://spacecraft.ssl.umd.edu/publications/ICES02- 2311.pdf
http://mvl.mit.edu/EVA/NIACPhaseIReport.pdf

For one example: Printing a physical textbook on dead trees is fairly expensive (several dollars), and it costs more money to physically transport it to the classroom. Burning the same information to a CD-R is two orders of magnitude cheaper (several cents).

Thanks to initiatives like this one, a poor, remote village school can access the contents of the world's best libraries for about the same cost as a decent set of encyclopedias.

Everyone knows about BSD's failure and its 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 the 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.

Check out Structure and Interpretation of Computer Programs.

I say:
I switched because less finger travel made my hands less tired at the same typing speed. I still use both layouts, but if I am typing a lot, I will use dvorak.

When I first thought about switching, I created an Excel macro to count finger reaches in QWERTY phrases and one for Dvorak. I also started making a list of common words that can be typed on the home row in each. In both of these endeavors, Dvorak won. roughly 25-30% less finger travel, more in some phrases. Many more common words on the home row.

Here http://www.kinesis-ergo.com/ is a company that makes ergo keyboards with vertical rows, QWERTY, Dvorak, or both.

History says:
The slant of the columns on the keyboard is an artifact left over from mechanical typewriters.
For those not acquainted with the story of the keyboards, here's a short version:
http://www.mit.edu:8001/people/jcb/Dvorak/

When I first read it I thought they were talking about Cog over at the MIT AI Lab.
I'm no robotics expert, but this seems so simple or at least first-generation in comparison.

When I first read it I thought they were talking about Cog over at the MIT AI Lab.
I'm no robotics expert, but this seems so simple or at least first-generation in comparison.

That's a much repeated falsehood.
Besides, everyone knows that all real geeks chord.

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.

Given that hacking draws so much from model railways (Tech Model Railroad Club) perhaps it is valid to say hackers have been quilting for years??

I take it you were recreating the MIT Athena Bathroom Cluster?

Pardon me for being insistent, but "openoffice.org" is a Web address, not a name. If the company that makes it doesn't want their customers to call it "Open Office," they should change the name. (They should probably change the name in any case. "Open Office" doesn't exactly stir the soul.)

That's not being insistent, it's being stupid. OpenOffice.org is the name of the software. The original poster was correct, you tried to correct him but looked like an idiot because you were wrong and then I corrected you. It's a very simple sequence of events; do try and keep up. As for what you think of the name, nothing you've posted so far inspires me to assign any value to your opinion.

Numbers.

A meaningless non-response with nothing to back it up, almost certainly indicating that you have no basis for your opinion. This is unsurprising.

No, it was supposed to be illustrative. Reading comprehension much?

Illustrative of what? That you don't hire competent people? That you change your hardware and software platform whenever you change IT personnel? It's certainly not illustrative of anything regarding open source software.

> We use open source software because we like the support, reliability and licensing freedom.

How odd. Because it has none of those three things.

I don't normally go in for personal attacks but you're really not a very honest person, are you? Starting from the end:

For you to claim that open source software doesn't provide licensing freedom is either stupid or dishonest. Since you're apparently capable of operating a computer with at least minimal competency I find it difficult to believe that you could be stupid enough to believe what you said. So you've apparently lying. Unfortunately you chose to lie about a subject that the Slashdot audience understands reasonably well so you're not going to get very far.

As for reliability, there are plenty of studies that show the reliability of open source.

And finally, support. I don't think this will be news to anyone except (perhaps) you but paid support is available for open source software. Linux is supported by distributions such as Redhat and Novell, Apache & Tomcat are supported by companies like JBoss and Samba is supported by a truly huge list of companies in many countries. As another poster pointed out, OpenOffice.org has commercial support available from companies like Blue Point

You shouldn't bother replying to this, but if you do be sure to bring some facts to back up your position. Your blind assertions do not impress.

Essentially they teach the class for the professor

And Scott McClellan is the President of the United States when Bush is in Texas?

Teaching is 99% planning; the execution part could just as easily be carried out by mannequins (which is one reason OCW is causing such a stir). A TA is a mannequin.

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.

Check out this diagram of a classifier system. It's taken from The Computational Beauty of Nature. The website isn't really up to date nowadays, but the full source code for everything in the book is available in both Linux and Windows downloads and there's a java applet of all the examples too.
The material covered in the book is also still very relevant and the books a joy to read.
You should buy it :^) Not astroturfing just really enjoyed the book myself.

Check out this diagram of a classifier system. It's taken from The Computational Beauty of Nature. The website isn't really up to date nowadays, but the full source code for everything in the book is available in both Linux and Windows downloads and there's a java applet of all the examples too.
The material covered in the book is also still very relevant and the books a joy to read.
You should buy it :^) Not astroturfing just really enjoyed the book myself.

Happiness is the competent exercise of rational powers in a life affording them proper scope, according to Aristotle (and some others.)

Richard Stallman said:

"...an Australian government study of the patent system in the 1980's concluded that aside from international pressure, there was no reason to have a patent system. It did no good for the public and recommended abolishing it if not for international pressure."

Maggie Thatcher's favourite economist, Hayek, said:

"I am thinking here of the extension of the concept of property to such rights and privileges as patents for inventions, copyright, trade-marks, and the like. It seems to me beyond doubt that in these fields a slavish application of the concept of property as it has been developed for material things has done a great deal to foster the growth of monopoly and that here drastic reforms may be required if competition is to be made to work. In the field of industrial patents in particular we shall have seriously to examine whether the award of a monopoly privilege is really the most appropriate and effective form of reward for the kind of risk-bearing which investment in scientific research involves."

Has had this sort of thing for a while