I don't see where the "free ride" comes in. They lost the home, wiped out their savings, probably increased their debt, and (almost certainly) killed their credit rating. It will be a long time before they can attempt to own a home again, even if we assume they've learned from the experience.
There was an old joke in the Soviet Union that there were only four channels on television. The first three were all news and the forth was a KGB agent waving his finger and saying, "No, no, no! Change the channel back!"
Actually, the whole point of the WHATWG is to try implementing the spec before it's finalized. The idea is that the problems can be found during implementation, then the spec adjusted before it falls into heavy use.
What W3C specification exists for a Javascript drawing API?
HTML5. Which is itself a W3C dump of the ongoing work over at the WHATWG. Here's the specific W3C text on Canvas:
The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.
Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies such as XBL.
When authors use the canvas element, they should also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content.
In interactive visual media, if the canvas element is with script, the canvas element represents an embedded element with a dynamically created image.
In non-interactive, static, visual media, if the canvas element has been previously painted on (e.g. if the page was viewed in an interactive visual medium and is now being printed, or if some script that ran during the page layout process painted on the element), then the canvas element represents embedded content with the current image and size. Otherwise, the element represents its fallback content instead.
In non-visual media, and in visual media if the canvas element is without script, the canvas element represents its fallback content instead.
The work over at the WHATWG is a collaboration between Mozilla, Opera, and Apple. Microsoft was offered to contribute, but they declined. (Though a few Microsofties have been seen on the mailing lists as of late.)
Welcome to today's Slashdot. Mindless fools that are 15 years old. The 80's? Don't even remember 'em!
Or maybe it was always that way and we older folks just don't have the time to invest in shaping this community anymore and thus it has become a haven for the newcomers. Oh, and get off my lawn!:-P
"Put simply, in deference to you Kent, it's like lasing a stick of dynamite." --Chris Knight
Fabrication of a 3000 metric ton space ship has not been achieved, either. Such fabrication has more in common with building a sky scraper than with the construction of most spacecraft. In result, we lack a fabrication infrastructure in space, but have an excellent infrastructure here on Earth.
Thus the two options are:
1. Reuse the existing fabrication infrastructure here on Earth. Find a way to launch ~3000 metric tons to LEO without engaging the nuclear pulse drive during launch. Suggested options include lining the outer hull with SRBs similar to those currently used in the Shuttle program. These SRBs have a high thrust to weight ratio despite their relative inefficiency. However, having a large number of SRB engines increases complexity as well as opportunity for failure.
2. Build and supply a construction yard in space. Actual launch mass will be many times the 3000 metric tons, but the mass will be able to be spread across dozens to hundreds of launches. Many launches will be low mass launches of highly trained construction workers. Such workers would work extended EVAs far in excess of existing EVA records. New EVA technology may be required to improve worker efficiency to acceptable levels.
I think we've got the 'getting it up there' part figured out already...
If you know how to do it, I think NASA would be extremely interested in your solution. 3000 metric tons to Low Earth Orbit (LEO) is a lot more than anyone has ever attempted before. The most powerful rocket in existence will be the Ares-V upon completion. It will be capable of lifting ~180 metric tons to LEO. Now scale that up by about 17x and we'll be good to launch an Orion.
That's only fair if you also include the Russian deaths on the ground. Who had the dubious honor of having the first space-related death? Why, the Russians with a training exercise in a pure oxygen environment. (Same issue that killed the Apollo astronauts.) Except that was 1961. Apollo wouldn't repeat that mistake until 1967. (Which was a perfectly avoidable mistake, and was a huge wake-up call to the NASA of the time.)
Don't even get me started on the number of near-fatal collisions and separation failures the Russians had in space! All of which is nicely spelled out in the same Wikipedia article.
I REPEAT. Space is dangerous business. Get over this idea that the Russians are inherently safe and the U.S. isn't. They're both as dangerous as you can possibly get. The different approaches to safety primarily yield different modes of failure rather than a superior safety record.
I hope you realize that Pournelle and Niven didn't just make that up? Project Orion was a very real attempt to develop nuclear pulse propulsion. It is still a viable option for space travel, as long we're not talking about a ground-launch using nuclear pulses. To get the sucker into orbit, we might have to resort to something a bit more mundane. Like a dozen SRBs or somesuch.
*sigh* The AC above me was trying to link to the List of Space Disasters article on Wikipedia. Which speaks of two major incidents resulting in the loss of crew. The first was a parachute failure which led to the death of the astronaut on board. The second was a valve failure that resulted in depressurization of the capsule and a loss of all crew members.
Score Card ========== Russia - 2 U.S. - 2
Seems to be a parity to me. Also, there is the issue that the Soviet Union didn't always tell everyone when an accident happened. It's difficult to tell if there were further incidents that have gone unpublished.
Regardless of that issue, there are more than enough near-fatal space accidents on the Russian side listed in the Wikipedia article to question whether the Russian space program really is safer. The truth is simply that space travel is risky business. It will continue to be risky business for a long time, unfortunately.
Indeed. I personally think it would be amazing if we could develop a set of standard comsats to spread across the solar system. Want to explore Mars? No problem. We already have a communications infrastructure for you. Explore Europa? We've got sats around Jupiter, too. Throw in some sats traveling along the Interplanetary Superhighway and you've got better coverage than your average cell phone.
I think people tend to underestimate the shear enabling factor of such a communications network. Not only would such a large deployment provide easy access to all our probes and manned missions, but it would pave the way for cheaper, standardized probes and sats. Manufacture anything in sufficient quantity and the price begins to drop. Just the areas of space that the comsats would be exposed to would easily teach us as much about space hardware as the probes we spend 20+ years planning for a single mission!
If people ever get to Mars, expect this to only get much worse in terms of bandwidth needs.
I think Mars was actually the tipping point that helped make this happen. There was some early interest in the project when it was first began, but that interest waned rather quickly. But now that we're sending so much hardware to Mars, the powers that be are looking for solutions.
It's an exciting time for space enthusiasts. Let's just hope that the next President doesn't kill all the progress we're making.:-(
I do believe the parent to your post was poking fun at my (rather silly) mistake of referring to an Asteroid as a Meteor. While not necessarily an incorrect usage, it does tend to refer to those rocks that hit the atmosphere and burn up.:-)
I think you're missing the point. The general idea here is to have a packet switched communications system throughout the solar system. That way if a probe is in the shadow of, say, Jupiter, it can bounce a signal off a probe orbiting Venus, which will relay the signal back to Earth.
The end result would be a more robust communications system. In the future, interplanetary communications satellites could even end up doing most of the grunt-work, thus allowing probes and manned spacecraft to carry smaller communications packages designed to work with the network rather than broadcasting in as many conditions as possible.
such a network would also be useful for astronauts on another planet or meteor. Rather than setting up a communications station, they can use orbiting satellites to relay their transmissions. (Something which NASA already does on a smaller scale with probes like the Mars rovers.)
I'd also rather write much less code. prototype scriptaculous have greatly shortened my development time, because instead of spending 8hrs fighting browser incompatibilities, I write 10 lines of code and it just works...
You write a runtime patch once and you're done. Meanwhile, you upgrade your Prototype and Scriptalicious libs and then spend an ungodly amount of time troubleshooting incompatibilities between versions.
Sounds like a winning proposition to me.;-)
Frameworks are almost most often more trouble than they are worth. Once you understand Javascript, you realize how stupidly simple most of the tasks are, and how much time you've been wasting on the framework. If you don't understand Javascript, you probably have wasted dozens (if not hundred!) of hours fighting with issues that are actually very avoidable to begin with.
e.g. Most folks don't understand Javascript scoping. So they'll be surprised when they accidently change a variable that they're using elsewhere in the code. A very simple mistake to avoid if you've read the documentation. But as Douglas Crockford of JSON fame has pointed out, most programmers start trying to hack the language without first understanding it. Which is a huge mistake considering that Javascript is only superficially similar to C/C++/Java-type languages.
It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.
The ideal solution in that case is NOT frameworks. It's to have runtime patches available that make your code run predictably on all browsers. That way if you need to support a new browser, you just add a new patch so that it functions predictably. (If necessary.) Since such patches tend to function based on whether or not a particular feature exists rather than the browser itself, they automatically deactivate when the browser maker finally gets it right.
In practice, of course, things are not nearly as bad as they're made out to be. IE needs the most patching for issues like DOM2 Events (or lack thereof), but otherwise coding to the base standards means portable code across browsers. No significant part of the industry is really doing anything fancy like SVG, Canvas, or Local Storage. (Yet, anyway.) The simple loop of "event fired, contact server, get response, update DOM" is actually pretty straightforward. Especially in the circumstances where GWT fails.
Meanwhile, I've seen all manner of screwy problems caused by folks who try to plugin a framework. One of my favorites was an issue with the prototype library where it was incorrectly deleting the "display" value to make an element visible. Obviously the hope was that it would display as a block element by default. Let's just say that it didn't always work right.
The reason why that example is my favorite is that it's such a stupid little thing. All that was needed was a simple "document.getElementById("myelement").style.display = 'block';" and you're done. There was no reason to abstract that. The abstraction actually CAUSED cross-browser issues rather than solving them. Not a good design.
...just not as much as you might expect. Part of the issue is that it's designed for when you develop your application from scratch. Generally with the intent of developing a desktop replacement webapp. The only problem is that not many companies are investing in such apps. They're investing in using DHTML/AJAX to make their sites more interactive rather than replacing the HTML interface outright. In that situation, GWT is not the ideal solution. (e.g. For quite a while, you couldn't even have more than one widget per page!) It works though, so you'll find it pop up here and there.
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
Internet Explorer is the only major browser to NOT implement SVG and Canvas. Which is a major failure on Microsoft's part. One might almost say that they're intentionally trying to prevent the adoption of standards that could replace their proprietary APIs like VML and ActiveX. Almost, anyway. It's not like Microsoft has a history of not implementing the DOM standards or anything.
(*Hint!* That was sarcasm. Microsoft fails miserably at implementing the DOM2 standards.)
First of all the Wii is quite a bit faster than PSP.
333MHz vs. 729MHz. Even if we assume that they have a different performance profile on a per-cycle basis, a little more than twice the clock speed is not really enough for smooth emulation.
Second, they are both MIPS so you don't need to emulate most code
Since when does the Wii contain a MIPS chip? Last I checked, the "Broadway" chip was a PowerPC processor running at 729MHz.
Third, most PSP games do not access any hardware directly (all the rendering is done through a library similar to a very light opengl and all the file and audio calls are similarly through system libraries).
That's true of nearly all modern consoles. Yet the last time I looked into GameCube emulators, they still showed very poor performance on a modern PC. And that's counting that most 3D emulation is done by using replacement libraries whenever possible.
Slashdot Mirror
I don't see where the "free ride" comes in. They lost the home, wiped out their savings, probably increased their debt, and (almost certainly) killed their credit rating. It will be a long time before they can attempt to own a home again, even if we assume they've learned from the experience.
There was an old joke in the Soviet Union that there were only four channels on television. The first three were all news and the forth was a KGB agent waving his finger and saying, "No, no, no! Change the channel back!"
Actually, the whole point of the WHATWG is to try implementing the spec before it's finalized. The idea is that the problems can be found during implementation, then the spec adjusted before it falls into heavy use.
HTML5. Which is itself a W3C dump of the ongoing work over at the WHATWG. Here's the specific W3C text on Canvas:
The work over at the WHATWG is a collaboration between Mozilla, Opera, and Apple. Microsoft was offered to contribute, but they declined. (Though a few Microsofties have been seen on the mailing lists as of late.)
Hmm... in hindsight a better quote might have been:
"I think the young people enjoy it when I "get down" verbally, don't you?" --Dr. Meredith
Welcome to today's Slashdot. Mindless fools that are 15 years old. The 80's? Don't even remember 'em!
Or maybe it was always that way and we older folks just don't have the time to invest in shaping this community anymore and thus it has become a haven for the newcomers. Oh, and get off my lawn! :-P
"Put simply, in deference to you Kent, it's like lasing a stick of dynamite." --Chris Knight
I'll take Point and Click for $500, Alex.
What is Zack and Wiki?
They tower over the ocean floor, don't they? Okay, how about "Cell Columns"? Or "Cell Structures"? Maybe "Cell Network Nodes"?
Use it to send an email instead. I wonder if the cell towers down there have 3G or EDGE?
Fabrication of a 3000 metric ton space ship has not been achieved, either. Such fabrication has more in common with building a sky scraper than with the construction of most spacecraft. In result, we lack a fabrication infrastructure in space, but have an excellent infrastructure here on Earth.
Thus the two options are:
1. Reuse the existing fabrication infrastructure here on Earth. Find a way to launch ~3000 metric tons to LEO without engaging the nuclear pulse drive during launch. Suggested options include lining the outer hull with SRBs similar to those currently used in the Shuttle program. These SRBs have a high thrust to weight ratio despite their relative inefficiency. However, having a large number of SRB engines increases complexity as well as opportunity for failure.
2. Build and supply a construction yard in space. Actual launch mass will be many times the 3000 metric tons, but the mass will be able to be spread across dozens to hundreds of launches. Many launches will be low mass launches of highly trained construction workers. Such workers would work extended EVAs far in excess of existing EVA records. New EVA technology may be required to improve worker efficiency to acceptable levels.
If you know how to do it, I think NASA would be extremely interested in your solution. 3000 metric tons to Low Earth Orbit (LEO) is a lot more than anyone has ever attempted before. The most powerful rocket in existence will be the Ares-V upon completion. It will be capable of lifting ~180 metric tons to LEO. Now scale that up by about 17x and we'll be good to launch an Orion.
That's only fair if you also include the Russian deaths on the ground. Who had the dubious honor of having the first space-related death? Why, the Russians with a training exercise in a pure oxygen environment. (Same issue that killed the Apollo astronauts.) Except that was 1961. Apollo wouldn't repeat that mistake until 1967. (Which was a perfectly avoidable mistake, and was a huge wake-up call to the NASA of the time.)
Don't even get me started on the number of near-fatal collisions and separation failures the Russians had in space! All of which is nicely spelled out in the same Wikipedia article.
I REPEAT. Space is dangerous business. Get over this idea that the Russians are inherently safe and the U.S. isn't. They're both as dangerous as you can possibly get. The different approaches to safety primarily yield different modes of failure rather than a superior safety record.
I hope you realize that Pournelle and Niven didn't just make that up? Project Orion was a very real attempt to develop nuclear pulse propulsion. It is still a viable option for space travel, as long we're not talking about a ground-launch using nuclear pulses. To get the sucker into orbit, we might have to resort to something a bit more mundane. Like a dozen SRBs or somesuch.
*sigh* The AC above me was trying to link to the List of Space Disasters article on Wikipedia. Which speaks of two major incidents resulting in the loss of crew. The first was a parachute failure which led to the death of the astronaut on board. The second was a valve failure that resulted in depressurization of the capsule and a loss of all crew members.
Score Card
==========
Russia - 2
U.S. - 2
Seems to be a parity to me. Also, there is the issue that the Soviet Union didn't always tell everyone when an accident happened. It's difficult to tell if there were further incidents that have gone unpublished.
Regardless of that issue, there are more than enough near-fatal space accidents on the Russian side listed in the Wikipedia article to question whether the Russian space program really is safer. The truth is simply that space travel is risky business. It will continue to be risky business for a long time, unfortunately.
Indeed. I personally think it would be amazing if we could develop a set of standard comsats to spread across the solar system. Want to explore Mars? No problem. We already have a communications infrastructure for you. Explore Europa? We've got sats around Jupiter, too. Throw in some sats traveling along the Interplanetary Superhighway and you've got better coverage than your average cell phone.
I think people tend to underestimate the shear enabling factor of such a communications network. Not only would such a large deployment provide easy access to all our probes and manned missions, but it would pave the way for cheaper, standardized probes and sats. Manufacture anything in sufficient quantity and the price begins to drop. Just the areas of space that the comsats would be exposed to would easily teach us as much about space hardware as the probes we spend 20+ years planning for a single mission!
I think Mars was actually the tipping point that helped make this happen. There was some early interest in the project when it was first began, but that interest waned rather quickly. But now that we're sending so much hardware to Mars, the powers that be are looking for solutions.
It's an exciting time for space enthusiasts. Let's just hope that the next President doesn't kill all the progress we're making. :-(
I do believe the parent to your post was poking fun at my (rather silly) mistake of referring to an Asteroid as a Meteor. While not necessarily an incorrect usage, it does tend to refer to those rocks that hit the atmosphere and burn up. :-)
I think you're missing the point. The general idea here is to have a packet switched communications system throughout the solar system. That way if a probe is in the shadow of, say, Jupiter, it can bounce a signal off a probe orbiting Venus, which will relay the signal back to Earth.
The end result would be a more robust communications system. In the future, interplanetary communications satellites could even end up doing most of the grunt-work, thus allowing probes and manned spacecraft to carry smaller communications packages designed to work with the network rather than broadcasting in as many conditions as possible.
such a network would also be useful for astronauts on another planet or meteor. Rather than setting up a communications station, they can use orbiting satellites to relay their transmissions. (Something which NASA already does on a smaller scale with probes like the Mars rovers.)
You write a runtime patch once and you're done. Meanwhile, you upgrade your Prototype and Scriptalicious libs and then spend an ungodly amount of time troubleshooting incompatibilities between versions.
Sounds like a winning proposition to me. ;-)
Frameworks are almost most often more trouble than they are worth. Once you understand Javascript, you realize how stupidly simple most of the tasks are, and how much time you've been wasting on the framework. If you don't understand Javascript, you probably have wasted dozens (if not hundred!) of hours fighting with issues that are actually very avoidable to begin with.
e.g. Most folks don't understand Javascript scoping. So they'll be surprised when they accidently change a variable that they're using elsewhere in the code. A very simple mistake to avoid if you've read the documentation. But as Douglas Crockford of JSON fame has pointed out, most programmers start trying to hack the language without first understanding it. Which is a huge mistake considering that Javascript is only superficially similar to C/C++/Java-type languages.
Here's a hint for you: Use Glassfish. Your life will be about 1000x easier.
Here's another hint: No matter what anyone tells you, AVOID JAVA SERVER FACES LIKE THE PLAGUE. The API will not help you.
Hope that helps. :-)
The ideal solution in that case is NOT frameworks. It's to have runtime patches available that make your code run predictably on all browsers. That way if you need to support a new browser, you just add a new patch so that it functions predictably. (If necessary.) Since such patches tend to function based on whether or not a particular feature exists rather than the browser itself, they automatically deactivate when the browser maker finally gets it right.
In practice, of course, things are not nearly as bad as they're made out to be. IE needs the most patching for issues like DOM2 Events (or lack thereof), but otherwise coding to the base standards means portable code across browsers. No significant part of the industry is really doing anything fancy like SVG, Canvas, or Local Storage. (Yet, anyway.) The simple loop of "event fired, contact server, get response, update DOM" is actually pretty straightforward. Especially in the circumstances where GWT fails.
Meanwhile, I've seen all manner of screwy problems caused by folks who try to plugin a framework. One of my favorites was an issue with the prototype library where it was incorrectly deleting the "display" value to make an element visible. Obviously the hope was that it would display as a block element by default. Let's just say that it didn't always work right.
The reason why that example is my favorite is that it's such a stupid little thing. All that was needed was a simple "document.getElementById("myelement").style.display = 'block';" and you're done. There was no reason to abstract that. The abstraction actually CAUSED cross-browser issues rather than solving them. Not a good design.
...just not as much as you might expect. Part of the issue is that it's designed for when you develop your application from scratch. Generally with the intent of developing a desktop replacement webapp. The only problem is that not many companies are investing in such apps. They're investing in using DHTML/AJAX to make their sites more interactive rather than replacing the HTML interface outright. In that situation, GWT is not the ideal solution. (e.g. For quite a while, you couldn't even have more than one widget per page!) It works though, so you'll find it pop up here and there.
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
Internet Explorer is the only major browser to NOT implement SVG and Canvas. Which is a major failure on Microsoft's part. One might almost say that they're intentionally trying to prevent the adoption of standards that could replace their proprietary APIs like VML and ActiveX. Almost, anyway. It's not like Microsoft has a history of not implementing the DOM standards or anything.
(*Hint!* That was sarcasm. Microsoft fails miserably at implementing the DOM2 standards.)
Perhaps you were thinking of the N64? That was MIPS all the way. The first TRUE 64 bit console. (Even if that didn't help it any.) :-)
333MHz vs. 729MHz. Even if we assume that they have a different performance profile on a per-cycle basis, a little more than twice the clock speed is not really enough for smooth emulation.
Since when does the Wii contain a MIPS chip? Last I checked, the "Broadway" chip was a PowerPC processor running at 729MHz.
That's true of nearly all modern consoles. Yet the last time I looked into GameCube emulators, they still showed very poor performance on a modern PC. And that's counting that most 3D emulation is done by using replacement libraries whenever possible.
Sorry, but I'm pretty sure that I am Batman!