Note that it's Firefox-only. No Internet Explorer support.
Intel has lately started to move into Microsoft's space. Microsoft used to object when Intel did much with software on mainstream platforms, and Intel used to back off. Intel isn't backing off any more. Interesting.
It's not that a single software-defined radio is all that important. It's that you can do the transforms on the incoming waveform and then extract N different channels with one signal processing system. That's what's been making cellular base stations go for almost two decades.
(All the hard work is on the receive side; transmission is easy.)
First generation cellular base stations (i.e. AMPS) had one big analog card per channel, each heavily shielded from its neighbors. The amount of hardware required was huge, and cell sites tended not to be fully populated with channel cards, so they were easy to overload.
Then things started to go digital, with combinations of analog and DSP components processing the signal. Both GSM and CDMA inherently assume digital processing, and in early systems, hard-wired special purpose components were used. As CPUs get faster, there's a steady trend toward using general purpose CPUs.
It's still rare to actually process RF directly in software. Usually, there's a local oscillator and mixer to down-convert the desired band to a working IF frequency, which is then digitized and processed. So it's only necessary to digitize at maybe 10-100MHz, not up in the gigahertz range.
For lower bands, though, a true software RF receivers are available. These just suck up everything from 0 to 30MHz and digitize it. An attached PC does all the hard work.
This actually makes some sense. NSA has two main divisions - Signals Intelligence, which collects information, and Information Assurance, which tries to protect US information. Traditionally, these were the codebreaking and codemaking sides of the agency.
It's a boost for NSA Secure Linux. The real intent of NSA Secure Linux, by the way, was not to plug holes in Linux. It was to get something that enforced mandatory security out into the community, so that that applications would be converted to run under stricter rules. For example, a browser should be running as several components, some of which are secure but dumb and some of which are insecure but untrusted.
Few application developers picked up on this. That part didn't get enough community attention.
NSA takes a quite different view of computer security than the "security industry". They're less concerned about annoying high volume attacks, and more concerned about quiet, focused attacks aimed at specific targets. They're also very interested in who's behind the attack,
and will devote collection resources to finding out more about the attackers.
This last may give some attackers something to worry about.
The basic idea is to create a small fission (not fusion) explosion using magnetic compression. Nuclear weapons use chemical explosives to create an implosion, and during the implosion the fissionable material is compressed hard enough to get a 1.5x to (maybe) 2x density increase.
With magnetic compression, a small pellet can be compressed hard enough to get a 10x density increase. This allows smaller explosions, around 50 gigajoules instead of the 20 terajoules of a fission bomb. They want to use curium or californium as the fuel, rather than plutonium.
They also want to use magnetic containment, rather than an Orion-style "pusher plate" sprayed with oil. Unclear if that can be made to work.
The experimental work (they compressed an aluminum cylinder with a big magnet at Sandia) was done back in 2002. This isn't really under active development.
It's not a totally unreasonable idea, but it would be a huge job to make it work. For one thing, the plan is to assemble a large spacecraft in orbit, not to take off from Earth. It doesn't help with the problem of putting mass in orbit.
USMC FMFM-1, "Warfighting", the US Marines guide to how to run a war. Quite a good read.
"USMC Small Wars Manual", from 1940 and still useful.
US Army FMI 3-07.22, "Counterinsurgency Operations", a recent and honest document about how not to make the same mistakes we made in Iraq.
"Impeachment: A Handbook", Yale University Press, 1974. From the Nixon era.
"Bin Laden: The Man Who Declared War on America" - the must-read book on bin Laden, from 1999, by a US congressional expert on terrorism. Offers a clear picture of what bin Laden is trying to do, written before 9/11. A key point of bin Laden's strategy was to force Western governments to become oppressive, less legitimate, less stable, and thus easier to overthrow.
That collection is likely to drive security people nuts, yet those are must-read books for anyone who wants to have an informed opinion on the current wars.
Even the Cato Institute, which is considered a conservative think tank, is unhappy about the denial of habeas corpus. They're also opposed to the extension of "anti-terror" legislation.
It's not clear why so many Republicans are still supporting this. It's not like being aligned with Bush will get them re-elected.
Last minute payments to an insider just before filing bankruptcy? That's disastrous for SCO. This is waving a red flag in front of the bankruptcy judge. This screams "attempted asset stripping".
It won't work, either.
The bankruptcy trustee can retroactively undo that payment. The trustee can go back into the past 90 days for any transaction and undo it, or back a full year for anything involving an insider. Special payments to insiders during a bankruptcy need explicit permission from the bankruptcy court. And saying "we did it before the bankruptcy" won't help. The law (11 U.S.C. 547) is that "the debtor is presumed to have been insolvent on and during the 90 days immediately preceding the date of the filing of the petition."
The side effects of this will be severe. Remember, SCO management is currently only a "debtor in possession", and can do only whatever the bankruptcy trustee and the court specifically let them do. As soon as the judge gets word of this, SCO's management will have their chain yanked. SCO management will be much more closely supervised and have much less discretionary authority than they expected.
SCO management was apparently thinking they could go into chapter 11 quietly and cut Novell out of the loop. They didn't even list Novell as a creditor in their initial filing. That plan stopped flying when Novell sent five bankruptcy attorneys from Morrison and Foerster to Delaware for the first-day bankruptcy hearing.
Novell's request for a "constructive trust" for the unpaid royalty payments just got a huge boost. Now they'll probably get it. Which drains out most of SCO's cash.
We're already near the end of Moore's Law. The problem is not feature size, it's getting rid of the heat. CPUs are already hitting heat and power limits, which is why CPU speeds stalled out around 3GHz.
Feature size alone matters for memory devices, and we can expect continued progress in memory density. Even for DRAM, getting rid of the heat is becoming a problem, so the future is with devices that don't require refresh cycles. We'll see progress in flash memories and static memory technologies.
Being an astronaut isn't all that great. There are few flights, and you spend years waiting to be assigned to one. Meanwhile, NASA sticks you in make-work jobs, like "Lunch with an Astronaut. You spend a big chunk of your life on hold. That's the basic frustration of the job.
The most successful astronauts are ones who work the system effectively to get good assignments during their downtime. One of the current astronauts spent a tour as an Undersecretary of State. It's a great career move for military types. Most astronauts are pilots; even those who aren't "pilot-astronauts" tend to be flyers. NASA encourages its astronauts to fly (the Original Seven lobbied for this), and has aircraft for astronauts to use. The astronaut corps is a pilot's club.
NASA has 92 active astronauts right now. But they're getting older, and NASA needs some younger people.
The previous system, installed at the Satellite Control Facility, or "Blue Cube" (Onizuka AFB) in Sunnyvale, was physically huge. It was the Technology that Put Men On the Moon: Philco consoles, just like in Apollo Control.
Each time a satellite needed a trajectory adjustment, it took three computers and lots of people. The signal processing was done in something called an Emulated Buffer Controller, which was a transistorized device emulating a previous tube device. The real-time processing was done on one of several UNIVAC 490 series machines from the 1960s, and the trajectory computation was done on a CDC 3800 mainframe from the 1960s.
All this gear was interconnected through big manual patchboards, where, for each satellite pass, people plugged in cables to pass data from the ground station links to the buffer controller to the UNIVAC machine to the CDC machine to the console system.
This operation just drove the satellites, not the payload. The USAF, in a very Air Force way, makes a strong distinction between "driving the bus" and operating the payload. Anything that involved commanding the satellite to move or change orientation went through the Satellite Control Facility. Payloads (GPS, cameras, receivers, etc.) were controlled by the using agencies elsewhere, over separate data links.
The SCF's ground stations had (and still have) large (20 meter) steerable dishes that can communicate with their satellites over a low-bandwidth link regardless of the satellite's orientation, even if it's tumbling. There are about eight ground stations, spaced around the world, and they can track as well as communicate. Once the satellite is properly stabilized and oriented, the wide bandwidth directional links used by the payload come up. Those use smaller ground antennas, so as not to tie up the big tracking dishes.
This was finally phased out in the late 1980s, when control moved to Falcon AFB. Still, during the entire history of the Satellite Control Facility at the Blue Cube, no satellite was ever lost due to an operational error there. That's partly why upgrades were delayed.
The upgrades generally maintained the structure of the system, without doing a complete redesign. (A complete redesign was tried once, in the early 1980s. It flopped.)
Novell already sent five heavy-hitters from Morrison and Foerster, the leading bankruptcy law firm, to Delaware to present their side of the SCO bankruptcy. SCO originally wanted to keep paying their lawyers for their various pre-existing lawsuits during bankruptcy. But they didn't even try to convince the bankruptcy judge of that in court today. So that legal money drain stops. Novell indicated they're going to file a motion to restart their lawsuit (it's just stayed temporarily after the bankruptcy filing), and on October 5, Novell gets to argue that their financial claim preempts most of the other creditors. SCO was just supposed to pass royalties through to Novell, not keep them. Judge Kimball agreed, and put that in his summary judgment order last month, so Novell will probably win that one.
Meanwhile, SCO stock is now at $0.18, down 99% from the peak after SCO sued IBM.
This is about Havok's investors finding an exit strategy, I expect. Havok isn't very profitable, and they had to shrink the company considerably a few years back. Game middleware just isn't that profitable a business.
Havok found new investors and hung on, replacing their top management, but the new investors need to cash out at some point. This is it.
The other major player in this space was Mathengine, which was a dot-com of sorts - too much initial investment and too little revenue. EA acquired them a few years ago.
I've had EA guys tell me they prefer Havok's physics engine, even though EA owns the Mathengine one.
Ageia's innovation was not their hardware, but their business model. Havok and Mathengine sold to game developers, getting a modest fixed fee for each title, plus some consulting and customization work. That just isn't a big revenue stream. Ageia has an end user product, which has more revenue potential.
Railroads and electricity made much bigger changes in people's lives. Before railroads, most people spent their lives within 50 miles of their birthplace.
Before electricity, it was, well, dark at night almost everywhere. Huge amounts of effort went into activities like basic cooking and cleaning clothes.
The changes between 1850 and 1900 were far, far greater than those between 1950 and 2000. In communications, in 1950 we had radio, television, teletype, and telephones. Even newspaper delivery via broadcast radio fax, although that never really caught on. Most important info was getting to its destination fast. Most of the communication things you can do today, you could do in 1950, but more expensively.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
That says, in one line, what I wrote in a much longer post.
Actually, those aren't the real problems with Python. They're not the ones that keep it from, say, replacing Perl.
Multicore support is a nonissue. CPython is too slow to need it. It's helpful to distinguish between the Python language, which isn't bad, and the CPython implementation, which is a slow, naive intepreter. CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C. What's needed is a Python compiler with some smarts. There's Shed Skin, but it doesn't work yet.
One side effect of the speed problem is a tendency to try to write C modules to do things that take significant time. Unfortunately, CPython's interface to C is terrible, bug-prone, and changes with each new release.
The "dynamic language" thing is overdone. CPython is a demonstration of the fact that if you make everything a dictionary, it's easy to implement a dynamic language. It's also a demonstration of "if the only tool you have is a hammer, everything looks like a nail". Too much time is wasted in Python checking to see if something changed that probably didn't change. You can add or change functions or data of a running object or a running function. From outside the object or functionor thread, even! It's cool! It's l33t! It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.) Those features just don't get used that much, except to patch around bugs in the buggy Python libraries. The troubles with the "global interpreter lock" stem from this problem. The "global interpreter lock" is mostly protecting all those dictionaries which define the program. After all, one thread might want to patch the code in another thread.
Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so.
Java has a certain amount of dynamism; you can, if you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that. The Shed Skin implementation imposes some restrictions on dynamism, and they're on the right track.
Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop. Many key modules aren't part of the main Python distribution and aren't synchronized with it. Examples are the interfaces to databases like MySQL and the interface to SSL. These lag months or years behind the base system. Modules outside the small "core" are not supported in any coherent way. Each is supported by a developer or two, working in isolation. If they lose interest, the module languishes, and nobody else can change it. This sometimes leads to multiple libraries for the same purpose, each with different bugs, and none good enough to obsolete the others.
The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
This is where open source fails. A feature list is not a design. Design by committee is usually terrible. Open source programs that aren't clones of some product tend to have poor user interface design.
And no, adding the ability to have "skins" does not improve the interface.
Social networking sites seem to me to be kind of over. A few years ago I was active on a few of them; Tribe and Nerve were fun. But the fun sites are over. Myspace is just the new AOL.
Phone-based social networking is probably where things are going. Although, interestingly, the iPhone doesn't have social networking. Helio does, but nobody uses Helio.
Quackwatch has a good section on how pseudoscience does not make progress, unlike real science.
That's the real problem. Homeopathy isn't any better understood than it was fifty years ago. Nor does it work better. Nor does is ESP. In real science, if you have some phenomenon that's near the noise threshold, people work to design experiments that yield a more definitive result. In psuedoscience, the results stay near the noise threshold forever.
So you never get a working technology out of psuedoscience. And that's the real problem.
Consider electricity. Early researchers, back in the "rubbing fur" era of electric generation, were barely able to get anything to happen. And sometimes, on humid days, it didn't work. It almost looked like psuedoscience. But there was progress. von Guericke in 1650 put a sulfur ball on a rotating shaft and started to build up serious static charges. Then von Kleist made a glass-jar capacitor, and charge could be stored. No question about whether it worked; that setup could deliver a serious zap. From then on, progress was steady.
Orsted discovered electromagnetism in 1820, and that, too, was a flaky phenomenon at first. A wire near a compass would move a compass needle when current flowed, but just barely. But more current caused more needle movement, an indication that this was real. (That's what to watch for - if there's something you can do that makes the effect stronger, it's probably real. If not, probably not.) By 1821, Faraday was able to demo the first electric motor. By 1835, motors had progressed from demo size to demo electric railway size.
The USSR sent robots to the moon in 1970 and 1973. Big, car-sized rovers. They worked well, too. Lunokhod 1 was operational for 322 days, and and Lunokhod 2 for about four months. $1 travelled about 10km, and #2 travelled a total of 37km, so those large vehicles got around quite a bit.
It would be possible to redo that mission today.
Lunokhod 3, never launched, is in a museum. Improved versions of the Proton booster used in 1970 are available from International Launch Services. The lunar landing module would have to be newly constructed, but the design is proven.
Several games have run into severe problems with the internal economy. One early MMORPG had resources which could be mined and converted into items. Abandoned items deteriorated into basic resources. This was envisioned as a closed system with a fixed set of resources. But it broke down when people kept making stuff and hoarding it, resulting in resource exhaustion and runaway inflation.
Another game ran into trouble when NPCs authorized to trade offered prices that allowed arbitrage. Players exploited this by buying from one NPC and selling to another elsewhere. Because the NPCs could create resources, this resulted in a huge increase in M1.
Then there's the relationship with the real world economy. What are the gold farmers doing, and how much are players paying them? Can players still play effectively without dealing with gold farmers?
These issues drive players away, so it's a real issue in game operations.
The article didn't say much about these kinds of issues. Either their economist is clueless or doesn't want to talk about such things. It's surprising to see an article about EvE's economy that doesn't mention gold farming.
The blimp hangar is abandoned and fenced off. The Navy wants to demolish it, and there's a "Save Hangar One organization that wants to preserve it. Nobody wants to pay for fixing its contamination problems.
Micron size water filters have been around for a long time, ask any outdoorsman or backpacker
Yes. I have one in my emergency supplies. Here's some basic info on small water purifiers. These things tend to be slow, low-throughput devices, since they work by forcing water through a 200nm or so absolute filter. Prices are in the US$100 - US$300 range, depending on throughput. Is this new thing faster, or easier to clean, or cheaper, or something?
Slashdot Mirror
Note that it's Firefox-only. No Internet Explorer support.
Intel has lately started to move into Microsoft's space. Microsoft used to object when Intel did much with software on mainstream platforms, and Intel used to back off. Intel isn't backing off any more. Interesting.
It's not that a single software-defined radio is all that important. It's that you can do the transforms on the incoming waveform and then extract N different channels with one signal processing system. That's what's been making cellular base stations go for almost two decades. (All the hard work is on the receive side; transmission is easy.)
First generation cellular base stations (i.e. AMPS) had one big analog card per channel, each heavily shielded from its neighbors. The amount of hardware required was huge, and cell sites tended not to be fully populated with channel cards, so they were easy to overload.
Then things started to go digital, with combinations of analog and DSP components processing the signal. Both GSM and CDMA inherently assume digital processing, and in early systems, hard-wired special purpose components were used. As CPUs get faster, there's a steady trend toward using general purpose CPUs.
It's still rare to actually process RF directly in software. Usually, there's a local oscillator and mixer to down-convert the desired band to a working IF frequency, which is then digitized and processed. So it's only necessary to digitize at maybe 10-100MHz, not up in the gigahertz range.
For lower bands, though, a true software RF receivers are available. These just suck up everything from 0 to 30MHz and digitize it. An attached PC does all the hard work.
This actually makes some sense. NSA has two main divisions - Signals Intelligence, which collects information, and Information Assurance, which tries to protect US information. Traditionally, these were the codebreaking and codemaking sides of the agency.
It's a boost for NSA Secure Linux. The real intent of NSA Secure Linux, by the way, was not to plug holes in Linux. It was to get something that enforced mandatory security out into the community, so that that applications would be converted to run under stricter rules. For example, a browser should be running as several components, some of which are secure but dumb and some of which are insecure but untrusted. Few application developers picked up on this. That part didn't get enough community attention.
NSA takes a quite different view of computer security than the "security industry". They're less concerned about annoying high volume attacks, and more concerned about quiet, focused attacks aimed at specific targets. They're also very interested in who's behind the attack, and will devote collection resources to finding out more about the attackers.
This last may give some attackers something to worry about.
First, this is a blog troll, to drive traffic to some ".info" site. The actual paper, "Proposed Follow-on Mini-Mag Orion Pulsed Propulsion Concept" presented at an AIAA conference last year, is more useful.
The basic idea is to create a small fission (not fusion) explosion using magnetic compression. Nuclear weapons use chemical explosives to create an implosion, and during the implosion the fissionable material is compressed hard enough to get a 1.5x to (maybe) 2x density increase. With magnetic compression, a small pellet can be compressed hard enough to get a 10x density increase. This allows smaller explosions, around 50 gigajoules instead of the 20 terajoules of a fission bomb. They want to use curium or californium as the fuel, rather than plutonium.
They also want to use magnetic containment, rather than an Orion-style "pusher plate" sprayed with oil. Unclear if that can be made to work.
The experimental work (they compressed an aluminum cylinder with a big magnet at Sandia) was done back in 2002. This isn't really under active development.
It's not a totally unreasonable idea, but it would be a huge job to make it work. For one thing, the plan is to assemble a large spacecraft in orbit, not to take off from Earth. It doesn't help with the problem of putting mass in orbit.
That collection is likely to drive security people nuts, yet those are must-read books for anyone who wants to have an informed opinion on the current wars.
Flashblock caught all of them, so we're OK for now.
Even the Cato Institute, which is considered a conservative think tank, is unhappy about the denial of habeas corpus. They're also opposed to the extension of "anti-terror" legislation.
It's not clear why so many Republicans are still supporting this. It's not like being aligned with Bush will get them re-elected.
Last minute payments to an insider just before filing bankruptcy? That's disastrous for SCO. This is waving a red flag in front of the bankruptcy judge. This screams "attempted asset stripping".
It won't work, either. The bankruptcy trustee can retroactively undo that payment. The trustee can go back into the past 90 days for any transaction and undo it, or back a full year for anything involving an insider. Special payments to insiders during a bankruptcy need explicit permission from the bankruptcy court. And saying "we did it before the bankruptcy" won't help. The law (11 U.S.C. 547) is that "the debtor is presumed to have been insolvent on and during the 90 days immediately preceding the date of the filing of the petition."
The side effects of this will be severe. Remember, SCO management is currently only a "debtor in possession", and can do only whatever the bankruptcy trustee and the court specifically let them do. As soon as the judge gets word of this, SCO's management will have their chain yanked. SCO management will be much more closely supervised and have much less discretionary authority than they expected.
SCO management was apparently thinking they could go into chapter 11 quietly and cut Novell out of the loop. They didn't even list Novell as a creditor in their initial filing. That plan stopped flying when Novell sent five bankruptcy attorneys from Morrison and Foerster to Delaware for the first-day bankruptcy hearing.
Novell's request for a "constructive trust" for the unpaid royalty payments just got a huge boost. Now they'll probably get it. Which drains out most of SCO's cash.
We're already near the end of Moore's Law. The problem is not feature size, it's getting rid of the heat. CPUs are already hitting heat and power limits, which is why CPU speeds stalled out around 3GHz.
Feature size alone matters for memory devices, and we can expect continued progress in memory density. Even for DRAM, getting rid of the heat is becoming a problem, so the future is with devices that don't require refresh cycles. We'll see progress in flash memories and static memory technologies.
Being an astronaut isn't all that great. There are few flights, and you spend years waiting to be assigned to one. Meanwhile, NASA sticks you in make-work jobs, like "Lunch with an Astronaut. You spend a big chunk of your life on hold. That's the basic frustration of the job.
The most successful astronauts are ones who work the system effectively to get good assignments during their downtime. One of the current astronauts spent a tour as an Undersecretary of State. It's a great career move for military types. Most astronauts are pilots; even those who aren't "pilot-astronauts" tend to be flyers. NASA encourages its astronauts to fly (the Original Seven lobbied for this), and has aircraft for astronauts to use. The astronaut corps is a pilot's club.
NASA has 92 active astronauts right now. But they're getting older, and NASA needs some younger people.
The previous system, installed at the Satellite Control Facility, or "Blue Cube" (Onizuka AFB) in Sunnyvale, was physically huge. It was the Technology that Put Men On the Moon: Philco consoles, just like in Apollo Control.
Each time a satellite needed a trajectory adjustment, it took three computers and lots of people. The signal processing was done in something called an Emulated Buffer Controller, which was a transistorized device emulating a previous tube device. The real-time processing was done on one of several UNIVAC 490 series machines from the 1960s, and the trajectory computation was done on a CDC 3800 mainframe from the 1960s.
All this gear was interconnected through big manual patchboards, where, for each satellite pass, people plugged in cables to pass data from the ground station links to the buffer controller to the UNIVAC machine to the CDC machine to the console system.
This operation just drove the satellites, not the payload. The USAF, in a very Air Force way, makes a strong distinction between "driving the bus" and operating the payload. Anything that involved commanding the satellite to move or change orientation went through the Satellite Control Facility. Payloads (GPS, cameras, receivers, etc.) were controlled by the using agencies elsewhere, over separate data links.
The SCF's ground stations had (and still have) large (20 meter) steerable dishes that can communicate with their satellites over a low-bandwidth link regardless of the satellite's orientation, even if it's tumbling. There are about eight ground stations, spaced around the world, and they can track as well as communicate. Once the satellite is properly stabilized and oriented, the wide bandwidth directional links used by the payload come up. Those use smaller ground antennas, so as not to tie up the big tracking dishes.
This was finally phased out in the late 1980s, when control moved to Falcon AFB. Still, during the entire history of the Satellite Control Facility at the Blue Cube, no satellite was ever lost due to an operational error there. That's partly why upgrades were delayed.
The upgrades generally maintained the structure of the system, without doing a complete redesign. (A complete redesign was tried once, in the early 1980s. It flopped.)
Novell already sent five heavy-hitters from Morrison and Foerster, the leading bankruptcy law firm, to Delaware to present their side of the SCO bankruptcy. SCO originally wanted to keep paying their lawyers for their various pre-existing lawsuits during bankruptcy. But they didn't even try to convince the bankruptcy judge of that in court today. So that legal money drain stops. Novell indicated they're going to file a motion to restart their lawsuit (it's just stayed temporarily after the bankruptcy filing), and on October 5, Novell gets to argue that their financial claim preempts most of the other creditors. SCO was just supposed to pass royalties through to Novell, not keep them. Judge Kimball agreed, and put that in his summary judgment order last month, so Novell will probably win that one.
Meanwhile, SCO stock is now at $0.18, down 99% from the peak after SCO sued IBM.
When a company goes into bankruptcy, the ticker symbol has a "Q" added at the end. So "SCOX" will change to "SCOXQ" shortly, probably on Wednesday.
This is about Havok's investors finding an exit strategy, I expect. Havok isn't very profitable, and they had to shrink the company considerably a few years back. Game middleware just isn't that profitable a business. Havok found new investors and hung on, replacing their top management, but the new investors need to cash out at some point. This is it.
The other major player in this space was Mathengine, which was a dot-com of sorts - too much initial investment and too little revenue. EA acquired them a few years ago. I've had EA guys tell me they prefer Havok's physics engine, even though EA owns the Mathengine one.
Ageia's innovation was not their hardware, but their business model. Havok and Mathengine sold to game developers, getting a modest fixed fee for each title, plus some consulting and customization work. That just isn't a big revenue stream. Ageia has an end user product, which has more revenue potential.
Before railroads you could travel, it was just ridiculously expensive.
Ever travel a hundred miles on horseback?
Railroads and electricity made much bigger changes in people's lives. Before railroads, most people spent their lives within 50 miles of their birthplace. Before electricity, it was, well, dark at night almost everywhere. Huge amounts of effort went into activities like basic cooking and cleaning clothes.
The changes between 1850 and 1900 were far, far greater than those between 1950 and 2000. In communications, in 1950 we had radio, television, teletype, and telephones. Even newspaper delivery via broadcast radio fax, although that never really caught on. Most important info was getting to its destination fast. Most of the communication things you can do today, you could do in 1950, but more expensively.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
That says, in one line, what I wrote in a much longer post.
Actually, those aren't the real problems with Python. They're not the ones that keep it from, say, replacing Perl.
Multicore support is a nonissue. CPython is too slow to need it. It's helpful to distinguish between the Python language, which isn't bad, and the CPython implementation, which is a slow, naive intepreter. CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C. What's needed is a Python compiler with some smarts. There's Shed Skin, but it doesn't work yet.
One side effect of the speed problem is a tendency to try to write C modules to do things that take significant time. Unfortunately, CPython's interface to C is terrible, bug-prone, and changes with each new release.
The "dynamic language" thing is overdone. CPython is a demonstration of the fact that if you make everything a dictionary, it's easy to implement a dynamic language. It's also a demonstration of "if the only tool you have is a hammer, everything looks like a nail". Too much time is wasted in Python checking to see if something changed that probably didn't change. You can add or change functions or data of a running object or a running function. From outside the object or functionor thread, even! It's cool! It's l33t! It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.) Those features just don't get used that much, except to patch around bugs in the buggy Python libraries. The troubles with the "global interpreter lock" stem from this problem. The "global interpreter lock" is mostly protecting all those dictionaries which define the program. After all, one thread might want to patch the code in another thread.
Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so. Java has a certain amount of dynamism; you can, if you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that. The Shed Skin implementation imposes some restrictions on dynamism, and they're on the right track.
Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop. Many key modules aren't part of the main Python distribution and aren't synchronized with it. Examples are the interfaces to databases like MySQL and the interface to SSL. These lag months or years behind the base system. Modules outside the small "core" are not supported in any coherent way. Each is supported by a developer or two, working in isolation. If they lose interest, the module languishes, and nobody else can change it. This sometimes leads to multiple libraries for the same purpose, each with different bugs, and none good enough to obsolete the others.
The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
This is where open source fails. A feature list is not a design. Design by committee is usually terrible. Open source programs that aren't clones of some product tend to have poor user interface design.
And no, adding the ability to have "skins" does not improve the interface.
Social networking sites seem to me to be kind of over. A few years ago I was active on a few of them; Tribe and Nerve were fun. But the fun sites are over. Myspace is just the new AOL.
Phone-based social networking is probably where things are going. Although, interestingly, the iPhone doesn't have social networking. Helio does, but nobody uses Helio.
Quackwatch has a good section on how pseudoscience does not make progress, unlike real science.
That's the real problem. Homeopathy isn't any better understood than it was fifty years ago. Nor does it work better. Nor does is ESP. In real science, if you have some phenomenon that's near the noise threshold, people work to design experiments that yield a more definitive result. In psuedoscience, the results stay near the noise threshold forever.
So you never get a working technology out of psuedoscience. And that's the real problem.
Consider electricity. Early researchers, back in the "rubbing fur" era of electric generation, were barely able to get anything to happen. And sometimes, on humid days, it didn't work. It almost looked like psuedoscience. But there was progress. von Guericke in 1650 put a sulfur ball on a rotating shaft and started to build up serious static charges. Then von Kleist made a glass-jar capacitor, and charge could be stored. No question about whether it worked; that setup could deliver a serious zap. From then on, progress was steady.
Orsted discovered electromagnetism in 1820, and that, too, was a flaky phenomenon at first. A wire near a compass would move a compass needle when current flowed, but just barely. But more current caused more needle movement, an indication that this was real. (That's what to watch for - if there's something you can do that makes the effect stronger, it's probably real. If not, probably not.) By 1821, Faraday was able to demo the first electric motor. By 1835, motors had progressed from demo size to demo electric railway size.
The USSR sent robots to the moon in 1970 and 1973. Big, car-sized rovers. They worked well, too. Lunokhod 1 was operational for 322 days, and and Lunokhod 2 for about four months. $1 travelled about 10km, and #2 travelled a total of 37km, so those large vehicles got around quite a bit.
It would be possible to redo that mission today. Lunokhod 3, never launched, is in a museum. Improved versions of the Proton booster used in 1970 are available from International Launch Services. The lunar landing module would have to be newly constructed, but the design is proven.
Several games have run into severe problems with the internal economy. One early MMORPG had resources which could be mined and converted into items. Abandoned items deteriorated into basic resources. This was envisioned as a closed system with a fixed set of resources. But it broke down when people kept making stuff and hoarding it, resulting in resource exhaustion and runaway inflation.
Another game ran into trouble when NPCs authorized to trade offered prices that allowed arbitrage. Players exploited this by buying from one NPC and selling to another elsewhere. Because the NPCs could create resources, this resulted in a huge increase in M1.
Then there's the relationship with the real world economy. What are the gold farmers doing, and how much are players paying them? Can players still play effectively without dealing with gold farmers?
These issues drive players away, so it's a real issue in game operations.
The article didn't say much about these kinds of issues. Either their economist is clueless or doesn't want to talk about such things. It's surprising to see an article about EvE's economy that doesn't mention gold farming.
The blimp hangar is abandoned and fenced off. The Navy wants to demolish it, and there's a "Save Hangar One organization that wants to preserve it. Nobody wants to pay for fixing its contamination problems.
Micron size water filters have been around for a long time, ask any outdoorsman or backpacker
Yes. I have one in my emergency supplies. Here's some basic info on small water purifiers. These things tend to be slow, low-throughput devices, since they work by forcing water through a 200nm or so absolute filter. Prices are in the US$100 - US$300 range, depending on throughput. Is this new thing faster, or easier to clean, or cheaper, or something?