You miss the main point - which I put in the first paragraph (or perhaps the second - I can't recall) - that we must develop a means of sustaining the human race through cataclysm. The archeological record is clear, there have been mass extinctions as a recurrent theme in the past, which indicates that there probably will be in the future, as well.
The archaeological record is clear - KT-style events happen infrequently. Even smaller impacts, such as the one beneath the Chesapeake Bay occur every 20 or 30 million years. The chances that an impact capable of wiping out humanity on this planet occurring in the next thousand years is vanishingly remote.
Still, let's say Earth was struck by a 100 million year event like Chicxulub and you wanted to choose the most hospitable location to live in in the immediate aftermath. It turns out that the best place is right here on Earth! After all, there will still be an atmosphere, full gravity, and a magnetosphere to protect from solar wind. You would have to live in a sealed environment with a self-contained food and power supply for awhile. But it would only be for awhile, a decade maybe. And you wouldn't have to start living like that until just before the thing hit. Compare that with any other place in the solar system. To establish a permanent Mars colony big enough and self-sufficient enough to be capable of surviving the loss of all other humanity would be an expense unlike any before seen. For a fraction of the cost you could set up an asteroid detection network, multiple layers of space-based nuclear robotic tugs capable of nudging an asteroid off course, AND a network of shelters for perserving the species if disaster couldn't be avoided. And, less you think I'm totally obsessed with cost, it would also save BILLIONS of lives and allow the survivors to continue flourishing in a relative garden of eden. And, since such a system would be much less expensive, that would mean more money to spend on much more likely disasters, like the disease, war and famine that is going on right now.
Sustaining the human race through a cataclysm is not a good reason for manned space flight at this time. It's an excuse that scares people into funding massive manned missions of colonization because they accept the premise that such colonization is the only way to save humanity in a disaster. Not only is it not the only way, it isn't even a good way.
Robots currently don't have the intelligence and flexibility to cope with changing environments quickly (look how long it took the mars rovers to cover the few miles during their explorations, that would have been a day trip for manned exploration).
First of all, most exploration of the Solar System does not require coping with changing environments quickly.
Secondly, it took the Mars rovers more time than you are used to mainly because they were solar powered and because the controllers were cautious. If there were astronauts riding on the rovers they'd go even slower because there'd be more mass to move around. I know this sounds facetious, but it's not. You'd either have slower rovers or bigger, more expensive ones. Plus, if I'd wanted to be facetious I'd have noted instead that the rovers would have gone nowhere because the astronauts would have shaded the solar cells.:)
The decision loop of a human being on-site is faster than a remote robot taking commands from JPL due to the great distances of interplanetary space making the speed of light an issue. However, that is not main delay with the rovers currently on Mars.
There is no substitute, yet, for a human being on the ground. There is a whole level of real-time experiences that a robot can not take in or comment on - that humans are more than capable of doing. Aside from collecting specimens and taking pictures, robots will never have the immediacy that humans offer.
First, you are wrong to say "never", unless you believe that AI of high-order is not possible.
Second, collecting specimens and taking pictures aren't the only thing robots are good for. They are also good at seismic studies, spectral analysis, chemical sampling, and myriad other measurement missions. Space robots are simply platforms for scientific instrumentation. The same kinds of instrumentation humans would carry, only better because it's all integrated and because you can carry more at a cheaper cost because you're not toting along astronauts and their creature comforts.
You are right that lots more data can be more quickly processed by a human brain if that brain is getting a high-bandwidth signal at close range, such as that provided by the good ol' Mark-1 Eyeball. However, that's a pretty darned expensive instrument. And, to make matters worse, it's not equipped with a very good data recorder, so you have to have separate devices to capture visual information in a format others can see.
The idea of a completely automated space program, is similar to the idea of a completely remote controlled military aparatus. I think we can all agree that, except in rare circumstances where a robot would perform better (air combat beyond gforce limits of human pilots, and remote reconnaisance), war must be fought by humans, due to the ability to make the right decisions that AI is incompetent to make - and, more importantly, to not distance ourselves so much from the life and death on the battlefield as to make it easy for us to choose war as a first option. Human beings bring moral and esthetical issues into the mix, which robots, for all their precision, lack.
Now, here is where your concern for immediacy is a problem - the modern Terran battlefield. Things do happen very quickly here and a delay of even a second can mean the difference between a kill and loss of your platform to hostile fire. Your point about removing humans from harm's way is also well taken. When you don't have millions of families worried about their relatives physical welfare, it's much too easy to get them to let you go kill other nation's people.
However, your warfare example is more of an anti-analogy than analogy for your two main points: immediacy and the impact to the mission of the death of those on the ground.
The issue of immediacy pretty much disappears when other people aren't trying to destroy you. And when you consider tha
Actually, that IS the problem: Drugs are TOO fun. They are often times more fun than other things in people's lives that turn out to be useful to society. Like work, friends, and family. If none of these (or any other) areas of your life are very appealing compared to being high, you tend to get high instead of spending time with them. Which tends to make work, friends, and family even less enjoyable, or not even available. And since drugs can be taken in doses much greater than their natural analogs, they often are more fun, almost by the biological definition of the word.
You have a reward system in your brain that has evolved for hundreds of millions of years to promote evolutionarily useful behavior. Drugs skirt right around this system and end up promoting one behavior; getting high again. And, since, as mentioned above, the doses can be so much higher (or bind tighter) than natural versions, you get habits and desires burned into your brain quickly and deeply.
Ever hear of "thinking with your genitals"? Much of that "thinking" is attributable to the reward system in your brain. Tapping into that with drugs is like hypnotizing yourself that doing drugs is what you want. You create a new, often dangerous behavior that becomes instinctual along the lines of sex because it uses the same pathways as sex!
Everyone thought we'd all kill each other with nuclear weapons. Since it hasn't happened yet, we've been lulled into thinking we were being paranoid. We were not. Not only could we have killed ourselves with nukes, we still can.
But that's not the worst of it.
Nuclear weapons were the first class of weapons which could kill everyone on the planet. But they aren't the last, or even the worst. Nuclear weapons, as should be filtering down to all of us via the coverage of the recent events in Iraq, are difficult to construct even for nation-states with BILLIONS of dollars to throw at the problem. Also, it takes a lot of time and, as Iran, North Korea and others have found out, is relatively easy to detect.
Biological weapons, however, are a different story. The knowledge of life and death are inextricably intertwined; how can you seriously figure out how to cure disease if you don't know how it is caused? Indeed, the primary way to study curing disease is to CAUSE it in test subjects and then try to fix it. The secrets of life (and thus death) are falling rapidly before us and it turns out to be frighteningly easy for small groups or even individuals to create disease that would encircle the globe and kill literally billions.
In fact, the only thing stopping this from happening is the lack of crazies who don't mind killing billions indiscriminately and have managed to keep it together long enough to get a degree in microbiology. Over the next fifty years, the bar for being able to modify life is going to keep lowering, while the population of crazies (along with the rest of us) will be increasing.
While the prospect of nuclear holocaust is a frightening possibility, it is much easier to prevent. The bar is high enough that one may operate at the nation-state level to ensure non-proliferation and as little all-out warfare as possible. But how can you prevent a single madman from using the techology we're creating to cure disease to create one which will fell us all?
I believe that life is a natural outcome of certain conditions that are likely to have existed sometime in the past 5 billion years in millions of places in this galaxy, to say nothing of the rest of the universe. Intelligent life with the ability to create a techology sufficient to spread itself to other planets is much rarer. Part of the reason is that intelligent life is rare compared to normal life and the other part is that the techologies likely to have co-developed with a potentially starfaring culture are too easily turned against themselves.
I'm starting to think that the Amish may be on to something. Then again, not many Amish civilizations would be detectable via radio telescopes.
... despite the name. It's a test to see how easily Windows and Mac users can apply their existing skills to using Gnome. Each user was asked to accomplish a task without being shown how to do it the "Gnome way".
Seems to me that usability should be a measure of how quickly and easily tasks can be accomplished when using the operating system as intended, which implies that the user must know how to and be practiced in it's use.
For instance, take the tested tasks and train users in how to accomplish them in the most efficient way available for each OS. Let them practice for some time with each. Then, do a timed test of how long it takes them to accomplish the task in each environment. THAT should be what we call usability.
This is really a test of people's initial reaction to having to use a similar, but different UI with no training. How valuable is that? Let's see: you set someone, who may not feel exactly secure using a computer in the first place, in front of a new UI and say that they have to try to get some stuff done. When they try to do what's worked for them in the past and it doesn't work, are they going to feel good about that? No. They'll feel that either they or the UI are stupid. And, human nature being what it is, they will generally assume that it must be the new UI. ESPECIALLY if you tell them they are helping you test the usability of the new UI.
How can the user take advantage of a better UI workflow if s/he is trying to do things the way it was done using the OS their used to?
How can all users go (untrained) through the tests as quickly and easily as the UI they've been using for five frigging years unless the tested UI is essentially identical?
I bet that if you showed them a tutorial video of how to accomplish all of the tasks and then asked them to try the tasks themselves, their reactions would have been much more positive. And, the researcher's recommendations wouldn't amount to "Hmmm, Gnome has more work to be done - it's not enough like Windows AND MacOS yet." Never mind that it can't be both. Instead, you'd have more helpful information like, "Gnome allowed users to reach a web page 17% faster than Windows. However, e-mail took 22% longer to use and needs some work."
Intuitive is nice, but is all about making connections with things the user already knows how to do. That's why icons and terms like "trashcan" are considered intuitive. When GUIs were new, they were designed to work like real-world objects enough that people could get a clue. Now that most of the people (in the US, anyway) have used a computer to some extent for years, an intuitive computer task is one that works like Windows. So, if you want to be intuitive to ex-Windows users, clone the Windows UI. And, of course, that is essentially what has happened. In the case of this test of Gnome, you'll notice that the rough spots in the testing were in those areas where Gnome DOESN'T work like Windows.
Looks more like Irish-American-Indian-Spiderman to me. Is it necessary to make him look "American" to appeal to Indian lovers of American comic books? If so, doesn't this bring into question the entire concept?
Why is this better than just having Spiderman realize that there might be other places in the world in more need of super-hero assistance than the rich and powerful United States?
According to the link you supplied, this mutation has little or nothing to do with myostatin or this boy:
In horses with HYPP, studies revealed a defect affecting a protein called the voltage-gaited sodium channel, a tiny gateway in the membrane of muscle cells. This gateway controls the movement of sodium particles in and out of the muscle cell. These sodium particles carry a charge that changes the voltage current of a muscle cell, allowing it to contract or relax. In horses with HYPP, the regulation of particles through the sodium channel occasionally fails, disrupting the normal flow of ions in and out of the muscle cell, causing uncontrollable muscle twitching or complete muscle failure.
Geiger581 is onto it. This weapon system is mainly about being able to cheaply attack land targets with impunity.
That's right. Finger of God within a 250 mile radius. Choose a grid coordinate, any coordinate: two minutes later, a hole appears. And being supersonic, you won't even hear it coming.
No need to land ships and establish a beachhead. No pilots to get captured. No AMERICAN lives lost. Just holes appearing where your people and equipment used to be every ten seconds or so, per railgun.
We keep talking about the best programming language for the desktop, but I think that's a bit misleading. What's most important is not the language, per se. What's important is the platform.
Look at what Microsoft is doing. They've created a platform with the CLR/.Net infrastructure. They have language products like C# and VB.Net (and J#, but no one's THAT big of a sucker) that allow the application programmer to choose a language in which THEY will be productive and/or feel comfortable. But guess what? The same resources (GUI / Network / DB / Web / etc.) are available to both. In fact, a VB.Net programmer and a C# programmer can each work on the same project and have everything work right together. Wanna know why? Because the USEFUL tools Microsoft has already written (in fast, native code) are accessed via the CLR and both programmers' code get converted to the same IL. Microsoft has created a unified ABI that all of their managed products use, so that it doesn't matter what language is chosen, you get to use all the neat toys that come with the PLATFORM.
And that's what we need. We need a virtual platform that has the following attributes:
1. Comprehensive and useful framework. It should be tuned to the needs of MODERN applications, i.e. it includes a full-featured GUI, a useful Database interface API, Network APIs, etc. The key is to provide a comprehensive foundation that programmers can use to create their apps so that they only have to write the code that is unique to their problem, not recreate infrastructure useful to many apps.
2. Provide application portability. It should be accessible only to applications via an architecture-independent bytecode system, so desktop applications written for the virtual platform will run unaltered on all compliant IMPLEMENTATIONS of this virtual platform.
With a modern JIT-ing virtual machine along the lines the JVM and CLR, the vast majority of non-platform code will run "fast enough". Making the platform bytecode engine able to pre-compile speed sensitive sections of user bytecode to native code after delivery should satisfy most people's "need for speed".
3. Have native speed. Each implementation of the platform must be written in blazingly fast native code, including the GUI! If the goal is to provide an extremely productive framework that allows developers to make useful programs in less code, it follows that the resulting programs will spend most of their "time" inside of platform code. Thus, it's gotta be FAST!
Let's be honest: Sun made a strategic mistake with writing Swing in Java. While it made it easier to only have to implement a full-blown GUI once, it was so dog-slow that until recently no one really took it seriously and it has acquired a bad reputation. In hindsight, they would have been much better off at this point to have implemented Swing natively on all supported platforms, as they do the core elements of the JRE.
4. Available to all. It must become as ubiquitous as we can make it. That means all OS platforms and that it can't be just for free/Free apps. If you want to maximize productivity for desktop programmers, it needs to become the "de facto" standard. If you're going to learn to program, THIS is what you should be able to learn at college and at your local "Learn to be a Computer Geek" training programs. If possible, implementations should be Open Source. Regardless, the platform itself needs to be protected by a community process or other trustee system to prevent hijacking by commercial interests. The idea is to provide, as a community of individuals and businesses, the infrastructure for us all to be productive.
What everyone is wrestling with is that a platform with all of these features does not yet exist. There are many platform or platform-like frameworks out there that provide some or much of this, but none of them do it all. Worse yet, the two platforms that are the closest to achieving the technical
1) Your apps were mostly computation-intensive or used in cases where raw speed was essential to be usable/competitive.
2) Your apps were mostly not computation-intensive, but included small sections that had the need for speed.
In case one, you now realize correctly that you may have chosen the wrong tool; C was probably a better choice than LISP.
Case two, however, has me confused. Most of the higher-level, modern production languages (Python, Perl, Java, C#, etc.) have support for native methods written in C. Why wouldn't you simply write the bits that need the speed (e.g. signal processing, as you mention) in C and call it from your high-level language? Then, you get the best of both worlds. Of course, you make cross-platform deployment more difficult, but no more difficult than if you wrote the whole thing in C.
BTW, none of this is to say that C is "unsuitable" for writing GUIs or anything else. I'm just saying that you don't have to give up the convenience of a high-level language because a small amount of code needs to be very fast.
Re:This is bad and misunderstands cc theft
on
The Universal Card
·
· Score: 1
Actually, it turns out that credit card companies do use this kind of software. At a credit card company where I used to work, there were hourly reports from a neural network-based fuzzy logic system that would flag "suspicious" purchases for examination by fraud personnel.
The software would notice just the kind of behavior you mention.
One of the classic fraud patterns was seeing the following:
1. Light or little activity for weeks.
2. A purchase of gasoline at the pump, followed quickly by...
3. Many high-dollar items, especially electronics, within a few hours.
Occasionally, there would be a few gas purchases interspersed. It turns out that the gas purchases weren't necessarily to fill up, so much as to test whether the card was still good in an anonymous and easily escapeable situation.
Unfortunately, things that look like they may be just be someone using a card they normally don't use a lot for holiday spending. It can be tricky. This is why a human fraud analyst gets called in to look things over and put a block on the card until they can contact the cardholder. If any of you have had a call from the credit card company about your activity, it was because of an automated system that flagged the account.
Actually, the best way to stop credit card fraud would be to move to a challenge/response system that uses encryption. Think Kerberos or some digitally signed transaction. But that's not going to happen until it's cheap enough for us all to have PDA-like devices.
In terms of preserving our satellite infrastructure during warfare, a much better strategy would be to have numerous spare satellites waiting atop launchers, a la ICBM's in their silos. If an attack (EMP-based or otherwise) seriously degrades the satellite fleet, "turn the keys" and have replacements within 20 minutes.
Granted, the technology for this isn't ready to deploy, but it certainly seems more feasible than developing extravagant counter-measures. Plus, the R&D involved may have the nice side-effect of reducing the cost of lofting things into orbit.
Of course, this means making the satellites smaller and cheaper, as well. Again, not necessarily easy, but seemingly much more feasible. And, again, this would have benefits beyond simply making the system more survivable.
For those unaware, "11B" is the US Army's Military Occupational Specialty (MOS) code for an Infantry soldier, often affectionately referred to as a "grunt".
They are also known, a bit less affectionately, to us ex-19-series (Armor) soldiers as "track grease".;)
It is neither easier nor cheaper to install a telescope on the Moon. The main issues of a LEO scope remain with a Lunar scope:
1. Cost of lifting to orbit
2. Complexity of designing a system that can handle extremes of heat and cold.
3. Radiation hardening, etc.
4. Power systems
5. Costs and dangers of getting people up there to do repairs.
In fact, having it three days away and sitting in a 1/6th gravity well would actually add to the costs.
You kind of already answered your own question. Here, listen to yourself:
> We _already_ pay to use the net. > We pay a monthly access fee (in NZ, broadband pays by the Mb, too). > We pay for our hosting space, and our domain registration. > We pay excess bandwidth use if we have a popular site, or if we want extra mailboxes or services.
You've already paid OTHER companies for infrastructure to reach the website's content (not to mention the other items you list that have NOTHING to do with looking at other people's websites), but you haven't paid the content provider for their content.
Asking why you have to watch commercials after paying all those other people is like asking why you have to watch television commercials when you've already paid for the TV, electricity to run the TV, and the snacks you eat while watching TV.
If he hasn't changed it since 1993-4 when I heard him speak in Ames, IA, the plan is to send a robotic mission to pre-manufacture the return vehicle's fuel, oxidizer, and the astronaut's water and oxygen from the Martian atmosphere using a nuclear power plant and relatively small amount of hydrogen. The beauty of manufacturing the fuel on Mars is the massive weight savings. The beauty of the robotic prep-mission is that you don't have to send the astronauts into harm's way until you know everything worked and the consumeables are waiting for you.
Here are the details:
1. Send a robotic site preparation mission first. The mission would be scheduled, as all Mars shots are, to coincide with close approach. The mission would only have enough fuel to get to the surface, and not have enough to return. Also, because it's robotic, it wouldn't have to have any oxygen for breathing or water for drinking. It would carry some hydrogen, a portable nuclear power plant, and a crew recovery vehicle capable of Earth return, were it properly fueled.
2. After landing, the nuke would be driven by a robotic rover to a safe distance, preferably in a nearby crater. Putting it in a crater allows one to reduce the (heavy) shielding.
3. Using power from the nuke, hydrogen from the lander, and CO2 from the atmosphere, the next two years would be spent making methane, oxygen and water. The water and oxygen are obvious (and heavy) needs for astronauts. Methane will be the fuel for the return flight. Also, it will fuel Mars exploration buggies/rovers/aircraft; no more need for staying near the equator to milk every little bit of energy from the Sun.
4. If something goes wrong with supplies production over the course of the two years, we'll know about it BEFORE we send the astronauts. If there is a problem, you send another automated site prep mission.
5. Once we have a fully fueled and equipped crew recovery vehicle waiting for us on Mars, we send the astronauts. Again, this vehicle can be fairly light, because it doesn't have to bring along return fuel or oxygen; that's already waiting for us on Mars.
The plan is absolutely brilliant and doable with today's technology. The sticking point would probably be the politics of the nuke.
Note that this plan does not depend on the existance of Martian water reserves. Finding appreciable amounts of water there would make taking the hydrogen unnecessary, but is not a necessary component of the mission.
He's complaining that the drivers just aren't there and that this makes the technology immature. WTF? If he were talking about how writing quality drivers for Linux was so much harder than writing them for Windows because of some flaw in the driver model for Linux, then he'd at least be making sense, because he'd actually be talking about the OS. He'd be wrong, of course, but at least he wouldn't be speaking gibberish.
It's true that there aren't Linux drivers for every device that comes out when it comes out, as there is for Windows. But how is this reflective of immature Linux technology? It's just that the manufacturers don't want to spend the money to write multiple drivers and so they pick the one that has 90% market share! That's it!
Let's see how mature Windows technology would look if hardware manufacturers told Microsoft to write their own damn drivers. Better yet, if they told Microsoft to hack them together through reverse engineering! How friggin' easy would it be burn your damn CD or use your wireless card on Windows then?
The real driver problem for Linux is market share. This is why drivers for enterprise types of hardware are getting better manufacturer driver support - Linux is actually gaining some market share there.
If Linux were to ever crack 40% market share on the home desktop, there'd be drivers come out our ears.
Actually, the DC-X used four RL-10 LH/LOX engines because they were:
Off-the-shelf
Had a long, extremely reliable track record
Throttleable over a large power range
Restartable, although this would only have come into play during a (sub-) orbital hop
Relatively cheap compared to the competition, the SSME
Granted, an actual orbital craft would have needed more than four to work. But there are enough other technologies needed to get something, anything up to replace current the STS that coming up with brand new engine technologies should only be considered if necessary.
Btw, not that this should lend me too much credibility, but I got the privelege of actually witnessing the first public (second overall) flight test of the DC-X at White Sands, along with other members of the Iowa State Space Society. It was a VERY cool summer trip.:)
---------------
Space: It's bigger than your house.
Now, if this was a school that would be based on Open Source software, then all schools everywhere would be able to take advantage of this prototype. Instead, as you point out, Microsoft gets to then take the stuff it writes and market it to other schools.
This is another example of why I believe that the vast majority of IT spend on software by public institutions should be legislated to be put towards developing Open Source software rather than proprietary, custom or off the shelf.
Here's an article that may shed more light on the political motivations behind such radical changes. Turns out that the state of Pennsylvania had to take over the Philly school system it stank so much.
Microsoft is not enabling this. While they are donating some services, Philadelphia is still footing the bill. Philadelphia could simply announce that they want to create this kind of school and then open the bidding on who was going to provide the services. The problem here is not that Microsoft is involved with such a project, it is a problem of HOW Microsoft has become involved. And the blame lies not at Microsoft's feet, but instead at those of Mayor Street's administration.
Let's just hope that VA Software doesn't try their own GINA implementation. I suspect that it would end up being susceptible to penetration by the Sobig virus.
Slashdot Mirror
Still, let's say Earth was struck by a 100 million year event like Chicxulub and you wanted to choose the most hospitable location to live in in the immediate aftermath. It turns out that the best place is right here on Earth! After all, there will still be an atmosphere, full gravity, and a magnetosphere to protect from solar wind. You would have to live in a sealed environment with a self-contained food and power supply for awhile. But it would only be for awhile, a decade maybe. And you wouldn't have to start living like that until just before the thing hit. Compare that with any other place in the solar system. To establish a permanent Mars colony big enough and self-sufficient enough to be capable of surviving the loss of all other humanity would be an expense unlike any before seen. For a fraction of the cost you could set up an asteroid detection network, multiple layers of space-based nuclear robotic tugs capable of nudging an asteroid off course, AND a network of shelters for perserving the species if disaster couldn't be avoided. And, less you think I'm totally obsessed with cost, it would also save BILLIONS of lives and allow the survivors to continue flourishing in a relative garden of eden. And, since such a system would be much less expensive, that would mean more money to spend on much more likely disasters, like the disease, war and famine that is going on right now.
Sustaining the human race through a cataclysm is not a good reason for manned space flight at this time. It's an excuse that scares people into funding massive manned missions of colonization because they accept the premise that such colonization is the only way to save humanity in a disaster. Not only is it not the only way, it isn't even a good way.
First of all, most exploration of the Solar System does not require coping with changing environments quickly.
:)
Secondly, it took the Mars rovers more time than you are used to mainly because they were solar powered and because the controllers were cautious. If there were astronauts riding on the rovers they'd go even slower because there'd be more mass to move around. I know this sounds facetious, but it's not. You'd either have slower rovers or bigger, more expensive ones. Plus, if I'd wanted to be facetious I'd have noted instead that the rovers would have gone nowhere because the astronauts would have shaded the solar cells.
The decision loop of a human being on-site is faster than a remote robot taking commands from JPL due to the great distances of interplanetary space making the speed of light an issue. However, that is not main delay with the rovers currently on Mars.
First, you are wrong to say "never", unless you believe that AI of high-order is not possible.
Second, collecting specimens and taking pictures aren't the only thing robots are good for. They are also good at seismic studies, spectral analysis, chemical sampling, and myriad other measurement missions. Space robots are simply platforms for scientific instrumentation. The same kinds of instrumentation humans would carry, only better because it's all integrated and because you can carry more at a cheaper cost because you're not toting along astronauts and their creature comforts.
You are right that lots more data can be more quickly processed by a human brain if that brain is getting a high-bandwidth signal at close range, such as that provided by the good ol' Mark-1 Eyeball. However, that's a pretty darned expensive instrument. And, to make matters worse, it's not equipped with a very good data recorder, so you have to have separate devices to capture visual information in a format others can see.
Now, here is where your concern for immediacy is a problem - the modern Terran battlefield. Things do happen very quickly here and a delay of even a second can mean the difference between a kill and loss of your platform to hostile fire. Your point about removing humans from harm's way is also well taken. When you don't have millions of families worried about their relatives physical welfare, it's much too easy to get them to let you go kill other nation's people.
However, your warfare example is more of an anti-analogy than analogy for your two main points: immediacy and the impact to the mission of the death of those on the ground.
The issue of immediacy pretty much disappears when other people aren't trying to destroy you. And when you consider tha
Actually, that IS the problem: Drugs are TOO fun. They are often times more fun than other things in people's lives that turn out to be useful to society. Like work, friends, and family. If none of these (or any other) areas of your life are very appealing compared to being high, you tend to get high instead of spending time with them. Which tends to make work, friends, and family even less enjoyable, or not even available. And since drugs can be taken in doses much greater than their natural analogs, they often are more fun, almost by the biological definition of the word.
You have a reward system in your brain that has evolved for hundreds of millions of years to promote evolutionarily useful behavior. Drugs skirt right around this system and end up promoting one behavior; getting high again. And, since, as mentioned above, the doses can be so much higher (or bind tighter) than natural versions, you get habits and desires burned into your brain quickly and deeply.
Ever hear of "thinking with your genitals"? Much of that "thinking" is attributable to the reward system in your brain. Tapping into that with drugs is like hypnotizing yourself that doing drugs is what you want. You create a new, often dangerous behavior that becomes instinctual along the lines of sex because it uses the same pathways as sex!
sure to get us all killed.
Everyone thought we'd all kill each other with nuclear weapons. Since it hasn't happened yet, we've been lulled into thinking we were being paranoid. We were not. Not only could we have killed ourselves with nukes, we still can.
But that's not the worst of it.
Nuclear weapons were the first class of weapons which could kill everyone on the planet. But they aren't the last, or even the worst. Nuclear weapons, as should be filtering down to all of us via the coverage of the recent events in Iraq, are difficult to construct even for nation-states with BILLIONS of dollars to throw at the problem. Also, it takes a lot of time and, as Iran, North Korea and others have found out, is relatively easy to detect.
Biological weapons, however, are a different story. The knowledge of life and death are inextricably intertwined; how can you seriously figure out how to cure disease if you don't know how it is caused? Indeed, the primary way to study curing disease is to CAUSE it in test subjects and then try to fix it. The secrets of life (and thus death) are falling rapidly before us and it turns out to be frighteningly easy for small groups or even individuals to create disease that would encircle the globe and kill literally billions.
In fact, the only thing stopping this from happening is the lack of crazies who don't mind killing billions indiscriminately and have managed to keep it together long enough to get a degree in microbiology. Over the next fifty years, the bar for being able to modify life is going to keep lowering, while the population of crazies (along with the rest of us) will be increasing.
While the prospect of nuclear holocaust is a frightening possibility, it is much easier to prevent. The bar is high enough that one may operate at the nation-state level to ensure non-proliferation and as little all-out warfare as possible. But how can you prevent a single madman from using the techology we're creating to cure disease to create one which will fell us all?
I believe that life is a natural outcome of certain conditions that are likely to have existed sometime in the past 5 billion years in millions of places in this galaxy, to say nothing of the rest of the universe. Intelligent life with the ability to create a techology sufficient to spread itself to other planets is much rarer. Part of the reason is that intelligent life is rare compared to normal life and the other part is that the techologies likely to have co-developed with a potentially starfaring culture are too easily turned against themselves.
I'm starting to think that the Amish may be on to something. Then again, not many Amish civilizations would be detectable via radio telescopes.
... despite the name. It's a test to see how easily Windows and Mac users can apply their existing skills to using Gnome. Each user was asked to accomplish a task without being shown how to do it the "Gnome way".
Seems to me that usability should be a measure of how quickly and easily tasks can be accomplished when using the operating system as intended, which implies that the user must know how to and be practiced in it's use.
For instance, take the tested tasks and train users in how to accomplish them in the most efficient way available for each OS. Let them practice for some time with each. Then, do a timed test of how long it takes them to accomplish the task in each environment. THAT should be what we call usability.
This is really a test of people's initial reaction to having to use a similar, but different UI with no training. How valuable is that? Let's see: you set someone, who may not feel exactly secure using a computer in the first place, in front of a new UI and say that they have to try to get some stuff done. When they try to do what's worked for them in the past and it doesn't work, are they going to feel good about that? No. They'll feel that either they or the UI are stupid. And, human nature being what it is, they will generally assume that it must be the new UI. ESPECIALLY if you tell them they are helping you test the usability of the new UI.
How can the user take advantage of a better UI workflow if s/he is trying to do things the way it was done using the OS their used to?
How can all users go (untrained) through the tests as quickly and easily as the UI they've been using for five frigging years unless the tested UI is essentially identical?
I bet that if you showed them a tutorial video of how to accomplish all of the tasks and then asked them to try the tasks themselves, their reactions would have been much more positive. And, the researcher's recommendations wouldn't amount to "Hmmm, Gnome has more work to be done - it's not enough like Windows AND MacOS yet." Never mind that it can't be both. Instead, you'd have more helpful information like, "Gnome allowed users to reach a web page 17% faster than Windows. However, e-mail took 22% longer to use and needs some work."
Intuitive is nice, but is all about making connections with things the user already knows how to do. That's why icons and terms like "trashcan" are considered intuitive. When GUIs were new, they were designed to work like real-world objects enough that people could get a clue. Now that most of the people (in the US, anyway) have used a computer to some extent for years, an intuitive computer task is one that works like Windows. So, if you want to be intuitive to ex-Windows users, clone the Windows UI. And, of course, that is essentially what has happened. In the case of this test of Gnome, you'll notice that the rough spots in the testing were in those areas where Gnome DOESN'T work like Windows.
Here's a direct link to the image.
Looks more like Irish-American-Indian-Spiderman to me. Is it necessary to make him look "American" to appeal to Indian lovers of American comic books? If so, doesn't this bring into question the entire concept?
Why is this better than just having Spiderman realize that there might be other places in the world in more need of super-hero assistance than the rich and powerful United States?
According to the link you supplied, this mutation has little or nothing to do with myostatin or this boy:
In horses with HYPP, studies revealed a defect affecting a protein called the voltage-gaited sodium channel, a tiny gateway in the membrane of muscle cells. This gateway controls the movement of sodium particles in and out of the muscle cell. These sodium particles carry a charge that changes the voltage current of a muscle cell, allowing it to contract or relax. In horses with HYPP, the regulation of particles through the sodium channel occasionally fails, disrupting the normal flow of ions in and out of the muscle cell, causing uncontrollable muscle twitching or complete muscle failure.
Geiger581 is onto it. This weapon system is mainly about being able to cheaply attack land targets with impunity.
That's right. Finger of God within a 250 mile radius. Choose a grid coordinate, any coordinate: two minutes later, a hole appears. And being supersonic, you won't even hear it coming.
No need to land ships and establish a beachhead. No pilots to get captured. No AMERICAN lives lost. Just holes appearing where your people and equipment used to be every ten seconds or so, per railgun.
And, did I mention it's cheap?
Wha-? I don't know that. WAHHHHHHhhhhh... [as I am flung off of the bridge I used to guard]
We keep talking about the best programming language for the desktop, but I think that's a bit misleading. What's most important is not the language, per se. What's important is the platform.
Look at what Microsoft is doing. They've created a platform with the CLR/.Net infrastructure. They have language products like C# and VB.Net (and J#, but no one's THAT big of a sucker) that allow the application programmer to choose a language in which THEY will be productive and/or feel comfortable. But guess what? The same resources (GUI / Network / DB / Web / etc.) are available to both. In fact, a VB.Net programmer and a C# programmer can each work on the same project and have everything work right together. Wanna know why? Because the USEFUL tools Microsoft has already written (in fast, native code) are accessed via the CLR and both programmers' code get converted to the same IL. Microsoft has created a unified ABI that all of their managed products use, so that it doesn't matter what language is chosen, you get to use all the neat toys that come with the PLATFORM.
And that's what we need. We need a virtual platform that has the following attributes:
1. Comprehensive and useful framework. It should be tuned to the needs of MODERN applications, i.e. it includes a full-featured GUI, a useful Database interface API, Network APIs, etc. The key is to provide a comprehensive foundation that programmers can use to create their apps so that they only have to write the code that is unique to their problem, not recreate infrastructure useful to many apps.
2. Provide application portability. It should be accessible only to applications via an architecture-independent bytecode system, so desktop applications written for the virtual platform will run unaltered on all compliant IMPLEMENTATIONS of this virtual platform.
With a modern JIT-ing virtual machine along the lines the JVM and CLR, the vast majority of non-platform code will run "fast enough". Making the platform bytecode engine able to pre-compile speed sensitive sections of user bytecode to native code after delivery should satisfy most people's "need for speed".
3. Have native speed. Each implementation of the platform must be written in blazingly fast native code, including the GUI! If the goal is to provide an extremely productive framework that allows developers to make useful programs in less code, it follows that the resulting programs will spend most of their "time" inside of platform code. Thus, it's gotta be FAST!
Let's be honest: Sun made a strategic mistake with writing Swing in Java. While it made it easier to only have to implement a full-blown GUI once, it was so dog-slow that until recently no one really took it seriously and it has acquired a bad reputation. In hindsight, they would have been much better off at this point to have implemented Swing natively on all supported platforms, as they do the core elements of the JRE.
4. Available to all. It must become as ubiquitous as we can make it. That means all OS platforms and that it can't be just for free/Free apps. If you want to maximize productivity for desktop programmers, it needs to become the "de facto" standard. If you're going to learn to program, THIS is what you should be able to learn at college and at your local "Learn to be a Computer Geek" training programs. If possible, implementations should be Open Source. Regardless, the platform itself needs to be protected by a community process or other trustee system to prevent hijacking by commercial interests. The idea is to provide, as a community of individuals and businesses, the infrastructure for us all to be productive.
What everyone is wrestling with is that a platform with all of these features does not yet exist. There are many platform or platform-like frameworks out there that provide some or much of this, but none of them do it all. Worse yet, the two platforms that are the closest to achieving the technical
So, I see two main possibilities:
1) Your apps were mostly computation-intensive or used in cases where raw speed was essential to be usable/competitive.
2) Your apps were mostly not computation-intensive, but included small sections that had the need for speed.
In case one, you now realize correctly that you may have chosen the wrong tool; C was probably a better choice than LISP.
Case two, however, has me confused. Most of the higher-level, modern production languages (Python, Perl, Java, C#, etc.) have support for native methods written in C. Why wouldn't you simply write the bits that need the speed (e.g. signal processing, as you mention) in C and call it from your high-level language? Then, you get the best of both worlds. Of course, you make cross-platform deployment more difficult, but no more difficult than if you wrote the whole thing in C.
BTW, none of this is to say that C is "unsuitable" for writing GUIs or anything else. I'm just saying that you don't have to give up the convenience of a high-level language because a small amount of code needs to be very fast.
Actually, it turns out that credit card companies do use this kind of software. At a credit card company where I used to work, there were hourly reports from a neural network-based fuzzy logic system that would flag "suspicious" purchases for examination by fraud personnel.
...
The software would notice just the kind of behavior you mention.
One of the classic fraud patterns was seeing the following:
1. Light or little activity for weeks.
2. A purchase of gasoline at the pump, followed quickly by
3. Many high-dollar items, especially electronics, within a few hours.
Occasionally, there would be a few gas purchases interspersed. It turns out that the gas purchases weren't necessarily to fill up, so much as to test whether the card was still good in an anonymous and easily escapeable situation.
Unfortunately, things that look like they may be just be someone using a card they normally don't use a lot for holiday spending. It can be tricky. This is why a human fraud analyst gets called in to look things over and put a block on the card until they can contact the cardholder. If any of you have had a call from the credit card company about your activity, it was because of an automated system that flagged the account.
Actually, the best way to stop credit card fraud would be to move to a challenge/response system that uses encryption. Think Kerberos or some digitally signed transaction. But that's not going to happen until it's cheap enough for us all to have PDA-like devices.
In terms of preserving our satellite infrastructure during warfare, a much better strategy would be to have numerous spare satellites waiting atop launchers, a la ICBM's in their silos. If an attack (EMP-based or otherwise) seriously degrades the satellite fleet, "turn the keys" and have replacements within 20 minutes.
Granted, the technology for this isn't ready to deploy, but it certainly seems more feasible than developing extravagant counter-measures. Plus, the R&D involved may have the nice side-effect of reducing the cost of lofting things into orbit.
Of course, this means making the satellites smaller and cheaper, as well. Again, not necessarily easy, but seemingly much more feasible. And, again, this would have benefits beyond simply making the system more survivable.
For those unaware, "11B" is the US Army's Military Occupational Specialty (MOS) code for an Infantry soldier, often affectionately referred to as a "grunt".
;)
They are also known, a bit less affectionately, to us ex-19-series (Armor) soldiers as "track grease".
It is neither easier nor cheaper to install a telescope on the Moon. The main issues of a LEO scope remain with a Lunar scope:
1. Cost of lifting to orbit
2. Complexity of designing a system that can handle extremes of heat and cold.
3. Radiation hardening, etc.
4. Power systems
5. Costs and dangers of getting people up there to do repairs.
In fact, having it three days away and sitting in a 1/6th gravity well would actually add to the costs.
You kind of already answered your own question. Here, listen to yourself:
> We _already_ pay to use the net.
> We pay a monthly access fee (in NZ, broadband pays by the Mb, too).
> We pay for our hosting space, and our domain registration.
> We pay excess bandwidth use if we have a popular site, or if we want extra mailboxes or services.
You've already paid OTHER companies for infrastructure to reach the website's content (not to mention the other items you list that have NOTHING to do with looking at other people's websites), but you haven't paid the content provider for their content.
Asking why you have to watch commercials after paying all those other people is like asking why you have to watch television commercials when you've already paid for the TV, electricity to run the TV, and the snacks you eat while watching TV.
If he hasn't changed it since 1993-4 when I heard him speak in Ames, IA, the plan is to send a robotic mission to pre-manufacture the return vehicle's fuel, oxidizer, and the astronaut's water and oxygen from the Martian atmosphere using a nuclear power plant and relatively small amount of hydrogen. The beauty of manufacturing the fuel on Mars is the massive weight savings. The beauty of the robotic prep-mission is that you don't have to send the astronauts into harm's way until you know everything worked and the consumeables are waiting for you.
Here are the details:
1. Send a robotic site preparation mission first. The mission would be scheduled, as all Mars shots are, to coincide with close approach. The mission would only have enough fuel to get to the surface, and not have enough to return. Also, because it's robotic, it wouldn't have to have any oxygen for breathing or water for drinking. It would carry some hydrogen, a portable nuclear power plant, and a crew recovery vehicle capable of Earth return, were it properly fueled.
2. After landing, the nuke would be driven by a robotic rover to a safe distance, preferably in a nearby crater. Putting it in a crater allows one to reduce the (heavy) shielding.
3. Using power from the nuke, hydrogen from the lander, and CO2 from the atmosphere, the next two years would be spent making methane, oxygen and water. The water and oxygen are obvious (and heavy) needs for astronauts. Methane will be the fuel for the return flight. Also, it will fuel Mars exploration buggies/rovers/aircraft; no more need for staying near the equator to milk every little bit of energy from the Sun.
4. If something goes wrong with supplies production over the course of the two years, we'll know about it BEFORE we send the astronauts. If there is a problem, you send another automated site prep mission.
5. Once we have a fully fueled and equipped crew recovery vehicle waiting for us on Mars, we send the astronauts. Again, this vehicle can be fairly light, because it doesn't have to bring along return fuel or oxygen; that's already waiting for us on Mars.
The plan is absolutely brilliant and doable with today's technology. The sticking point would probably be the politics of the nuke.
Note that this plan does not depend on the existance of Martian water reserves. Finding appreciable amounts of water there would make taking the hydrogen unnecessary, but is not a necessary component of the mission.
He's complaining that the drivers just aren't there and that this makes the technology immature. WTF? If he were talking about how writing quality drivers for Linux was so much harder than writing them for Windows because of some flaw in the driver model for Linux, then he'd at least be making sense, because he'd actually be talking about the OS. He'd be wrong, of course, but at least he wouldn't be speaking gibberish.
It's true that there aren't Linux drivers for every device that comes out when it comes out, as there is for Windows. But how is this reflective of immature Linux technology? It's just that the manufacturers don't want to spend the money to write multiple drivers and so they pick the one that has 90% market share! That's it!
Let's see how mature Windows technology would look if hardware manufacturers told Microsoft to write their own damn drivers. Better yet, if they told Microsoft to hack them together through reverse engineering! How friggin' easy would it be burn your damn CD or use your wireless card on Windows then?
The real driver problem for Linux is market share. This is why drivers for enterprise types of hardware are getting better manufacturer driver support - Linux is actually gaining some market share there.
If Linux were to ever crack 40% market share on the home desktop, there'd be drivers come out our ears.
Sounds like an improvement over the previous CLI, codenamed "NoNad" (aka CMD.EXE).
Granted, an actual orbital craft would have needed more than four to work. But there are enough other technologies needed to get something, anything up to replace current the STS that coming up with brand new engine technologies should only be considered if necessary.
Btw, not that this should lend me too much credibility, but I got the privelege of actually witnessing the first public (second overall) flight test of the DC-X at White Sands, along with other members of the Iowa State Space Society. It was a VERY cool summer trip.
---------------
Space: It's bigger than your house.
Now, if this was a school that would be based on Open Source software, then all schools everywhere would be able to take advantage of this prototype. Instead, as you point out, Microsoft gets to then take the stuff it writes and market it to other schools.
This is another example of why I believe that the vast majority of IT spend on software by public institutions should be legislated to be put towards developing Open Source software rather than proprietary, custom or off the shelf.
Here's an article that may shed more light on the political motivations behind such radical changes. Turns out that the state of Pennsylvania had to take over the Philly school system it stank so much.
Microsoft is not enabling this. While they are donating some services, Philadelphia is still footing the bill. Philadelphia could simply announce that they want to create this kind of school and then open the bidding on who was going to provide the services. The problem here is not that Microsoft is involved with such a project, it is a problem of HOW Microsoft has become involved. And the blame lies not at Microsoft's feet, but instead at those of Mayor Street's administration.
Let's just hope that VA Software doesn't try their own GINA implementation. I suspect that it would end up being susceptible to penetration by the Sobig virus.