WebGL allowing shader usage is pretty much a non-issue security wise. GLSL shaders are *extremely* limited in scope. They can't access anything besides model data and textures, and even then only the model data and textures provided to them by the host program. GLSL is very domain-specific and doesn't support pointers or any way to access things outside the purview of the GPU.
Furthermore, they aren't pre-compiled (aside from some vendor-specific methods on *OpenGL ES*, and even those only compile to bytecode IIRC), so WebGL can at least attempt to do some shader validation. OpenGL and WebGL programs literally hand the GLSL source code to the driver, which is then responsible for compiling it. This actually turns out to be good for performance, since future compiler improvements in the driver can result in the same shader on the same hardware running faster. It also means WebGL could do validation on the shaders before handing them off to the driver, to keep an eye out for any obvious attempts to do something bad.
And when it comes to malicious shaders, only two attacks can be executed: try to crash the GPU by running a very intensive shader, or try to peek at other web pages via what seems to be an implementation flaw in WebGL/HTML5 Canvas.
The first attack can be easily avoided. In fact, it *shouldn't* be possible at all on Windows, which is supposed to restart the GPU if the GPU crashes, and when it can't that's a *Windows* bug.
The second is a little harder but, again, looks to be an *implementation* flaw, not a fundamental flaw in WebGL or shaders or anything like that.
Face facts, modern GPUs don't offer any of the old fixed-function pipeline anymore. It's not anywhere to be found on the silicon; modern GPU drivers merely emulate it for old OpenGL programs. This means that if WebGL didn't have shader support it would be completely useless.
Raiders of the Lost Ark was good because of people *NOT* named George Lucas. Lucas came up with some good ideas, but also some really bad ones that Spielberg and others shot down.
Basically, once Lucas had the initial idea, it was turned into a good movie by Steven Spielberg, Lawrence Kasdan, and Harrison Ford.
I think you're missing the point, which is that Lawrence Kasdan (the writer) and Irvin Kirshner (the director) tried to lift ESB above being a one-dimensional movie, and succeeded for the most part. Real character development, good dialog, good acting & directing, etc.
Of course, if you're the kind of person who just wants to "turn their brain off" when they watch a movie, well...
The built-in alarm clock app in iOS works nothing like the article describes.
The use of a "+" button to mean "add [something]" is used throughout iOS. You don't use the "+" button to adjust an existing alarm, BTW. The alarm clock app initially has no alarms set, so you use the "+" button to add one (which then automatically takes you to a screen where you can set the alarm). If you want to change an alarm, you press the clearly labeled "Edit" button.
Also, Windows (the most likely target of any attack) has had the ability since Vista to restart the GPU if it hangs (which is the only real attack possible when it comes to shaders: use a shader that is so computationally intensive the GPU becomes unresponsive). This isn't bullet proof, of course, but if Windows isn't able to restart the GPU after a few seconds of unresponsiveness then that's a *Windows* bug.
As with the previous article, this is much ado about nothing.
The GPU can only run "arbitrary code" in the loosest possible sense. What happens is that an OpenGL or WebGL application gives the shader source code to the driver, which then compiles it into the native GPU instructions. You *can* pre-compile your shaders in OpenGL ES 2.0, but even then it's just intermediary bytecode, and the bytecode is vendor-specific.
Furthermore, GLSL, the language used for OpenGL and WebGL shaders, is *very* domain-specific. It has no pointers, and no language support for accessing anything outside the GPU other than model geometry and texture data. *AND* it can only access the model geometry and texture data that the application have provided to it, and for GPUs that don't have any on-board VRAM it's up to the *driver* to determine where in shared system memory that the texture will be located.
And you can't get around using shaders on modern GPUs. Modern GPUs don't have a fixed function pipeline, it's not in the silicon at all. For apps that try to use the old OpenGL fixed function pipeline, the driver generates shaders that do what the fixed function pipeline *would* have done based on the current state. Drivers won't keep emulating the old fixed function pipeline forever, though.
Yes, something similar was mentioned in the article, and it *should* be fixed. But beyond that, shaders themselves don't expose anything particularly dangerous. GLSL, the language WebGL and OpenGL shaders are written in, doesn't have language features to access anything beyond the GPU. You can't access the user's hard disk from within a shader.
You can't get rid of shaders. Modern GPUs don't have a fixed function pipeline, it's totally gone from the silicon. Instead, for apps that try to use the old fixed function pipeline, the driver generates a shader that does what the fixed function pipeline *would* have done given the current state. Sooner or later the drivers are going to stop even emulating it.
Which is part of the reason WebGL has shader support in the first place, it wouldn't do anyone any good if it was obsolete right out of the gate.
Shaders aren't the problem, crappy web browsers are.
For the most part this is a lot of security handwaving.
While the GPU itself can do DMA and whatnot, shaders don't have access to any of that. If a shader can access texture memory that hasn't been assigned to it *in certain browsers* then it sounds like a bug in the browser or the browser's WebGL plugin. Being able to "overload" the GPU and blue screen the computer sounds like Yet Another Windows Bug.
A shader isn't just some arbitrary binary blob that gets executed directly by the GPU. Even native programs can't do this. You provide the driver your shader source code, the driver does the rest. It's intentionally a black-box process so that the driver can optimize the shader for the GPU and not force a specific instruction set or architecture onto GPU designers. Thus allowing the underlying GPU design to evolve, possibly radically or in unforseen ways, without breaking compatibility.
Furthermore, a shader can only access memory via the texture sampler units, which must be set up by the application. If the WebGL application (which is just JavaScript) can set things up to access texture memory it isn't supposed to be able to, the problem is with the WebGL and/or HTML5 implementation, not the concept of WebGL or the GPU driver.
I find it interesting that people who grew up using the metric system always try to use the yard as a comparable imperial unit, yet people who grew up using the imperial system don't use the yard to measure things that often. Few people in the US know how many yards are in a mile because nobody cares, it's like someone in a metric-using country measuring things in decameters.
The imperial system, for all its warts, has two advantages that metric does not:
1)Human-sized measurements. The foot is about the length of an average adult's foot. A yard is about the length of the average person's arm, and about the length of the average person's stride. Etc., etc., etc.
2)Evenly divisible units. A foot will evenly divide into halves, thirds, and fourths. A gallon will evenly divide into halves and fourths, ditto for the quart and cup. These are pretty common things to do, especially for things like basic home carpentry and cooking & baking, so it's nice that they divide up evenly.
Granted, converting between Imperial units isn't always easy, but the basics aren't that hard. Nobody actually uses rods & hogsheads to measure things. Most gripes about imperial units being too byzantine seem to come from people who grew up using the metric system, so metric is naturally what's more familiar and comfortable to them.
I think a more accurate question would be: Why would someone doing medical imaging play music/videos on the same computer? Let alone at the same time?
"Hey guys, I know this computer is only supposed to be used to control the MRI machine, but let's throw our MP3 collections on it! ROCK OUT WITH YOUR COCK OUT!"
Because the system starts each subsystem in a certain order, and generally requires them all to be present and working in order to have a "useable" computer.
You can't very well "use what's *already* installed while it looks for the new stuff" if that "new stuff" is something the system needs in order to even work, such as video, hard disks, etc.
The thing you're ignoring is that a cross-platform application should run more or less the same on all target platforms, unless you just really hate users running a different OS than you. It'd be nice if users didn't have to re-learn the app's interface if they go from a shop that runs TheProgram on Windows to a shop that runs TheProgram on Mac OS X, or if they run the Windows version of TheProgram at work but use the OS X version at home. Imagine if Photoshop for OS X was a completely different beast than Photoshop for Windows.
One possible solution might be to have the program alter its behavior based on some setting. On installation, or the first time the program is run, allow the user to choose between Cross-platform or Native behavior. Make this something they can easily change later should they change their mind.
This isn't really a perfect solution, though. The best way would be to just have the program behave like target OS's native apps as much as can be done without requiring a large degree of re-learning and alienation for users switching from one platform to another (or using the program on both).
And keep in mind that a lot of developers just plain don't have access to more than one platform.
Actually, the jet pack chase scene was NOT filmed on a soundstage. It was an actual location. However, they needed to attach rigging to the buildings to support the lights and the flying rigs. So, when it became clear that rigging was visible in the puddles, ILM removed it in post, since they were already going to be doing a number of VFX in that sequence (flames coming from the jet packs, wire removals, etc.).
As an aside, the production had to get some sort of special permit for all the rigging they built, since evidently it extended a good ways above the buildings, and was the tallest construction in that area. Read American Cinematographer's issue on Minority Report's cinematography for more details.
How exactly is an electoral college different? As it stands, rural states don't get many electors, so the end result is the same: states with less population have less say in the presidential elections.
Which, IMHO, is exactly how it should be. A minority group's vote *should* count, but not more than a majority group's vote (while what's best for California may not be what's best for the rest of the country, what's best for Wyoming may not be what's best for everybody else either). In fact, it should count less, because why should the 10 people in Group A have the same say as the 100 people in Group B?
Not really. The Moon is essentially a big money hole, in that you spend lots and lots and get very little in return.
First, there is zero (or near zero) possibility for a Moon base to be self-sufficient. You're always going to have to lug things up there from Earth.
A Mars base, on the other hand, has the possibility of at least limited self-sufficiency. The base can get oxygen from the atmosphere (Martian atmosphere is mostly CO2), water from the ice caps or the permafrost, and rocket fuel can be produced there as well (using the same method outlined in the Mars Direct and Mars Semi-Direct plans).
Lastly, we humans do generally do better in gravity. Mars has more gravity than the Moon, so humans living there would suffer less from the adverse health effects of low/no gravity.
And while it's easy to say, "We should just send people and forget about bringing them back," are you really willing to send someone into what will be an extremely hard, and probably much shorter life just so you can say, "But see? We're doing zero frills space exploration!" Unless they can have at least a decent life once they arrive at their permanent destination, no one is going to want to go.
I really liked the concept of using the space station as a base for Lunar exploration and, in turn using the Moon as a base of operations for a Mars expidition.
Except both would be completely useless for that purpose.
The ISS is in an absolutely useless orbit, and is in that orbit solely so that the Russians can reach it using their launch facilities in Kazakhstan.
As to using the Moon as a base of operations for a Mars expedition: what sense does it make to go to all the trouble of leaving Earth's gravity, only to have to slow down, get into the Moon's orbit, land on the Moon, and then have to leave it again, all in order to get to Mars? It's much easier to just go on a direct route. We should be following the Mars Direct or Mars Semi-Direct plans for reaching Mars, not coming up with some plan that's reminiscent of the 90-day Report in it's "I'll scratch your back, and you scratch mine" nature.
In mode 13h all the pixels fall on byte boundaries. In fact, that's what made mode 13h so popular: each pixel was represented by a single byte, and that byte contained an index into a 256 color palette.
Slashdot Mirror
This BS *again*?!?!
GPU shaders != running code on the CPU.
WebGL allowing shader usage is pretty much a non-issue security wise. GLSL shaders are *extremely* limited in scope. They can't access anything besides model data and textures, and even then only the model data and textures provided to them by the host program. GLSL is very domain-specific and doesn't support pointers or any way to access things outside the purview of the GPU.
Furthermore, they aren't pre-compiled (aside from some vendor-specific methods on *OpenGL ES*, and even those only compile to bytecode IIRC), so WebGL can at least attempt to do some shader validation. OpenGL and WebGL programs literally hand the GLSL source code to the driver, which is then responsible for compiling it. This actually turns out to be good for performance, since future compiler improvements in the driver can result in the same shader on the same hardware running faster. It also means WebGL could do validation on the shaders before handing them off to the driver, to keep an eye out for any obvious attempts to do something bad.
And when it comes to malicious shaders, only two attacks can be executed: try to crash the GPU by running a very intensive shader, or try to peek at other web pages via what seems to be an implementation flaw in WebGL/HTML5 Canvas.
The first attack can be easily avoided. In fact, it *shouldn't* be possible at all on Windows, which is supposed to restart the GPU if the GPU crashes, and when it can't that's a *Windows* bug.
The second is a little harder but, again, looks to be an *implementation* flaw, not a fundamental flaw in WebGL or shaders or anything like that.
Face facts, modern GPUs don't offer any of the old fixed-function pipeline anymore. It's not anywhere to be found on the silicon; modern GPU drivers merely emulate it for old OpenGL programs. This means that if WebGL didn't have shader support it would be completely useless.
Raiders of the Lost Ark was good because of people *NOT* named George Lucas. Lucas came up with some good ideas, but also some really bad ones that Spielberg and others shot down.
Basically, once Lucas had the initial idea, it was turned into a good movie by Steven Spielberg, Lawrence Kasdan, and Harrison Ford.
I think you're missing the point, which is that Lawrence Kasdan (the writer) and Irvin Kirshner (the director) tried to lift ESB above being a one-dimensional movie, and succeeded for the most part. Real character development, good dialog, good acting & directing, etc.
Of course, if you're the kind of person who just wants to "turn their brain off" when they watch a movie, well...
The built-in alarm clock app in iOS works nothing like the article describes.
The use of a "+" button to mean "add [something]" is used throughout iOS. You don't use the "+" button to adjust an existing alarm, BTW. The alarm clock app initially has no alarms set, so you use the "+" button to add one (which then automatically takes you to a screen where you can set the alarm). If you want to change an alarm, you press the clearly labeled "Edit" button.
Also, Windows (the most likely target of any attack) has had the ability since Vista to restart the GPU if it hangs (which is the only real attack possible when it comes to shaders: use a shader that is so computationally intensive the GPU becomes unresponsive). This isn't bullet proof, of course, but if Windows isn't able to restart the GPU after a few seconds of unresponsiveness then that's a *Windows* bug.
As with the previous article, this is much ado about nothing.
The GPU can only run "arbitrary code" in the loosest possible sense. What happens is that an OpenGL or WebGL application gives the shader source code to the driver, which then compiles it into the native GPU instructions. You *can* pre-compile your shaders in OpenGL ES 2.0, but even then it's just intermediary bytecode, and the bytecode is vendor-specific.
Furthermore, GLSL, the language used for OpenGL and WebGL shaders, is *very* domain-specific. It has no pointers, and no language support for accessing anything outside the GPU other than model geometry and texture data. *AND* it can only access the model geometry and texture data that the application have provided to it, and for GPUs that don't have any on-board VRAM it's up to the *driver* to determine where in shared system memory that the texture will be located.
And you can't get around using shaders on modern GPUs. Modern GPUs don't have a fixed function pipeline, it's not in the silicon at all. For apps that try to use the old OpenGL fixed function pipeline, the driver generates shaders that do what the fixed function pipeline *would* have done based on the current state. Drivers won't keep emulating the old fixed function pipeline forever, though.
IIRC OpenGL ES 2.0 can, but it's all vendor-specific. And it's still intermediary bytecode, not something that will execute directly on the hardware.
Actually it was the US Gov't that insisted on a second supplier when they used Intel processors in the space shuttle.
Yes, something similar was mentioned in the article, and it *should* be fixed. But beyond that, shaders themselves don't expose anything particularly dangerous. GLSL, the language WebGL and OpenGL shaders are written in, doesn't have language features to access anything beyond the GPU. You can't access the user's hard disk from within a shader.
You can't get rid of shaders. Modern GPUs don't have a fixed function pipeline, it's totally gone from the silicon. Instead, for apps that try to use the old fixed function pipeline, the driver generates a shader that does what the fixed function pipeline *would* have done given the current state. Sooner or later the drivers are going to stop even emulating it.
Which is part of the reason WebGL has shader support in the first place, it wouldn't do anyone any good if it was obsolete right out of the gate.
Shaders aren't the problem, crappy web browsers are.
Shaders themselves are pretty limited in scope, though. You can't really access anything beyond the GPU, textures, and model geometry.
GLSL (the language WebGL and OpenGL shaders are written in) doesn't have pointers and is most definitely NOT a general purpose language.
Even without shader support in WebGL you'd have the potential for intentionally bad model geometry crashing a really poorly written driver.
For the most part this is a lot of security handwaving.
While the GPU itself can do DMA and whatnot, shaders don't have access to any of that. If a shader can access texture memory that hasn't been assigned to it *in certain browsers* then it sounds like a bug in the browser or the browser's WebGL plugin. Being able to "overload" the GPU and blue screen the computer sounds like Yet Another Windows Bug.
A shader isn't just some arbitrary binary blob that gets executed directly by the GPU. Even native programs can't do this. You provide the driver your shader source code, the driver does the rest. It's intentionally a black-box process so that the driver can optimize the shader for the GPU and not force a specific instruction set or architecture onto GPU designers. Thus allowing the underlying GPU design to evolve, possibly radically or in unforseen ways, without breaking compatibility.
Furthermore, a shader can only access memory via the texture sampler units, which must be set up by the application. If the WebGL application (which is just JavaScript) can set things up to access texture memory it isn't supposed to be able to, the problem is with the WebGL and/or HTML5 implementation, not the concept of WebGL or the GPU driver.
I find it interesting that people who grew up using the metric system always try to use the yard as a comparable imperial unit, yet people who grew up using the imperial system don't use the yard to measure things that often. Few people in the US know how many yards are in a mile because nobody cares, it's like someone in a metric-using country measuring things in decameters.
The imperial system, for all its warts, has two advantages that metric does not:
1)Human-sized measurements. The foot is about the length of an average adult's foot. A yard is about the length of the average person's arm, and about the length of the average person's stride. Etc., etc., etc.
2)Evenly divisible units. A foot will evenly divide into halves, thirds, and fourths. A gallon will evenly divide into halves and fourths, ditto for the quart and cup. These are pretty common things to do, especially for things like basic home carpentry and cooking & baking, so it's nice that they divide up evenly.
Granted, converting between Imperial units isn't always easy, but the basics aren't that hard. Nobody actually uses rods & hogsheads to measure things. Most gripes about imperial units being too byzantine seem to come from people who grew up using the metric system, so metric is naturally what's more familiar and comfortable to them.
Actually, no. You only need to validate the game *once*, right after installing it.
After that, you can play it just fine without an internet connection.
All Steam games work this way.
I think a more accurate question would be: Why would someone doing medical imaging play music/videos on the same computer? Let alone at the same time?
"Hey guys, I know this computer is only supposed to be used to control the MRI machine, but let's throw our MP3 collections on it! ROCK OUT WITH YOUR COCK OUT!"
Because the system starts each subsystem in a certain order, and generally requires them all to be present and working in order to have a "useable" computer.
You can't very well "use what's *already* installed while it looks for the new stuff" if that "new stuff" is something the system needs in order to even work, such as video, hard disks, etc.
The thing you're ignoring is that a cross-platform application should run more or less the same on all target platforms, unless you just really hate users running a different OS than you. It'd be nice if users didn't have to re-learn the app's interface if they go from a shop that runs TheProgram on Windows to a shop that runs TheProgram on Mac OS X, or if they run the Windows version of TheProgram at work but use the OS X version at home. Imagine if Photoshop for OS X was a completely different beast than Photoshop for Windows.
One possible solution might be to have the program alter its behavior based on some setting. On installation, or the first time the program is run, allow the user to choose between Cross-platform or Native behavior. Make this something they can easily change later should they change their mind.
This isn't really a perfect solution, though. The best way would be to just have the program behave like target OS's native apps as much as can be done without requiring a large degree of re-learning and alienation for users switching from one platform to another (or using the program on both).
And keep in mind that a lot of developers just plain don't have access to more than one platform.
Since some people don't seem to understand what editing is when it comes to movie terminology, editing is just cutting the movie together.
So, in that regard, no, Linux is not used to edit movies.
However, Linux is used for VFX work, such as rendering, modelling, animation, and compositing.
The majority of film editors use Avid, which runs on Windows and OS X. Final Cut Pro is making inroads, but Avid is still on top (for now).
Actually, the jet pack chase scene was NOT filmed on a soundstage. It was an actual location. However, they needed to attach rigging to the buildings to support the lights and the flying rigs. So, when it became clear that rigging was visible in the puddles, ILM removed it in post, since they were already going to be doing a number of VFX in that sequence (flames coming from the jet packs, wire removals, etc.).
As an aside, the production had to get some sort of special permit for all the rigging they built, since evidently it extended a good ways above the buildings, and was the tallest construction in that area. Read American Cinematographer's issue on Minority Report's cinematography for more details.
No, it probably just switches between ROM banks.
How exactly is an electoral college different? As it stands, rural states don't get many electors, so the end result is the same: states with less population have less say in the presidential elections.
Which, IMHO, is exactly how it should be. A minority group's vote *should* count, but not more than a majority group's vote (while what's best for California may not be what's best for the rest of the country, what's best for Wyoming may not be what's best for everybody else either). In fact, it should count less, because why should the 10 people in Group A have the same say as the 100 people in Group B?
Yes, it worked in the, "there was no violence" meaning, but there were highly questionable acts committed by members of both political parties.
Let's face it: both the Democratic and Republican parties have some highly corrupt members and have done some highly questionable things in the past.
Not really. The Moon is essentially a big money hole, in that you spend lots and lots and get very little in return.
First, there is zero (or near zero) possibility for a Moon base to be self-sufficient. You're always going to have to lug things up there from Earth.
A Mars base, on the other hand, has the possibility of at least limited self-sufficiency. The base can get oxygen from the atmosphere (Martian atmosphere is mostly CO2), water from the ice caps or the permafrost, and rocket fuel can be produced there as well (using the same method outlined in the Mars Direct and Mars Semi-Direct plans).
Lastly, we humans do generally do better in gravity. Mars has more gravity than the Moon, so humans living there would suffer less from the adverse health effects of low/no gravity.
And while it's easy to say, "We should just send people and forget about bringing them back," are you really willing to send someone into what will be an extremely hard, and probably much shorter life just so you can say, "But see? We're doing zero frills space exploration!" Unless they can have at least a decent life once they arrive at their permanent destination, no one is going to want to go.
I really liked the concept of using the space station as a base for Lunar exploration and, in turn using the Moon as a base of operations for a Mars expidition.
Except both would be completely useless for that purpose.
The ISS is in an absolutely useless orbit, and is in that orbit solely so that the Russians can reach it using their launch facilities in Kazakhstan.
As to using the Moon as a base of operations for a Mars expedition: what sense does it make to go to all the trouble of leaving Earth's gravity, only to have to slow down, get into the Moon's orbit, land on the Moon, and then have to leave it again, all in order to get to Mars? It's much easier to just go on a direct route. We should be following the Mars Direct or Mars Semi-Direct plans for reaching Mars, not coming up with some plan that's reminiscent of the 90-day Report in it's "I'll scratch your back, and you scratch mine" nature.
In mode 13h all the pixels fall on byte boundaries. In fact, that's what made mode 13h so popular: each pixel was represented by a single byte, and that byte contained an index into a 256 color palette.