It uses psychological coercion to recruit, indoctrinate and retain its members
Sounds like any other religion to me, except most religions do this from childhood, so you don't see it being done to adults.
It forms an elitist totalitarian society.
Pick any theocracy. Any at all.
Its founder leader is self-appointed, dogmatic, messianic, not accountable and has charisma.
Jesus, Muhammad, etc.
It believes 'the end justifies the means' in order to solicit funds recruit people.
Tithing, anyone? That covers the funds bit. Recruiting people, well, I covered that. Child abuse (not the Catholic sexual kind) is definitely up there with lying and harrassment.
Its wealth does not benefit its members or society.
Nope. The money goes to further indoctrination and defending itself from sexual abuse scandals. Though, occasionally, a school does get built. Maybe that's the difference. Religions do occasionally spend money on humanitarian things, though usually with strings attached. You're gay? No school for you. AIDS problems? We'll help, but we won't touch those dirty condoms.
I thought the point of faith was that it was believed in spite of or in lack of evidence, and thus required no defense. Obviously, there are no proofs one way or the other, so I fail to see how one might defend a faith other than repetition. The fact that we have no way to know which faith, if any, is the correct one is enough for me to reject the whole matter as completely hopeless.
People who kill people do so for a variety of reasons. Some do it out of religion. Others do it out of greed for power.Some do it because it is the rational thing to do, such as in self defense. or euthenasia. The point is that most people believe that killing people is bad for whatever reason, and this belief needs to be overcome. Religion perverts reason and is one way in which it can be overcome. Not all evil will be gone from the world when religion is seen as what it is - the rejection of reason - but we will have eliminated one major cause of grief and suffering in the world.
But you are right on one count - you can't decree a ban on religion. People should be free to believe what they will, however misguided. But worse than that, it will not work. Nothing strengthens religion more than persecution. The only way we will ever be free of religion is through enlightenment, not edict.
Nowhere did I call Kerberos security through obscurity. It's a form of security based off of shared secrets and key exchange and follows generally accepted cryptographic principles. But if you think that Kerberos can be used to prevent me from doing things with the files I just downloaded off of the kerberized NFS server I'm using right now, you're sadly mistaken.
Which, again, is the key point. Trusted computing tries to limit what I can do with a computer. But if I have the keys and I know the protocols and algorithms, I can circumvent it. It's that simple. The only thing that trusted computing brings to the table is that it makes getting those keys harder. If I can get the key, I can request a shiny, temporary authorization key from whatever server I like and it has no way to know that I'm not the locked down program it's known so well for so long. It will happily grant me that ticket and then I can have modified software that strips all that cute little encryption so I don't have to do this every time.
Why should I look into both? Let me say it more clearly: I already know how both work.
Try reading what I said in my last message again and reflect on what you could do if you had the keys that were in the hardware and you had open source implementations of all the security protocols. As I said before: it's still security through obscurity because, as well hidden as it is, you've still got the key on the desk in front of you.
Trusted computing only makes it harder to obtain the keys. The basic principle is still the same. You've got the keys and the code, and together, you can break all the encryption on anything encrypted with them. All you need is a way of pulling the key out of the hardware and that's the ball game. Therefore, I stand by my assertion and extend it to say that even trusted computing is security through obscurity. It's just making one part of the process more obscure than most users can effectively deal with.
But I'm not sure what you're getting at with Kerberos. I know how it works, but I'm not sure what virtue it has to support the use case in question.
Sigh. I don't know why I bother answering such idiocy, but here goes.
That is so wrong it isn't even funny. Hell, that is Microsoft's main argument about Closed Source vs Open Source. "If you could see the code, you could hack anything! Nothing would be safe!"
Please learn to read. I didn't say that, and I doubt Microsoft has said that, either. Please don't put words in my mouth.
You have (or can have) the code for GnuPG, but does that mean you can break the data encrypted with it. And no, DRM isn't special in that way.
Of course DRM is special. For DRM to work, you need to provide both the keys and the code together. The code must have a way of getting those keys, and all that code is open source, so the key is available, too. I know subtlety isn't your strong point, but I believe my other clarification post spelled that out more clearly.
I have terminals at work on a production line that are basically document display units.
Good for you. You both contradict what you said earlier (your DRM doesn't work so you need other measures like physical security and signed binaries) and you wander into the irrelevant. Please point out the bit in the OP's question where he mentioned he wanted to neuter his platform so he could protect documents.
I should know better than to oversimplify on Slashdot.
Yes, you need both the code and the keys to break DRM*. At least one of the two must be hidden. The point is that, with open source, both must be given in plain view, so it doesn't work.
* Sometimes, you can even break it without the keys if the algorithm itself can be attacked.
DRM is security through obscurity. If you have the code, you can break any DRM, so there's no point in developing open source DRM. It's also why all DRM eventually fails.
Use encryption if you want safety. But you still can't prevent the people who have legitimate access from doing whatever they want to the documents.
Why, yes it is obvious (map::erase() invalidates all iterators in the map, as it should say right in the documentation for erase())
Nope. Erase on a map invalidates only the iterators pointing at the erased item. Such is true for all associative containers in C++. You're thinking about vectors.
I think part of your reply is meant to say that he had the way cleared in front of him. I knew that because, like you, I read the article and his comments. As another poster correctly points out (somewhere further down this page), if the bike wasn't supposed to move, and hence no helmet or other precautions were necessary, why did they clear the way? Furthermore, if the way was clear, why was there a minivan, presumably with an owner who, at some point, would want to leave, be directly in front of him?
It seems quite clear that the precautions taken to protect bystanders were as flimsy as the ones he took himself.
What does that even mean? Clearly, you need to re-read the GPL. The GPLv2 is *already* "dual licensed" (I put the term in quotes because it's nonsensical to talk about it as such) as GPLv3 by virtue of its "any future version" clause. Furthermore, GCC requires assignment of copyright to the FSF, so the FSF has full say over what the license is. Nothing additional is required of contributors.
I think you might want to consult with a lawyer about your own project's licenses, as well. It seems to me what you really want is to continue accepting contributions as GPLv2, but I can't actually make any sense out of what you are saying above.
That's probably why she doesn't have a home. She keeps giving away her music. Now that's perfectly fine if either (a) she doesn't mind living on the streets; or (b) she has many friends and family who will pay for her to live. But for everyone else who has to pay their own way, buy their own musical instruments, tour, and so on. The money is sorely needed.
She owns a home, which she sublets. Anyway, you've completely missed my point. Without people giving away the music, nobody ever finds out about the artist. The people who really don't like file sharers are the ones who are already established. The ones who are trying to build a fanbase ought to be embracing this new way of advertising. Unless they really don't think they are good enough to sell records when people know about them, of course. The main problem with file sharing is that the advertisement is also the final product. However, in the mainstream, it appears that this isn't actually harming music sales all that much, so maybe it's not a big problem, anyway. I certainly haven't seen you quoting any evidence that these artists have lost sales because of the sharing.
Your reading comprehension is wonderful. Let me try again. If you link against or include GPLed code, you have done something wrong if your application is not GPLed. But violating the copyright does not give the damaged party the right to relicense your code at its discretion, under the GPL or otherwise.
Think it through, please. If I distribute a story with the license that says that, "If you distribute this story, then I get one dollar for every word in the entire book that it appears in, I own the copyright of all your books, including the one my story appeared in, and I am entitled to have your first-born son as a slave." If someone were to steal my story, does that mean I'm entitled to all of the above? Of course not. The author who stole my story could do the above to meet the license, but odds are he wouldn't. If I sued him, there are two likely outcomes. One outcome is that I seek an injunction to stop him from distributing my story, and seek monetary damages. The other case is that the author pays me a sum of money that I consider reasonable to buy a license for the work.
Do you understand now? If not, I suggest you talk to a lawyer because I can't think of any simpler way to put it except to say that, when an injured party seeks relief for you violating a copyright, there are more options than you being forced to relicense your work under terms that are acceptable to the injured party, especially when you are TiVo.
Now why doesn't this surprise me. Slashdot isn't a discussion forum where people with differing opinions. Its a forum where boys can all agree with one another except when comparing OS-X/Linux/Windows or Macs and PCs.
So let me get this straight - you post a message that says the following:
You call the GPL viral without any substantiating evidence.
RMS is a "hippy".
The community is losing out because it can't benefit from your code.
You are losing out because you can't use the community's code.
Point one is obviously wrong, and I can understand why people treat your post with such contempt based on that alone, as it displays your complete ignorance of copyright law. The GPL applies only to code placed under it, and derived works of said code. If you integrate GPLed code into an application, your application is not automatically GPLed. If someone calls you on it, you have a choice. You can tear out the GPLed parts, or you can make the entire thing GPLed. Alternatively, you could come to some agreement with the copyright holder. These choices are the same as if you were caught violating any other copyright, except that normally, you don't have the choice of escaping unscathed by putting the entire app under the GPL. In other words, the GPL gives you more options if you are sued for violating it, not fewer. People like you obviously haven't grasped that concept, despite other people trying very hard to beat it into your heads. I don't know why I'm bothering to explain it now.
Point two is laughable. RMS may or may not be a hippy, but you calling him such doesn't lend anything to your credibility, especially when it has no bearing on the discussion. I guess you have little other factual information so you must degrade to ad-hominem attacks.
Point three displays quite a bit of presumption. The community doesn't need or want your code if it's code to implement DRM, so the community hasn't lost anything. And that's without even discussing whether your code is even worth the bits of storage it uses.
Point four is, perhaps, your only valid point. I have no sympathy for you, however. You know what kind of industry you are in and you've chosen to work there. You're no better than the media companies that want DRM. Unlike them, you can't even claim ignorance of the technology.
Finally, you post this latest drivel about how slashdot users are boys, which, in itself, is a piece of Slashdot groupthink. Therefore, you really can't claim any high ground there. You claim that you can strip DRM when you like, but it's against the law in the US, and, if you are in the US, you have just admitted to a crime. The US isn't the only country with laws like that. You say that there's nothing wrong with embedding personal information in a song so you can identify the person stealing the song. As you can probably guess, that's as ineffective as DRM. You say you are pissed whenever you see people sharing music from an artist that has a day job. I just spoke with an artist who doesn't have a home not five hours ago. I bought a copy of her CD. She almost begged me to copy it and send it as far and wide as I could. She ranted about DRM and iTunes. She'd probably find what you do despicable and think your anger severely misguided. Think about it for a little while. It might do you some good. At the very least, stop making a fool of yourself in such a public place.
Thanks for that. I shouldn't have concentrated on the compiler. What I really think we need is language-level constructs, but that's certainly not what I said.
I like the actor's model. It sounds like a formalization of message-passing, which (as I mentioned cross thread), is, in my opinion, the best multiprocessing model we have so far.
I think this analogy is a bit disingenuous. First, OOP isn't all that complicated, and I did acknowledge that better tools that hide the complexity will help things. The other thin you have to consider is that OOP and threading are meant to achieve two separate goals. OOP is meant to simplify design whereas threading is meant to increase performance, often at the expense of simplicity. Threading is fundamentally harder than OOP because it's harder to think about, and it only matters if you need performance. OOP is a good idea to make a good design. That is always important. Threading, as it exists today, is actually at odds with correctness as it is much harder to guarantee correctness in the presence of threading. As correctness trumps performance any day ("I can make any program run instantly if it doesn't need to produce a correct result"), threading should be used sparingly. Oftentimes, you can make better performing apps by concentrating on other things, anyway.
Anyway, I don't know why I'm writing so much. I could have just substituted "brainfuck" in place of OOP and shown that, just by substituting a word, you haven't proven anything. Just because it was a good idea to use OOP doesn't make it a good idea to use threading.
BTW, where do you get your information about Google employees having paid research time? Google employees have 20% time, certainly, but that isn't "paid research time".
The time slice of an app stays the same, so you have just as many context switches on a single- or a multi-core CPU, assuming you have more tasks than CPUs. Furthermore, performance does not scale by the number of cores you have. You have locking contention, which means that you end up being serialized for at least part of the time. In almost all cases, you're better off with one fast core than two slow ones.
Actually, it was a single benchmark running with a new technology that had nothing to do with the overclocking that produced the 2x speedup. Most likely, the benchmark they used was atypical and, furthermore, has nothing to do with the overclocking bit.
We've had it for decades - Just look for multiprocessor support, and you have implicit multithreaded support automatically.
Well, yes and no. I think the easiest model for multithreading today is message passing, but it doesn't suit all needs and requires you to design your app to support it from the start. Most mainstream languages (read C/C++, Java, and.NET) don't really support much beyond your basic mutex, semaphore, and monitor. There are a few other things out there that provide various ways of doing things, but none are universal and none seem to have really caught on.
What we really need is either a language that can express things in such a way that the compiler can easily make good decisions about what can be parallelized, or a compiler that can do that with existing languages. I think that the latter approach may prove impossible. To make informed decisions about threading, a compiler really needs to know things about the data, and most procedural languages just don't cope with that very well.
It seems that HPF may provide some of these things already. I did a few quick Google searches and it seems interesting, but I wonder how much better it is than current work that is being done on auto-vectorization of loops and such in modern compilers. I'll have to look into that language more closely before I can really draw any conclusions. I believe that IBM has been trying to do some interesting work in this area with the Cell processor, too, and I suspect that's why Sony makes interesting statements about how the true power of the Cell will never be fully realized.
Regardless, the next decade is going to be an interesting one for compiler writers, I suspect.
Slashdot Mirror
Sounds like any other religion to me, except most religions do this from childhood, so you don't see it being done to adults.
Pick any theocracy. Any at all.
Jesus, Muhammad, etc.
Tithing, anyone? That covers the funds bit. Recruiting people, well, I covered that. Child abuse (not the Catholic sexual kind) is definitely up there with lying and harrassment.
Nope. The money goes to further indoctrination and defending itself from sexual abuse scandals. Though, occasionally, a school does get built. Maybe that's the difference. Religions do occasionally spend money on humanitarian things, though usually with strings attached. You're gay? No school for you. AIDS problems? We'll help, but we won't touch those dirty condoms.
I thought the point of faith was that it was believed in spite of or in lack of evidence, and thus required no defense. Obviously, there are no proofs one way or the other, so I fail to see how one might defend a faith other than repetition. The fact that we have no way to know which faith, if any, is the correct one is enough for me to reject the whole matter as completely hopeless.
People who kill people do so for a variety of reasons. Some do it out of religion. Others do it out of greed for power.Some do it because it is the rational thing to do, such as in self defense. or euthenasia. The point is that most people believe that killing people is bad for whatever reason, and this belief needs to be overcome. Religion perverts reason and is one way in which it can be overcome. Not all evil will be gone from the world when religion is seen as what it is - the rejection of reason - but we will have eliminated one major cause of grief and suffering in the world.
But you are right on one count - you can't decree a ban on religion. People should be free to believe what they will, however misguided. But worse than that, it will not work. Nothing strengthens religion more than persecution. The only way we will ever be free of religion is through enlightenment, not edict.
You clearly aren't reading what I've said.
Nowhere did I call Kerberos security through obscurity. It's a form of security based off of shared secrets and key exchange and follows generally accepted cryptographic principles. But if you think that Kerberos can be used to prevent me from doing things with the files I just downloaded off of the kerberized NFS server I'm using right now, you're sadly mistaken.
Which, again, is the key point. Trusted computing tries to limit what I can do with a computer. But if I have the keys and I know the protocols and algorithms, I can circumvent it. It's that simple. The only thing that trusted computing brings to the table is that it makes getting those keys harder. If I can get the key, I can request a shiny, temporary authorization key from whatever server I like and it has no way to know that I'm not the locked down program it's known so well for so long. It will happily grant me that ticket and then I can have modified software that strips all that cute little encryption so I don't have to do this every time.
Assuming I don't live in the US, anyway.
Why should I look into both? Let me say it more clearly: I already know how both work.
Try reading what I said in my last message again and reflect on what you could do if you had the keys that were in the hardware and you had open source implementations of all the security protocols. As I said before: it's still security through obscurity because, as well hidden as it is, you've still got the key on the desk in front of you.
Trusted computing only makes it harder to obtain the keys. The basic principle is still the same. You've got the keys and the code, and together, you can break all the encryption on anything encrypted with them. All you need is a way of pulling the key out of the hardware and that's the ball game. Therefore, I stand by my assertion and extend it to say that even trusted computing is security through obscurity. It's just making one part of the process more obscure than most users can effectively deal with.
But I'm not sure what you're getting at with Kerberos. I know how it works, but I'm not sure what virtue it has to support the use case in question.
Please learn to read. I didn't say that, and I doubt Microsoft has said that, either. Please don't put words in my mouth.
Of course DRM is special. For DRM to work, you need to provide both the keys and the code together. The code must have a way of getting those keys, and all that code is open source, so the key is available, too. I know subtlety isn't your strong point, but I believe my other clarification post spelled that out more clearly.
Good for you. You both contradict what you said earlier (your DRM doesn't work so you need other measures like physical security and signed binaries) and you wander into the irrelevant. Please point out the bit in the OP's question where he mentioned he wanted to neuter his platform so he could protect documents.
I should know better than to oversimplify on Slashdot.
Yes, you need both the code and the keys to break DRM*. At least one of the two must be hidden. The point is that, with open source, both must be given in plain view, so it doesn't work.
* Sometimes, you can even break it without the keys if the algorithm itself can be attacked.
DRM is security through obscurity. If you have the code, you can break any DRM, so there's no point in developing open source DRM. It's also why all DRM eventually fails.
Use encryption if you want safety. But you still can't prevent the people who have legitimate access from doing whatever they want to the documents.
And what's a SIGSEGV if it's not an auto-null check? ;-)
Nope. Erase on a map invalidates only the iterators pointing at the erased item. Such is true for all associative containers in C++. You're thinking about vectors.
I think part of your reply is meant to say that he had the way cleared in front of him. I knew that because, like you, I read the article and his comments. As another poster correctly points out (somewhere further down this page), if the bike wasn't supposed to move, and hence no helmet or other precautions were necessary, why did they clear the way? Furthermore, if the way was clear, why was there a minivan, presumably with an owner who, at some point, would want to leave, be directly in front of him?
It seems quite clear that the precautions taken to protect bystanders were as flimsy as the ones he took himself.
Can we all just agree that he's a dick, and then everyone else can argue about why he's qualified later?
And what about the people walking across the parking lot? Or the owner of that minivan?
Given:
I was thinking the same thing. We need another acronym. I vote for POO - Presumption, Overconfidence, and Overzealousness.
What does that even mean? Clearly, you need to re-read the GPL. The GPLv2 is *already* "dual licensed" (I put the term in quotes because it's nonsensical to talk about it as such) as GPLv3 by virtue of its "any future version" clause. Furthermore, GCC requires assignment of copyright to the FSF, so the FSF has full say over what the license is. Nothing additional is required of contributors.
I think you might want to consult with a lawyer about your own project's licenses, as well. It seems to me what you really want is to continue accepting contributions as GPLv2, but I can't actually make any sense out of what you are saying above.
She owns a home, which she sublets. Anyway, you've completely missed my point. Without people giving away the music, nobody ever finds out about the artist. The people who really don't like file sharers are the ones who are already established. The ones who are trying to build a fanbase ought to be embracing this new way of advertising. Unless they really don't think they are good enough to sell records when people know about them, of course. The main problem with file sharing is that the advertisement is also the final product. However, in the mainstream, it appears that this isn't actually harming music sales all that much, so maybe it's not a big problem, anyway. I certainly haven't seen you quoting any evidence that these artists have lost sales because of the sharing.
Your reading comprehension is wonderful. Let me try again. If you link against or include GPLed code, you have done something wrong if your application is not GPLed. But violating the copyright does not give the damaged party the right to relicense your code at its discretion, under the GPL or otherwise.
Think it through, please. If I distribute a story with the license that says that, "If you distribute this story, then I get one dollar for every word in the entire book that it appears in, I own the copyright of all your books, including the one my story appeared in, and I am entitled to have your first-born son as a slave." If someone were to steal my story, does that mean I'm entitled to all of the above? Of course not. The author who stole my story could do the above to meet the license, but odds are he wouldn't. If I sued him, there are two likely outcomes. One outcome is that I seek an injunction to stop him from distributing my story, and seek monetary damages. The other case is that the author pays me a sum of money that I consider reasonable to buy a license for the work.
Do you understand now? If not, I suggest you talk to a lawyer because I can't think of any simpler way to put it except to say that, when an injured party seeks relief for you violating a copyright, there are more options than you being forced to relicense your work under terms that are acceptable to the injured party, especially when you are TiVo.
So let me get this straight - you post a message that says the following:
Point one is obviously wrong, and I can understand why people treat your post with such contempt based on that alone, as it displays your complete ignorance of copyright law. The GPL applies only to code placed under it, and derived works of said code. If you integrate GPLed code into an application, your application is not automatically GPLed. If someone calls you on it, you have a choice. You can tear out the GPLed parts, or you can make the entire thing GPLed. Alternatively, you could come to some agreement with the copyright holder. These choices are the same as if you were caught violating any other copyright, except that normally, you don't have the choice of escaping unscathed by putting the entire app under the GPL. In other words, the GPL gives you more options if you are sued for violating it, not fewer. People like you obviously haven't grasped that concept, despite other people trying very hard to beat it into your heads. I don't know why I'm bothering to explain it now.
Point two is laughable. RMS may or may not be a hippy, but you calling him such doesn't lend anything to your credibility, especially when it has no bearing on the discussion. I guess you have little other factual information so you must degrade to ad-hominem attacks.
Point three displays quite a bit of presumption. The community doesn't need or want your code if it's code to implement DRM, so the community hasn't lost anything. And that's without even discussing whether your code is even worth the bits of storage it uses.
Point four is, perhaps, your only valid point. I have no sympathy for you, however. You know what kind of industry you are in and you've chosen to work there. You're no better than the media companies that want DRM. Unlike them, you can't even claim ignorance of the technology.
Finally, you post this latest drivel about how slashdot users are boys, which, in itself, is a piece of Slashdot groupthink. Therefore, you really can't claim any high ground there. You claim that you can strip DRM when you like, but it's against the law in the US, and, if you are in the US, you have just admitted to a crime. The US isn't the only country with laws like that. You say that there's nothing wrong with embedding personal information in a song so you can identify the person stealing the song. As you can probably guess, that's as ineffective as DRM. You say you are pissed whenever you see people sharing music from an artist that has a day job. I just spoke with an artist who doesn't have a home not five hours ago. I bought a copy of her CD. She almost begged me to copy it and send it as far and wide as I could. She ranted about DRM and iTunes. She'd probably find what you do despicable and think your anger severely misguided. Think about it for a little while. It might do you some good. At the very least, stop making a fool of yourself in such a public place.
Thanks for that. I shouldn't have concentrated on the compiler. What I really think we need is language-level constructs, but that's certainly not what I said.
I like the actor's model. It sounds like a formalization of message-passing, which (as I mentioned cross thread), is, in my opinion, the best multiprocessing model we have so far.
I think this analogy is a bit disingenuous. First, OOP isn't all that complicated, and I did acknowledge that better tools that hide the complexity will help things. The other thin you have to consider is that OOP and threading are meant to achieve two separate goals. OOP is meant to simplify design whereas threading is meant to increase performance, often at the expense of simplicity. Threading is fundamentally harder than OOP because it's harder to think about, and it only matters if you need performance. OOP is a good idea to make a good design. That is always important. Threading, as it exists today, is actually at odds with correctness as it is much harder to guarantee correctness in the presence of threading. As correctness trumps performance any day ("I can make any program run instantly if it doesn't need to produce a correct result"), threading should be used sparingly. Oftentimes, you can make better performing apps by concentrating on other things, anyway.
Anyway, I don't know why I'm writing so much. I could have just substituted "brainfuck" in place of OOP and shown that, just by substituting a word, you haven't proven anything. Just because it was a good idea to use OOP doesn't make it a good idea to use threading.
BTW, where do you get your information about Google employees having paid research time? Google employees have 20% time, certainly, but that isn't "paid research time".
Er, not quite.
The time slice of an app stays the same, so you have just as many context switches on a single- or a multi-core CPU, assuming you have more tasks than CPUs. Furthermore, performance does not scale by the number of cores you have. You have locking contention, which means that you end up being serialized for at least part of the time. In almost all cases, you're better off with one fast core than two slow ones.
Actually, it was a single benchmark running with a new technology that had nothing to do with the overclocking that produced the 2x speedup. Most likely, the benchmark they used was atypical and, furthermore, has nothing to do with the overclocking bit.
Well, yes and no. I think the easiest model for multithreading today is message passing, but it doesn't suit all needs and requires you to design your app to support it from the start. Most mainstream languages (read C/C++, Java, and .NET) don't really support much beyond your basic mutex, semaphore, and monitor. There are a few other things out there that provide various ways of doing things, but none are universal and none seem to have really caught on.
What we really need is either a language that can express things in such a way that the compiler can easily make good decisions about what can be parallelized, or a compiler that can do that with existing languages. I think that the latter approach may prove impossible. To make informed decisions about threading, a compiler really needs to know things about the data, and most procedural languages just don't cope with that very well.
It seems that HPF may provide some of these things already. I did a few quick Google searches and it seems interesting, but I wonder how much better it is than current work that is being done on auto-vectorization of loops and such in modern compilers. I'll have to look into that language more closely before I can really draw any conclusions. I believe that IBM has been trying to do some interesting work in this area with the Cell processor, too, and I suspect that's why Sony makes interesting statements about how the true power of the Cell will never be fully realized.
Regardless, the next decade is going to be an interesting one for compiler writers, I suspect.