I was trying to say that the Boost documentation is such that you are best served by thoroughly reading the entire documentation on a library before using it.
Theoretically, you are correct. But there is no time to read everything, especially when under pressure to finish a project on time.
assuming the GC system/language you're using has such a distinction and EVERYTHING isn't like a heap allocation
I am talking specifically about C++, which has most values allocated in the stack. That's the reason C++ produces the fastest code anyway.
All RAII means is that the resource is allocated when the object encapsulating it is created, and deallocated when that object is destroyed. You can have RAII in a GC environment too, but the problem is it's non-deterministic (you don't generally know when it will actually happen).
Your definition of RAII is wider than mine. I was talking specifically about stack-based RAII. The one great thing in C++, and the reason I don't give up on it, it's that destructors are called at procedure exit. That's so great! it helps with a lot of problems. I solely miss this in Java, where I usually have to declare the same code inside finally clauses and outside of finally clauses.
I guess my question is, how do you go about achieving determinstic object destruction in a GC environment, which is what's required for RAII to be effective with non-trivial destructors? As far as I'm aware, you don't, and that's one of the drawbacks.
Of course, you're right. But the question is moot with stack-based RAII.
It's an overhead that adds up if you are passing around thousands of smart pointers, not just leaving them in collections.
Smart pointers are not for collections only. I am surprised that almost everyone has such a narrow scope, as if no one has ever made a complex program.
For example, in my current project, I have to create hundreds of objects per second (radar plots). Each plot is not a simple POD object: there is a hierarchy of classes, each plot having its own attributes, and some plots are associated with other plots. The associations are done via pointers. The plots are fed to a series of complex processes, different threads, that do different things on the objects (for example, checking for collisions, providing alarms after specific events, interfacing with external systems (Link 11, Link 16, AWACS etc).
It goes without saying that:
it was not possible to treat these objects as values. Some objects are huge, in the range of kilobytes (you can't believe how much data a radar can produce).
All associations are done with smart pointers. The object model is very complex, and I not that sure that there are not cyclic references in there.
The overhead of managing reference counts atomically is measurable. A single frame of data is captured and processed at almost half the time when using raw pointers (and no deletes!) compared to using smart pointers. The overhead also includes the cost of allocation/deallocation. If I had a good threaded garbage collector, allocation would be almost for free (because GC allocators usually increment a pointer), and deallocation would be almost free if the CPU has more than one core (because the garbage data can be processed by a separate thread running on a different CPU). No such lack with smart pointers.
Additionally, many of your arguments assume that the pointer is being used in a multi-threaded environment, AND that there is no guarantee of any kind of thread locality. Otherwise atomic operations would simply be unnecessary.
I have never coded an application with less than two threads. Even for my personal projects, I put long jobs in different threads, so as that the GUI is not blocked. My current application may have up to 30
Yeah, it's definitely buried in the documentation, but it is there. The link I gave you was direct to the boost docs. Unfortunately a lot of the stuff is like that, and I'd really recommend going through the documentation for any boost lib thoroughly before using it. It helps a LOT.
It's not possible to search for something when you don't know it exists.
For complex resources, however, my complaint against GC is that it introduces the overhead of having a collection process running in the background (or at various intervals or whatever)
The overhead from GC is negligible. I am also a Java programmer, and Java is way faster than C++ in the same algorithm (with C++ using smart pointers). I've done a little research regarding the use of Boehm's gc, and in that context, I measured various things using Boehm's benchmark (if you search the relevant newsgroup, you'll find it).
but without any usability benefits over just using new/delete. I still have the burden of having to release them manually, and the potential errors of forgetting to do so.
But you don't have to release them manually! I've said it twice before: you use RAII for files, sockets etc, and GC for anything else. It's simple, it works, and it covers most cases.
As for atomic increments/decrements, those tend to be fairly fast, as (correct me if I'm wrong) most modern processors provide machine level commands for those sorts of atomic operations without having to resort to locks/mutexes
At the lowest level, caches are locked and synchronized and the other cores enter a spin loop. It's an overhead that, if you don't use many smart pointers, it's negligible, but when you use thousands of them in arrays or collections, it starts to show, especially when measured against GC.
In modern collectors, the overhead is way way way less than smart pointers, especially for those collectors that use the underlying hardware (the page mechanism) to tell when something has changed. Modern collectors are also multithreaded: they split the workload into equal parts, thus getting an almost linear scaling with the number of cores. Whereas with smart pointers, if two cores look at the same memory location, an atomic operation will lock the caches and stall both CPUs.
The nice thing about boost signals though is you can pass ANY functor (functions, member functions, function objects) through them
It goes without saying that function binding and lambda functions is THE most important feature of any programming language. I like boost for this, and I think it should be in the STL, but my comment was about how integrating boost with other libs may not be as easy as it sounds. Or any other two c++ libs, for that matter. You see, in C++, every toolkit/library/framework is its own universe.
Regarding your other post, while I'm not 100% sure what you're getting at, if it is what I think it is, then you are actually incorrect. See here. I can certainly understand being averse to Boost's smart pointer implementation if you weren't aware of this functionality.
Indeed, I was not aware of it. But the docs don't have it. Where I was supposed to find it? I went on and did my own implementation, complete with a SharedObject base class that does just this.
But then you're more or less defeating the entire point of garbage collection, which is not having to worry about manually releasing any resources when they go out of scope.
That's not the point of GC. The point of GC is to have complex object relationships, i.e. to manage memory, without worrying too much about how the memory is freed.
Once you start requiring that resources be manually deallocated before being let out of scope, you've just lost any real benefit
of using a GC model in the first place.
Nope, you use RAII for that. You use RAII to manage resources deterministically, except for memory.
Sure GC *can* work with non-trivial destructors, but in doing so you lose the real benefits you've gotten from GC in the first place, which is why I claim that smart pointers are actually much more suited to such a situation because they retain that same benefit.
No, you don't lose anything. With GC, you can do things like circular references and stuff without having to think about them. And a whole bunch of other stuff smart pointers can't do. And then there is the problem of performance: all those increments and decrements that are also atomic put a serious constraint in performance.
I do concede that cyclic references are the weakest aspect of smart pointers, and do require a little more work in the design of your software to avoid them. I will admit though, if you have a situation where cyclic references are legion, then GC might be a superior choice. With limited cyclic references, however, weak smart pointers are a perfectly elegant solution. It's usually obvious from a design perspective which pointers should be made weak.
Ok, smart pointers are not that bad. In my current project, around 50,000 lines of code, I don't have any deletes. But I had to be really careful not to introduce any cyclic references. And the performance is not what it could have been. There are lost CPU cycles in atomic increments and decrements. And the code is on the ugly side...
No, auto_ptr is bad because of move semantics, not because of lack of rvalues.
RValues are bad because they will encourage people to write move constructors, thus making it difficult to tell who owns the data.
My point about swap is that rvalues are not required for it.
Regarding the templates, 99% of the time the problem is at the point of instantiation, not inside the template. The priority should have been the point of instantiation: the first line should show the point of instantiation, and the last line the actual template.
GC will never come in C++, let's not fool ourselves.
Boost is actually very easy to integrate for most of its features. A few (small handful) of its components require compilation, but the vast majority of them are template-based and header only. Meaning just include a header file and there you go, you're using boost. No extra compilation/installation required.
That is, until you try to combine it with other libraries, like Qt, for example. Boost has a namespace signals, Qt has a #define signals. Yes, you can solve the problem using the preprocessor, but boost was supposed to be 'plug-n-play'...
I have trouble imagining a situation where a real garbage collector would ever be superior to an RAII model with shared smart pointers for stuff allocated on the heap, outside of plugging up a leaking legacy app.
Smart pointers are difficult to manage in the context of complex object relationships. See my other post for more info.
Maybe for very simple programs, but once you get non-trivial destructors (for example, with objects that lock system resources), then you start having to do manual memory management in your GC environment anyway, and end up with a horribly ugly conglomeration of "mixed metaphors" as it were.
The idea that destructors don't play well with GC is largely a myth. Non-trivial jobs should not be done in destructors. But even if they are done in destructors, they should be invoked using RAII style. The destructor is only a function, so it can be called normally just like any other C++ function.
Smart pointers really give you the best of both worlds: deterministic destruction, without having to worry about manually releasing anything. It's just a matter of getting used to declaring a smart pointer wherever you would have a "type *name" instead. So yes, I'd argue they ARE a substitute for garbage collection in almost any situation.
As I explain in my other post, the problems of cyclic references introduced indirectly, the situation where you only have 'this' and you should use shared_ptrs, etc are great problems and you should not underestimate them.
...header files. Having to manually synchronize header and implementation files each time the design changes is a major pain the butt. It takes away valuable time and greatly distracts from the mental process that is design of a program.
And you surely don't seem like a person who's had to code a complex C++ app in mimimum time, then.
C/C++'s memory/pointer-related problems are due to careless/clueless programmers, not due to the language itself.
The language does everything to undermine the programmer in this respect. It's not helpful at all. Of course, all errors are human errors, but there is a limit at which programming languages are not longer convenient.
You clearly fail to understand the language, yet pretend to answer with authority.
If you were ever called to program a complex project in C++ (complex in the sense of complex relationships between objects), you will see that there is a lot of merit to what the guy said.
Do you use (or even know) the RAII idiom?
RAII is tremendously good in dealing with resources other than memory. Complex object relationships are difficult to manage with RAII.
that smart pointers have been there for years?
No, they haven't. They are not yet part of the standard; smart pointers will be available in the next standard revision. Which means that in order to make a source-level cross platform app for all major compilers, all major compilers should provide those smart pointers.
Smart pointers also have great technical challenges hidden in them. I will explain below.
Yes, I mean auto_ptr
Auto_ptr is a complete disaster, because it requires the programmer to track who's got the ownership of the resource, which is a highly difficult job, the difficulty of rises exponentially with each additional statement.
and shared_ptr.
Some technical problems that one should be aware of when using smart pointers:
you should never pass 'this' to a shared_ptr. Your object will be deleted.
the above is a big issue, because it forces a style of programming that is not object-oriented: for every job that a shared_ptr is required, it must be done outside of an object by another object. This complicates programming a lot.
If you forgot that you have a shared_ptr somewhere and then you instantiate another shared_ptr from a raw ptr, then there will be two reference counts for this object, the object will be deleted when the second shared_ptr goes out of scope, leaving the first shared_ptr with dangling references.
it's very easy to introduce a memory leak, using shared_ptrs (i.e. circular dependencies), especially through sub-classing: a base class might not have a circle, but a derived class might do so. And it's a very difficult problem to track.
How about the Boost library (which is being included partly in C++0x).
Yesterday I had to code my own smart pointer classes: a shared_ptr class used for lifetime management, a weak_ptr class for using weak references, and a strong_ptr class for using weak_ptrs. Boost's design is wrong: you shouldn't have to instantiate a shared_ptr in order to use a weak_ptr, because in some cases the object is not shared yet (for example, when constructing an object). The best solution is to use a strong_ptr to pin down the object that a weak_ptr contains.
Garbage Collectors are non-deterministic by nature; Therefore, they are a real no-no for real projects (think real-time systems or massive number crunching, where memory pools are common)
Garbage collection is not a panacea, but it's certainly way more useful than the set of auto_ptr, shared_ptr, weak_ptr and intrusive_ptr that boost or C++ proposes. And there is nothing that does not allow you from using memory pools and garbage collection.
Not how to spawn threads and create mutexes, but lower-level issues, like coherency.
Programmers need those though.
Rvalue references will help a lot with the creation of temporaries that are just copied and destroyed.
RValues is a disaster waiting to happen. Move semantics is wrong, as the auto_ptr fiasco proved.
You see this now in all the specializations in the libraries for the swap function.
It's silly, swapping aggregates should be pointer swaps, not value swaps.
Currently template error messages are a mess. several lines of unreadable garbage because your type doesn't supply a member or operator that the template needs. Concepts will lead to concise, easy to understand error messages.
That's because the compiler writers did not make a good effort to make error messages comprehensible. If the error message started from the line of template instantiation, instead of the template code, there would not be such a problem.
Lambdas and closures will simplify using the STL algorithms without having to create a lot of functors.
But the lambda function syntax is silly. Using [] to declare a lambda? it's silly. Having to declare which outer variables should be in the closure? double silly.
They forgot the most important thing: garbage collection...
I work for a small software house that also sells PC hardware. Most of our clients (around 90%) prefer XP to Vista, even if they have to pay a little more for an XP license.
The computers in our network are all XP machines. There are only two boxes with Vista, one is used by the CEO in his office (most probably to impress clients) and the other one is used by our quality manager in order to test things for those clients that want the latest and greatest.
Do you consider Hitler's Germany equal to Saddam's Iraq or Afghanistan? Germany was a serious threat to global freedom, and after Europe and Russia had been conquered, it was America that would have been the next target of the German boot. On the other hand, Saddam was much less powerful than Hitler, and Iraq could not invade and conquer any other country except its most weak neighbors.
The reasons Iraq was invaded are totally different from the reasons Germany was invaded. Back in World War II, America was the true land of the free, home of the brave. It represented freedom in a grand scale. And it's this freedom ideology that pushed the common folk to fight in World War II with such dedication. On the other hand, America now has an army of professionals who don't care about their missions, as long as the army puts food on their table (well, most of them), and the presence of American army in Iraq is part of the new geopolitical strategy of the US for the 21st century.
Under this light, from your post, it seems you are a little bit brainwashed (you might not be at all, it's just seems that way), and I am surprised you were modded 5, insightful.
No one dares to write a new language like C++
on
Boost 1.36 Released
·
· Score: 0
Even the gurus (Stroustrup etc) don't dare think about a new language.
I tried to use boost.bimap and my compilations got x10 slower. I then wrote my own bimap, with simpler interfaces of course, and compilation times got back to normal.
One of the biggest problems in C++ is header files. I am surprised they do nothing for this. The slowness of compilation of boost programs comes from parsing and compiling the huge amount of code that lives in the header files.
I don't understand why everybody says Doom 3 was a 'demo'. It was not. It was an awesome game. Highly entertaining, as it kept the player on the edge with different events, an awesome atmosphere, amazing environments, high adrenaline etc.
The word "will" implies a process of logical thinking leading to a decision. Free will exists both in predictable and unpredictable cases: the subject of free will makes an effort to decide which route to take, so from his/her/its point of view he/she/it has free will. But the result choice could be predictable or not predictable, and that's irrelevant to free will.
Politicians will exploit every opportunity there is to create and sell more guns through their industrial and military connections. That's all there is to it regarding this so called 'terrorism'.
The problem with kernel modules is that they are not isolated from the rest of the system, because the CPU design does not provide a mechanism for such a type of isolation, forcing O/S designers to revert to schemes like a microkernel, where each module is a separate process. CPU designers are to blame, not software designers.
The 8086 set the PC technology back 15 years
on
Origins of the Modern PC
·
· Score: 2, Interesting
The 8086 set the PC technology back 15 years, at least. At 1985, the Amiga could do hi-res multicolor bitmap displays, preemptive multitasking, hardware-accelerated graphics and sound, DMA, auto-configurable peripherals (through Zorro slots), 32-bit programming (although the addressing was 24 bit) without the curse of far pointers, and many other goodies that came much later in the PC world.
The PC technology was largely retarded: stupid BIOS, stupid VGA register layout, stupid memory addressing, stupid interrupt controller, stupid DMA...all these things were very hard to program. But it dominated the world, because of compatibility...
How can we reach mr Lucas to tell him that the fate of Atlantis is THE scenario for the next Indiana Jones? If we mass-mail him, he will start thinking about it seriously.
I don't think Firefox/Safari/Opera are not affected. The exploit is not browser specific: it relies on the Win32 function LoadAniIcon, which has a bug that can be exploited...this function can be invoked by any browser, from example, from within a Java applet.
All exploits are based on a bug in the function LoadAniIcon.
What they do goes roughly like this:
1) put the code to execute in a string that is repeated in memory (to increase the chances of the code being called). 2) exploit the bug in LoadAniIcon to execute the code in the string.
Slashdot Mirror
Why not put the players in the world, give them tools and let them make quests of their own?
So Joe Pesci is not God after all?
Theoretically, you are correct. But there is no time to read everything, especially when under pressure to finish a project on time.
I am talking specifically about C++, which has most values allocated in the stack. That's the reason C++ produces the fastest code anyway.
Your definition of RAII is wider than mine. I was talking specifically about stack-based RAII. The one great thing in C++, and the reason I don't give up on it, it's that destructors are called at procedure exit. That's so great! it helps with a lot of problems. I solely miss this in Java, where I usually have to declare the same code inside finally clauses and outside of finally clauses.
Of course, you're right. But the question is moot with stack-based RAII.
Smart pointers are not for collections only. I am surprised that almost everyone has such a narrow scope, as if no one has ever made a complex program.
For example, in my current project, I have to create hundreds of objects per second (radar plots). Each plot is not a simple POD object: there is a hierarchy of classes, each plot having its own attributes, and some plots are associated with other plots. The associations are done via pointers. The plots are fed to a series of complex processes, different threads, that do different things on the objects (for example, checking for collisions, providing alarms after specific events, interfacing with external systems (Link 11, Link 16, AWACS etc).
It goes without saying that:
I have never coded an application with less than two threads. Even for my personal projects, I put long jobs in different threads, so as that the GUI is not blocked. My current application may have up to 30
"You can't buy or sell without the mark"...coming to a chipping office near you.
Big war involving East attacking the west? you bet.
It's not possible to search for something when you don't know it exists.
The overhead from GC is negligible. I am also a Java programmer, and Java is way faster than C++ in the same algorithm (with C++ using smart pointers). I've done a little research regarding the use of Boehm's gc, and in that context, I measured various things using Boehm's benchmark (if you search the relevant newsgroup, you'll find it).
But you don't have to release them manually! I've said it twice before: you use RAII for files, sockets etc, and GC for anything else. It's simple, it works, and it covers most cases.
At the lowest level, caches are locked and synchronized and the other cores enter a spin loop. It's an overhead that, if you don't use many smart pointers, it's negligible, but when you use thousands of them in arrays or collections, it starts to show, especially when measured against GC. In modern collectors, the overhead is way way way less than smart pointers, especially for those collectors that use the underlying hardware (the page mechanism) to tell when something has changed. Modern collectors are also multithreaded: they split the workload into equal parts, thus getting an almost linear scaling with the number of cores. Whereas with smart pointers, if two cores look at the same memory location, an atomic operation will lock the caches and stall both CPUs.
It goes without saying that function binding and lambda functions is THE most important feature of any programming language. I like boost for this, and I think it should be in the STL, but my comment was about how integrating boost with other libs may not be as easy as it sounds. Or any other two c++ libs, for that matter. You see, in C++, every toolkit/library/framework is its own universe.
Indeed, I was not aware of it. But the docs don't have it. Where I was supposed to find it? I went on and did my own implementation, complete with a SharedObject base class that does just this.
That's not the point of GC. The point of GC is to have complex object relationships, i.e. to manage memory, without worrying too much about how the memory is freed.
Nope, you use RAII for that. You use RAII to manage resources deterministically, except for memory.
No, you don't lose anything. With GC, you can do things like circular references and stuff without having to think about them. And a whole bunch of other stuff smart pointers can't do. And then there is the problem of performance: all those increments and decrements that are also atomic put a serious constraint in performance.
Ok, smart pointers are not that bad. In my current project, around 50,000 lines of code, I don't have any deletes. But I had to be really careful not to introduce any cyclic references. And the performance is not what it could have been. There are lost CPU cycles in atomic increments and decrements. And the code is on the ugly side...
It was not personal...header files is a big headache for any serious program.
No, auto_ptr is bad because of move semantics, not because of lack of rvalues.
RValues are bad because they will encourage people to write move constructors, thus making it difficult to tell who owns the data.
My point about swap is that rvalues are not required for it.
Regarding the templates, 99% of the time the problem is at the point of instantiation, not inside the template. The priority should have been the point of instantiation: the first line should show the point of instantiation, and the last line the actual template.
GC will never come in C++, let's not fool ourselves.
That is, until you try to combine it with other libraries, like Qt, for example. Boost has a namespace signals, Qt has a #define signals. Yes, you can solve the problem using the preprocessor, but boost was supposed to be 'plug-n-play'...
Smart pointers are difficult to manage in the context of complex object relationships. See my other post for more info.
The idea that destructors don't play well with GC is largely a myth. Non-trivial jobs should not be done in destructors. But even if they are done in destructors, they should be invoked using RAII style. The destructor is only a function, so it can be called normally just like any other C++ function.
As I explain in my other post, the problems of cyclic references introduced indirectly, the situation where you only have 'this' and you should use shared_ptrs, etc are great problems and you should not underestimate them.
...header files. Having to manually synchronize header and implementation files each time the design changes is a major pain the butt. It takes away valuable time and greatly distracts from the mental process that is design of a program.
And you surely don't seem like a person who's had to code a complex C++ app in mimimum time, then.
The language does everything to undermine the programmer in this respect. It's not helpful at all. Of course, all errors are human errors, but there is a limit at which programming languages are not longer convenient.
If you were ever called to program a complex project in C++ (complex in the sense of complex relationships between objects), you will see that there is a lot of merit to what the guy said.
RAII is tremendously good in dealing with resources other than memory. Complex object relationships are difficult to manage with RAII.
No, they haven't. They are not yet part of the standard; smart pointers will be available in the next standard revision. Which means that in order to make a source-level cross platform app for all major compilers, all major compilers should provide those smart pointers.
Smart pointers also have great technical challenges hidden in them. I will explain below.
Auto_ptr is a complete disaster, because it requires the programmer to track who's got the ownership of the resource, which is a highly difficult job, the difficulty of rises exponentially with each additional statement.
Some technical problems that one should be aware of when using smart pointers:
Yesterday I had to code my own smart pointer classes: a shared_ptr class used for lifetime management, a weak_ptr class for using weak references, and a strong_ptr class for using weak_ptrs. Boost's design is wrong: you shouldn't have to instantiate a shared_ptr in order to use a weak_ptr, because in some cases the object is not shared yet (for example, when constructing an object). The best solution is to use a strong_ptr to pin down the object that a weak_ptr contains.
Garbage collection is not a panacea, but it's certainly way more useful than the set of auto_ptr, shared_ptr, weak_ptr and intrusive_ptr that boost or C++ proposes. And there is nothing that does not allow you from using memory pools and garbage collection.
Programmers need those though.
RValues is a disaster waiting to happen. Move semantics is wrong, as the auto_ptr fiasco proved.
It's silly, swapping aggregates should be pointer swaps, not value swaps.
That's because the compiler writers did not make a good effort to make error messages comprehensible. If the error message started from the line of template instantiation, instead of the template code, there would not be such a problem.
But the lambda function syntax is silly. Using [] to declare a lambda? it's silly. Having to declare which outer variables should be in the closure? double silly.
They forgot the most important thing: garbage collection...
I work for a small software house that also sells PC hardware. Most of our clients (around 90%) prefer XP to Vista, even if they have to pay a little more for an XP license.
The computers in our network are all XP machines. There are only two boxes with Vista, one is used by the CEO in his office (most probably to impress clients) and the other one is used by our quality manager in order to test things for those clients that want the latest and greatest.
Do you consider Hitler's Germany equal to Saddam's Iraq or Afghanistan? Germany was a serious threat to global freedom, and after Europe and Russia had been conquered, it was America that would have been the next target of the German boot. On the other hand, Saddam was much less powerful than Hitler, and Iraq could not invade and conquer any other country except its most weak neighbors.
The reasons Iraq was invaded are totally different from the reasons Germany was invaded. Back in World War II, America was the true land of the free, home of the brave. It represented freedom in a grand scale. And it's this freedom ideology that pushed the common folk to fight in World War II with such dedication. On the other hand, America now has an army of professionals who don't care about their missions, as long as the army puts food on their table (well, most of them), and the presence of American army in Iraq is part of the new geopolitical strategy of the US for the 21st century.
Under this light, from your post, it seems you are a little bit brainwashed (you might not be at all, it's just seems that way), and I am surprised you were modded 5, insightful.
Even the gurus (Stroustrup etc) don't dare think about a new language.
I tried to use boost.bimap and my compilations got x10 slower. I then wrote my own bimap, with simpler interfaces of course, and compilation times got back to normal.
One of the biggest problems in C++ is header files. I am surprised they do nothing for this. The slowness of compilation of boost programs comes from parsing and compiling the huge amount of code that lives in the header files.
I don't understand why everybody says Doom 3 was a 'demo'. It was not. It was an awesome game. Highly entertaining, as it kept the player on the edge with different events, an awesome atmosphere, amazing environments, high adrenaline etc.
The word "will" implies a process of logical thinking leading to a decision. Free will exists both in predictable and unpredictable cases: the subject of free will makes an effort to decide which route to take, so from his/her/its point of view he/she/it has free will. But the result choice could be predictable or not predictable, and that's irrelevant to free will.
Politicians will exploit every opportunity there is to create and sell more guns through their industrial and military connections. That's all there is to it regarding this so called 'terrorism'.
...what these guys had to go through.
Cooking requires some level of intelligence. How did humans become so clever so as that they started to cook?
The problem with kernel modules is that they are not isolated from the rest of the system, because the CPU design does not provide a mechanism for such a type of isolation, forcing O/S designers to revert to schemes like a microkernel, where each module is a separate process. CPU designers are to blame, not software designers.
The 8086 set the PC technology back 15 years, at least. At 1985, the Amiga could do hi-res multicolor bitmap displays, preemptive multitasking, hardware-accelerated graphics and sound, DMA, auto-configurable peripherals (through Zorro slots), 32-bit programming (although the addressing was 24 bit) without the curse of far pointers, and many other goodies that came much later in the PC world.
The PC technology was largely retarded: stupid BIOS, stupid VGA register layout, stupid memory addressing, stupid interrupt controller, stupid DMA...all these things were very hard to program. But it dominated the world, because of compatibility...
How can we reach mr Lucas to tell him that the fate of Atlantis is THE scenario for the next Indiana Jones? If we mass-mail him, he will start thinking about it seriously.
I don't think Firefox/Safari/Opera are not affected. The exploit is not browser specific: it relies on the Win32 function LoadAniIcon, which has a bug that can be exploited...this function can be invoked by any browser, from example, from within a Java applet.
All exploits are based on a bug in the function LoadAniIcon.
What they do goes roughly like this:
1) put the code to execute in a string that is repeated in memory (to increase the chances of the code being called).
2) exploit the bug in LoadAniIcon to execute the code in the string.