As long as "the powerful" (whoever they may be) have the attitude that we have a "global economy" and that market forces are the only consideration, similar trends will continue.
The trend of offshoring computer work alone will tend to hurt the U.S. economy over the long haul, while driving people to other (probably non-techical) lines of work.
It's time that policy change to reflect the reality that the U.S. can't afford to lose leadership in science and technology, or it will inevitably become a second-rate power. It should also be remembered that military leadership can change very rapidly these days - one breakthrough could completely shift the balance of power. Military research is as (or more) important than any other kind.
You should check out this article: IDC: Apple lost marketshare in 2003, to 3.2 percent. Those figures are only for the U.S., worldwide it's worse. Apples marketshare has continued to fall through 2004 so far as well.
I hear there's going to be a big push to try and get G5 sales to where Apple thought they should be to begin with... (I think Apple got some significant negative publicity with the controversial "worlds fastest PC" campaign.)
Ultimately, it seems to me that the pathetic Linux community needs Apple a hell of a lot more than Apple needs Linux.
Heh, what do you think of desktop Linux passing Apple in marketshare? Then there's the server market, where Linux is creaming Apple. Don't tell me Apple doesn't want the server market, why else put all the effort into XServes, RAID and SAN?
It seems to me that Apple has a lot to gain by courting the Linux community (as does everyone else, possibly including Microsoft). The best way to do it is as yet to be determined... (BTW, if Java 1.5 can finally lick the 'no good for desktop apps' mantra, possibly in conjunction with SWT, this whole issue will be moot...Windows+Mac+Linux in one fell swoop...)
I like Apple and Apple stuff...I want a G5 even though they're expensive...but if Apple's attitude is anything like yours regarding Linux it'll hurt it. Mark my words...
I mean come on, Apple is the greatest hardware and software company the world has ever seen, and even the vastly overhyped "open source" community will never be a match for it. I think it is high time for Linux users to simply accept the fact that Linux is now and always will be a niche product for a niche market.
ROFLMAO. Apple is the definition of the word "niche" at this point. It has 2% marketshare, and falling. Pot, kettle, black...;-)
Apple had best continue (yes, continue) to court the Open Source community, if nothing else than on the "enemy of my enemy" principle.
Seriously, i have a nokia 6600, what can the Zire's do that the 6600 cant.[?]
Display on a larger screen with 320x320 resolution. Run software that requires a 300+ MHz. ARM processor. Use a regular SD card for memory expansion of 256 MB (and up?). I'm not sure about the phone, what does it use for mem expansion? What is it's native memory capacity? (The Treos are a nice meld of phone and PalmOS BTW...still with small screens though.)
The one thing that didn't look too good to me with this was battery life - only about 4 hours if used heavily. Also the camera looks pretty bad unless this reviewer got a bad unit.
I'd be interested in other reviews if anyone finds one. The Sony TH55 looks interesting for longer battery life and higher res screen, though it is more expensive and has an even worse camera. The Tapwave devices also seem worth a look. The Zire 72 looked near perfect (for me) until I read the review though.:/
The stack that Microsoft is creating will not only empower more people to create more sophisticated applications, but will increase the productivity of application programmers by at least 30% over todays Unix/Linux development stacks!!!
Er, didn't Visual Basic already do that?;-) (With unimpressive results I might add.)
This story is essentially a dupe from a couple days ago...read my take on that for yet another perspective. Don't forget, this won't hit the streets until 2006...that's a long ways off. Also read the responses to the "miguel" (not sure if it's the real one) post...I couldn't have said it any better myself.
But time is definitely reversed at all velocities greater than the speed of light:)
This may follow if you accelerate past lightspeed using GR (or instantaneously convert yourself to tachyons;).
However, I don't think "effectively" FTL travel via wormholes, hyperspace or similar mechanisms would run afoul of the same issues. I can imagine crossing several light years of space through such a gateway, and positive time would still have elapsed all around. True, the light will take awhile to reach my departure point, but so...?
Considering that we have Einstein with a proof that faster than light is impossible,
What we have is a theory (GR) that says that conventional acceleration of a massive object to lightspeed requires infinite energy.
GR doesn't state that FTL communication via quantum entanglement (for instance) is impossible (though that effect is also yet to be demonstrated as an FTL effect). This effect was used to explain the "ansible" used in Orson Scott Card's books. FTL communication would completely invalidate the conclusions reached in this paper.
There are other potential ways to achieve FTL travel that don't implicitly violate GR, such as wormholes or other 'doorways' into spaces that connect places in our universe with [much] shorter distances than connect them here. This is also the basis for many of the "hyperspace" ideas in science fiction. Also yet to be demonstrated...
My main point though is that this paper may well turn out to be way off in the fairly short term (non-constant or non-existent cosmological constant). It's not that original, since similar work had already been done using older assumptions about the Universe. I'd have suggested the authors find a more useful role for all that cleverness and effort, especially since it seems there is absolutely no practical use for this study...;-)
"Galileo was a devout Catholic, yet his writings on Copernican heliocentrism disturbed some in the Catholic Church, who believed in a geocentric model of the solar system. They argued that heliocentrism was in direct contradiction of the Bible (Which is a questionable claim) and the highly revered ancient writings of Aristotle and Plato. For his insights, Galileo was threatened with death at the stake and would eventually face lifelong house arrest after recanting his claims."
Hope that helped...;-)
BTW 'death at the stake' was of course by burning...
Skewe's number of angels can dance on the head of a pin...
This article contains a very large number of assumptions, which may well prove not to be the case (constant cosmological constant, no FTL communication/travel, no access to other universes etc. etc.). Still, an interesting intellectual exercise I suppose...;-)
Perhaps it's time for a GNU sandbox system, or at least a portable byte code. What about GNU Lightning, the GNU JIT? How far did that get?
I'd look either at Parrot (the new Perl VM) or the CLR. Nothing wrong with the CLR, it's an open standard and'll even run Java code.;-)
How important are portable binaries nowadays that a lot of stuff is "open source?"
Quite important, in that plenty of stuff is also "closed source". If people want to protect their IP, obfuscation is a good thing. Also, things are lots easier for the user if it's just "click and go" rather than "click, compile, resolve dependencies, download dependencies, go". Jar files are a good thing...
Maybe I'm on a fruitbreak or something, but why not pick up GNUstep and enhance that? That way you get some semblance of source compatibility with Mac OSX Cocoa apps. Why follow Microsoft's example? It has always ended in tears in the past.
First, the GNUstep runtime has no concept of a sandbox (or applets for that matter) so you lose a big part of Java's appeal. Second, it uses native code, so you don't get easy portability. Third, it uses Objective-C, which for better or worse has struggled to gain developer mindshare - which Java has in spades.
There are reasons Apple has become a big Java proponent...
(All that said, I like Objective-C and have been meaning to mess around with GNUstep for quite a while...)
* Implement Avalon/XAML and ship it with Linux (with Mono). * Come up with our own, competitive stack.
Where is "Java" in that list? Java's only big problem, at this point, is the mindset that "something is wrong with it". It's really quite good, and there is a growing ecosystem of open source stuff (see SWT and friends) growing around it.
Every major computer company besides Microsoft supports it, and a Sun JVM now ships with many (most?) new Windows PCs. Even if not, a broadband JRE download is only a couple of minutes...and ~40% of U.S. households are on broadband if I remember a recent article correctly.
There is also plenty of effort going into Free/OSS JVM development, including gcj and IKVM on Mono.
Java tends to break the MS monopoly...Mono/.Nyet tends to lock it in. Which do we really want?
In assessing the usefulness of the ABL, the study group adopted its publicly reported design goals: 3 MW of power focused into a 1.2-m-diameter beam (close to the diffraction limit) that could illuminate the target missile for up to 20 s. We also considered the utility of systems with greater and lesser capabilities. We found that if the ABL achieves its design goals, it would have a range of about 600 km against liquid-propellant ICBMs. That would be useful against liquid-propellant ICBMs launched from North Korea, but not from Iran. Against solid-propellant ICBMs, its range would be only about 300 km, too short to be useful in any of the scenarios we examined. The ABL's range is relatively insensitive to its power.
First of all, the statement "In assessing the usefulness of the ABL" refers to using it against ICBMs, which is not it's primary purpose. It was designed to go after battlefield weapons, such as SCUDs.
I think the only way it would be effective against ICBMs in general would be if the U.S. had air superiority and was able to fly ABLs (remember several are being built) in the airspace over the launch sites. That would overcome most of the objections raised in the article you cite.;-)
SAMs would be the primary problem (the U.S. seems to have a good handle against aircraft at this point) but that might be solvable given the altitude at which the ABL flies. Too bad it's not a stealthy airframe, one wonders if there's a black project to do an ABL B2...
One last point, I wonder if going after the main body of the missile is the best strategy with solid fueled rockets? If the geometry is such that the exhaust area is exposed, I'm guessing that the added heat from a megawatt-class laser would be sufficient to damage the nozzles. Missiles don't tend to fly well with damaged nozzles. Just a thought...
What this means is that if we had a near perfect 3MW laser, which we don't, and the ICBM was of an ancient design, then we could defend against some countries in the far east, but not the middle east. And even in the best case scenario, we might have to forget Alaska.
IIRC, the current crop of North Korean weapons is liquid fueled. Further, I could easily see a scenario happening where we had ABLs orbiting in Iranian airspace.;-)
As for "forgetting Alaska", why exactly would anyone care to hit it with ICBMs in the first place...? To invite massive U.S. retaliation without damaging any vital interests? Anyone considering a missile based WMD attack against the U.S. would do well to remember the gigatons of TNT equivalent we can return in kind. That is still our best anti-missile defense.
I think it's a little strange the BC/FC is being mounted on such a large aircraft, with slow scramble speed and low maneuverability, unless the US is planning to have many planes airborne, around the clock, which does seem somewhat wasteful.
The laser and supporting equipment are large enough that the 747 was the smallest plane they could use.
The plan is to have multiple planes airborne over threat areas for extended periods of time.
There are plans for a 100+ KW solid state laser to be used with the Joint Strike Fighter and the Raptor.
Nothing is said about the range of this laser, so I'm not sure if it would work from space or not.
Chemical lasers aren't a good match for space deployment.
However, I suspect the ABL will be a pretty good antisatellite weapon...;-)
It will also do fine in a pinch shooting down enemy planes, I'd guess. The range is 100 miles plus, under good conditions. The ABL will typically fly close to max. altitude.
The hatch for the beam is on top just behind the bubble. This is a great angle to hit inbound ICBM comming from above the aircraft, but a lousy angle to catch SAM rockets from below it.
Er, no. The beam exit is from a steerable turret on the nose of the aircraft, and can cover almost the entire hemisphere in front. Note the nifty animation on it's home page.;-)
Also, it is not designed to destroy "inbound ICBMs", it is designed to go after boost phase missiles just after launch. They are easiest to see then, moving relatively slowly, under stress, can't launch decoys AND the debris (including warheads) falls on the launching party's territory. That's the theory anyhow...
Having a too-good memory is what you don't want. They relate the case of a hyperretentive memorist from Russia, who had almost supernatural retention skills, but was hopeless at appreciating metaphors, or pattern matching or generalizations. Which are the building blocks of analytical intelligence.
Well, one assumes a "hypertentive memorist" is dealing primarily with long-term memory. I interpret this article as dealing with the type of short term memory used in solving an equation, or writing a small code section. It's certainly possibly your HM was deficient in that area.
I think there's a valid point to be made about how much information someone can deal with in those contexts. The one caveat I'd make is whether the person is dealing with text or imagery - AFAIK there's quite a range there.
At any rate, I think it's clear that many intelligent people also have above average long-term memories.
In the following results the claim is made: "450 MT equivalent". However, at a point only 20 km. the overpressure is only.628 PSI, and the sound is only 73 db. All of that is a gross underestimate, I'm sure. The lethal blast radius of a 450 MT blast is at least 20 km. (probably more).
Check it out:
Impact Effects
Robert Marcus, H. Jay Melosh, and Gareth Collins
Your Inputs:
Distance from Impact: 20.00 km = 12.42 miles
Projectile Diameter: 100.00 m = 328.00 ft = 0.06 miles
Projectile Density: 8000 kg/m3
Impact Velocity: 30.00 km/s = 18.63 miles/s
Impact Angle: 90 degrees
Target Density: 1500 kg/m3
Target Type: Competent Rock or saturated soil
Energy:
1.88 x 1018 Joules = 4.50 x 102 MegaTons TNT
The average interval between impacts of this size somewhere on Earth is 1.2 x 104years
Crater Size:
What does this mean?
Transient Crater Diameter: 4.16 km = 2.58 miles
Final Crater Diameter: 5.04 km = 3.13 miles
The crater formed is a complex crater.
Thermal Radiation:
What does this mean?
Time for maximum radiation: 0.08 seconds after impact
Visible fireball radius: 2.4 km = 1.5 miles
The fireball appears 27.7 times larger than the sun
Thermal Exposure: 2.21 x 105 Joules/m2
Duration of Irradiation: 3 seconds
Radiant flux (relative to the sun): 68.9
Seismic Effects:
What does this mean?
The major seismic shaking will arrive at approximately 4.0 seconds.
Richter Scale Magnitude: 6.4
Mercalli Scale Intensity at a distance of 20 km:
VII. Difficult to stand. Noticed by drivers of motor cars. Hanging objects quiver. Furniture broken. Damage to masonry D, including cracks. Weak chimneys broken at roof line. Fall of plaster, loose bricks, stones, tiles, cornices (also unbraced parapets and architectural ornaments). Some cracks in masonry C. Waves on ponds; water turbid with mud. Small slides and caving in along sand or gravel banks. Large bells ring. Concrete irrigation ditches damaged.
VIII. Steering of motor cars affected. Damage to masonry C; partial collapse. Some damage to masonry B; none to masonry A. Fall of stucco and some masonry walls. Twisting, fall of chimneys, factory stacks, monuments, towers, elevated tanks. Frame houses moved on foundations if not bolted down; loose panel walls thrown out. Decayed piling broken off. Branches broken from trees. Changes in flow or temperature of springs and wells. Cracks in wet ground and on steep slopes.
Masonry A. Good workmanship, mortar, and design; reinforced, especially laterally, and bound together using steel, concrete, etc.; designed to resist lateral forces.
Masonry B. Good workmanship and mortar; reinforced, but not designed in detail to resist lateral forces.
Masonry C. Ordinary workmanship and mortar; no extreme weaknesses like failing to tie in at corners, but neither reinforced nor designed against horizontal forces.
Masonry D. Weak materials, such as adobe; poor mortar; low standards of workmanship; weak horizontally.
Ejecta:
What does this mean?
The ejecta will arrive approximately 64.0 seconds after the impact.
Average Ejecta Thickness: 39.0 cm = 15.36 inches
Mean Fragment Diameter: 2.2 m = 7.27 ft
Air Blast:
What does this mean?
The air blast will arrive at approximately 66.7 seconds.
Peak Overpressure: 4422.6 Pa = 0.0442 bars = 0.6280 psi
Max wind velocity: 9.3 m/s = 20.8 mph
Sound Intensity: 73 dB (Loud as heavy traffic)
Not only do you get interesting graphics of similar impact craters, but if the impact is big enough you get the Martian from Bugs Bunny making pithy comments while he looks through his telescope at Earth. Cool stuff!
What is the top theoretical speed of the current US fighter/and or/stealth aircraft?
Current fighters top out at somewhat over Mach 2, perhaps Mach 2.5 for the F-15.
The upcoming F-22's top speed is classified, but it might be as high as Mach 3 (this is purely a guess on my part). It is quite a bit higher performance than the F-15, and can cruise at supersonic speed (somewhere over Mach 1, again classified) without afterburner. It's the first aircraft ever to have this capability, dubbed "supercruise" (not after Tom...I think).
The SR-71 is the current air-breathing airplane speed record holder, with a top speed of around Mach 3.5, though the actual top speed is still classified as far as I can tell.
The X-15 had a speed record of Mach 6.72 (in 1968!) but was a rocket, not an air-breathing aircaft.
Without escape velocity, the Earth has you - forever! It doesn't matter if you travel as far as the Sun - unless you have escape velocity with respect to the Earth, you're going home. Gaining escape velocity with respect to the Sun is another problem. ..
Your post was mostly right except for this part. IF (yes that's a big if;) you had sufficient fuel, as you pointed out above, you could fly at 1 MPH to the Moon. And, once you reach the crossover point (where the Moon's gravitational field is stronger than the Earth's), you have escaped in the sense of escape velocity. You won't be going back home.
Escape velocity is only relevant for ballistic (unpowered) objects.
Given our current propulsion systems, all of our spacecraft are essentially ballistic except for the new ion powered ones - and those are very low thrust. Practical antimatter propulsion would make things a lot more interesting!:-)
Projectile: Rocky Asteroid Diameter:.03 kilometer(s) Velocity: 20.0 km/s Target: Earth
RESULT: Explosion 5-20 km Above Tibet [note: they made this part up;)] in Asia!! Energy Released = 2 MT (MegaTons of TNT) (Largest Nuclear Weapon: 100 MT)
A collision this large occurs roughly once every 58 years. ---end results---
Now, we don't know much about this object's composition, so it could be iron. If so, and if it were moving a bit faster (30 km/s), this is what we get:
---begin results--- YOUR COLLISION PARAMETERS
Projectile: Iron Asteroid Diameter:.03 kilometer(s) Velocity: 30.0 km/s Target: Earth
RESULT: Impact into Australia [note: they made this part up;)] in Oceania!! Energy Released = 12 MT (MegaTons of TNT) (Largest Nuclear Weapon: 100 MT)
QUAKE!! Magnitude 6.3 (largest recorded Earthquake: 9.5)
People need to avoid the language hype - C# and Java are not the way to go. There's quite enough bloatware out there already, and running code inside virtual machines does not help.
Almost everyone in this discussion seems to be missing the fact that gcj isn't (primarily) a VM. The point of gcj is to traditionally compile Java (or Java bytecode) ahead of time, with full optimizations. This is also a tradeoff, but an acceptable one for many situations.
The reason gcj runtime memory requirements are large is that it uses a garbage collector, and GC requires an initial, non-trivial heap. With the advent of 512 megabyte entry-level desktops I'd suggest that isn't much of a concern either. You can only use one app at a time, if others swap out oh well.;-)
This will be even less of a concern as the 64-bit desktops take off with > 4 GB address space.
The Java codes aren't a good match for the Python language, so there's considerable overhead, as I understand it.
I've been meaning to play with it, so I guess some benchmarking is in order.
Also: If you want to call appropriate machine language subroutines, as the OpenGL bindings do, then nearly any language can handle what you want. But you will be doing most of your computing outside the specified language, so it's not really fair to say that the language is handling, e.g., the 3D graphics.
There are two issues. The first is handling computations outside the graphics libraries (AI, physics, object morphing, collisions, LOD and so on). This involves a lot of calculation, which should be as efficient as possible so you can have more complex worlds at higher frame rates. The second issue is passing various data (lots of it!) in and out of the 3D libraries - that is what NIO improved and what made the Canyon demo possible.
Straight computation in Java is very close to C/C++ levels these days (sometimes it even does better!). Check around for benchmarks if you don't believe me.
Now I must admit that I don't currently use Java. And I haven't bothered to study the coding used in the "Grand Canyon demo", but the text around the link indicated that the codeing wasn't done in Java, but rather that Java was able to pass the necessary info along to the routine that did it in a newly more efficient manner. Quite a different claim.
Yes, the main improvement highlighted by the GCD was passing large data buffers more efficiently to C routines - necessary and good stuff.
However, the other computation that Java was handling was non-trivial - the flight model and world LOD were both done in pure Java. The target system (700 MHz. PIII) was quite modest by today's standards, and the JDK wasn't as good as the current version.
Still, I really doubt that an interpreter can ever produce code as good as a good compiler can, and the JVM is really just a fancy interpreter, even with all the compiled code cache-ing. (It's the same concept as UCSD Pascal, and I always called that an interpreter, even if it isn't the same kind of interpreter as was used by Basics of the same period.)
I suppose that a claim could be made that rather than a fancy interpreter the JVM was a fancy state machine, but I don't think that improves matters. It's still slow compared to good compiled code. Whether this matters is something else. If you are doing all of your number crunching in some other language, it may not matter.
Nope, you're way off base here. Java is doing very well with straight computation these days. Look for some of the many benchmarks published over the last couple of years, or roll your own. Also, gcj is getting increasingly interesting as a HPC Java implementation - it has good fast math support and you can turn off array bounds checking and GC for your time critical sections. As a traditional compiler, it at least addresses your skepticism regarding "interpreters".;-)
Slashdot Mirror
Of course they're talking one-time pads... ;-)
As long as "the powerful" (whoever they may be) have the attitude that we have a "global economy" and that market forces are the only consideration, similar trends will continue.
The trend of offshoring computer work alone will tend to hurt the U.S. economy over the long haul, while driving people to other (probably non-techical) lines of work.
It's time that policy change to reflect the reality that the U.S. can't afford to lose leadership in science and technology, or it will inevitably become a second-rate power. It should also be remembered that military leadership can change very rapidly these days - one breakthrough could completely shift the balance of power. Military research is as (or more) important than any other kind.
I hear there's going to be a big push to try and get G5 sales to where Apple thought they should be to begin with... (I think Apple got some significant negative publicity with the controversial "worlds fastest PC" campaign.)
Heh, what do you think of desktop Linux passing Apple in marketshare? Then there's the server market, where Linux is creaming Apple. Don't tell me Apple doesn't want the server market, why else put all the effort into XServes, RAID and SAN?
It seems to me that Apple has a lot to gain by courting the Linux community (as does everyone else, possibly including Microsoft). The best way to do it is as yet to be determined... (BTW, if Java 1.5 can finally lick the 'no good for desktop apps' mantra, possibly in conjunction with SWT, this whole issue will be moot...Windows+Mac+Linux in one fell swoop...)
I like Apple and Apple stuff...I want a G5 even though they're expensive...but if Apple's attitude is anything like yours regarding Linux it'll hurt it. Mark my words...
I mean come on, Apple is the greatest hardware and software company the world has ever seen, and even the vastly overhyped "open source" community will never be a match for it. I think it is high time for Linux users to simply accept the fact that Linux is now and always will be a niche product for a niche market.
ROFLMAO. Apple is the definition of the word "niche" at this point. It has 2% marketshare, and falling. Pot, kettle, black... ;-)
Apple had best continue (yes, continue) to court the Open Source community, if nothing else than on the "enemy of my enemy" principle.
Display on a larger screen with 320x320 resolution. Run software that requires a 300+ MHz. ARM processor. Use a regular SD card for memory expansion of 256 MB (and up?). I'm not sure about the phone, what does it use for mem expansion? What is it's native memory capacity? (The Treos are a nice meld of phone and PalmOS BTW...still with small screens though.)
The one thing that didn't look too good to me with this was battery life - only about 4 hours if used heavily. Also the camera looks pretty bad unless this reviewer got a bad unit.
I'd be interested in other reviews if anyone finds one. The Sony TH55 looks interesting for longer battery life and higher res screen, though it is more expensive and has an even worse camera. The Tapwave devices also seem worth a look. The Zire 72 looked near perfect (for me) until I read the review though. :/
Er, didn't Visual Basic already do that? ;-) (With unimpressive results I might add.)
This story is essentially a dupe from a couple days ago...read my take on that for yet another perspective. Don't forget, this won't hit the streets until 2006...that's a long ways off. Also read the responses to the "miguel" (not sure if it's the real one) post...I couldn't have said it any better myself.
This may follow if you accelerate past lightspeed using GR (or instantaneously convert yourself to tachyons;).
However, I don't think "effectively" FTL travel via wormholes, hyperspace or similar mechanisms would run afoul of the same issues. I can imagine crossing several light years of space through such a gateway, and positive time would still have elapsed all around. True, the light will take awhile to reach my departure point, but so...?
What we have is a theory (GR) that says that conventional acceleration of a massive object to lightspeed requires infinite energy.
GR doesn't state that FTL communication via quantum entanglement (for instance) is impossible (though that effect is also yet to be demonstrated as an FTL effect). This effect was used to explain the "ansible" used in Orson Scott Card's books. FTL communication would completely invalidate the conclusions reached in this paper.
There are other potential ways to achieve FTL travel that don't implicitly violate GR, such as wormholes or other 'doorways' into spaces that connect places in our universe with [much] shorter distances than connect them here. This is also the basis for many of the "hyperspace" ideas in science fiction. Also yet to be demonstrated...
My main point though is that this paper may well turn out to be way off in the fairly short term (non-constant or non-existent cosmological constant). It's not that original, since similar work had already been done using older assumptions about the Universe. I'd have suggested the authors find a more useful role for all that cleverness and effort, especially since it seems there is absolutely no practical use for this study... ;-)
"Galileo was a devout Catholic, yet his writings on Copernican heliocentrism disturbed some in the Catholic Church, who believed in a geocentric model of the solar system. They argued that heliocentrism was in direct contradiction of the Bible (Which is a questionable claim) and the highly revered ancient writings of Aristotle and Plato. For his insights, Galileo was threatened with death at the stake and would eventually face lifelong house arrest after recanting his claims."
Hope that helped... ;-)
BTW 'death at the stake' was of course by burning...
This article contains a very large number of assumptions, which may well prove not to be the case (constant cosmological constant, no FTL communication/travel, no access to other universes etc. etc.). Still, an interesting intellectual exercise I suppose... ;-)
I'd look either at Parrot (the new Perl VM) or the CLR. Nothing wrong with the CLR, it's an open standard and'll even run Java code. ;-)
How important are portable binaries nowadays that a lot of stuff is "open source?"
Quite important, in that plenty of stuff is also "closed source". If people want to protect their IP, obfuscation is a good thing. Also, things are lots easier for the user if it's just "click and go" rather than "click, compile, resolve dependencies, download dependencies, go". Jar files are a good thing...
First, the GNUstep runtime has no concept of a sandbox (or applets for that matter) so you lose a big part of Java's appeal. Second, it uses native code, so you don't get easy portability. Third, it uses Objective-C, which for better or worse has struggled to gain developer mindshare - which Java has in spades.
There are reasons Apple has become a big Java proponent...
(All that said, I like Objective-C and have been meaning to mess around with GNUstep for quite a while...)
This "analysis" is poor:
Where is "Java" in that list? Java's only big problem, at this point, is the mindset that "something is wrong with it". It's really quite good, and there is a growing ecosystem of open source stuff (see SWT and friends) growing around it.
Every major computer company besides Microsoft supports it, and a Sun JVM now ships with many (most?) new Windows PCs. Even if not, a broadband JRE download is only a couple of minutes...and ~40% of U.S. households are on broadband if I remember a recent article correctly.
There is also plenty of effort going into Free/OSS JVM development, including gcj and IKVM on Mono.
Java tends to break the MS monopoly...Mono/.Nyet tends to lock it in. Which do we really want?
First of all, the statement "In assessing the usefulness of the ABL" refers to using it against ICBMs, which is not it's primary purpose. It was designed to go after battlefield weapons, such as SCUDs.
I think the only way it would be effective against ICBMs in general would be if the U.S. had air superiority and was able to fly ABLs (remember several are being built) in the airspace over the launch sites. That would overcome most of the objections raised in the article you cite. ;-)
SAMs would be the primary problem (the U.S. seems to have a good handle against aircraft at this point) but that might be solvable given the altitude at which the ABL flies. Too bad it's not a stealthy airframe, one wonders if there's a black project to do an ABL B2...
One last point, I wonder if going after the main body of the missile is the best strategy with solid fueled rockets? If the geometry is such that the exhaust area is exposed, I'm guessing that the added heat from a megawatt-class laser would be sufficient to damage the nozzles. Missiles don't tend to fly well with damaged nozzles. Just a thought...
What this means is that if we had a near perfect 3MW laser, which we don't, and the ICBM was of an ancient design, then we could defend against some countries in the far east, but not the middle east. And even in the best case scenario, we might have to forget Alaska.
IIRC, the current crop of North Korean weapons is liquid fueled. Further, I could easily see a scenario happening where we had ABLs orbiting in Iranian airspace. ;-)
As for "forgetting Alaska", why exactly would anyone care to hit it with ICBMs in the first place...? To invite massive U.S. retaliation without damaging any vital interests? Anyone considering a missile based WMD attack against the U.S. would do well to remember the gigatons of TNT equivalent we can return in kind. That is still our best anti-missile defense.
The laser and supporting equipment are large enough that the 747 was the smallest plane they could use.
The plan is to have multiple planes airborne over threat areas for extended periods of time.
There are plans for a 100+ KW solid state laser to be used with the Joint Strike Fighter and the Raptor.
Nothing is said about the range of this laser, so I'm not sure if it would work from space or not.
Chemical lasers aren't a good match for space deployment.
However, I suspect the ABL will be a pretty good antisatellite weapon... ;-)
It will also do fine in a pinch shooting down enemy planes, I'd guess. The range is 100 miles plus, under good conditions. The ABL will typically fly close to max. altitude.
Er, no. The beam exit is from a steerable turret on the nose of the aircraft, and can cover almost the entire hemisphere in front. Note the nifty animation on it's home page. ;-)
Also, it is not designed to destroy "inbound ICBMs", it is designed to go after boost phase missiles just after launch. They are easiest to see then, moving relatively slowly, under stress, can't launch decoys AND the debris (including warheads) falls on the launching party's territory. That's the theory anyhow...
Well, one assumes a "hypertentive memorist" is dealing primarily with long-term memory. I interpret this article as dealing with the type of short term memory used in solving an equation, or writing a small code section. It's certainly possibly your HM was deficient in that area.
I think there's a valid point to be made about how much information someone can deal with in those contexts. The one caveat I'd make is whether the person is dealing with text or imagery - AFAIK there's quite a range there.
At any rate, I think it's clear that many intelligent people also have above average long-term memories.
Check it out:
Impact Effects Robert Marcus, H. Jay Melosh, and Gareth Collins Your Inputs: Distance from Impact: 20.00 km = 12.42 miles Projectile Diameter: 100.00 m = 328.00 ft = 0.06 miles Projectile Density: 8000 kg/m3 Impact Velocity: 30.00 km/s = 18.63 miles/s Impact Angle: 90 degrees Target Density: 1500 kg/m3 Target Type: Competent Rock or saturated soil Energy: 1.88 x 1018 Joules = 4.50 x 102 MegaTons TNT The average interval between impacts of this size somewhere on Earth is 1.2 x 104years Crater Size: What does this mean? Transient Crater Diameter: 4.16 km = 2.58 miles Final Crater Diameter: 5.04 km = 3.13 miles The crater formed is a complex crater. Thermal Radiation: What does this mean? Time for maximum radiation: 0.08 seconds after impact Visible fireball radius: 2.4 km = 1.5 miles The fireball appears 27.7 times larger than the sun Thermal Exposure: 2.21 x 105 Joules/m2 Duration of Irradiation: 3 seconds Radiant flux (relative to the sun): 68.9 Seismic Effects: What does this mean? The major seismic shaking will arrive at approximately 4.0 seconds. Richter Scale Magnitude: 6.4 Mercalli Scale Intensity at a distance of 20 km: VII. Difficult to stand. Noticed by drivers of motor cars. Hanging objects quiver. Furniture broken. Damage to masonry D, including cracks. Weak chimneys broken at roof line. Fall of plaster, loose bricks, stones, tiles, cornices (also unbraced parapets and architectural ornaments). Some cracks in masonry C. Waves on ponds; water turbid with mud. Small slides and caving in along sand or gravel banks. Large bells ring. Concrete irrigation ditches damaged. VIII. Steering of motor cars affected. Damage to masonry C; partial collapse. Some damage to masonry B; none to masonry A. Fall of stucco and some masonry walls. Twisting, fall of chimneys, factory stacks, monuments, towers, elevated tanks. Frame houses moved on foundations if not bolted down; loose panel walls thrown out. Decayed piling broken off. Branches broken from trees. Changes in flow or temperature of springs and wells. Cracks in wet ground and on steep slopes. Masonry A. Good workmanship, mortar, and design; reinforced, especially laterally, and bound together using steel, concrete, etc.; designed to resist lateral forces. Masonry B. Good workmanship and mortar; reinforced, but not designed in detail to resist lateral forces. Masonry C. Ordinary workmanship and mortar; no extreme weaknesses like failing to tie in at corners, but neither reinforced nor designed against horizontal forces. Masonry D. Weak materials, such as adobe; poor mortar; low standards of workmanship; weak horizontally. Ejecta: What does this mean? The ejecta will arrive approximately 64.0 seconds after the impact. Average Ejecta Thickness: 39.0 cm = 15.36 inches Mean Fragment Diameter: 2.2 m = 7.27 ft Air Blast: What does this mean? The air blast will arrive at approximately 66.7 seconds. Peak Overpressure: 4422.6 Pa = 0.0442 bars = 0.6280 psi Max wind velocity: 9.3 m/s = 20.8 mph Sound Intensity: 73 dB (Loud as heavy traffic)
Not only do you get interesting graphics of similar impact craters, but if the impact is big enough you get the Martian from Bugs Bunny making pithy comments while he looks through his telescope at Earth. Cool stuff!
Current fighters top out at somewhat over Mach 2, perhaps Mach 2.5 for the F-15.
The upcoming F-22's top speed is classified, but it might be as high as Mach 3 (this is purely a guess on my part). It is quite a bit higher performance than the F-15, and can cruise at supersonic speed (somewhere over Mach 1, again classified) without afterburner. It's the first aircraft ever to have this capability, dubbed "supercruise" (not after Tom...I think).
The SR-71 is the current air-breathing airplane speed record holder, with a top speed of around Mach 3.5, though the actual top speed is still classified as far as I can tell.
The X-15 had a speed record of Mach 6.72 (in 1968!) but was a rocket, not an air-breathing aircaft.
Hope that helped! :-)
Your post was mostly right except for this part. IF (yes that's a big if;) you had sufficient fuel, as you pointed out above, you could fly at 1 MPH to the Moon. And, once you reach the crossover point (where the Moon's gravitational field is stronger than the Earth's), you have escaped in the sense of escape velocity. You won't be going back home.
Escape velocity is only relevant for ballistic (unpowered) objects.
Given our current propulsion systems, all of our spacecraft are essentially ballistic except for the new ion powered ones - and those are very low thrust. Practical antimatter propulsion would make things a lot more interesting! :-)
Now, we don't know much about this object's composition, so it could be iron. If so, and if it were moving a bit faster (30 km/s), this is what we get:
If the iron version hit the ocean, it'd create quite a significant tsunami - though not a catastrophic one unless it hit near the shore.
Almost everyone in this discussion seems to be missing the fact that gcj isn't (primarily) a VM. The point of gcj is to traditionally compile Java (or Java bytecode) ahead of time, with full optimizations. This is also a tradeoff, but an acceptable one for many situations.
The reason gcj runtime memory requirements are large is that it uses a garbage collector, and GC requires an initial, non-trivial heap. With the advent of 512 megabyte entry-level desktops I'd suggest that isn't much of a concern either. You can only use one app at a time, if others swap out oh well. ;-)
This will be even less of a concern as the 64-bit desktops take off with > 4 GB address space.
Heh, I guess the Cray Red Storm system kind of shoots down that theory... ;-)
Actually the design of Opteron beats Itanium for HPC, and the relative number of Opteron vs. Itanium HPC design wins bears that out nicely.
I've been meaning to play with it, so I guess some benchmarking is in order.
Also: If you want to call appropriate machine language subroutines, as the OpenGL bindings do, then nearly any language can handle what you want. But you will be doing most of your computing outside the specified language, so it's not really fair to say that the language is handling, e.g., the 3D graphics.
There are two issues. The first is handling computations outside the graphics libraries (AI, physics, object morphing, collisions, LOD and so on). This involves a lot of calculation, which should be as efficient as possible so you can have more complex worlds at higher frame rates. The second issue is passing various data (lots of it!) in and out of the 3D libraries - that is what NIO improved and what made the Canyon demo possible.
Straight computation in Java is very close to C/C++ levels these days (sometimes it even does better!). Check around for benchmarks if you don't believe me.
Now I must admit that I don't currently use Java. And I haven't bothered to study the coding used in the "Grand Canyon demo", but the text around the link indicated that the codeing wasn't done in Java, but rather that Java was able to pass the necessary info along to the routine that did it in a newly more efficient manner. Quite a different claim.
Yes, the main improvement highlighted by the GCD was passing large data buffers more efficiently to C routines - necessary and good stuff.
However, the other computation that Java was handling was non-trivial - the flight model and world LOD were both done in pure Java. The target system (700 MHz. PIII) was quite modest by today's standards, and the JDK wasn't as good as the current version.
Still, I really doubt that an interpreter can ever produce code as good as a good compiler can, and the JVM is really just a fancy interpreter, even with all the compiled code cache-ing. (It's the same concept as UCSD Pascal, and I always called that an interpreter, even if it isn't the same kind of interpreter as was used by Basics of the same period.) I suppose that a claim could be made that rather than a fancy interpreter the JVM was a fancy state machine, but I don't think that improves matters. It's still slow compared to good compiled code. Whether this matters is something else. If you are doing all of your number crunching in some other language, it may not matter.
Nope, you're way off base here. Java is doing very well with straight computation these days. Look for some of the many benchmarks published over the last couple of years, or roll your own. Also, gcj is getting increasingly interesting as a HPC Java implementation - it has good fast math support and you can turn off array bounds checking and GC for your time critical sections. As a traditional compiler, it at least addresses your skepticism regarding "interpreters". ;-)
Hope you found it interesting!