That was a real test of engineering. By the current standards, Google (probably) has the largest supercomputer in the world.
Sorry, but no. As big as one of Google's several data centers might be, it can't touch one of these guys for computational power, memory or communications bandwidth, and it's darn near useless for the kind of computing that needs strong floating point (including double precision) everywhere. In fact, I'd say that Google's systems are targeted to an even narrower problem domain than Roadrunner or Intrepid or Ranger. It's good at what it does, and what it does is very important commercially, but that doesn't earn it a space on this list.
More generally, the "real tests of engineering" are still there. What has changed is that the scaling is now horizontal instead of vertical, and the burden for making whole systems has shifted more to the customer. It used to be that vendors were charged with making CPUs and shared-memory systems that ran fast, and delivering the result as a finished product. Beowulf and Red Storm and others changed all that. People stopped making monolithic systems because they became so expensive that it was infeasible to build them on the same scales already being reached by clusters (or "massively parallel systems" if you prefer). Now the vendors are charged with making fast building blocks and non-shared-memory interconnects, and customers take more responsibility for assembling the parts into finished systems. That's actually more difficult overall. You think building a thousand-node (let alone 100K-node) cluster is easy? Try it, noob. Besides the technical challenge of putting together the pieces without creating bottlenecks, there's the logistical problem of multiple-vendor compatibility (or lack thereof), and then how do you program it to do what you need? It turns out that the programming models and tools that make it possible to write and debug programs that run on systems this large run almost as well on a decently engineered cluster as they would on a UMA machine - for a tiny fraction of the cost.
Economics is part of engineering, and if you don't understand or don't accept that then you're no engineer. A system too expensive to build or maintain is not a solution, and the engineer who remains tied to it has failed. It's cost and time to solution that matter, not the speed of individual components. Single-core performance was always destined to hit a wall, we've known that since the early RISC days, and using lots of processors has been the real engineering challenge for two decades now.
Disclosure: I work for SiCortex, which makes machines of this type (although they're probably closer to the single-system model than just about anything they compete with). Try not to reverse cause and effect between my statements and my choice of employer.
They make it sound like the decision not to support FF3 was a recent one. Bovine excrement. They'd lost interest months ago, and never intended to add such support. I got tired of waiting a while ago, and even wrote about my switch just this past week. The same thing is happening with lots of other extensions too, such as S3 Organizer which I've also abandoned. There's an old saying that nobody sees the bodies until the tide goes out, and a major release of something like Firefox is the tide going out. That's when you get to find out about all the projects whose developers actually wandered off months ago, but nobody had noticed because nothing had broken yet. Now it's broken. It's not a big surprise in most cases, but it is a little disappointing from an organization with the resources and reputation of Google.
I wasn't familiar with the problems; I looked, and saw lots of descriptions of working systems. It's hardly what I'd call cherry picking.
I'm calling bullshit on that. What did you search for? I did the most obvious search - "Dell E1505 Linux" - and the first page is pretty much nothing but HOWTOs explaining how to make various things work, or "will it work" questions on Linux forums followed by "yeah, I got it to work, but I had to..." kinds of responses. Clearly these kinds of problems are common.
If only it had some bearing on the rest of your comment.
Now you're just being a slashdick. My very next sentence drew the connection between that and what it implies about how less experienced users might perceive Linux based on these flaws. You might not make the same connection, but it's as relevant as your anecdotes based on limited experience and knowledge.
Yes, a lot of people (including me) have posted information about how to get it working. Why? Because it doesn't work out of the box. We wouldn't have bothered if it did, now would we? I just installed Ubuntu Hardy on mine mere weeks ago. At least the video and wireless drivers kinda-sorta worked this time - they didn't work at all when I first got the machine and put Edgy on it, which was well after either came out - and I could use EnvyNG to get the right video driver so I could use full resolution and acceleration. On the other hand, I'm still stuck with ndiswrapper and the Broadcom driver if I want wireless that works at more than one-fifth speed, maintains its AP associations for more than a few minutes, or survives a suspend/resume cycle, because b43 can't do any of those things.
So what am I talking about? Real-world experience shared by many people on a millions-of-units machine, not some Google cherry-pickings to support your biases. I've been using Linux longer and on more systems than 99% of the people here, and my day job is to write kernel code for big piles of interconnected Linux systems (on an unusual architecture at that). If I have to spend one minute finding and tweaking extra drivers so an extremely common system will work properly, then that means someone with less knowledge will have an even less gratifying experience and that means somebody upstream didn't finish their job.
Oddball hardware? Like a millions-of-units Dell E1505, on which the Broadcom wireless doesn't work out of the box and one of the most popular video-card upgrades doesn't either? What percentage of the common hardware out there have you used? 0.01% maybe? Don't overgeneralize from your own experience, whether it's good or bad. Look at actual statistics about actual hardware used by actual people before you try to make the "oddball hardware" excuse. You've been fortunate. Leave it at that.
We still don't know how to handle congestion in the middle of an IP network. The best we have is "random early drop", but that's a hack.
With all due respect, RED is not the best we have. Stochastic Fair Blue, for example, is clearly superior - perhaps not good enough for it to substitute for admission control, but still better.
soft engineering/programming is a subset of computer science
One could just as well argue the exact opposite. The things you learn in CS are useful to a working programmer, but very CS curricula that cover things like source control and debuggers explicitly; usually you're just supposed to pick those up on your own in the process of completing your assignments. Important skills like writing a decent spec, reviewing a spec, laying out a realistic schedule, running a productive meeting, conducting an intervew, etc. get even shorter shrift, as does the entire business side of real-world programming. CS profs only care about computational cost, not human or financial.
But I'm not really arguing that either is a subset of the others. The real point is that CS and programming merely intersect, and not nearly as much as some people seem to think. That's OK, colleges aren't necessarily supposed to be about job training, but - as someone who has been a corporate/academic liaison to some of the best CS programs in the country and mentored grad students - I'll be damned if I'll let some undergrad claim that what I do is a mere subset of CS. That's like saying what a CEO does is a mere subset of accounting.
If you bought this computer and are looking for something to do with it, set it up as a file server or something (by putting Windows Home Server on it).
Better yet, buy a $10 hammer and use that to smash your hard disk. That's the level of file service that Windows Home Server provides, and I stopped reading as soon as I saw that suggestion.
There was an Israeli company several years ago called Constellation 3D (originally TeraStor) promising the same things based on the same fluorescent multilayer buzzwords. They failed, and there were a couple of scandals including one about a rigged demo. None of the names I see on the Mempile website ring a bell, but I still don't think I'll hold my breath waiting for this crew to deliver the goods.
. . . if you want to repeat the experience of having the author die before he finishes his darn series. Don't get me wrong, I thought the first couple of SoIaF books were among the best fantasy I'd read, but then it became apparent that he was going to keep adding more characters and locations and organizations and plotlines than he was shedding . . . just like Jordan and WoT. Robin Hobb's Farseer and Tawny Man trilogies are just as good, and they do reach resolutions. I'm really really hoping that Greg Keyes's Thorn and Bone series doesn't suffer the same kind of rot, because it's just as good too. Simple rule: if you're still discovering new civilizations, secret societies, or kinds of magic in the third book, give up because the author's obviously adrift in a sea of unconnected ideas.
Read it again; that was 1995, not 1985. Domains were free for a long time.
In 1995 the NSF authorized NSI to begin charging registrants (of.org and.net as well as.com) an annual fee, for the first-time since its inception.
(The grammar error is the responsibility of the wikidork who made the entry.)
I wasn't in early enough to get a domain for free, but I do have one for which I paid a one-time fee.
Well put. Just because there are many alternatives doesn't mean we should stop trying new things. Somehow, though, it's not surprising that someone at Intel would be pushing for earlier standardization. They're a player in this space, and I'm sure they'd like to tie everyone to their chosen flavor before the market heats up even more.
With hundreds of drugs out there, is anyone really dumb enough to think "yet another one" will fix their illness? With hundreds of energy sources out there, is anyone really dumb enough to think "yet another one" will solve our problems? With hundreds of CPU/computer architectures, is anyone really dumb enoguh to think "yet another one" will solve our problems?
Sometimes the answer is yes, because it's not "just another" one. Sometimes the first hundred alternatives all suck, but the hundred-and-first is the one that puts all the others to shame. Look up the story of Edison trying different materials for the first light bulb. Choice overload is a real problem, sometimes #101 sucks just as much as 1-100, but that's no excuse for stifling innovation. Parallel programming languages and frameworks are not like jam. They're not matters of personal taste alone. There are empirical measures by which one can determine whether one approach works better than another, either in one environment or across a variety. Also, again unlike jam, parallel programming is still a poorly understood problem domain. The potential for major conceptual breakthroughs is still there, and by their very nature we cannot predict when or where such breakthroughs will occur. Therefore a lot of different people have to try a lot of different things. That's how innovation works, and how progress is made.
Standardizing too early is at least as bad as standardizing too late. Competition works. It might be messy sometimes, but it still beats the alternatives.
That's an order of magnitude less expensive than other solutions.
Sure, and a Hyundai is cheaper than a Porsche, too. What's the difference in performance? In reliability? Don't compare GigE to 4Gb/s FC, don't compare a cheap box with multiple SPOFs (Single Points Of Failure) to a fully redundant disk array, and by the way don't include the price of switches and cables for one alternative while omitting them from the other. Make a genuine apples-to-apples comparison, show us numbers to prove that it's apples to apples, and you'll have something. Until then, blathering about ZFS's supposed data-integrity benefits while proposing an inherently unreliable hardware platform just looks like more of the astroturf Sun has become famous for.
Yes, CISC has better work per instruction, except for one glaring issue I'll get to in a moment, but - for various reasons explained throughout H&P - it loses on the other two and thus overall. That's why nobody's making new processors that are CISC internally any more; they just couldn't hit the issue widths and clock speeds are achievable with a RISC core (even if that core has a CISC ISA bolted on the front). What's missing here is that not all work is useful work. As anyone who has accidentally coded an infinite loop knows, executing lots of instructions is not necessarily a good thing. The glaring issue I mentioned earlier is that a lot of the instructions executed on a register-poor architecture like x86 are not doing useful work. Register thrashing means i-cache bandwidth is wasted fetching instructions which are then used to waste d-cache bandwidth, which more than outweighs any advantage from variable-length instructions.
So, you say, wouldn't variable-length instructions on a register-rich processor be the best of both worlds? Not so fast. A regular instruction set makes superscalar execution easier because it means that multiple instructions can be fetched literally at the same time without having to examine the first one to figure out where the second one begins and so on. It also makes deeper pipelines easier because it allows many internal activities (e.g. register allocation, hazard detection) to start after a simple pre-decode stage, in parallel with the remainder of decode. Either way, regular instruction sets allow for more parallelism - and parallelism in some form is the generally the key to CPU performance. If you're willing to give up performance by eschewing most modern processor-design techniques, which might be the case for a deeply embedded system with extreme size and/or power requirements, then variable-width instructions might still be a reasonable choice. In that case you might as well use an older architecture; there are plenty to choose from. For new processor designs, though, variable-width instructions are almost invariably a way to lose.
The talking points in this story so exactly mirror those I've seen in the last couple of days elsewhere (especially the "angry about other formats" one and the overuse of "negative buzz" just like on digg yesterday) that coincidence seems an unlikely explanation. Somebody's trying very hard to "get the word out" on blogs and forums, and probably being paid to do it. It's not clear whether Cymfony merely failed to notice the astroturf or are complicit in it but, since they call themselves a "market influence" (PR) vendor, active involvement seems a whole lot more likely than naivete. Either way, Slashdot shouldn't be posting disguised press releases.
Full disclosure: none to make. I don't own Blu-Ray or HD-DVD, or even an HDTV. I don't intend to own any of those things soon, either, and I have no other financial connection (that I'm aware of) to any of the organizations that do have a horse in this race. I just really hate astroturf.
Do what, now? Stay awake while the teacher mumbles about stuff you already know?
If you already knew it, you wouldn't be failing or getting low grades like dosius said he was. Clearly he either didn't know it for the tests, or couldn't be bothered doing the assignments (or doing a good job on them), or both. All of those possibilities dovetail nicely with KingSkippus's response. Being bored is not an excuse for doing poorly. If you're that smart you should be able to pull decent grades and still read Heinlein in class . . . like I did.
Unfortunately, on many OSes (e.g. the older version of Linux we're forced to use at work) it's nearly impossible to distinguish swapping that might indicate a problem from swapping that merely indicates plain old file-cache creep. People have mentioned having more limits on swap aggressiveness, but without similar controls on file-cache aggressiveness that loses much of its utility.
The motivation behind PASIS is to expose all options and possibilties.
...which is exactly what I would want from a research project, and why I cited it. When I saw it at a PDL open house as a representative from EMC I was very impressed with how thoroughly some of those tradeoffs had been examined, and couldn't have cared less that it was nowhere near being a completely functional system. Producing a completely functional system is what I was doing, in a commercial context, though it turned out that my employer was too short-sighted to make use of the result. Even then there are plenty of precedents for what Cleversafe is doing, though I'd say GoogleFS is not as close as HiveCache (based on MojoNation, as is MNet) or Mango's Medley (which I also worked on). I apologize if you feel I misrepresented PASIS, which I meant to praise, but I stand by my point that the field is full of both commercial and academic precedents for what has been presented here as though it were innovative. Everything I see on their site indicates that it's a pretty straightforward synthesis of existing ideas.
This is so not-new it's not even funny. I've already seen FreeNet and MNet mentioned as precursors, which is appropriate. Dozens of other P2P "filesystems" (in quotes because I don't believe it's truly a filesystem unless it's fully integrated into the OS) and block-level data stores have done this. Probably the one that most thoroughly examined the inherent tradeoffs, and that's most directly based on Shamir's IDA work, is PASIS at CMU. Presenting Cleversafe as the first to move in this direction is an insult to those who have gone before.
If it happens with a dedicated controller such as ServeRAID, then my first hunch would be that the chipset isn't handling memory contention very well. We used to see this at Dolphin a lot; the Intel chipsets at the time would behave terribly if there was any kind of serious memory traffic coming from the "far side" of the memory controller. This could also be a problem on the "softmodem-like" RAID controllers, where one core is trying to bring previously DMAed data in for its XOR while the other is trying to do its normal stream of memory accesses. It wouldn't be quite the same kind of thrashing as in the previous case, but it's very easy to imagine that it would still occur.
Here we see an eye-for-an-eye. Gandhi said if we followed that rule the whole world would be blind.
You're in luck, then, because this isn't really eye for an eye. It's poetic justice - "hoist by their own petard" - which is a bit different. Consider the agents involved. "Eye for an eye" would be someone else initiating an action against the MPAA using their own tactics. This is someone else drawing attention to an action that MPAA themselves initiated. The MPAA, not someone else, is violating some of the very same laws that the MPAA has rammed down our throats.
good luck finding someone who dresses like you who can provide it
This is where you went from mildly annoying to delusional. Sorry, but unless you're truly one of the top hundred people in your specialty (and there's no evidence in your bio that you're even in the top million) there really are people just as good as you who are willing to wear a suit a few times a year to meet with the people who pay them. Then they'll dress however the heck they like the rest of the time while they get the work done.
If you prefer to buy crap from other suits, go for it. Your competitors, who are also smarter than you, will happily deal with us long-haired freaks to get the good stuff.
That cuts both ways. If you want to get peanuts from other longhairs, go for it. Your competitors, who are also smarter than you, will happily deal with the suits to get the good stuff. There's nothing wrong with dressing down - I wore shorts to work yesterday - but the person who's more flexible will always have an advantage over the person who is less so. If you can't or won't dress any other way than what you're used to, that sends a message that you're inflexible and it will cost you business. You might only need to do it once, ever, with any given customer just to show you can, but it does make a difference. If your attitude about dress codes really hasn't hurt you it's because all the damage had already been done by your other shortcomings.
Slashdot Mirror
Sorry, but no. As big as one of Google's several data centers might be, it can't touch one of these guys for computational power, memory or communications bandwidth, and it's darn near useless for the kind of computing that needs strong floating point (including double precision) everywhere. In fact, I'd say that Google's systems are targeted to an even narrower problem domain than Roadrunner or Intrepid or Ranger. It's good at what it does, and what it does is very important commercially, but that doesn't earn it a space on this list.
More generally, the "real tests of engineering" are still there. What has changed is that the scaling is now horizontal instead of vertical, and the burden for making whole systems has shifted more to the customer. It used to be that vendors were charged with making CPUs and shared-memory systems that ran fast, and delivering the result as a finished product. Beowulf and Red Storm and others changed all that. People stopped making monolithic systems because they became so expensive that it was infeasible to build them on the same scales already being reached by clusters (or "massively parallel systems" if you prefer). Now the vendors are charged with making fast building blocks and non-shared-memory interconnects, and customers take more responsibility for assembling the parts into finished systems. That's actually more difficult overall. You think building a thousand-node (let alone 100K-node) cluster is easy? Try it, noob. Besides the technical challenge of putting together the pieces without creating bottlenecks, there's the logistical problem of multiple-vendor compatibility (or lack thereof), and then how do you program it to do what you need? It turns out that the programming models and tools that make it possible to write and debug programs that run on systems this large run almost as well on a decently engineered cluster as they would on a UMA machine - for a tiny fraction of the cost.
Economics is part of engineering, and if you don't understand or don't accept that then you're no engineer. A system too expensive to build or maintain is not a solution, and the engineer who remains tied to it has failed. It's cost and time to solution that matter, not the speed of individual components. Single-core performance was always destined to hit a wall, we've known that since the early RISC days, and using lots of processors has been the real engineering challenge for two decades now.
Disclosure: I work for SiCortex, which makes machines of this type (although they're probably closer to the single-system model than just about anything they compete with). Try not to reverse cause and effect between my statements and my choice of employer.
They make it sound like the decision not to support FF3 was a recent one. Bovine excrement. They'd lost interest months ago, and never intended to add such support. I got tired of waiting a while ago, and even wrote about my switch just this past week. The same thing is happening with lots of other extensions too, such as S3 Organizer which I've also abandoned. There's an old saying that nobody sees the bodies until the tide goes out, and a major release of something like Firefox is the tide going out. That's when you get to find out about all the projects whose developers actually wandered off months ago, but nobody had noticed because nothing had broken yet. Now it's broken. It's not a big surprise in most cases, but it is a little disappointing from an organization with the resources and reputation of Google.
Yes, a lot of people (including me) have posted information about how to get it working. Why? Because it doesn't work out of the box. We wouldn't have bothered if it did, now would we? I just installed Ubuntu Hardy on mine mere weeks ago. At least the video and wireless drivers kinda-sorta worked this time - they didn't work at all when I first got the machine and put Edgy on it, which was well after either came out - and I could use EnvyNG to get the right video driver so I could use full resolution and acceleration. On the other hand, I'm still stuck with ndiswrapper and the Broadcom driver if I want wireless that works at more than one-fifth speed, maintains its AP associations for more than a few minutes, or survives a suspend/resume cycle, because b43 can't do any of those things. So what am I talking about? Real-world experience shared by many people on a millions-of-units machine, not some Google cherry-pickings to support your biases. I've been using Linux longer and on more systems than 99% of the people here, and my day job is to write kernel code for big piles of interconnected Linux systems (on an unusual architecture at that). If I have to spend one minute finding and tweaking extra drivers so an extremely common system will work properly, then that means someone with less knowledge will have an even less gratifying experience and that means somebody upstream didn't finish their job.
Oddball hardware? Like a millions-of-units Dell E1505, on which the Broadcom wireless doesn't work out of the box and one of the most popular video-card upgrades doesn't either? What percentage of the common hardware out there have you used? 0.01% maybe? Don't overgeneralize from your own experience, whether it's good or bad. Look at actual statistics about actual hardware used by actual people before you try to make the "oddball hardware" excuse. You've been fortunate. Leave it at that.
There was an Israeli company several years ago called Constellation 3D (originally TeraStor) promising the same things based on the same fluorescent multilayer buzzwords. They failed, and there were a couple of scandals including one about a rigged demo. None of the names I see on the Mempile website ring a bell, but I still don't think I'll hold my breath waiting for this crew to deliver the goods.
Well put. Just because there are many alternatives doesn't mean we should stop trying new things. Somehow, though, it's not surprising that someone at Intel would be pushing for earlier standardization. They're a player in this space, and I'm sure they'd like to tie everyone to their chosen flavor before the market heats up even more.
With hundreds of drugs out there, is anyone really dumb enough to think "yet another one" will fix their illness? With hundreds of energy sources out there, is anyone really dumb enough to think "yet another one" will solve our problems? With hundreds of CPU/computer architectures, is anyone really dumb enoguh to think "yet another one" will solve our problems? Sometimes the answer is yes, because it's not "just another" one. Sometimes the first hundred alternatives all suck, but the hundred-and-first is the one that puts all the others to shame. Look up the story of Edison trying different materials for the first light bulb. Choice overload is a real problem, sometimes #101 sucks just as much as 1-100, but that's no excuse for stifling innovation. Parallel programming languages and frameworks are not like jam. They're not matters of personal taste alone. There are empirical measures by which one can determine whether one approach works better than another, either in one environment or across a variety. Also, again unlike jam, parallel programming is still a poorly understood problem domain. The potential for major conceptual breakthroughs is still there, and by their very nature we cannot predict when or where such breakthroughs will occur. Therefore a lot of different people have to try a lot of different things. That's how innovation works, and how progress is made. Standardizing too early is at least as bad as standardizing too late. Competition works. It might be messy sometimes, but it still beats the alternatives.
You're forgetting the basic formula from Hennessy and Patterson:
Yes, CISC has better work per instruction, except for one glaring issue I'll get to in a moment, but - for various reasons explained throughout H&P - it loses on the other two and thus overall. That's why nobody's making new processors that are CISC internally any more; they just couldn't hit the issue widths and clock speeds are achievable with a RISC core (even if that core has a CISC ISA bolted on the front). What's missing here is that not all work is useful work. As anyone who has accidentally coded an infinite loop knows, executing lots of instructions is not necessarily a good thing. The glaring issue I mentioned earlier is that a lot of the instructions executed on a register-poor architecture like x86 are not doing useful work. Register thrashing means i-cache bandwidth is wasted fetching instructions which are then used to waste d-cache bandwidth, which more than outweighs any advantage from variable-length instructions.
So, you say, wouldn't variable-length instructions on a register-rich processor be the best of both worlds? Not so fast. A regular instruction set makes superscalar execution easier because it means that multiple instructions can be fetched literally at the same time without having to examine the first one to figure out where the second one begins and so on. It also makes deeper pipelines easier because it allows many internal activities (e.g. register allocation, hazard detection) to start after a simple pre-decode stage, in parallel with the remainder of decode. Either way, regular instruction sets allow for more parallelism - and parallelism in some form is the generally the key to CPU performance. If you're willing to give up performance by eschewing most modern processor-design techniques, which might be the case for a deeply embedded system with extreme size and/or power requirements, then variable-width instructions might still be a reasonable choice. In that case you might as well use an older architecture; there are plenty to choose from. For new processor designs, though, variable-width instructions are almost invariably a way to lose.
The talking points in this story so exactly mirror those I've seen in the last couple of days elsewhere (especially the "angry about other formats" one and the overuse of "negative buzz" just like on digg yesterday) that coincidence seems an unlikely explanation. Somebody's trying very hard to "get the word out" on blogs and forums, and probably being paid to do it. It's not clear whether Cymfony merely failed to notice the astroturf or are complicit in it but, since they call themselves a "market influence" (PR) vendor, active involvement seems a whole lot more likely than naivete. Either way, Slashdot shouldn't be posting disguised press releases. Full disclosure: none to make. I don't own Blu-Ray or HD-DVD, or even an HDTV. I don't intend to own any of those things soon, either, and I have no other financial connection (that I'm aware of) to any of the organizations that do have a horse in this race. I just really hate astroturf.
Unfortunately, on many OSes (e.g. the older version of Linux we're forced to use at work) it's nearly impossible to distinguish swapping that might indicate a problem from swapping that merely indicates plain old file-cache creep. People have mentioned having more limits on swap aggressiveness, but without similar controls on file-cache aggressiveness that loses much of its utility.
This is so not-new it's not even funny. I've already seen FreeNet and MNet mentioned as precursors, which is appropriate. Dozens of other P2P "filesystems" (in quotes because I don't believe it's truly a filesystem unless it's fully integrated into the OS) and block-level data stores have done this. Probably the one that most thoroughly examined the inherent tradeoffs, and that's most directly based on Shamir's IDA work, is PASIS at CMU. Presenting Cleversafe as the first to move in this direction is an insult to those who have gone before.
If it happens with a dedicated controller such as ServeRAID, then my first hunch would be that the chipset isn't handling memory contention very well. We used to see this at Dolphin a lot; the Intel chipsets at the time would behave terribly if there was any kind of serious memory traffic coming from the "far side" of the memory controller. This could also be a problem on the "softmodem-like" RAID controllers, where one core is trying to bring previously DMAed data in for its XOR while the other is trying to do its normal stream of memory accesses. It wouldn't be quite the same kind of thrashing as in the previous case, but it's very easy to imagine that it would still occur.
Don't you mean "fix it yourself and provide source to everybody on the internet"?