Yup, I'd have to agree with you. Whilst Mark's work here is neat, it's hardly earth-shattering. It's a pretty standard reverse engineering of a VM to understand it's internals, discovering an absolutely pathetic memory protection scheme, and writing what is finally a relatively simple exploit. Generally speaking, security professionals are more likely to b bemused by the lack of a secure memory model for the ActionScript VM. Implementing the VM stack on the CPU's stack? Now there's an idiot security breach just waiting to happen. I imagine they did it for performance reasons, but good grief, Adobe has only themselves to blame if ever anybody uses this exploit for evil.
Exactly. Apple for example. MacOS9 and MacOSX have practically nothing in common, BUT, you could run MacOS9 apps in a compatibility environment under MacOSX, and it was a relatively simple task to upgrade MacOS9 programs to MacOSX, thanks to the Carbon APIs. The result was that applications that ran under the compatibility layer did not need to be touched at all, and apps that didn't run well could be easily ported to MacOSX. Mac users barely felt the changeover (except in a positive sense).
Apple basically transitioned an entire ecosystem with barely a hitch. It's a shame that Microsoft did not take the oppotunity to do something similar when passing from XP to Vista.
They actually use the transport to remove all of their rubbish. They can't just throw waste outside, that would present yet another orbital risk. So, they load everything into the supply module (Progress, ATV, or the new Japanese HTV which should get it's first launch next year), and then the supply module burns its engines to re-enter Earth's atmosphere and burning up.
You're not paying attention. In my previous post, I was describing attacks against a server-based protection scheme, not a card-based protection scheme. But if you read all of the posts on this topic, others have already pointed out how to attack cards - there are physical means to get inside the card, and watch what is happening on its internal bus. Sure, it's out of the reach of a bored teenage hacker, but the pros have the necessary equipment.
Also, the prvious post was in reply to Jiminicus, who apparently has no idea of the history of the content protection industry. I started out from a very simple system, patchable by changing a boolean value, to a system where i needed to convince the server to give me the key I needed - in other words, from doing a boolean check to needing to obtain some information from the content protection system, which is the direct equivalent of your idea. I was showing, in one post, the evolution of pirate attacks against systems over time.
But basically you are right, in every system produced since smartcards began, you pass an encrypted control word to the smartcard, and the smartcard gives you the decrypted control word. you can't just patch around that. But as I have already mentioned, there are attacks to obtain the keys inside the card. Or, another popular attack in these internet-enabled times, is simply to buy a rack of decoders with cards, and stick probes on the interface between the card and the decoder. You grab the decrypted control words as they pass, and stick them on a server on the Internet. Then there is a little module that can be inserted in the place of a smartcard in a normal decoder, which basically retrieves the control words from the server. Voilà, system breached again.
That attack is protected against by encrypting the link between the CPU in the decoder, and the smartcard. The decrypted control word never appears on an external bus. These systems are very hard to manage though, as you need to lock the card to the secure chipset on the decoder's motherboard, which is done by getting the two systems to exchange a key. This exchange has to be done whilst following a secure protocol. The system is very brittle, and it is very easy to finish up with a dead decoder/smartcard, which is a logistical nightmare.
Another solution is to do this encryption in software, which happens to be my current project. Of course, software protection can be reverse engineered, so the trick is to make that software easy to update, so you change the encryption algorithm every month or so.
So yes, the systems I work on are probably every bit as hard to crack as the DirecTV system you talk about. And yes, I'm aware of the various counter-attacks used by most content protection providers, such as NDS, Irdeto, Viaccess, Nagra, and friends. I helped design some of them.
There are, nevertheless, certain things that computer scientists know better how to do then computer engineers.
Example: I'm an engineer, and I had a job to do that required parsing C header files. Parsers, compilers, loaders, virtual memory, and all that good stuff just never appears in engineering degrees. Too theoretical. Troubles is, I needed that stuff to make a virtual machine implementation actually usable in the real world. I then had to spend three months learning how to write compilers from textbooks, because my company ONLY has engineers, no scientists.
A practical understanding of programming can only get you so far. When you need to do something truly exceptional with computers, you need the theory to back it up.
Yes, yes they have. Not by you though, apparently.
Jiminicus, my job is to crack decoders. Well, at least half the time. The other half is spent designing systems to make the cracker's life difficult, by blocking the attacks that I have used myself.
For example, with your scheme, I would reverse engineer the official decoder, and then patch the code that checks the return code, so that the check always returns TRUE. Now, that can be defeated by making it so that the value returned by the server is actually a key. My next attack would then be to try and convince the server that I am a real official decoder, and that it should give me the key. Unless care is taken, I could probably get the necessary information for this by launching a man-in-the-middle attack on an official decoder.
The typical defence against this attack is to protect the link by using certificates signed by the encryption provider, and linked to the decoder's serial number. As a pirate, I then just extract the official certificate either from the decoder itself, or from the conversation of a real box. I can then clone the certificate/identity of the decoder, and the server will talk to me as though I'm a real decoder.
The response to that attack is to verify that there are not two decoders connected at the same time that use the same identity. But this is not as simple as it sounds. For performance reasons, servers are distributed to handle different 'parks' of decoders. But I have to maintain a synchronized list of currently logged in decoder identities across all servers. This is a definately non-trivial task, or at least that's what my collegues that work on the head-end code tell me.
Other options for a cracker include trying to find a way to compromise the head-end server, and then poke around on it to dig up signing certificates and other good stuff to circumvent the protection. Or he might launch a denial of service attack - most server solutions have a 'degraded' fall back mode where the TV signal is encrypted with a key kept locally in the decoder, to be used if the key servers fail for whatever reason. That key can of course be extracted by the traditional means.
Believe me, many, many, many people have tried to come up with solutions to this problem. The server approach that I have just outlined is the most secure that we have found to date, but as I have also described, it has problems too. Not to mention that it is expensive/complicated to implement.
Nothing else matters. You can have your geeked out background processes on your WinME device, but when the other cool kids load up their 3D games using the 3D accelerometer on the iPhone, your Twitter client is not going to seem so impressive...
Yes, with time and more capable hardware, Apple will no doubt make some background processes available to third party apps, but really, it doesn't matter. Because there will be games.
And I, as a big bad pirate, will just make sure that my box doesn't call home on the return channel by unplugging the phone line, or putting in a firewall between the decoder and its head-end.
So then what you need to do is make it so that my box doesn't work UNLESS I call home, for example it needs to call home to get the key in the first place. This is the key server that I mentioned above, with the inconveniences that go along with it.
Lol, you are a GENIUS! Why didn't anybody think of that before?!?!?
Or, we have thought of it, it's just not as easy as you think. The problem is that the decoder has to have the key, otherwise the paying client can't watch TV. A pirate reverse engineers the decoder to find the key. The defence against this type of attack is to try and hide the key - one solution is to hide the key in hardware - the smartcard option. Another is to hide the code in software, using code obfuscators, virtual machines, whiteboxes. The final option is to obtain the key from a server, using two-way comms.
None of these solutions is fullproof, the first two choices are just security through obscurity - they can, and will, be hacked given enough time/incentive. The third option is problematic because what happens if the key server goes down? Plus, you need to have a whole head-end server infrastructure to support the solution, which the operators don't like. I know, I implemented the client half of such a system for a major content protection company a couple of years back.
I just want to know who was the genius zombie that decided to attack the University admin block first. Getting nerf guns banned = sure sign that the zombies are gaming the system:-)
Of course, a wiser person would note that for a portable MP3 players, style is one of the functions. Sales figures for the iPod would even seem to suggest that it is one of the primary functions of an mp3 player...
Re:Please O PLEASE stop equating Ruby and Rails
on
Advanced Rails
·
· Score: 1
++ for point #1. I actually learned Ruby as part of using Rails. I've since let my Rails development slide a bit, but I'm using Ruby everywhere else - I have just finished writing a c-parser/automatig glue code generator for a virtual machine, all done in Ruby, and I'm also developing Cocoa apps on Mac OSX using RubyCocoa (the FSM's gift to Mac programmers everywhere).
Sure, it would be easier. But my point was that it just doesn't matter! OK, so Palestine is fractured, so what? You live with potentially sub-optimal conditions for a few years, until the Israelis get bored of paying huge taxes to employ tons of soldiers to police the now peaceful Palestinian zones. The walls go down, economic interests take over, and everyone wins.
The problem is that there is enough support in both the Israeli and Palestinian communities for continuing the conflict that there will always be someone that feels that they can advance their political position by ordering a few suicide-bomber attacks, or counter-reprisals. In such an environment, game theory says that the Hawks will always win out over the Doves, and the conflict will continue.
The only hope for an end to this conflict is for the Palestinians to renounce violence - to effectively start policing their own to prevent rogue attacks, and to bring to justice any criminals that slip through the net and launch an attack. I don't think that Israel renouncing violence would change much - the Palestinians will continue to attack regardless of Israel's own military actions (or lack thereof).
Anyway, I for one shall not be holding my breath for an end to this conflict...
You know, I normally avoid commenting on this topic, because nobody EVER takes the rational approach...
Take your comment for example. you ask the question "Oh right. So having been rounded up into little groups by the Israelis and continually provoked, the Palestinians should just give up and let themselves be exterminated?"
Firstly, if the Palestinians stop lobbing rockets and bombs, I'm pretty damn sure the Israelis won't be doing any 'exterminating'. Note the lack of Israeli action during Palestinian cease-fires.
Secondly, and this is the bit where rationality disappears in a puff of religious fervour, the Palestinians need to get it through their heads that they lost the war, and that they are highly unlikely to ever be able to recapture their land through military action. They also need to recognise that their financial well-being would be better served by putting down the guns and bombs, and working on developing their country as it is - build schools, build roads, invest in the future, rather than piss money away futilely trying to right the wrongs of the past.
Yet what do the Palestinian people do? They elect a representative of Hamas. Brilliant idea. I can't help wondering why they don't pull their heads out of their arses, and have a look at what happened in Japan after World War II. The Japanese were crushed during that war - their economy was a wreck, the country's infrastructure badly damaged. But they didn't keep fighting an uprising against their invaders. No, they pulled their heads in, swallowed their pride, and when quietly about their lives. They are now once again an economic powerhouse and a major player on the global stage. Same thing in Germany. Palestine on the other hand, which in theory should only be a few years behind these two, is a complete mess, despite never having been completely invaded. A rational observer can only conclude that they are infact their own worst enemy, and that they would have been better off if Israel had taken control of ALL of Palestine.
To sign off, none of the above should be taken as excusing the actions of the Israelis. They were wrong to invade, they are still wrong to respond to provocation by military force. But at the end of the day, none of that is important. The only important thing is what needs to happen to improve the lives of the Palestinian people, and from where I sit, prolonging the conflict is a guaranteed worse outcome than simply conceding defeat.
Unless I'm missing a major class of computational problem, we have only two types of problem in computing at the moment.
1) We have very computationally intensive tasks, which are inevitably trivial to parallelise. Examples include calculating graphics, running sims, and compiling. These tasks all involve many, many small tasks that can be completed independantly. Ffor example, we can compile individual source files independantly of each other, we can calculate the dot product of a vector with each element calculated in parallel, etc.
2) And then we have the rest. Messy, real world types of problems that are sequential by their very nature. I've tried, but I just can't find any real-world example of this type of problem that is very computationally intensive. Maybe somebody else can think of one? Video compression? But even there, we insert full frames every second or so, to limit propagation errors... Databases? I know that transactions impose an order, but even there the limit seems to be only on accessing one record/table simultaneously by multiple clients.
When I read discussions on massively parallel computing, people always talk about how hard it is. And it's true that parallelising problems of type 2 is difficult. But I just can't think of any real world use case, which leads me to conclude that we don't actually have a problem at all. In other words, Much Ado About Nothing, move along, nothing to see here...
No, not exactly. Satellites have highly circular orbits - this keeps them at a maximum distance from the Earth at all points of the orbit, and hence keeps atmospheric drag to a mimimum.
To increase the altitude of a sattelite, you need to do two burns - the first burn accelerates the satellite in the direction of it's orbit. This produces an egg shaped orbit, known as a transfer orbit. The round end of the 'egg' is near the Earth, and the pointy end is the point the furthest from the Earth. When the satellite subsequently reaches the pointy end, a second burn is executed, that makes the orbit circular again. I don't remember exactly what the vector of this burn has to be (a tangent to the circular orbit of that altitude I think...), but anyway, the idea is that you use energy to raise the average altitude of the orbit up to the highest point of the transfer orbit. It normally takes several burns over several orbits to achieve a highly circular orbit.
Disclaimer: Take all of this with a grain of salt. I'm not involved with the space industry. It's just that I wrote a game a while back where you are in a space ship protecting the earth from a hoard of attacking satellites that were bombing the Earth. The game was like good ol' Asteroids, you spin left, right, shoot and accelerate. But the thing was, both the satellites and the space ship were in orbit around the Earth, and I modelled gravity. What I just explained above was the technique I used as the player to raise the altitude of my ship's orbit...
To expand on this, I write code for set top boxes. I recently saw some code written by someone evidently completely untrained in assembly programming. It looked like this:
for (i = 0; i field0 = blah_0;...
pStruct->.fieldn = blah_n; }
which in turn gives:
mv r1, i
mv r2, sizeof(struct)
mult r1, r2;result now in r1
mv r2, addr(struct_array)
add r1, r2 ; result now in r1 is the pointer to struct_array[i]
mv r3, r1 ; copy stored in r3
mv r1, r3
add r1, field0_offset ; r1 now contains a pointer to field0 of the first struct
mv addr(r1), blah_0....
mv r1, r3
add r1, fieldn_offset ; r1 now contains a pointer to fieldn of the first struct
mv addr(r1), blah_n
The programmer has probably just saved a few hundred bytes of code, and lots of processor cycles each time the routine is run.
As it so happens, I discovered this little effort when I was reverse engineering some code. Later, when I was given access to the actual source, it amused me greatly to see it all written out in C:-)
Slashdot Mirror
Yup, I'd have to agree with you. Whilst Mark's work here is neat, it's hardly earth-shattering. It's a pretty standard reverse engineering of a VM to understand it's internals, discovering an absolutely pathetic memory protection scheme, and writing what is finally a relatively simple exploit. Generally speaking, security professionals are more likely to b bemused by the lack of a secure memory model for the ActionScript VM. Implementing the VM stack on the CPU's stack? Now there's an idiot security breach just waiting to happen. I imagine they did it for performance reasons, but good grief, Adobe has only themselves to blame if ever anybody uses this exploit for evil.
Exactly. Apple for example. MacOS9 and MacOSX have practically nothing in common, BUT, you could run MacOS9 apps in a compatibility environment under MacOSX, and it was a relatively simple task to upgrade MacOS9 programs to MacOSX, thanks to the Carbon APIs. The result was that applications that ran under the compatibility layer did not need to be touched at all, and apps that didn't run well could be easily ported to MacOSX. Mac users barely felt the changeover (except in a positive sense).
Apple basically transitioned an entire ecosystem with barely a hitch. It's a shame that Microsoft did not take the oppotunity to do something similar when passing from XP to Vista.
They actually use the transport to remove all of their rubbish. They can't just throw waste outside, that would present yet another orbital risk. So, they load everything into the supply module (Progress, ATV, or the new Japanese HTV which should get it's first launch next year), and then the supply module burns its engines to re-enter Earth's atmosphere and burning up.
Oh come on! OS/X is at least a Pleo! :-)
You're not paying attention. In my previous post, I was describing attacks against a server-based protection scheme, not a card-based protection scheme. But if you read all of the posts on this topic, others have already pointed out how to attack cards - there are physical means to get inside the card, and watch what is happening on its internal bus. Sure, it's out of the reach of a bored teenage hacker, but the pros have the necessary equipment.
Also, the prvious post was in reply to Jiminicus, who apparently has no idea of the history of the content protection industry. I started out from a very simple system, patchable by changing a boolean value, to a system where i needed to convince the server to give me the key I needed - in other words, from doing a boolean check to needing to obtain some information from the content protection system, which is the direct equivalent of your idea. I was showing, in one post, the evolution of pirate attacks against systems over time.
But basically you are right, in every system produced since smartcards began, you pass an encrypted control word to the smartcard, and the smartcard gives you the decrypted control word. you can't just patch around that. But as I have already mentioned, there are attacks to obtain the keys inside the card. Or, another popular attack in these internet-enabled times, is simply to buy a rack of decoders with cards, and stick probes on the interface between the card and the decoder. You grab the decrypted control words as they pass, and stick them on a server on the Internet. Then there is a little module that can be inserted in the place of a smartcard in a normal decoder, which basically retrieves the control words from the server. Voilà, system breached again.
That attack is protected against by encrypting the link between the CPU in the decoder, and the smartcard. The decrypted control word never appears on an external bus. These systems are very hard to manage though, as you need to lock the card to the secure chipset on the decoder's motherboard, which is done by getting the two systems to exchange a key. This exchange has to be done whilst following a secure protocol. The system is very brittle, and it is very easy to finish up with a dead decoder/smartcard, which is a logistical nightmare.
Another solution is to do this encryption in software, which happens to be my current project. Of course, software protection can be reverse engineered, so the trick is to make that software easy to update, so you change the encryption algorithm every month or so.
So yes, the systems I work on are probably every bit as hard to crack as the DirecTV system you talk about. And yes, I'm aware of the various counter-attacks used by most content protection providers, such as NDS, Irdeto, Viaccess, Nagra, and friends. I helped design some of them.
There are, nevertheless, certain things that computer scientists know better how to do then computer engineers.
Example: I'm an engineer, and I had a job to do that required parsing C header files. Parsers, compilers, loaders, virtual memory, and all that good stuff just never appears in engineering degrees. Too theoretical. Troubles is, I needed that stuff to make a virtual machine implementation actually usable in the real world. I then had to spend three months learning how to write compilers from textbooks, because my company ONLY has engineers, no scientists.
A practical understanding of programming can only get you so far. When you need to do something truly exceptional with computers, you need the theory to back it up.
Yes, yes they have. Not by you though, apparently.
Jiminicus, my job is to crack decoders. Well, at least half the time. The other half is spent designing systems to make the cracker's life difficult, by blocking the attacks that I have used myself.
For example, with your scheme, I would reverse engineer the official decoder, and then patch the code that checks the return code, so that the check always returns TRUE. Now, that can be defeated by making it so that the value returned by the server is actually a key. My next attack would then be to try and convince the server that I am a real official decoder, and that it should give me the key. Unless care is taken, I could probably get the necessary information for this by launching a man-in-the-middle attack on an official decoder.
The typical defence against this attack is to protect the link by using certificates signed by the encryption provider, and linked to the decoder's serial number. As a pirate, I then just extract the official certificate either from the decoder itself, or from the conversation of a real box. I can then clone the certificate/identity of the decoder, and the server will talk to me as though I'm a real decoder.
The response to that attack is to verify that there are not two decoders connected at the same time that use the same identity. But this is not as simple as it sounds. For performance reasons, servers are distributed to handle different 'parks' of decoders. But I have to maintain a synchronized list of currently logged in decoder identities across all servers. This is a definately non-trivial task, or at least that's what my collegues that work on the head-end code tell me.
Other options for a cracker include trying to find a way to compromise the head-end server, and then poke around on it to dig up signing certificates and other good stuff to circumvent the protection. Or he might launch a denial of service attack - most server solutions have a 'degraded' fall back mode where the TV signal is encrypted with a key kept locally in the decoder, to be used if the key servers fail for whatever reason. That key can of course be extracted by the traditional means.
Believe me, many, many, many people have tried to come up with solutions to this problem. The server approach that I have just outlined is the most secure that we have found to date, but as I have also described, it has problems too. Not to mention that it is expensive/complicated to implement.
Let me help you all out.
Games.
PSP/DS class games.
Nothing else matters. You can have your geeked out background processes on your WinME device, but when the other cool kids load up their 3D games using the 3D accelerometer on the iPhone, your Twitter client is not going to seem so impressive...
Yes, with time and more capable hardware, Apple will no doubt make some background processes available to third party apps, but really, it doesn't matter. Because there will be games.
And I, as a big bad pirate, will just make sure that my box doesn't call home on the return channel by unplugging the phone line, or putting in a firewall between the decoder and its head-end.
So then what you need to do is make it so that my box doesn't work UNLESS I call home, for example it needs to call home to get the key in the first place. This is the key server that I mentioned above, with the inconveniences that go along with it.
Lol, you are a GENIUS! Why didn't anybody think of that before?!?!?
Or, we have thought of it, it's just not as easy as you think. The problem is that the decoder has to have the key, otherwise the paying client can't watch TV. A pirate reverse engineers the decoder to find the key. The defence against this type of attack is to try and hide the key - one solution is to hide the key in hardware - the smartcard option. Another is to hide the code in software, using code obfuscators, virtual machines, whiteboxes. The final option is to obtain the key from a server, using two-way comms.
None of these solutions is fullproof, the first two choices are just security through obscurity - they can, and will, be hacked given enough time/incentive. The third option is problematic because what happens if the key server goes down? Plus, you need to have a whole head-end server infrastructure to support the solution, which the operators don't like. I know, I implemented the client half of such a system for a major content protection company a couple of years back.
Exactly
:-)
I just want to know who was the genius zombie that decided to attack the University admin block first. Getting nerf guns banned = sure sign that the zombies are gaming the system
Of course, a wiser person would note that for a portable MP3 players, style is one of the functions. Sales figures for the iPod would even seem to suggest that it is one of the primary functions of an mp3 player...
++ for point #1. I actually learned Ruby as part of using Rails. I've since let my Rails development slide a bit, but I'm using Ruby everywhere else - I have just finished writing a c-parser/automatig glue code generator for a virtual machine, all done in Ruby, and I'm also developing Cocoa apps on Mac OSX using RubyCocoa (the FSM's gift to Mac programmers everywhere).
Ahhh, finally somebody that is talking sense!
Sure, it would be easier. But my point was that it just doesn't matter! OK, so Palestine is fractured, so what? You live with potentially sub-optimal conditions for a few years, until the Israelis get bored of paying huge taxes to employ tons of soldiers to police the now peaceful Palestinian zones. The walls go down, economic interests take over, and everyone wins.
The problem is that there is enough support in both the Israeli and Palestinian communities for continuing the conflict that there will always be someone that feels that they can advance their political position by ordering a few suicide-bomber attacks, or counter-reprisals. In such an environment, game theory says that the Hawks will always win out over the Doves, and the conflict will continue.
The only hope for an end to this conflict is for the Palestinians to renounce violence - to effectively start policing their own to prevent rogue attacks, and to bring to justice any criminals that slip through the net and launch an attack. I don't think that Israel renouncing violence would change much - the Palestinians will continue to attack regardless of Israel's own military actions (or lack thereof).
Anyway, I for one shall not be holding my breath for an end to this conflict...
You know, I normally avoid commenting on this topic, because nobody EVER takes the rational approach...
Take your comment for example. you ask the question "Oh right. So having been rounded up into little groups by the Israelis and continually provoked, the Palestinians should just give up and let themselves be exterminated?"
Firstly, if the Palestinians stop lobbing rockets and bombs, I'm pretty damn sure the Israelis won't be doing any 'exterminating'. Note the lack of Israeli action during Palestinian cease-fires.
Secondly, and this is the bit where rationality disappears in a puff of religious fervour, the Palestinians need to get it through their heads that they lost the war, and that they are highly unlikely to ever be able to recapture their land through military action. They also need to recognise that their financial well-being would be better served by putting down the guns and bombs, and working on developing their country as it is - build schools, build roads, invest in the future, rather than piss money away futilely trying to right the wrongs of the past.
Yet what do the Palestinian people do? They elect a representative of Hamas. Brilliant idea. I can't help wondering why they don't pull their heads out of their arses, and have a look at what happened in Japan after World War II. The Japanese were crushed during that war - their economy was a wreck, the country's infrastructure badly damaged. But they didn't keep fighting an uprising against their invaders. No, they pulled their heads in, swallowed their pride, and when quietly about their lives. They are now once again an economic powerhouse and a major player on the global stage. Same thing in Germany. Palestine on the other hand, which in theory should only be a few years behind these two, is a complete mess, despite never having been completely invaded. A rational observer can only conclude that they are infact their own worst enemy, and that they would have been better off if Israel had taken control of ALL of Palestine.
To sign off, none of the above should be taken as excusing the actions of the Israelis. They were wrong to invade, they are still wrong to respond to provocation by military force. But at the end of the day, none of that is important. The only important thing is what needs to happen to improve the lives of the Palestinian people, and from where I sit, prolonging the conflict is a guaranteed worse outcome than simply conceding defeat.
Unless I'm missing a major class of computational problem, we have only two types of problem in computing at the moment.
1) We have very computationally intensive tasks, which are inevitably trivial to parallelise. Examples include calculating graphics, running sims, and compiling. These tasks all involve many, many small tasks that can be completed independantly. Ffor example, we can compile individual source files independantly of each other, we can calculate the dot product of a vector with each element calculated in parallel, etc.
2) And then we have the rest. Messy, real world types of problems that are sequential by their very nature. I've tried, but I just can't find any real-world example of this type of problem that is very computationally intensive. Maybe somebody else can think of one? Video compression? But even there, we insert full frames every second or so, to limit propagation errors... Databases? I know that transactions impose an order, but even there the limit seems to be only on accessing one record/table simultaneously by multiple clients.
When I read discussions on massively parallel computing, people always talk about how hard it is. And it's true that parallelising problems of type 2 is difficult. But I just can't think of any real world use case, which leads me to conclude that we don't actually have a problem at all. In other words, Much Ado About Nothing, move along, nothing to see here...
Wait, what? When did Perth join the 21st century and get DST????
What about all the embedded code developers, you insensitive clod! :-)
Yeah, but it's a drag, it's a bore, it's really such a pity, to be looking at a board, not looking at the city... or marscape as the case may be.
No, not exactly. Satellites have highly circular orbits - this keeps them at a maximum distance from the Earth at all points of the orbit, and hence keeps atmospheric drag to a mimimum.
To increase the altitude of a sattelite, you need to do two burns - the first burn accelerates the satellite in the direction of it's orbit. This produces an egg shaped orbit, known as a transfer orbit. The round end of the 'egg' is near the Earth, and the pointy end is the point the furthest from the Earth. When the satellite subsequently reaches the pointy end, a second burn is executed, that makes the orbit circular again. I don't remember exactly what the vector of this burn has to be (a tangent to the circular orbit of that altitude I think...), but anyway, the idea is that you use energy to raise the average altitude of the orbit up to the highest point of the transfer orbit. It normally takes several burns over several orbits to achieve a highly circular orbit.
Disclaimer: Take all of this with a grain of salt. I'm not involved with the space industry. It's just that I wrote a game a while back where you are in a space ship protecting the earth from a hoard of attacking satellites that were bombing the Earth. The game was like good ol' Asteroids, you spin left, right, shoot and accelerate. But the thing was, both the satellites and the space ship were in orbit around the Earth, and I modelled gravity. What I just explained above was the technique I used as the player to raise the altitude of my ship's orbit...
Heh heh. Yup, Cody's response was comedy gold :-) BTW, not all of us on Slashdot are male...
Sure, just as soon as you stop using "rediculous". It, unlike 'authored' is not actually a word...
Do a search for "embedded" instead of "assembly language" on any job site...
To expand on this, I write code for set top boxes. I recently saw some code written by someone evidently completely untrained in assembly programming. It looked like this:
...
;result now in r1
....
:-)
for (i = 0; i field0 = blah_0;
pStruct->.fieldn = blah_n;
}
which in turn gives:
mv r1, i
mv r2, sizeof(struct)
mult r1, r2
mv r2, addr(struct_array)
add r1, r2 ; result now in r1 is the pointer to struct_array[i]
mv r3, r1 ; copy stored in r3
mv r1, r3
add r1, field0_offset ; r1 now contains a pointer to field0 of the first struct
mv addr(r1), blah_0
mv r1, r3
add r1, fieldn_offset ; r1 now contains a pointer to fieldn of the first struct
mv addr(r1), blah_n
The programmer has probably just saved a few hundred bytes of code, and lots of processor cycles each time the routine is run.
As it so happens, I discovered this little effort when I was reverse engineering some code. Later, when I was given access to the actual source, it amused me greatly to see it all written out in C