and that health problems have been observed thousands of miles away. No, they weren't. There was a massive propaganda shitfest about that (recent photos of random people with birth defects attributed to Chernobyl didn't help, either), however real, measurable effects on health are confined to a very small area. I know because I lived in Gomel (about 80 miles from Chernobyl power plant at the time).
The _increase in background radiation_ was observed thousands of miles away, however it required methods similar to ones that would detect radioactive cats in cars.
First of all, that's less than a total percentage of people who CLAIM to be religious. Outside of US religion is pretty unpopular already.
Second, and more important point, very few people REALLY believe in religious dogmas. They merely see it as an integral part of a bullshit that is present in their culture, and therefore refuse to disagree or even think about those things, and would never dare (or bother) to defend religion in any serious discussion. Their unwillingness to think is a problem, but the content of their superstitions isn't -- if they started to believe that scientists spout divine truth by a virtue of being called scientists, it would be not much of an improvement.
For most of the childhood people are in the mode when they accept knowledge given them by authority figures (parents, teachers, through books, etc.) uncritically. There is't much an alternative to that because their critical thinking abilities are still being developed, and it is more efficient for them to absorb knowledge from others assuming that those others are not, for lack of better expression, full of shit. As kids grow, they lose interest in this "absorbtion" of knowledge and gain ability to challenge views that are presented to them. Unfortunately this is often recognized as losing the interest in learning, however in fact this is the point where real learning begins -- a person becomes capable of building a consistent system of knowledge, and to be able to place new knowledge in it, he has to determine if it is true, if it is consistent with what he knows, how does it alter things that he accepted before, and how it fits in his personal system of knowledge. This is impossible without critical thinking.
Superstitions don't enter people's mind at the stage when critical thinking works, so religions only can spread in a childhood "learn from authority" mode, or to people who regress into it after a severe psychological trauma. If religion taken such a strong foothold that it is accepted as a base for all future "critical thinking", the person is truly lost. He still tries to think, but his method of thinking is based on beliefs that he unquestioningly accepts, and his method of verification for everything he hears is consistency with his pre-existing beliefs and maybe whether it makes him feel good about his position.
The consequences of this true belief are truly monstrous. If such a person following Judaism, Christianity or Islam will be, say, given control of a nuclear weapon, and had a hallucination (or was deceived into believing) that a god tells him to sacrifice his city, he would blow up a city, seeing it as an equivalent of Abraham's sacrifice and likely expecting that city will be miraculously saved from destruction. Anyone else (and that anyone else would not be a "true" follower of a religion that is based on Old Testament regardless of what he may claim) would recognize that even though it matches a situation described in the Bible that he is "supposed to believe", his critical thinking will prevent him from doing so no matter how convincing a hallucination or deception is. I am sure, every government recognizes that, and would not, among other things, allow a true Christian anywher close to nukes no matter what its non-discrimination policy claims. Yes, even American one, even though things like Iraq war make me think that only nukes enjoy this protection from nutcases there.
Someone may claim that there is a big difference between willing to argue that religions' world view is true and sacrifices of cities. I disagree. Many religions, and at least most of branches of Christianity and Islam, are based on the premise is that the belief in a god and obedience to god's will are the only true ethical things, and everything else is derived from that because god is by its nature benevolent while people by their nature are sinister. If a "good samaritan" person does something positive without belief in god, then it's kinda okay if it is exactly the same as what a
The purpose of arguing with religious people is not to convince them -- except for negligible fraction of them, they are too far gone, and their minds are broken if they believe in that crap. If the goal was to convince them, it would be about as dumb as going to a mental clinic and arguing with delusional patients.
It's to prevent them from convincing OTHER people who are vulnerable to being indoctrinated with religion. You can't cure them but you can stop the spread of a disease to the next generation of people.
It's clear to me that your parent doesn't suggest "it compiles; ship it". Successful compilation and execution is a necessary, not sufficient, condition for code to be considered shippable (:=? correct). That is, "shipped implies verified in testing". If the test is "ultimate", it means, it must be sufficient.
Also, isn't it reasonable to assume that the part where you LOOK AT THE CODE is the part where you form a working theory of how the code will function? I think that's what P meant. Once you've looked at the code, you then proceed to testing. Both looking and testing are done AFTER the code is written, so at best they can confirm that someone indeed wrote something usable. To make sure that programmers follow a standard they have to actually understand it, and write in a manner compatible with it, not rely on testing catching their mistakes and misunderstandings.
Say you want to argue that the parent's proposition is wrong. This means code is shipped without being verified in testing. Do you propose we don't test our code, or do you propose we ship code that fails our test suite? Or have I missed a third option? Most of interfaces are too complex to actually show all incompatible code in tests, and security problems are pretty much defy any usable testing procedure. Tests don't really verify anything, they at best provide a really, really coarse net to fish out most egregious mistakes, so the most important part of development is writing code correctly, not testing it.
It seems to me that you agree with your parent. Code breaks when built with the new compiler and ran against a faulty kernel. No. There are no "bugs", and nothing is "faulty". All code acts exactly in the same manner as what accepted version of a standard prescribes, the only difference is that accepted version of a standard used by BSD and Linux was not the same as SysV ABI specification. Neither Linux nor BSD are System V, and they don't run System V binaries, so there is nothing unusual in the difference between their standards. If Linux and BSD were expected to follow SysV ABI, GCC would not clear the direction flag in the first place.
What? You're doing some serious reading between the lines on that one. I didn't read anything about the executive communicating anything to JP Morgan regarding whether to sell or not sell. Absent that communication, it doesn't matter that JP Morgan cancels trades on its own since the cancellation wasn't done on the basis of nonpublic information. What else can it be for?
The rule itself just implements Section 10(b) of the '34 act, which applies only "in connection with the purchase or sale of any security." In 1975, the Supreme Court said that because of this limitation, decisions NOT to sell or purchase aren't covered. If you think the rule should change, Congress is the appropriate authority, not the SEC. SEC is not a court, police or FBI.
10b5-1 plans are intended to let insiders, who (1) are typically compensated in stock and (2) who typically have inside information sell their shares without using that inside information to time their shares. Most of people who are compensated in stock have a massive initial blackout set for trades, to prevent this very thing. Financial institutions that organize those stock-based compensation packages insist on doing that to protect themselves from dropping stock prices caused by a large number of people selling at the same time. This has very little to do with insider trading that is performed by company executives, who usually have massive amount of stock, and want to get rid of it quickly when they know, they messed up.
The plan linked to in the wikileaks article doesn't affect this at all. Instead, it just says "Ok. You're going to be selling shares in the future. Here's a way you can protect yourself it the value goes down. (oh, and incidentally, you don't use any inside information to protect yourself.) The whole point is that service provided by JP Morgan assists with this manipulation of canceling orders that otherwise would have to be done personally by the client, requiring him to make an effort and take a risk of missing the deadlines.
It's also pretty obvious that SEC did a horrible job making that rule in the first place -- if it wanted to effectively reduce the amount of insider trading, it would have to require pre-announced orders that can't be canceled once announced. Then the person making a trade has to either trade less, or accept the same amount of risk as general public, or inform the public about expected drop in stock price by announcing large amount of sales.
I don't think it's unreasonable to ask that, if there isn't enough RAM to run OpenOffice or Eclipse, that the OS put up a dialog box telling you so. Unless you think 32M is not enough memory to put up a dialog box... but I seem to remember Macintosh doing that just fine in 128k of RAM. Oh, there is enough RAM to run it. It just has to constantly use swap, so it may take half an hour to start. All operating systems behave in this manner, it's just no one would "play with Vista" on an obviously inadequate and likely broken computer, however every time a Microsoft fan installs Linux, he chooses a computer he wouldn't expect being usable for any other purpose.
For what it's worth, my experience was a lot like Anonymous Coward's. I came across tons of bugs in software packages, mysterious error messages, applications quitting with *no* error message, etc. Examples, please. I hear this constantly from Microsoft fans, and it always happens that they never installed the system in the first place but heard it from someone else.
I know that "well, it's better now" but it's been "better now" since the first time I tried Linux with Red Hat 6, Do you mean, the LAST time? Red Hat 6.0 was released in 1999. Windows OSes that were released around the same time, and especially drivers provided with them, were notoriously hard to install by a "person who knows computer GUIs pretty well", unless they were preinstalled. Guess what, Red Hat 6.0 in a professionally preinstalled configuration worked just fine, too.
and I'm sick of being jerked around. When a non-biased person, a person who knows computer GUIs pretty well, a person who will ensure 100% feature parity with at least Windows 2000 or Mac OS 9, tells me that Linux is as good as Windows, maybe I'll believe him. Right now Linux is this weird mix of technologically advanced applications and concepts, while missing some of the most basic usability concepts that Microsoft and Apple had right in the mid-90s. Are you sure that those "usability concepts" aren't actually your expectations that everything in the world has to have an exact copy of Windows interface (pre-OSX Mac OS was where it was copied from, this is why it looks familiar to you)? Try to use OSX that some people claim to be the latest and greatest in UI design -- you will complain in exactly the same manner about it, because it also has some significant differences from Windows.
People hate to write their own signal handlers because they are called completely asynchronously to the process, leaving very little room for doing anything complex in there without creating a race condition. Usually libraries configure signal handlers for things like errors, timers or I/O, so the only places where application programmer has to make his own signal handler are setting flags for daemons exit or reload, or custom cleanup procedures. That's about once per project, and usually done by someone who is well aware of how CPU state looks like.
Oh. Please don't think I'm all pro M$. Tux TM OS is cool too, but I don't know about a development framework for linux that can do what.net can do. I know there is Mono, but that's not a Tux TM invention. There is no monolithic "framework" in a way that Java or dotnet made. Every piece of the system is designed to be usable as a part of any "framework" you need, they are all perfectly interchangeable.
Theoretically you're right, but reality is different. A company just can't start from scratch each time they extend their product. Yes, it can. And yes, I have participated in projects that had to do it -- when design no longer matches the purpose of a product or its development direction, development of patches upon patches asymptotically approaches a usable release candidate, never producing a version that a sane person would want to release and support. Usually the only way to cross that line is to remove old cruft and build an infrastructure, what can be easily seen on examples of open source applications -- Mozilla, OpenOffice.org, X11, etc. With proprietary software it's exactly the same, except less people see the extent of every problem, and less is done about that.
Word. When I click an icon, I'd like my document to open or my program to start, or at least some feedback explaining why it didn't. All too often, Linux just sits there and gives you a dumb look when you tell it to do something. Hint: in default configuration you are supposed to double-click on icons.
You are also not supposed to "install Linux" on a failing hard drive, on an old box that you stopped using after it literally fell apart, with 133MHz Pentium MMX and 32M of RAM, then complain about humongous packages such as OpenOffice and Eclipse "giving you a dumb look when you tell it to do something".
This is only relevant if function is a signal handler, so kernel may call it with a set direction flag instead of cleared one.
If it's in a regular program, all flags remain consistent regardless of what kernel does, because flags are initialized when the process starts, saved when the process sleeps, and restored when the process is awakened from sleep, so continuity is preserved. The whole problem with signal handlers is that they may be called while the process had the flag set, so they inherit the flag, and the next string function called from them is executed backwards, wreaking havoc on process' stack or heap. This is what the kernel patch fixes -- flag is now cleared before calling a signal handler.
You two are on different wavelengths. Did FCC allocate a special wavelength for things that are utterly and hopelessly wrong?
Consider that before you open your little can of whoop-ass next time. BTW, your attitude is a real turn-off which makes hearing your point much more difficult. Oh noes, my popularity among Anonymous Cowards is getting dangerously low! What should I do? What should I do?
As af ar I know and you don't there is a different reason. "Type safe" and "managed" are your Google keywords for today. Who cares? You don't build a consistent system by taking old, inconsistently designed pieces and making them seem to fall into some scheme by calling them from wrappers. You build a system in a way that reuses fundamental components as much as possible, so it is consistent by design.
Unix file descriptor remains being the greatest example of this consistent design -- whatever is added to the system, interface is provided by the same mechanism, so kernel interface, security, caching and buffering, naming and most of the ways to access those features rely on the same existing infrastructure. What is the closest Windows equivalent? Handle, an ugly wrapper, implemented without even a rudimental polymorphism.
Even if this is right, your comment shows you're rather "new" at programming. I'll explain. Option 1: rewrite (i mean completely really rewrite) the wrapped classes. Hey! We need to rewrite and test almost everything (application / os) that has been built on this classes that were working, but nor have been rewritten. Option 2: write a wrapper, possibly fix/catch bugs from wrapped classes, and no rewrite of apps and os. Option 3: don't write hideously convoluted crap that has to be concealed by layers of makeup in the first place.
It's really telling that Qt, a toolkit that by its very purpose has to contain wrappers providing compatibility between multiple platforms and targeted for a lower-level language, ended up being more consistent, more efficient, and easier to develop for than dotnet.
Yes, your code could be so much better and nicer with option 1, but there are limiting factors like time and money. This would mean something if Microsoft's efforts on building more layers upon layers didn't lead to exponentially growing complexity of both implementation and interface. If anything, the article illustrates how complex, and therefore expensive to develop, dotnet became.
Yes, actually. There's a ton of features in Windows at the SDK level and.NET is really designed to be a wrapper around all the different Windows services. Wrappers are acceptance of defeat as far as consistent infrastructure development is concerned.
A lot of things in Windows are rather difficult to program at the C or even the C++ level. The standard Win32 API isn't too bad to work with in C, but the windowing functions and the messages mechanism is enough to provoke tears. Really, Windows is terrible for programming in C compared to Linux, and so, at least.NET papers over all the crap. This only means that Microsoft "technologies" developed before dotnet are even crappier than dotnet itself (and dotnet runs on top of them). But we already knew that.
When insiders were expected to pre-announce their trades, large amount of announced sales could be used by investors as a sign that insiders have low confidence in company's long-term profitability, and act accordingly. With this scheme being known and believed to be widespread, this communication channel is lost -- everyone can announce that he is selling everything then cancel at the last moment, and helpful brokerages will make sure that no one (except for the general public and employees with options and stock purchase plans) will be late to the musical chairs.
It really exposes something fascinating about the development process: Code is written based on certain assumptions and a working theory of how the code will function once put into use, but the only way to really know how well it works is to hand it over to the ultimate judge of code correctness--the computer--by running the code. If it works, case closed. Please don't ever again offer your great insight into software development process. If everything was stuffed into the kernel (or other software projects) once it compiles and runs, we would drown in unstable, crashing, insecure, impossible to debug code. Without any doubt, there are plenty of geniuses (some of them in Northwestern US) who develop in this manner, but I can assure you, neither Linux kernel, nor GCC, glibc or other major open source projects use this procedure. If you want to discuss this method further I recommend you to send your opinion to a friendly individual at djb@cr.yp.to .
Before anything is released, people have to LOOK AT THE CODE and make sure that the source gives them a reason to think, it will run correctly when used with interfaces that it is supposed to utilize or provide. There are plenty of things in the kernel that would require massive amount of testing to be verified with any certainty, so people write usable code not because they are testing it until their hardware breaks but because they know what they are doing.
Now it's entirely possible that the kernel developers never heard of this obscure nuance of the Intel processor. Then one day, the compiler changed, and with it, the assumptions changed. Mature code that has been declared good years ago seemingly breaks. Now it's easy to blame the code, but really this is a deletion of a feature from the compiler. Nevertheless, it exposes the fact that ultimately, no matter what tools we use and no matter how well we think our code through, you can only consider the code good once it runs and appears to do what it's supposed to. What the hell are you talking about?
Code generated by a C compiler remains consistent regardless of the version, unless you mix binaries built with different versions of GCC. When code that kernel uses to pass control to applications' signal handlers does not keep the direction flag as it is supposed to according to ABI, then userspace code -- ANY CODE THAT CONTAINS SIGNAL HANDLERS -- compiled by a new compiler will not work correctly. In other words, kernel provides an interface that is incompatible with binaries made by a new GCC, and since the standard is on the side of the new GCC behavior, it's kernel that has to be changed. That's all. Nothing else is involved -- some code compiled with a new compiler will not work on an old kernel. Code compiled with an old compiler remains usable with a new kernel, no sources except for five lines in the kernel have to be changed. It's not even something that a C programmer has any control over unless he writes pieces of his program in assembly -- and then he should know. I don't even believe, any for a C programmer who knows how to write a signal handler it's possible that he "never heard of this obscure nuance of the Intel processor" -- both are very rarely used directly -- however this is completely irrelevant, the only sources that have to be changed are five lines in the kernel, not in signal handlers.
The only real problem this "exposes" is that for some reason everyone who used x86 SysV ABI for anything that matters (Linux and BSD), decided to change the interface to exclude the requirement to clear the direction flag, even though that "official" standard said otherwise -- however it was known from the very beginning, and this is why older C compiler taken it into account in the first place. It's not a bug or someone's lack of knowledge, it's a violation of a standard, and GCC developers decided to get things back to the letter of a standard because the compiler's optimization benefits from it.
If you bothered read the linked article you would find that:
1. JP Morgan established a whole service specifically designed to abuse this rule. 2. Service was offered to people who would profit from such abuse without any announcement to the public or regulators. 3. The article shows a specific example of service being offered to a particular person, Barry Diller, and subsequent drop in stock value that the person was supposed to be shielded from (I assume, it is not known if the service was actually used in that situation).
Now you, and two morons that were so eager to praise you in responses, can take your sorry attempt of rebuttal, and tattoo it on your foreheads in 12pt Helvetica font.
I am sure, a lot of nerds work, or worked at some point at public companies, and had to trade their companies' stock because at large extent they were paid in stock options. Ironically those employees, who usually had a lot of insider information themselves, suffered most from insider trading -- while their options and stock were still blocked from trading, management and major investors were fearlessly driving the companies into the ground, shielded from all negative consequences by machinations like this.
He contrasts how your ears really do detect the intensities of each frequency, rather than say just detecting low, medium, and high frequencies, then figuring intermediate ones by how much they trigger the two nearby detectors. That's like comparing driving a car to having a headache -- two completely unrelated things.
Slashdot Mirror
The _increase in background radiation_ was observed thousands of miles away, however it required methods similar to ones that would detect radioactive cats in cars.
90 percent of population?
First of all, that's less than a total percentage of people who CLAIM to be religious. Outside of US religion is pretty unpopular already.
Second, and more important point, very few people REALLY believe in religious dogmas. They merely see it as an integral part of a bullshit that is present in their culture, and therefore refuse to disagree or even think about those things, and would never dare (or bother) to defend religion in any serious discussion. Their unwillingness to think is a problem, but the content of their superstitions isn't -- if they started to believe that scientists spout divine truth by a virtue of being called scientists, it would be not much of an improvement.
For most of the childhood people are in the mode when they accept knowledge given them by authority figures (parents, teachers, through books, etc.) uncritically. There is't much an alternative to that because their critical thinking abilities are still being developed, and it is more efficient for them to absorb knowledge from others assuming that those others are not, for lack of better expression, full of shit. As kids grow, they lose interest in this "absorbtion" of knowledge and gain ability to challenge views that are presented to them. Unfortunately this is often recognized as losing the interest in learning, however in fact this is the point where real learning begins -- a person becomes capable of building a consistent system of knowledge, and to be able to place new knowledge in it, he has to determine if it is true, if it is consistent with what he knows, how does it alter things that he accepted before, and how it fits in his personal system of knowledge. This is impossible without critical thinking.
Superstitions don't enter people's mind at the stage when critical thinking works, so religions only can spread in a childhood "learn from authority" mode, or to people who regress into it after a severe psychological trauma. If religion taken such a strong foothold that it is accepted as a base for all future "critical thinking", the person is truly lost. He still tries to think, but his method of thinking is based on beliefs that he unquestioningly accepts, and his method of verification for everything he hears is consistency with his pre-existing beliefs and maybe whether it makes him feel good about his position.
The consequences of this true belief are truly monstrous. If such a person following Judaism, Christianity or Islam will be, say, given control of a nuclear weapon, and had a hallucination (or was deceived into believing) that a god tells him to sacrifice his city, he would blow up a city, seeing it as an equivalent of Abraham's sacrifice and likely expecting that city will be miraculously saved from destruction. Anyone else (and that anyone else would not be a "true" follower of a religion that is based on Old Testament regardless of what he may claim) would recognize that even though it matches a situation described in the Bible that he is "supposed to believe", his critical thinking will prevent him from doing so no matter how convincing a hallucination or deception is. I am sure, every government recognizes that, and would not, among other things, allow a true Christian anywher close to nukes no matter what its non-discrimination policy claims. Yes, even American one, even though things like Iraq war make me think that only nukes enjoy this protection from nutcases there.
Someone may claim that there is a big difference between willing to argue that religions' world view is true and sacrifices of cities. I disagree. Many religions, and at least most of branches of Christianity and Islam, are based on the premise is that the belief in a god and obedience to god's will are the only true ethical things, and everything else is derived from that because god is by its nature benevolent while people by their nature are sinister. If a "good samaritan" person does something positive without belief in god, then it's kinda okay if it is exactly the same as what a
The purpose of arguing with religious people is not to convince them -- except for negligible fraction of them, they are too far gone, and their minds are broken if they believe in that crap. If the goal was to convince them, it would be about as dumb as going to a mental clinic and arguing with delusional patients.
It's to prevent them from convincing OTHER people who are vulnerable to being indoctrinated with religion. You can't cure them but you can stop the spread of a disease to the next generation of people.
You don't market phone OS to users -- you market it to cellular carriers.
It's also pretty obvious that SEC did a horrible job making that rule in the first place -- if it wanted to effectively reduce the amount of insider trading, it would have to require pre-announced orders that can't be canceled once announced. Then the person making a trade has to either trade less, or accept the same amount of risk as general public, or inform the public about expected drop in stock price by announcing large amount of sales.
Yes.
People hate to write their own signal handlers because they are called completely asynchronously to the process, leaving very little room for doing anything complex in there without creating a race condition. Usually libraries configure signal handlers for things like errors, timers or I/O, so the only places where application programmer has to make his own signal handler are setting flags for daemons exit or reload, or custom cleanup procedures. That's about once per project, and usually done by someone who is well aware of how CPU state looks like.
You are also not supposed to "install Linux" on a failing hard drive, on an old box that you stopped using after it literally fell apart, with 133MHz Pentium MMX and 32M of RAM, then complain about humongous packages such as OpenOffice and Eclipse "giving you a dumb look when you tell it to do something".
This is only relevant if function is a signal handler, so kernel may call it with a set direction flag instead of cleared one.
If it's in a regular program, all flags remain consistent regardless of what kernel does, because flags are initialized when the process starts, saved when the process sleeps, and restored when the process is awakened from sleep, so continuity is preserved. The whole problem with signal handlers is that they may be called while the process had the flag set, so they inherit the flag, and the next string function called from them is executed backwards, wreaking havoc on process' stack or heap. This is what the kernel patch fixes -- flag is now cleared before calling a signal handler.
No. But you can make code that only has security holes if you compile it with a new compiler (what is absolutely useless).
"Type safe" and "managed" are your Google keywords for today. Who cares? You don't build a consistent system by taking old, inconsistently designed pieces and making them seem to fall into some scheme by calling them from wrappers. You build a system in a way that reuses fundamental components as much as possible, so it is consistent by design.
Unix file descriptor remains being the greatest example of this consistent design -- whatever is added to the system, interface is provided by the same mechanism, so kernel interface, security, caching and buffering, naming and most of the ways to access those features rely on the same existing infrastructure. What is the closest Windows equivalent? Handle, an ugly wrapper, implemented without even a rudimental polymorphism. Even if this is right, your comment shows you're rather "new" at programming. I'll explain.
Option 1: rewrite (i mean completely really rewrite) the wrapped classes. Hey! We need to rewrite and test almost everything (application / os) that has been built on this classes that were working, but nor have been rewritten.
Option 2: write a wrapper, possibly fix/catch bugs from wrapped classes, and no rewrite of apps and os. Option 3: don't write hideously convoluted crap that has to be concealed by layers of makeup in the first place.
It's really telling that Qt, a toolkit that by its very purpose has to contain wrappers providing compatibility between multiple platforms and targeted for a lower-level language, ended up being more consistent, more efficient, and easier to develop for than dotnet. Yes, your code could be so much better and nicer with option 1, but there are limiting factors like time and money. This would mean something if Microsoft's efforts on building more layers upon layers didn't lead to exponentially growing complexity of both implementation and interface. If anything, the article illustrates how complex, and therefore expensive to develop, dotnet became.
Psychology studies opinions of psychologists.
Did it ever occur to you that IT'S FUNNY BECAUSE IT'S SO OBVIOUS?
For the same reason, O RLY owl is funny -- everyone, his brother and his dog knows how it looks like, and nevertheless it's still relevant.
There is another part of the picture.
When insiders were expected to pre-announce their trades, large amount of announced sales could be used by investors as a sign that insiders have low confidence in company's long-term profitability, and act accordingly. With this scheme being known and believed to be widespread, this communication channel is lost -- everyone can announce that he is selling everything then cancel at the last moment, and helpful brokerages will make sure that no one (except for the general public and employees with options and stock purchase plans) will be late to the musical chairs.
Before anything is released, people have to LOOK AT THE CODE and make sure that the source gives them a reason to think, it will run correctly when used with interfaces that it is supposed to utilize or provide. There are plenty of things in the kernel that would require massive amount of testing to be verified with any certainty, so people write usable code not because they are testing it until their hardware breaks but because they know what they are doing. Now it's entirely possible that the kernel developers never heard of this obscure nuance of the Intel processor. Then one day, the compiler changed, and with it, the assumptions changed. Mature code that has been declared good years ago seemingly breaks. Now it's easy to blame the code, but really this is a deletion of a feature from the compiler. Nevertheless, it exposes the fact that ultimately, no matter what tools we use and no matter how well we think our code through, you can only consider the code good once it runs and appears to do what it's supposed to. What the hell are you talking about?
Code generated by a C compiler remains consistent regardless of the version, unless you mix binaries built with different versions of GCC. When code that kernel uses to pass control to applications' signal handlers does not keep the direction flag as it is supposed to according to ABI, then userspace code -- ANY CODE THAT CONTAINS SIGNAL HANDLERS -- compiled by a new compiler will not work correctly. In other words, kernel provides an interface that is incompatible with binaries made by a new GCC, and since the standard is on the side of the new GCC behavior, it's kernel that has to be changed. That's all. Nothing else is involved -- some code compiled with a new compiler will not work on an old kernel. Code compiled with an old compiler remains usable with a new kernel, no sources except for five lines in the kernel have to be changed. It's not even something that a C programmer has any control over unless he writes pieces of his program in assembly -- and then he should know. I don't even believe, any for a C programmer who knows how to write a signal handler it's possible that he "never heard of this obscure nuance of the Intel processor" -- both are very rarely used directly -- however this is completely irrelevant, the only sources that have to be changed are five lines in the kernel, not in signal handlers.
The only real problem this "exposes" is that for some reason everyone who used x86 SysV ABI for anything that matters (Linux and BSD), decided to change the interface to exclude the requirement to clear the direction flag, even though that "official" standard said otherwise -- however it was known from the very beginning, and this is why older C compiler taken it into account in the first place. It's not a bug or someone's lack of knowledge, it's a violation of a standard, and GCC developers decided to get things back to the letter of a standard because the compiler's optimization benefits from it.
If you bothered read the linked article you would find that:
1. JP Morgan established a whole service specifically designed to abuse this rule.
2. Service was offered to people who would profit from such abuse without any announcement to the public or regulators.
3. The article shows a specific example of service being offered to a particular person, Barry Diller, and subsequent drop in stock value that the person was supposed to be shielded from (I assume, it is not known if the service was actually used in that situation).
Now you, and two morons that were so eager to praise you in responses, can take your sorry attempt of rebuttal, and tattoo it on your foreheads in 12pt Helvetica font.
I am sure, a lot of nerds work, or worked at some point at public companies, and had to trade their companies' stock because at large extent they were paid in stock options. Ironically those employees, who usually had a lot of insider information themselves, suffered most from insider trading -- while their options and stock were still blocked from trading, management and major investors were fearlessly driving the companies into the ground, shielded from all negative consequences by machinations like this.