That's exactly what NASA and DARPA were thinking last year.
However, there's more to the package than meets the eye. In the Endeavor package, we launched a pair of picosats tethered together by 50' of kevlar embedded with gold to get the antenna cross section up.
While picosats do get the cost down, development still isn't particularly inexpensive.
I was involved in a DARPA picosat effort last year; I can actually say my code launched off Endeavor back on December 12th. Our picosats also used the ARM as the "main host" on the stack, had 8MB of flash, used a Rockwell/Conexant digital cordless telephone chip for the radio boards. I seem to recall we used vxWorks for our main host. I wrote the Conexant-related comms code.
At the time, the company I work for "unexpectedly" inherited the picosat project from another NASA and DARPA contractor. Embedded Linux wasn't really an option since we had a lot to do in very little time.
Writing code that flew in space definitely rocked!
No, you've missed the point. The Conquest FS is part of the OS, not the drive. Putting more RAM into the drive is the wrong thing to do, because you're running at the drive interface's bus speed (33, 66,.. Mhz) instead of at the CPU-RAM bus speed (100, 200+ FSB speed.)
Even with an aggressive caching algo, you can't flush memory to disk at the disk's bandwidth because you have metadata to update (inode arrays being one, directory blocks being another.)
Conquest doesn't impose much of a FS on the disk, so it doesn't have a lot of metadata to update. Therefore, it flushes to disk at close to the controller's bandwidth. It also doesn't have all of the other complexities that come with the disk-oriented parts of the OS such as caching, after all RAM is already the cache.
Actually, you're incorrect. It's not the specific types of files that get stuck into RAM (that's a side effect.) It's small files under 1M that get stuck in RAM. Large files pretty much stay out on disk.
BTW: The paper's author sits next to me in my office here at UCLA. So I might know a thing or two about this research.
Dr. Kleinrock wasn't the sole inventor of the Internet (or ARPANET, for that matter), but he's recognzed as being one the few singly influential people in its creation. There's also Paul Baran, once upon a time from RAND in Santa Monica, who's came up with the idea of cheap, redundant components for communication, which also lead to the 'Net.
"lk" wrote two really influential books on queueing theory that are required knowledge for networking theory. If you know what a M/M/1, M/G/1, M/M/n queues are, it probably came from or was derived from Kleinrock's books at some point or another.
UCLA modded up Dr. Kleinrock's influence over the 'Net. Historically, UCLA took delivery of the first IMP, Internet message processor. The first 'login' prompt ever seen across IMPs was from UCLA to UCSD. "lk" was there for that event. Being as influential in the 'Net's creation is something to be proud of, and Dr. Kleinrock is awfully proud of his lifetime's achievements.
Dr Kleinrock graduated a lot of people who also became rather influential. "lk" was Vint Cerf's advisor. You know the 3-way handshake? That was one of Vint Cerf's students, Carl Sunshine. Oh, and Chris Ferguson, the US poker champion from two years ago's advisor was... you guessed it, Dr. Kleinrock.
"lk" is an emeritus professor. He's retired. He can do what he wants with his time. Being an expert witness is one of the things he does. It's lucrative. Dr. Kleinrock's well respected in his field. He's pretty intelligent Go figure!
Dr. Kleinrock isn't the only expert witness, he's the one with serious name recognition. All of the expert witnesses, besides "lk" and there are a more than a few of them, have been analyzing whether or not the file peer-to-peer systems can be controlled and whether they could have had more control over the content being shared. Clearly the answer is yes if there are servers involved (or supernodes, for that matter.)
Will there be summary judgement? Probably not. Remains to be seen.
Did the RIAA and MPAA make good faith efforts to identify protected content and assist the filtering? Doesn't sound like they did. Do they have a "shoot them all, let God sort them out" attitude with litigation? Yup, sure looks like it.
Does money talk and bullshit walk? Yeah, it does. MPAA and RIAA have money and vested interests. Can they afford an intelligent team of expert witnesses? You betcha!
If you really want to do something useful, contribute to a PAC that is out to protect fair-use rights.
It's not green and its not in the engineering library (or for that matter, what used to be the computer science archives.) It's in the spare office across the hall from Dr. Kleinrock's office.
First node (actually IMP "Internet Message Processor" produced by BBN) was here at UCLA. Second node was UCSB or UCSD, depending on whom you ask. But UCLA was the first to take delivery of IMP #1.
It doesn't really matter if you OSS the source: the contract you are presumably working under contains a clause to the effect "The Government retains an interest in this code" (i.e. the gov't can request the source at any time for free.) This clause is in standard DARPA contracts and grants, USAF acquisitions, etc.. Whether or not the contractor decides to release the code as a general work is another issue.
Classification-level of the code and work product is a total red herring.
There are some obvious layers of release process you have to go through before you can publish any source outside your project. The biggest hurdle is getting the contract's program office to agree that the code is publishable outside the program.
What it comes down to is: sure, go ahead, put an OSS license on the code if you want to. If you do decide to make a case for publishing the code as OSS to the general public and run the gauntlet through program offices, make sure you can separate the unclassified components from the rest of the code.
Just because you OSS your code doesn't mean that the program office or contractor automagically has to publish the code, esp. when access levels get in the way.
At anyrate, the definition of a fact, is a social contstruct. It is a fact that the sky is blue. there for the sky is blue.
Wrong. The description of the shade of color, if we can actually know what 'color' is, is part of a linguistic convention, so that we can communicate ideas and concepts with each other.
'Social construction' is a very undescriptive term. It implies that there is some absolute frame of reference upon which all people agree or commonly hallucinate. Who does this construction? This 'construction' is nothing more than 'consensus', where both of us, agreeing to speak English, also agree to describe the color of the sky with sunlight streaming through it 'blue'. And there are other languages that follow the same principle, consensus to denote the color of the sky as an equivalent term.
Where's my 'Objectivist Epistemology' clue-by-four
on
Why Community Matters
·
· Score: 1
There is only one reality: Physical reality. Without it, existence is futile. In physical reality, there are actions, causes, and reactions. Saying that reality is a social construction is completely meaningless, because, like author said, "I jump off a building and get killed", which is not a social construction.
Exploring "reality", or in this case various "reality" contexts, is completely worthless. "Social reality" is a meaningless term because there is no absolute frame of reference for interpreting socal interactions.
"The reality" of anything is always relative to the perceptions of the observer and the observer's predispositions to interpreting the causes, actions, and reactions perceived.
Philosophically, I can't actually tell to which epistemology the author subscribes, but I'll be more than happy to help him out with a free copy of Ayn Rand's "Objectivist Epistemology" to get him straightened out!
There are multiple problems with multicast, not the least of which will be setting up your routers to actually do multicast routing. In the words of an IETF routing area director: "We've spent how many years on this problem, and we still can't do inter-domain multicast routing?"
You've got two choices in the LAN environment: DVMRP and PIM-DM. Router vendors converged on PIM-SM, because it fits better with its inter-domain big brother, PIM-SM (and partly the result of IETF multicast standards politics.) However, I have not come across an open source version of PIM-SM for either FreeBSD or Linux. If you know of such a critter and it ACTUALLY WORKS, I'd be interested in finding out about it.
If you're not interested in inter-domain type multicast routing, then DVMRP works just fine. There are a number of open source implementations out there, although, you should be advised that it will probably go the way of T Rex in the future.
Once you get multicast routing to work, then you'll need to consider things like reliable multicast transport. TCP doesn't work for reasonably obvious reaons apparent to even undergrads. You'll also want to look for IETF RFCs from the LSMA working group that talk about how to apply multicast to large scale simulations. And you will have to carefully analyze what makes sense to multicast in your application environment, i.e. where one-to-many partial computation replication actually makes sense. For example, does your application have one-to-many partial computations that form a staged pipeline?
Multicast has the potential for being a fine tool, but it solves one set of problems at a fairly low network level. There's a lot of extra thinking one has to do to use it effectively at the application level, above and beyond content streaming.
I know this concept will get flamed pretty badly, but one of the reasons why there is a concept of intellectual property is that not all people out there in the world are, well, nice! Like a nuclear weaspon, a patent can also be used for good and for evil. What isn't "fair" to most/.-ers is that a patent prevents use without permission of the patent holder. In my personal experience, the commercial world is full of ruthless competition, and patents can be really useful in making sure your competition doesn't screw you -- esp. if you're competing against larger companies (who'll remain nameless, but you can probably fill in the blank.)
There are a whole range of behaviors, ranging from "use this patented code but don't change it w/o my permission" to "Don't use this code unless you pay me an unreasonable amount of money." Most of the time, depending on how useful your code is, there's a middle ground.
What you might think about, because it'll be much less expensive for you in the short term, is letting the company patent your work BUT also make sure that you still have the ability to use to code with very favorable licensing terms. Then, propose to strike out on your own, offering the company the ability to both invest and outsource the development. It's a win-win for both you and the company.
The current ballot system is setup the way it is to protect the voter's anonymity. Period. While I'm proudly a Republican and voted that way, I do know a number of people out here in LA who'd prefer for professional reasons (related to the entertainment industry) to remain apolitical or appear apathetic.
It's interesting to hear/. get apoplectic every time the on-line ad agencies use a semi-anonymous cookie identifier. What would happen if Harris Poll or doubleclick started correlating voter electronic IDs with voting patterns. Imagine the market potential for the political parties, not to mention the SPAM!
You can't run a company and have an H-1B visa at the same time as a foreign national. You have to be sponsored by the company to get issued one in the first place.
Sure, there are people of originally foreign origin who are creating and running companies in Sillycon Valley. But they ain't the one's to whom the H-1B visa applies.
H-1B visas are a kind of indentured servitude. If you think this is a good thing, well, maybe civil rights got pushed back a few years. If memory serves me correctly, I seem to recall that (a) H-1B visa holders get paid substantially less than us citizenry, (b) the visa holder can't piss and moan about it too loudly because they can't move jobs. If that isn't a form of servitude, smack me with a wet Chihuahua!
What you've missed is that Symantec makes it easy for a luser to actually use the products. Hylafax, while it exists as a feature, requires a decent amount of clue to configure. WinFAX actually has a user-mostly-friendly UI to interact with. And don't get me started with procmail (which I've been using for quite a number of years, thank you very much, when my mail transport was smail via UUCP.)
Yes, Linux and FreeBSD (my platform of choice) have all these features. But they are not for the average luser.
I think one could attribute this to network stack idiosyncracies. For example, if the Linux stack only sets its recv buffer to some specific size that's smaller than the *BSD size, would account for the difference. IIRC, Van Jacobson pointed out a number of problems with the TCP implementation doing weird things in slow start and congestion avoidance that might also account for impedance mismatching.
A similar problem cropped up when Samba was benchmarked against NT's SMB implementation.
He bemoans the fact that computer scientists still tend to use such crufty old tools as Unix, Emacs, and TeX, despite the fact that these tools are still very capable and that they grow more capable every day. The Novelty that Mr. Pike is so obsessed with is only useful when it constitutes an improvement over what is currently in use.
Pike's been around for a while, as in version 0.1 of AT&T Unix circa 1970. So, if he hasn't seen any real innovations, he'd pretty much be an authority on the subject.
As for your comments wrt "the standard tools", I'd tend to agree with Rob. My usage of Emacs, TeX, and the GNU C compiler hasn't changed in 10 years. However, even I have to give MS a few points for the Visual XXX environments -- they may have been acquired, but they've been packaged nicely. Try getting Emacs to manage a Java code project the way Visual J++ does (w/o manually editing and crafting Makefile.am's, etc)!
Now, if we were talking about software quality, well, now, I'd have to violently agree that MS software quality is dubious at best.
ISI is a research institution, so it's not going to be a truly commercial endeavour. It's not vaporware or vacuumware, it's a research product.
In fact, it's pretty useful.
And while Joe Touch has a pretty thick hide, I feel compelled to point out that your comments are completely uncalled for. I've known Joe for about 6 years now and I wish I were as capable and as knowledgeable as he is. You should be so lucky as to be an undergrad USC serf working for him, you might actually learn something.
The Navy has this plan called "IT-21", which makes it mandatory to use "Commercial, off-the-shelf" technologies. Usually, "COTS" is code for "MS Windows NT". Unfortunately, this is still being used by the Navy and its contractors in the new smart ship program. Which doesn't make me feel all that good when my next ship tour comes up in a couple of years. Clearly, this plan needs revising.
However, that doesn't mean that I refuse to advocate "The right tool for the right job", like FreeBSD for web servers, etc. The problem is that enlisted rates like the DP's and the RM's (now IT's) had bad experiences with other Unixes and like the "simplicity" of NT.
OTOH, the Navy also committed to ATM as their fundamental network technology for the 21st century. So,...
Look, guys, the solution is pretty obvious, and no, the sky isn't falling on open source.
In a rational economy, all participants work towards their own self interest. That's why a small level of cheating is tolerated but egregious acts of cheating eventually get wiped out (unless you're La Cosa Nostra, but that's another story.) Who in their right mind would want to play against a known cheater if they've been outed?
It's something that old command-line news readers have: A kill file. It doesn't take long to discover an aim-bot. If I have a kill file, I can choose to (a) ignore the cheater, (b) refuse to connect to the server that lets him play. The main requirement is that each Quaker player identify himself/herself. Names can be faked and new aliases crafted -- but once outed, again, it's into the kill file. Alternatively, Quake could generate a signature for itself that it exchanges with the server. Again, this could be damaged and faked, but make the effort sufficiently high to do this, and one takes the incentive out of it.
Even better is the QBL (Quake Black Hole) [My appologies to Paul Vixie.] This requires a mod to the server and the server d/l's a list of persona non grata periodically. Your name or signature in the QBL? Tough! It seems to work pretty well to combat e-mail spam...
I know, this requires infrastructure, but what solutions to problems doesn't?
Slashdot Mirror
I forgot to include this in my earlier posting: STS-113 pre-flight and picosat launch photos
Enjoy!
It's called "solar power".
That's exactly what NASA and DARPA were thinking last year.
However, there's more to the package than meets the eye. In the Endeavor package, we launched a pair of picosats tethered together by 50' of kevlar embedded with gold to get the antenna cross section up.
While picosats do get the cost down, development still isn't particularly inexpensive.
I was involved in a DARPA picosat effort last year; I can actually say my code launched off Endeavor back on December 12th. Our picosats also used the ARM as the "main host" on the stack, had 8MB of flash, used a Rockwell/Conexant digital cordless telephone chip for the radio boards. I seem to recall we used vxWorks for our main host. I wrote the Conexant-related comms code.
At the time, the company I work for "unexpectedly" inherited the picosat project from another NASA and DARPA contractor. Embedded Linux wasn't really an option since we had a lot to do in very little time.
Writing code that flew in space definitely rocked!
No, you've missed the point. The Conquest FS is part of the OS, not the drive. Putting more RAM into the drive is the wrong thing to do, because you're running at the drive interface's bus speed (33, 66, .. Mhz) instead of at the CPU-RAM bus speed (100, 200+ FSB speed.)
Even with an aggressive caching algo, you can't flush memory to disk at the disk's bandwidth because you have metadata to update (inode arrays being one, directory blocks being another.)
Conquest doesn't impose much of a FS on the disk, so it doesn't have a lot of metadata to update. Therefore, it flushes to disk at close to the controller's bandwidth. It also doesn't have all of the other complexities that come with the disk-oriented parts of the OS such as caching, after all RAM is already the cache.
Actually, you're incorrect. It's not the specific types of files that get stuck into RAM (that's a side effect.) It's small files under 1M that get stuck in RAM. Large files pretty much stay out on disk.
BTW: The paper's author sits next to me in my office here at UCLA. So I might know a thing or two about this research.
Dr. Kleinrock isn't the only expert witness, he's the one with serious name recognition. All of the expert witnesses, besides "lk" and there are a more than a few of them, have been analyzing whether or not the file peer-to-peer systems can be controlled and whether they could have had more control over the content being shared. Clearly the answer is yes if there are servers involved (or supernodes, for that matter.)
Will there be summary judgement? Probably not. Remains to be seen.
Did the RIAA and MPAA make good faith efforts to identify protected content and assist the filtering? Doesn't sound like they did. Do they have a "shoot them all, let God sort them out" attitude with litigation? Yup, sure looks like it.
Does money talk and bullshit walk? Yeah, it does. MPAA and RIAA have money and vested interests. Can they afford an intelligent team of expert witnesses? You betcha!
If you really want to do something useful, contribute to a PAC that is out to protect fair-use rights.
Otherwise, quit yer whining!
It's not green and its not in the engineering library (or for that matter, what used to be the computer science archives.) It's in the spare office across the hall from Dr. Kleinrock's office.
First node (actually IMP "Internet Message Processor" produced by BBN) was here at UCLA. Second node was UCSB or UCSD, depending on whom you ask. But UCLA was the first to take delivery of IMP #1.
It's unclassified work under a DARPA contract or grant.
It doesn't really matter if you OSS the source: the contract you are presumably working under contains a clause to the effect "The Government retains an interest in this code" (i.e. the gov't can request the source at any time for free.) This clause is in standard DARPA contracts and grants, USAF acquisitions, etc.. Whether or not the contractor decides to release the code as a general work is another issue.
Classification-level of the code and work product is a total red herring.
There are some obvious layers of release process you have to go through before you can publish any source outside your project. The biggest hurdle is getting the contract's program office to agree that the code is publishable outside the program.
What it comes down to is: sure, go ahead, put an OSS license on the code if you want to. If you do decide to make a case for publishing the code as OSS to the general public and run the gauntlet through program offices, make sure you can separate the unclassified components from the rest of the code.
Just because you OSS your code doesn't mean that the program office or contractor automagically has to publish the code, esp. when access levels get in the way.
At anyrate, the definition of a fact, is a social contstruct. It is a fact that the sky is blue. there for the sky is blue.
Wrong. The description of the shade of color, if we can actually know what 'color' is, is part of a linguistic convention, so that we can communicate ideas and concepts with each other.
'Social construction' is a very undescriptive term. It implies that there is some absolute frame of reference upon which all people agree or commonly hallucinate. Who does this construction? This 'construction' is nothing more than 'consensus', where both of us, agreeing to speak English, also agree to describe the color of the sky with sunlight streaming through it 'blue'. And there are other languages that follow the same principle, consensus to denote the color of the sky as an equivalent term.
There is only one reality: Physical reality. Without it, existence is futile. In physical reality, there are actions, causes, and reactions. Saying that reality is a social construction is completely meaningless, because, like author said, "I jump off a building and get killed", which is not a social construction.
Exploring "reality", or in this case various "reality" contexts, is completely worthless. "Social reality" is a meaningless term because there is no absolute frame of reference for interpreting socal interactions.
"The reality" of anything is always relative to the perceptions of the observer and the observer's predispositions to interpreting the causes, actions, and reactions perceived.
Philosophically, I can't actually tell to which epistemology the author subscribes, but I'll be more than happy to help him out with a free copy of Ayn Rand's "Objectivist Epistemology" to get him straightened out!
There are multiple problems with multicast, not the least of which will be setting up your routers to actually do multicast routing. In the words of an IETF routing area director: "We've spent how many years on this problem, and we still can't do inter-domain multicast routing?"
You've got two choices in the LAN environment: DVMRP and PIM-DM. Router vendors converged on PIM-SM, because it fits better with its inter-domain big brother, PIM-SM (and partly the result of IETF multicast standards politics.) However, I have not come across an open source version of PIM-SM for either FreeBSD or Linux. If you know of such a critter and it ACTUALLY WORKS, I'd be interested in finding out about it.
If you're not interested in inter-domain type multicast routing, then DVMRP works just fine. There are a number of open source implementations out there, although, you should be advised that it will probably go the way of T Rex in the future.
Once you get multicast routing to work, then you'll need to consider things like reliable multicast transport. TCP doesn't work for reasonably obvious reaons apparent to even undergrads. You'll also want to look for IETF RFCs from the LSMA working group that talk about how to apply multicast to large scale simulations. And you will have to carefully analyze what makes sense to multicast in your application environment, i.e. where one-to-many partial computation replication actually makes sense. For example, does your application have one-to-many partial computations that form a staged pipeline?
Multicast has the potential for being a fine tool, but it solves one set of problems at a fairly low network level. There's a lot of extra thinking one has to do to use it effectively at the application level, above and beyond content streaming.
I know this concept will get flamed pretty badly, but one of the reasons why there is a concept of intellectual property is that not all people out there in the world are, well, nice! Like a nuclear weaspon, a patent can also be used for good and for evil. What isn't "fair" to most /.-ers is that a patent prevents use without permission of the patent holder. In my personal experience, the commercial world is full of ruthless competition, and patents can be really useful in making sure your competition doesn't screw you -- esp. if you're competing against larger companies (who'll remain nameless, but you can probably fill in the blank.)
There are a whole range of behaviors, ranging from "use this patented code but don't change it w/o my permission" to "Don't use this code unless you pay me an unreasonable amount of money." Most of the time, depending on how useful your code is, there's a middle ground.
What you might think about, because it'll be much less expensive for you in the short term, is letting the company patent your work BUT also make sure that you still have the ability to use to code with very favorable licensing terms. Then, propose to strike out on your own, offering the company the ability to both invest and outsource the development. It's a win-win for both you and the company.
The current ballot system is setup the way it is to protect the voter's anonymity. Period. While I'm proudly a Republican and voted that way, I do know a number of people out here in LA who'd prefer for professional reasons (related to the entertainment industry) to remain apolitical or appear apathetic.
/. get apoplectic every time the on-line ad agencies use a semi-anonymous cookie identifier. What would happen if Harris Poll or doubleclick started correlating voter electronic IDs with voting patterns. Imagine the market potential for the political parties, not to mention the SPAM!
It's interesting to hear
-scooter
You can't run a company and have an H-1B visa at the same time as a foreign national. You have to be sponsored by the company to get issued one in the first place.
Sure, there are people of originally foreign origin who are creating and running companies in Sillycon Valley. But they ain't the one's to whom the H-1B visa applies.
H-1B visas are a kind of indentured servitude. If you think this is a good thing, well, maybe civil rights got pushed back a few years. If memory serves me correctly, I seem to recall that (a) H-1B visa holders get paid substantially less than us citizenry, (b) the visa holder can't piss and moan about it too loudly because they can't move jobs. If that isn't a form of servitude, smack me with a wet Chihuahua!
-scooter
What you've missed is that Symantec makes it easy for a luser to actually use the products. Hylafax, while it exists as a feature, requires a decent amount of clue to configure. WinFAX actually has a user-mostly-friendly UI to interact with. And don't get me started with procmail (which I've been using for quite a number of years, thank you very much, when my mail transport was smail via UUCP.)
Yes, Linux and FreeBSD (my platform of choice) have all these features. But they are not for the average luser.
Just my $0.02.
-scooter
I think one could attribute this to network stack idiosyncracies. For example, if the Linux stack only sets its recv buffer to some specific size that's smaller than the *BSD size, would account for the difference. IIRC, Van Jacobson pointed out a number of problems with the TCP implementation doing weird things in slow start and congestion avoidance that might also account for impedance mismatching.
A similar problem cropped up when Samba was benchmarked against NT's SMB implementation.
-scooter
He bemoans the fact that computer scientists still tend to use such crufty old tools as Unix, Emacs, and TeX, despite the fact that these tools are still very capable and that they grow more capable every day. The Novelty that Mr. Pike is so obsessed with is only useful when it constitutes an improvement over what is currently in use.
Pike's been around for a while, as in version 0.1 of AT&T Unix circa 1970. So, if he hasn't seen any real innovations, he'd pretty much be an authority on the subject.
As for your comments wrt "the standard tools", I'd tend to agree with Rob. My usage of Emacs, TeX, and the GNU C compiler hasn't changed in 10 years. However, even I have to give MS a few points for the Visual XXX environments -- they may have been acquired, but they've been packaged nicely. Try getting Emacs to manage a Java code project the way Visual J++ does (w/o manually editing and crafting Makefile.am's, etc)!
Now, if we were talking about software quality, well, now, I'd have to violently agree that MS software quality is dubious at best.
-scooter
ISI is a research institution, so it's not going to be a truly commercial endeavour. It's not vaporware or vacuumware, it's a research product.
In fact, it's pretty useful.
And while Joe Touch has a pretty thick hide, I feel compelled to point out that your comments are completely uncalled for. I've known Joe for about 6 years now and I wish I were as capable and as knowledgeable as he is. You should be so lucky as to be an undergrad USC serf working for him, you might actually learn something.
-scooter
A divide by zero shouldn't cause a blue screen of death. Which is what happened on the servers.
-scooter
The Navy has this plan called "IT-21", which makes it mandatory to use "Commercial, off-the-shelf" technologies. Usually, "COTS" is code for "MS Windows NT". Unfortunately, this is still being used by the Navy and its contractors in the new smart ship program. Which doesn't make me feel all that good when my next ship tour comes up in a couple of years. Clearly, this plan needs revising.
...
However, that doesn't mean that I refuse to advocate "The right tool for the right job", like FreeBSD for web servers, etc. The problem is that enlisted rates like the DP's and the RM's (now IT's) had bad experiences with other Unixes and like the "simplicity" of NT.
OTOH, the Navy also committed to ATM as their fundamental network technology for the 21st century. So,
-scooter
Look, guys, the solution is pretty obvious, and no, the sky isn't falling on open source.
In a rational economy, all participants work towards their own self interest. That's why a small level of cheating is tolerated but egregious acts of cheating eventually get wiped out (unless you're La Cosa Nostra, but that's another story.) Who in their right mind would want to play against a known cheater if they've been outed?
It's something that old command-line news readers have: A kill file. It doesn't take long to discover an aim-bot. If I have a kill file, I can choose to (a) ignore the cheater, (b) refuse to connect to the server that lets him play. The main requirement is that each Quaker player identify himself/herself. Names can be faked and new aliases crafted -- but once outed, again, it's into the kill file. Alternatively, Quake could generate a signature for itself that it exchanges with the server. Again, this could be damaged and faked, but make the effort sufficiently high to do this, and one takes the incentive out of it.
Even better is the QBL (Quake Black Hole) [My appologies to Paul Vixie.] This requires a mod to the server and the server d/l's a list of persona non grata periodically. Your name or signature in the QBL? Tough! It seems to work pretty well to combat e-mail spam...
I know, this requires infrastructure, but what solutions to problems doesn't?
-scooter