The only market that still supports 32-bit CPUs is the embedded market- not a market Intel has ever displayed much interest in.
Really? Can you explain the 960, then, or the acquisition of StrongARM/XScale, or the IXP network processors, or any of the other stuff you can read about in the "Applied Computing" section of Intel's developer website (especially communications and networking)? No, sir, Intel has displayed quite a bit of interest in the embedded market.
IIRC, 2.4.10 was the first 2.4 kernel with the AA VM. Yes, it was a mess, but I don't think advances since then explain a 10% performance difference for this type of benchmark.
I also don't know for sure that OBL used 2.4.10. They said they used SuSE 7.3, and SuSE's page for 7.3 says it uses 2.4.10, but that doesn't mean the benchmark used that version. Overall, there do seem to be a few things about the benchmark that give legitimate cause for suspicion. For example, I couldn't find the actual benchmark programs, or even a description, and why the hell were they testing on an HP Omnibook (700MHz P3) instead of a more realistic desktop system, and why did they build the code for a WinXP system on a Win2K system? Very odd.
Numerical computation code running on Intel Windows and Intel Linux will run at exactly the same speed.
...except that they didn't, in this case, and the article - which you obviously didn't read - even suggests some reasons why that might not always be the case.
I'm surprised that nobody has commented on what might be the most interesting result on these tests - that the same code produced by the same compiler runs 10% faster on Windows XP than on Linux (2.4.10, according to SuSE's description of 7.3). Sure, the "kernels"[1] used by the benchmark might not be as representative of real life as we'd like, but this should still be cause for concern. Kernel developers have flamed each other endlessly over smaller differences on less comprehensive benchmarks between the Arcangeli and van Riel VM systems. Do we have to go through a Mindcraft-like period of denial before anyone starts taking such a result seriously?
[1]The objections about the "kernels" used in the benchmarks not being the same as the "kernel" with which we're all familiar only demonstrate the ignorance of people who don't know that the scientific programming and benchmark communities have been using the term just as long as the OS community. Their usage may be different, but it's just as valid.
After a while, I began to understand that the way to win in chess was to become "fluent" in the patterns of chess itself, and that those patterns didn't really have any important analog elsewhere.
I totally disagree. I think chess teaches many important lessons and skills that are quite generally applicable. For example:
Chess teaches concentration, memory and patience - qualities most people could stand to improve.
Chess teaches you timing, not in the sense of "playing the clock" in timed games (I hate that) but rather in the sense of knowing when to prepare an attack, when to execute, when to fall back, etc.
Chess teaches humility. There's always someone better than you, and you're always going to make mistakes, and chess rubs your nose in both facts.
Chess teaches you strategic concepts of misdirection, multiple goals, prophylaxis, etc.
Competitive chess teaches you how to evaluate your own capabilities realistically, not only at the board but also in selection of opponents or venues. Wishful thinking is anathema to chess players.
Chess analysis is almost a whole separate endeavour, reinforcing many of the lessons from the game itself and also teaching some new ones (e.g. thoroughness).
Altogether, I think chess provides excellent "mental exercise" as others have said. Almost every day, I find myself using skills that I have learned at the chessboard, such as when I'm thinking "several moves ahead" in traffic or deciding how to respond to some bit of office-political nonsense. Sure, the minutiae of openings and pawn structure and light/dark square complexes don't translate directly into other endeavors, but neither do the precise motions of any physical sport or exercise translate directly into another. Nonetheless, increasing one's strength/endurance/agility in one activity can improve your performance in another, and that's just as true in the mental realm as the physical. Chess is like a health club for the mind; it might not be the real thing, but it prepares you for the real thing.
The first few suggestions - e.g. separate code and data, use secure default configurations - sound great, but I think Schneier and Shostack go a little bit too far when they get to this point:
We recommend that all protocols and interfaces used in Microsoft software be immediately published, and a one-year moratorium be placed on all non-security modifications to those protocols.
One year? One year?!? Does Linux do that? Does anyone? I'm sorry, but a year is a damn long time, and this is a time-based business. Making their protocols public at all is a big pill for Microsoft to swallow; expecting them to develop a protocol -which might define much of a new product's functionality - and then sit on their hands for a full year while security experts diddle and competitors get a head start implementing Microsoft's ideas is just ridiculous.
The next part is almost as bad:
We feel that Microsoft needs to go further, and reward not only Microsoft employees but independent researchers...needs both automated security reviews and evaluations by security experts.
Translation: "We feel left out, and the dot-bomb has left us destitute. Send some money our way to make us feel better, and maybe we'll change our tune." Shameless. Constructive engagement with the security community is well and good, but Schneier and Shostak's "suggestion" as given is little short of demanding protection money. Thought experiment: substitute "government" for "Microsoft" in the above and consider whether such an arrangement would qualify as corruption.
Really, if those last few paragraphs had been left out it would have been an excellent article, but they got kind of carried away there at the end. What a shame that an opportunity for a truly constructive dialog was pissed away out of greed like that.
Re:Nasar's flawed image of genius
on
A Beautiful Mind
·
· Score: 3, Interesting
While Nash was there, Princeton was full of first-rate intellects --- geniuses by any yardstick --- who shared nothing of Nash's sociopathic nature...Von Neumann was articulate and cosmopolitan, and heavily involved in politics.
I just have to add a plug here for Prisoners' Dilemma which is a combination von Neumann bio and mathematical exploration of his game-theoretic ideas. There are many other people mentioned in the book, from both Princeton and RAND, who further exemplify the non-correlation between being a genius and being an asshole.
I think this "eccentric genius" meme is one of the ugliest to infect the computer community. People see the luminaries of the field acting in eccentric ways, and imitate the style while possessing none of the substance. If you don't know what I mean, look around. You're in the right forum to see that very phenomenon in action. I'll save my rant for somewhere else.
Why does the same code that causes the athlon to crash work fine on pentiums? Apparently the GART is cacheable on pentium systems? And the Athlon is billed as pentium-compatible...
There are different types and levels of compatibility. The Athlon claims base-instruction-set and register compatibility with the Pentium, but it's not pin-compatible and may also differ in any number of behavioral/timing characteristics. This is one such case. The behavior in question is perfectly acceptable within the bounds of the compatibility and standards compliance that AMD claims.
Why does disabling large pages fix the problem?
Because it's the large pages that are (incorrectly) marked as cacheable. No large pages, no incorrect mappings, no problem.
But to claim it's not a hardware bug is ludicrous. It's a bug with the Athlon CPU, or with certain GARTS found in Athlon chipsets, or both.
Nope. It's a bug in the OS. Anyone who works with memory systems should know the dangers inherent in mixing cache-coherent and non-coherent accesses to the same memory, and should mark pages accordingly.
It's very tempting to criticize AMD for their handling of speculative writes, but that handling is really irrelevant. It seems to me that the cache line's contents should not be marked dirtybefore the processor has actually written to it (which in this case it never does). Under normal conditions, though, this would only be a performance issue. If a coherent access were made from elsewhere, invalidation and writeback would ensue; the writeback would be unnecessary but not harmful, because it would be writing the same data that were already in main memory. However, the cache wouldn't be involved in the first place if the pages were mapped correctly. There would be no write-allocate, no invalidation, no writeback, and no problem. The invalid mapping turns a slightly silly but legal and normally-harmless processor behavior into a serious coherency problem.
I was really drooling over the 610, which seems to've been discontinued in favor of the 615. What's disappointing is that a large part of the 610's appeal for me was the viewable-in-all-light reflective screen it shared with the higher-priced 760. According to the specs, the 615 is using a boring old transmissive TFT with a backlight. Now I can only get the cooler screen if I pay more $$$ for a 760 that has features I don't want.:-(
If you have enough swap space (whether you call it "tertiary" or not) for all writable memory, you're not overcommitting. By definition.
You might (or might not) be overcommitting. Up to you. However, even if you are, you're not waiting until the last second and then going postal instead of taking concrete steps sooner to avoid total memory exhaustion. For example you could say that, once you start dipping into the overcommit pool, fork() will start failing but existing processes can continue. You could say that only certain processes that are being allowed to run to completion will be able to allocate new swap space; anyone else will just get suspended the first time they try. Once you have set a high watermark somewhere short of total exhaustion, you can do any number of things, even if you're overcommitting. Some of those measures are pretty drastic, but still better than the OOM killer.
To a certain extent, perhaps, these "softer" approaches just slow down what might be an inevitable march to OOM. In theory, you could still reach the total-exhaustion deadlock that OOM-killer is supposed to deal with, although it really doesn't because it doesn't in any way guarantee that your system will really be any more useable than if the deadlock had occurred. In practice, though, you'd be hard pressed to find a system that (a) allows overcommit, which is only necessary with VM systems that are broken (wrt how much swap they allow) to start with, (b)takes such drastic measures before going OOM, (c) does in fact hit OOM anyway, and (d) would benefit from an OOM killer if it had one. Without such an existence proof, claims that an OOM killer is necessary are pretty bogus.
As I've said, these aren't new ideas just off the top of my head. These are approaches that are proven to work. Ask yourself: how is it that so many systems get by just fine without an OOM killer? There are answers out there.
It's funny that you accuse Rik of NIH
Actually I didn't. I accused other Linux kernel hackers of NIH, and tried to warn Rik about becoming more like them. I know Rik's smarter than that, but sometimes even smart people submit to "common nonsense".
So we know before a process gets to execute exactly what its memory usage profile is?
Please don't construct strawmen. Oh wait, that's not just a strawman, it's also circularity. You're assuming that the OOM killer exists, then using that to "prove" that an alternative approach is impossible to implement. Well yeah, an alternative system that both does and does not incorporate the OOM-killer concept is impossible. Congratulations. Well done.
What I'm really saying is that the VM system should ensure that it has other means to deal with memory exhaustion. Disallowing overcommit altogether is one approach, and that has proven quite acceptable for many systems, but there are plenty of other approaches as well. I've briefly sketched out only one; look up the others yourself (the information is available in plenty of places including some OS textbooks).
"taken away"? Where do they go?
The phrase "suspended with all of their pages taken away" (which is what I said) includes the case where the pages have already been taken away. English 101.
As for where they go, the obvious answer is not the general swap area, because that's already full. However, that doesn't preclude the existence of a secondary (actually tertiary) swap area that exists only for this purpose. It could also be a percentage of the general swap area, which starts to look very much like the memory-pressure code in the very highly regarded FreeBSD VM, or Solaris, etc. The point is that there's a middle ground between "no overcommit at all" and "if you allow overcommit we might shoot you in the head just because we feel like it".
Color me skeptical.
Skepticism is one thing; strawmen and circularity are another. I'm skeptical about the need for an OOM killer.
I have to wonder what the process is going to do when it starts up and has no pages - it'll crash instantly, so why not kill it, right?
If you can't start the process, fork() should fail. That way the caller gets an error code and has some hope of doing something genuinely useful.
Even if you did mean that, my understanding is that the OOM killer only takes effect when there is no memory space left - including swap.
What I'm saying is that you should never wait that long to detect that condition. Sure, you can disable overcommit entirely, but that's pretty inflexible. Overcommit is a good thing, if it's handled properly. Some people would rather not, but if you want you should be able to walk out on that narrow ledge, right up to the point where you can't go any further, and then stop. Gracefully. OOM-killer is like taking you right up to the edge of the cliff, then throwing you off and saying it's your own damn fault.
the idea behind the OOM killer was to prevent the kernel from panicing...
Fine, but there are other ways as well.
...and instead leave a working system
If that's the goal, it fails, because it makes no such guarantee that your system will be working in any intuitive or useful sense of the word.
Rik is an extremely bright (and likeable) guy, but his adherence to the OOM killer concept is disappointing. I've seen a lot of dumb ideas gain currency in the computing community or some part of it; OOM killer is the dumbest. If your process was allowed to exist in the first place, it should not be killed by the VM system. The worst that should happen is that it gets suspended with all of its pages taken away. If that doesn't free up any memory then neither would killing it (modulo some metadata - read on). If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up - which won't happen if you killed it. There are only two differences between the two approaches:
Suspension does not take irrevocable action; the suspended process can still be restarted.
Suspension bears the cost of retaining the metadata for the suspended process so it can be restarted.
The usual whine from OOM-killer advocates is that you can still get into a situation where all of that retained metadata clogs up the system and essential system functions can't allocate pages. However, that's preventable too. All you need to do is preallocate a special pool of memory that's only available for use by those essential system processes - either individually or collectively. The size of that pool and the exact details of how it gets allocated (e.g. which processes are considered essential) could be treated as site-specific tuning parameters. The same idea can then be further generalized to allow definition of multiple private pools, creating a semi-hard barrier between different sets of tasks running on the system (if you want one; the default pool is still there otherwise). This actually fits in very nicely with other things like processor affinity and NUMA-friendly VM, which I know because I once worked on a kernel that had all of these features.
In short, there's no need for the OOM killer. Plenty of systems, many of which handle extreme VM load much better than Linux, have been implemented without such a crock. Rik contends that a lot of people make suggestions without actually understanding the problem, and he's right, but I also submit that sometimes he also rejects suggestions from people who do know what they're talking about. This row has been hoed before, and Rik's smart enough that he should know to avoid the NIH syndrome that afflicts so many of the other Linux kernel heavyweights.
Any network programmer worth half a grain of salt would know about the problems inherent in using UDP
Perhaps more importantly, within days - or quite likely hours - of any such braindead application being deployed, any network engineer worth half a grain of salt will figure out to deal with it. Ports (either logical UDP port numbers or physical phone-line ports) will be throttled or blocked PDQ. Ingress points will deny UDP entirely if they have to. As others have pointed out, there are plenty of network programmers not worth half a grain of salt, but a few strategically placed people with half a clue apiece can prevent the former group from doing any serious damage.
The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people.
...nor does it allow any arbitrary right to be claimed. How about that right to public urination, eh? Can the government deny or disparage that right? Of course it can. The attitude that the ninth allows people to claim whatever rights they want, just because they want, is the Constitutional equivalent of solipsism and has been repeatedly rejected by the courts. All the ninth says, in practical terms, is that the government *must have a reason* for limiting people's freedom, and libel or breach of contract are quite sufficient reasons in the case of anonymity.
Good thing I never said that, then. For God's sake, try reading the Constitution. Article I, Section 8 explicitly charges Congress to "provide for the common defense and general welfare of the United States" etc. etc. and then "To make all laws which shall be necessary and proper for carrying into execution the foregoing powers". The Tenth Amendment notwithstanding, this phrasing can be and has been interpreted very broadly to allow legislation on any matter that Congress considers necessary to the "general welfare" of the United States. The courts have, in general, upheld this interpretation and have only struck down laws that conflict with specifically granted rights (or states' rights).
But doesn't the Tenth Amendment grant to people other unenumerated rights? No, it does not. Here's the text:
The powers not delegated to the United States by the Constitution, nor prohibited by it to the states, are reserved to the states respectively, or to the people.
Note that the word "rights" does not appear. The Tenth Amendment is about powers, not rights, and devolves power to the state or "the people", not to individual persons. It cannot be used to support fabrication of new rights. It cannot be used to say, for example, that a right of public urination is sacrosanct and may not be limited by the government in the interests of common welfare (specifically health). This supposed "right to anonymity" is no different. It's a right not recognized by the Constitution, nor is it implied or supported by the Constitution except through the most egregious word-twisting. Anonymity is allowable and might even be considered beneficial, and that benefit might even be considered in court when deciding issues of common welfare (as in the previously cited case) but it is not protected any more than public urination is...and people like you prove that the similarity doesn't end there.
Let me repeat: there is no Constitutional basis for a "right to anonymity". If you want to claim such a right you'll have to justify it by some other means. Deal with it.
First off, that's basically a public-interest argument, not an individual-rights argument. Only the last sentence is really relevant, and even then it only posits that the option to remain anonymous is *an aspect* of free speech, not a separate right in itself. As previously pointed out, free speech is not infinitely free, and there's plenty of precedent for setting aside some aspect of that freedom based on public-interest arguments (e.g. pornography, incitement to riot). You might not like it, but the same Constitution and Supreme Court in which you seem to have such faith have allowed it.
Of course there is [a right to anonymity], and the Supreme Court has upheld it.
There is not, and they have not. It's very important to distinguish between what is guaranteed by the Constitution itself, what has been upheld by legal word-twisting and precedent in the two centuries since, and what doesn't even meet that standard. The Constitution guarantees neither privacy nor anonymity. Courts have constructed a right of privacy, on pretty dubious Constitutional grounds IMO, but no specific right to anonymity has been generally accepted.
Freedom of speech includes the right to not be compelled to speak things one does not want to, such as one's identity.
The Fifth Amendment says that people cannot be made to testify against themselves. However, interpreting that as a general right to conceal or destroy information to avoid legal responsibility would be absurd. Many people are in jail, and rightly so, for obstruction of justice because they tried that. Furthermore, the Fifth says nothing about any right of other people to avoid testimony. Your name may be revealed pursuant to a properly authorized search warrant (which is not testimony) or by other people, and the Fifth doesn't have a damn thing to do with it in either case.
And the Constitution does not grant rights; it enumerates the specific powers of the federal government. The question should not be "does the Constitution grant individuals the right to do X" but "does the Constitution empower the government to regulate X".
Section 8 of the Constitution charges Congress - and, by extension, the government in general - to "provide for the common defense and general welfare of the United States". To do this, they must have the power to enforce the law. Obviously, the government must respect people's rights in the enforcement of laws, but as noted previously no specific right to anonymity has gained acceptance by the courts. The laws against libel and breach of contract have been held to be Constitutional, and these particular cases do not seem to involve any abridgement of individual rights that really do exist. Legally speaking, there's nothing wrong going on in these cases. One could well make a moral or philosophical argument about the outcomes, but arguments based on a combination of "Constitution as Sacred Document" and fabrication of rights never hinted at by the Constitution are non-starters.
...these particular cases don't worry me too much. Consider:
Varian case: 14,000 messages? Man, these guys were busy. That's a concerted effort to defame the company. The defendant's quote is particularly amusing. Companies don't have as free a hand as he seems to think (let's see how far they'd get posting 14,000 messages to message boards) and he did just a little more than say "I disagree" or "the CEO is ignorant" according to the article. He comes across as a sleazeball making excuses and hoping to get off with a wink and a nod.
Intel case: the issue is spam, not employee loyalty. If all spammers got fired from their jobs, most people here would probably like that, and it just so happens that Intel had the ability to make it happen in this case.
printCafe: libel and breach of confidentiality. Case closed.
Let's face it, folks: there is no right to anonymity. Check the Constituion if you want. It's not there. Come to think of it, there's no right to privacy either, but that's a different debate. The whole notion of rights is based on assumptions about responsible use of those rights; check Locke et al for that one. The right to free speech does not imply the right to shout "fire" in a crowded theater (Oliver Wendell Holmes, I think); similarly, it does not imply the right to commit libel or breach a valid confidentiality clause in an employment contract. Non-competes might be unenforceable, but that's totally irrelevant; the validity of confidentiality as a term of any valid contract has never been seriously challenged in the courts.
Now, should employers be able to punish employees for statements made on their own time, at their own expense (if any), that are neither libelous nor a breach of confidentiality? That's a whole different question. So far the answer is no, and so far the law still recognizes that. Don't count on that lasting very long, but that's the way it is today; none of the case in the article imply otherwise. The only thing that's threatened by such precedence is the non-existent but much-presumed right to be an anonymous asshole, and the quicker people learn that they have no such right the better.
P.S. For those who are using this as an excuse to go on an anti-corporatist rant, consider this: if a company posted 14,000 defamatory messages about an employee, they'd be just as liable. The only reason we don't hear about such cases is that such behavior requires a certain level of obsession, and companies tend toward a shortage rather than an excess of attention paid to employees.
A lot of people seem to be forgetting that objects can be used to represent algorithms or protocols instead of GUI widgets or physical things, and that subclassing still applies. It's very easy to imagine, for example, a MonteCarlo class or a FiniteElement class with virtual methods for the equations to be applied to each element/unit/whatever. It's much cleaner and more maintainable than explicit dispatch tables and function pointers, and never even mind the cut-and-paste approaches that many scientific code is still based on. Various notational conveniences such as function overloading and default arguments could also be useful.
Sure, the OOP literature tends to give different sorts of examples, but the basic tools are still useful if you just allow yourself to think in terms of relationships between algorithms instead of between actual objects.
Re:Speaking of laptop power savings: LED backlight
on
Via One-ups Transmeta
·
· Score: 3, Interesting
So why don't we see some low-power LED-light screens?
Very simply, because LEDs aren't powerful enough. They might seem pretty bright when viewed directly, but when you're putting that light through a lossy backlight assembly onto the relatively large area of a laptop screen, and hoping that the result is sufficient to counteract ambient glare, you get a different impression. Frontlights are even worse.
Some vendors have tried replacing standard CCFLs with LEDs in PDA applications, where the screen size is smaller, and even there it has led to "customer acceptance issues". Translation: customers hated it. For the larger screens that laptops use, current-generation LED technology doesn't even merit serious consideration. With any luck, somebody will earn a Nobel prize figuring out how to make an ultra-bright LED that can compete with CCFL, but I wouldn't count on it.
In the case of MSN messenger I assume that the client keep some sort of a connexion open with the central messenging server.
Yeah, that scales really well. Requiring that people leave outbound connections open to centralized servers for weeks at a time just so they can receive notification when events happen is just really bad design. Revealing internal IP addresses is also bad. Fortunately, SOCKS already solves enough of this problem to be useful (though it has its warts) and is supported by most programs that need to do this sort of thing.
because of our extremism when it comes to copyright law, we ban technologies that threaten copyright interests whether or not they have legitimate, independent uses
This is my favorite part not because it's the most correct, but because it's the most thought-provoking (for me). It's like the doctrine of "substantial non-infringing use" stood on its head; I'm not sure where that leads us, but I'm sure I'll enjoy puzzling it out.
For what it's worth, I've written my own review. It's oriented toward those familiar with the book, and contains some "spoilers" (for those who, unlike me, think a film adaptation of a well-known work can contain spoilers). Enjoy!
Slashdot Mirror
Really? Can you explain the 960, then, or the acquisition of StrongARM/XScale, or the IXP network processors, or any of the other stuff you can read about in the "Applied Computing" section of Intel's developer website (especially communications and networking)? No, sir, Intel has displayed quite a bit of interest in the embedded market.
IIRC, 2.4.10 was the first 2.4 kernel with the AA VM. Yes, it was a mess, but I don't think advances since then explain a 10% performance difference for this type of benchmark.
I also don't know for sure that OBL used 2.4.10. They said they used SuSE 7.3, and SuSE's page for 7.3 says it uses 2.4.10, but that doesn't mean the benchmark used that version. Overall, there do seem to be a few things about the benchmark that give legitimate cause for suspicion. For example, I couldn't find the actual benchmark programs, or even a description, and why the hell were they testing on an HP Omnibook (700MHz P3) instead of a more realistic desktop system, and why did they build the code for a WinXP system on a Win2K system? Very odd.
...except that they didn't, in this case, and the article - which you obviously didn't read - even suggests some reasons why that might not always be the case.
I'm surprised that nobody has commented on what might be the most interesting result on these tests - that the same code produced by the same compiler runs 10% faster on Windows XP than on Linux (2.4.10, according to SuSE's description of 7.3). Sure, the "kernels"[1] used by the benchmark might not be as representative of real life as we'd like, but this should still be cause for concern. Kernel developers have flamed each other endlessly over smaller differences on less comprehensive benchmarks between the Arcangeli and van Riel VM systems. Do we have to go through a Mindcraft-like period of denial before anyone starts taking such a result seriously?
[1]The objections about the "kernels" used in the benchmarks not being the same as the "kernel" with which we're all familiar only demonstrate the ignorance of people who don't know that the scientific programming and benchmark communities have been using the term just as long as the OS community. Their usage may be different, but it's just as valid.
I totally disagree. I think chess teaches many important lessons and skills that are quite generally applicable. For example:
Altogether, I think chess provides excellent "mental exercise" as others have said. Almost every day, I find myself using skills that I have learned at the chessboard, such as when I'm thinking "several moves ahead" in traffic or deciding how to respond to some bit of office-political nonsense. Sure, the minutiae of openings and pawn structure and light/dark square complexes don't translate directly into other endeavors, but neither do the precise motions of any physical sport or exercise translate directly into another. Nonetheless, increasing one's strength/endurance/agility in one activity can improve your performance in another, and that's just as true in the mental realm as the physical. Chess is like a health club for the mind; it might not be the real thing, but it prepares you for the real thing.
The first few suggestions - e.g. separate code and data, use secure default configurations - sound great, but I think Schneier and Shostack go a little bit too far when they get to this point:
One year? One year?!? Does Linux do that? Does anyone? I'm sorry, but a year is a damn long time, and this is a time-based business. Making their protocols public at all is a big pill for Microsoft to swallow; expecting them to develop a protocol -which might define much of a new product's functionality - and then sit on their hands for a full year while security experts diddle and competitors get a head start implementing Microsoft's ideas is just ridiculous.
The next part is almost as bad:
Translation: "We feel left out, and the dot-bomb has left us destitute. Send some money our way to make us feel better, and maybe we'll change our tune." Shameless. Constructive engagement with the security community is well and good, but Schneier and Shostak's "suggestion" as given is little short of demanding protection money. Thought experiment: substitute "government" for "Microsoft" in the above and consider whether such an arrangement would qualify as corruption.
Really, if those last few paragraphs had been left out it would have been an excellent article, but they got kind of carried away there at the end. What a shame that an opportunity for a truly constructive dialog was pissed away out of greed like that.
I just have to add a plug here for Prisoners' Dilemma which is a combination von Neumann bio and mathematical exploration of his game-theoretic ideas. There are many other people mentioned in the book, from both Princeton and RAND, who further exemplify the non-correlation between being a genius and being an asshole.
I think this "eccentric genius" meme is one of the ugliest to infect the computer community. People see the luminaries of the field acting in eccentric ways, and imitate the style while possessing none of the substance. If you don't know what I mean, look around. You're in the right forum to see that very phenomenon in action. I'll save my rant for somewhere else.
There are different types and levels of compatibility. The Athlon claims base-instruction-set and register compatibility with the Pentium, but it's not pin-compatible and may also differ in any number of behavioral/timing characteristics. This is one such case. The behavior in question is perfectly acceptable within the bounds of the compatibility and standards compliance that AMD claims.
Because it's the large pages that are (incorrectly) marked as cacheable. No large pages, no incorrect mappings, no problem.
Nope. It's a bug in the OS. Anyone who works with memory systems should know the dangers inherent in mixing cache-coherent and non-coherent accesses to the same memory, and should mark pages accordingly.
It's very tempting to criticize AMD for their handling of speculative writes, but that handling is really irrelevant. It seems to me that the cache line's contents should not be marked dirtybefore the processor has actually written to it (which in this case it never does). Under normal conditions, though, this would only be a performance issue. If a coherent access were made from elsewhere, invalidation and writeback would ensue; the writeback would be unnecessary but not harmful, because it would be writing the same data that were already in main memory. However, the cache wouldn't be involved in the first place if the pages were mapped correctly. There would be no write-allocate, no invalidation, no writeback, and no problem. The invalid mapping turns a slightly silly but legal and normally-harmless processor behavior into a serious coherency problem.
I was really drooling over the 610, which seems to've been discontinued in favor of the 615. What's disappointing is that a large part of the 610's appeal for me was the viewable-in-all-light reflective screen it shared with the higher-priced 760. According to the specs, the 615 is using a boring old transmissive TFT with a backlight. Now I can only get the cooler screen if I pay more $$$ for a 760 that has features I don't want. :-(
You might (or might not) be overcommitting. Up to you. However, even if you are, you're not waiting until the last second and then going postal instead of taking concrete steps sooner to avoid total memory exhaustion. For example you could say that, once you start dipping into the overcommit pool, fork() will start failing but existing processes can continue. You could say that only certain processes that are being allowed to run to completion will be able to allocate new swap space; anyone else will just get suspended the first time they try. Once you have set a high watermark somewhere short of total exhaustion, you can do any number of things, even if you're overcommitting. Some of those measures are pretty drastic, but still better than the OOM killer.
To a certain extent, perhaps, these "softer" approaches just slow down what might be an inevitable march to OOM. In theory, you could still reach the total-exhaustion deadlock that OOM-killer is supposed to deal with, although it really doesn't because it doesn't in any way guarantee that your system will really be any more useable than if the deadlock had occurred. In practice, though, you'd be hard pressed to find a system that (a) allows overcommit, which is only necessary with VM systems that are broken (wrt how much swap they allow) to start with, (b)takes such drastic measures before going OOM, (c) does in fact hit OOM anyway, and (d) would benefit from an OOM killer if it had one. Without such an existence proof, claims that an OOM killer is necessary are pretty bogus.As I've said, these aren't new ideas just off the top of my head. These are approaches that are proven to work. Ask yourself: how is it that so many systems get by just fine without an OOM killer? There are answers out there.
Actually I didn't. I accused other Linux kernel hackers of NIH, and tried to warn Rik about becoming more like them. I know Rik's smarter than that, but sometimes even smart people submit to "common nonsense".
Please don't construct strawmen. Oh wait, that's not just a strawman, it's also circularity. You're assuming that the OOM killer exists, then using that to "prove" that an alternative approach is impossible to implement. Well yeah, an alternative system that both does and does not incorporate the OOM-killer concept is impossible. Congratulations. Well done.
What I'm really saying is that the VM system should ensure that it has other means to deal with memory exhaustion. Disallowing overcommit altogether is one approach, and that has proven quite acceptable for many systems, but there are plenty of other approaches as well. I've briefly sketched out only one; look up the others yourself (the information is available in plenty of places including some OS textbooks).
The phrase "suspended with all of their pages taken away" (which is what I said) includes the case where the pages have already been taken away. English 101.
As for where they go, the obvious answer is not the general swap area, because that's already full. However, that doesn't preclude the existence of a secondary (actually tertiary) swap area that exists only for this purpose. It could also be a percentage of the general swap area, which starts to look very much like the memory-pressure code in the very highly regarded FreeBSD VM, or Solaris, etc. The point is that there's a middle ground between "no overcommit at all" and "if you allow overcommit we might shoot you in the head just because we feel like it".
Skepticism is one thing; strawmen and circularity are another. I'm skeptical about the need for an OOM killer.
If you can't start the process, fork() should fail. That way the caller gets an error code and has some hope of doing something genuinely useful.
What I'm saying is that you should never wait that long to detect that condition. Sure, you can disable overcommit entirely, but that's pretty inflexible. Overcommit is a good thing, if it's handled properly. Some people would rather not, but if you want you should be able to walk out on that narrow ledge, right up to the point where you can't go any further, and then stop. Gracefully. OOM-killer is like taking you right up to the edge of the cliff, then throwing you off and saying it's your own damn fault.
Fine, but there are other ways as well.
If that's the goal, it fails, because it makes no such guarantee that your system will be working in any intuitive or useful sense of the word.
Rik is an extremely bright (and likeable) guy, but his adherence to the OOM killer concept is disappointing. I've seen a lot of dumb ideas gain currency in the computing community or some part of it; OOM killer is the dumbest. If your process was allowed to exist in the first place, it should not be killed by the VM system. The worst that should happen is that it gets suspended with all of its pages taken away. If that doesn't free up any memory then neither would killing it (modulo some metadata - read on). If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up - which won't happen if you killed it. There are only two differences between the two approaches:
The usual whine from OOM-killer advocates is that you can still get into a situation where all of that retained metadata clogs up the system and essential system functions can't allocate pages. However, that's preventable too. All you need to do is preallocate a special pool of memory that's only available for use by those essential system processes - either individually or collectively. The size of that pool and the exact details of how it gets allocated (e.g. which processes are considered essential) could be treated as site-specific tuning parameters. The same idea can then be further generalized to allow definition of multiple private pools, creating a semi-hard barrier between different sets of tasks running on the system (if you want one; the default pool is still there otherwise). This actually fits in very nicely with other things like processor affinity and NUMA-friendly VM, which I know because I once worked on a kernel that had all of these features.
In short, there's no need for the OOM killer. Plenty of systems, many of which handle extreme VM load much better than Linux, have been implemented without such a crock. Rik contends that a lot of people make suggestions without actually understanding the problem, and he's right, but I also submit that sometimes he also rejects suggestions from people who do know what they're talking about. This row has been hoed before, and Rik's smart enough that he should know to avoid the NIH syndrome that afflicts so many of the other Linux kernel heavyweights.
Perhaps more importantly, within days - or quite likely hours - of any such braindead application being deployed, any network engineer worth half a grain of salt will figure out to deal with it. Ports (either logical UDP port numbers or physical phone-line ports) will be throttled or blocked PDQ. Ingress points will deny UDP entirely if they have to. As others have pointed out, there are plenty of network programmers not worth half a grain of salt, but a few strategically placed people with half a clue apiece can prevent the former group from doing any serious damage.
...nor does it allow any arbitrary right to be claimed. How about that right to public urination, eh? Can the government deny or disparage that right? Of course it can. The attitude that the ninth allows people to claim whatever rights they want, just because they want, is the Constitutional equivalent of solipsism and has been repeatedly rejected by the courts. All the ninth says, in practical terms, is that the government *must have a reason* for limiting people's freedom, and libel or breach of contract are quite sufficient reasons in the case of anonymity.
Good thing I never said that, then. For God's sake, try reading the Constitution. Article I, Section 8 explicitly charges Congress to "provide for the common defense and general welfare of the United States" etc. etc. and then "To make all laws which shall be necessary and proper for carrying into execution the foregoing powers". The Tenth Amendment notwithstanding, this phrasing can be and has been interpreted very broadly to allow legislation on any matter that Congress considers necessary to the "general welfare" of the United States. The courts have, in general, upheld this interpretation and have only struck down laws that conflict with specifically granted rights (or states' rights).
But doesn't the Tenth Amendment grant to people other unenumerated rights? No, it does not. Here's the text:
Note that the word "rights" does not appear. The Tenth Amendment is about powers, not rights, and devolves power to the state or "the people", not to individual persons. It cannot be used to support fabrication of new rights. It cannot be used to say, for example, that a right of public urination is sacrosanct and may not be limited by the government in the interests of common welfare (specifically health). This supposed "right to anonymity" is no different. It's a right not recognized by the Constitution, nor is it implied or supported by the Constitution except through the most egregious word-twisting. Anonymity is allowable and might even be considered beneficial, and that benefit might even be considered in court when deciding issues of common welfare (as in the previously cited case) but it is not protected any more than public urination is...and people like you prove that the similarity doesn't end there.
Let me repeat: there is no Constitutional basis for a "right to anonymity". If you want to claim such a right you'll have to justify it by some other means. Deal with it.
Take your own advice.
First off, that's basically a public-interest argument, not an individual-rights argument. Only the last sentence is really relevant, and even then it only posits that the option to remain anonymous is *an aspect* of free speech, not a separate right in itself. As previously pointed out, free speech is not infinitely free, and there's plenty of precedent for setting aside some aspect of that freedom based on public-interest arguments (e.g. pornography, incitement to riot). You might not like it, but the same Constitution and Supreme Court in which you seem to have such faith have allowed it.
There is not, and they have not. It's very important to distinguish between what is guaranteed by the Constitution itself, what has been upheld by legal word-twisting and precedent in the two centuries since, and what doesn't even meet that standard. The Constitution guarantees neither privacy nor anonymity. Courts have constructed a right of privacy, on pretty dubious Constitutional grounds IMO, but no specific right to anonymity has been generally accepted.
The Fifth Amendment says that people cannot be made to testify against themselves. However, interpreting that as a general right to conceal or destroy information to avoid legal responsibility would be absurd. Many people are in jail, and rightly so, for obstruction of justice because they tried that. Furthermore, the Fifth says nothing about any right of other people to avoid testimony. Your name may be revealed pursuant to a properly authorized search warrant (which is not testimony) or by other people, and the Fifth doesn't have a damn thing to do with it in either case.
Section 8 of the Constitution charges Congress - and, by extension, the government in general - to "provide for the common defense and general welfare of the United States". To do this, they must have the power to enforce the law. Obviously, the government must respect people's rights in the enforcement of laws, but as noted previously no specific right to anonymity has gained acceptance by the courts. The laws against libel and breach of contract have been held to be Constitutional, and these particular cases do not seem to involve any abridgement of individual rights that really do exist. Legally speaking, there's nothing wrong going on in these cases. One could well make a moral or philosophical argument about the outcomes, but arguments based on a combination of "Constitution as Sacred Document" and fabrication of rights never hinted at by the Constitution are non-starters.
...these particular cases don't worry me too much. Consider:
Let's face it, folks: there is no right to anonymity. Check the Constituion if you want. It's not there. Come to think of it, there's no right to privacy either, but that's a different debate. The whole notion of rights is based on assumptions about responsible use of those rights; check Locke et al for that one. The right to free speech does not imply the right to shout "fire" in a crowded theater (Oliver Wendell Holmes, I think); similarly, it does not imply the right to commit libel or breach a valid confidentiality clause in an employment contract. Non-competes might be unenforceable, but that's totally irrelevant; the validity of confidentiality as a term of any valid contract has never been seriously challenged in the courts.
Now, should employers be able to punish employees for statements made on their own time, at their own expense (if any), that are neither libelous nor a breach of confidentiality? That's a whole different question. So far the answer is no, and so far the law still recognizes that. Don't count on that lasting very long, but that's the way it is today; none of the case in the article imply otherwise. The only thing that's threatened by such precedence is the non-existent but much-presumed right to be an anonymous asshole, and the quicker people learn that they have no such right the better.
P.S. For those who are using this as an excuse to go on an anti-corporatist rant, consider this: if a company posted 14,000 defamatory messages about an employee, they'd be just as liable. The only reason we don't hear about such cases is that such behavior requires a certain level of obsession, and companies tend toward a shortage rather than an excess of attention paid to employees.
A lot of people seem to be forgetting that objects can be used to represent algorithms or protocols instead of GUI widgets or physical things, and that subclassing still applies. It's very easy to imagine, for example, a MonteCarlo class or a FiniteElement class with virtual methods for the equations to be applied to each element/unit/whatever. It's much cleaner and more maintainable than explicit dispatch tables and function pointers, and never even mind the cut-and-paste approaches that many scientific code is still based on. Various notational conveniences such as function overloading and default arguments could also be useful.
Sure, the OOP literature tends to give different sorts of examples, but the basic tools are still useful if you just allow yourself to think in terms of relationships between algorithms instead of between actual objects.
Very simply, because LEDs aren't powerful enough. They might seem pretty bright when viewed directly, but when you're putting that light through a lossy backlight assembly onto the relatively large area of a laptop screen, and hoping that the result is sufficient to counteract ambient glare, you get a different impression. Frontlights are even worse.
Some vendors have tried replacing standard CCFLs with LEDs in PDA applications, where the screen size is smaller, and even there it has led to "customer acceptance issues". Translation: customers hated it. For the larger screens that laptops use, current-generation LED technology doesn't even merit serious consideration. With any luck, somebody will earn a Nobel prize figuring out how to make an ultra-bright LED that can compete with CCFL, but I wouldn't count on it.
Yeah, that scales really well. Requiring that people leave outbound connections open to centralized servers for weeks at a time just so they can receive notification when events happen is just really bad design. Revealing internal IP addresses is also bad. Fortunately, SOCKS already solves enough of this problem to be useful (though it has its warts) and is supported by most programs that need to do this sort of thing.
This is my favorite part not because it's the most correct, but because it's the most thought-provoking (for me). It's like the doctrine of "substantial non-infringing use" stood on its head; I'm not sure where that leads us, but I'm sure I'll enjoy puzzling it out.
For what it's worth, I've written my own review. It's oriented toward those familiar with the book, and contains some "spoilers" (for those who, unlike me, think a film adaptation of a well-known work can contain spoilers). Enjoy!