one can only assume that SCO is using Linus' code.
You can't assume that! All you can assume is that SCO has again demonstrated they have no knowledge of the pedigree of simple, widely used code. Like SCO's malloc fiasco, it's another case of, "Linux has it, but we're older than Linux, so we had it first!" Wrong again, SCO.
And again, none of the files mentioned seem to have anything to do with what SCO is suing IBM for! NUMA, RCU, SMP, JFS-- where are you???
I guess I meant "got screwed" as a euphemism for "was attacked unjustly by the then-evil USSR, kicked ass, but ended up allied with the losing side out of necesity." I still couldn't say you won per se, but you're right that things turned out better than they could have. I've just always thought it sucked that Finland ended up allied with Germany.
Just because the french are the best lobbyists and diplomats and most ruthlessly serve solely their own interests, while demanding from others to serve the public interest, they get their way all the time.
Replace "the french" with "farmers" and we have the same problems in the US. Nobody fights agriculture.
The site selection has nothing to do with anyone's position on Iraq or else France would have the support of the other countries as well. As it stands, they only have the support of the EU for typical reasons.
The Spanish opposition disagrees-- they say that the EU selected the French site because of politics. The NY Times mentions here that the Spanish political losers think Spain's support of the war in Iraq killed the chances of the reactor being built there.
Industry may well have been the States' chief contribution to the defeat of fascism in Europe. This makes good thesis material, but not exciting movies.
Thanks for all your British help in winning the war in the Pacific theatre of WW2, you ungrateful asshole! Yup, your imperial subjects in Singapore sure loved the bang-up job of defence you managed there when you were so handily beating Adolf all by yourself. And where were you in the Pacific after 1942? Commonwealth doesn't count.
And as for the European theatre, I suppose Monty would have run circles around Rommel just the same without the American landings in North Africa. Right. So much for El Alamein. The only victories Britain managed without American help was the sinking of a few Nazi battleships-- Graf Spee and Bismark-- early in the war. By yourselves you had great success at Dunkirk, Norway, the Balkans, Greece, Crete and Singapore. With American help, you managed to recapture Europe and North Africa, but never without American armies at your side.
The pointer arithmetic example just illuminates why there's a distinction between a high-level languages and assembly language. A high-level language should allow you to not have to pick out hidden operations and resequence instructions to use accumulators, registers, memory or cycles efficiently. A basic and correct compiler could do a load and a store to/from memory every time you do an i++ rather than keeping the loop variable in a register. But recognizing that a loop condition variable shouldn't have to be fetched from memory is so trivial it's not really considered much of an "optimization" to avoid it. However, the code is technically correct without. In fact, a load-store-load-etc. on the same address is so ugly that modern processors with ridiculous amounts of instructions in flight and out of order execution would basically ignore the explicit instructions but guarantee things look correct in the end. Intel's so fed up with making optimizing processors that they've decided to mandate hyper-intelligent EPIC compilers with IA64, guaranteeing that well-compiled assembly will bear no resemblence to elegant program code.
Overall, it's probably not worth using unless you really need a compiler that generates fast code.
Yeah! Who needs fast code anyways?? Real C coders use only "#pragma I'll do it my goddamn self!" statements and asm{} blocks! Real men don't need any stinkin' optimizing compilers other than their own beautiful minds.
I'm a little confused about the IBM reference, since if you're using UMC as a fab, you don't get to use IBM cores unless you also use IBM as an ASIC vendor on some level. Unless that has changed in the last 4 years, which I guess is possible.
That was a guess based on their process technology agreements, and upon looking further, it appears I was wrong. UMC's IP catalog.
However, it seems like the CPU core itself is open-source, while a lot of the bonus features on the SoC (System On a Chip) example cited are IP from Flextronics (the the company that did the physical design for this open-source CPU core, which was manufactured by UMC). I can't tell for sure because the site is slashdotted already. The links on PCI, JTAG etc. would presumably tell if all these IP macros (besides the CPU) are open source also -- does anyone know for sure?
Objection! Asked and answered... chances are the PCI and JTAG IP, as well as some of the other stuff, is from UMC, which may get it through alliance with IBM. The JTAG (Joint Test Action Group) specification is public, and it's something more of a methodology (boundary scan and whatnot) than a core. PCI is also a spec, but more of a core than JTAG. Chances are many foundries and ASIC design houses have their own implementations of that spec and others. If there were a good open source implementation, it might save smaller foundries and ASIC forms some development costs.
Sure it is, but to find a quality programmer that actually wants to stop what they're doing and work for you is a little more difficult. The sky is not falling every time qualified candidates don't line up for every mediocre job. There have got to be lots of cruddy code-monkey jobs that can be gladly outsourced-- (Here, please take this complicated bloated ANSI English-language application and localize it with Unicode, but please don't touch anything important or add features.)
They are claiming that IBM misappropriated Unixware trade secrets they learned in the Monteray project. They are also claiming that IBM had a contractual obligation to keep RCU, and NUMA technologies confidential. Expect that argument to be thoroughly demolished by IBM's crack legal team as opposed to SCO's crack-smoking legal team.
Except that we all know they have no leg to stand on there since there's record of several Caldera/SCO employees contributing to Linux development of SMP, NUMA, and RCU.
Low temperatures actually improves data retention in SRAM when it's unpowered
No. I may be missing you point because you say "unpowered," but I can't make sense of what you mean here.
SRAM doesn't need to be refreshed, so data retention in the DRAM sense is a non-issue. If anything, colder temperatures lower resistance and increase leakage and power consumption. Cold in fact increases problems with SRAM cell stability (mismatched cross-couple strengths), and increases the soft error rate from alpha particles. Space applications where cold and radiation are problems avoid SRAM for this reason.
THE INTERNET IS GROWING TOO FAST, AND WILL COLLAPSE UPON ITSELF PRESENTLY.
Is this a segue into the need for IPv6?
IPv6 itself is a good counterpoint to the "upgrades are inevitable" aphorism. And we all know mainframes aren't dead, another misnomer. IPv4 and mainframes and COBOL and everything else-- they're here to haunt us forever.
Shhh!! Don't let everyone else into the sekrit Kucinich Kabal. Don't forget to meetup in the streets outside the next WTO or G7 meeting. Wear all black and bring golf balls.
Slashdot Mirror
But Snoopy already went to space!
And again, none of the files mentioned seem to have anything to do with what SCO is suing IBM for! NUMA, RCU, SMP, JFS-- where are you???
SCO is a member of the Open Group.
I guess I meant "got screwed" as a euphemism for "was attacked unjustly by the then-evil USSR, kicked ass, but ended up allied with the losing side out of necesity." I still couldn't say you won per se, but you're right that things turned out better than they could have. I've just always thought it sucked that Finland ended up allied with Germany.
Industry may well have been the States' chief contribution to the defeat of fascism in Europe. This makes good thesis material, but not exciting movies.
The Battle of Britain counts for something.
I agree. The allies won the war, not America alone, not Britain alone, nor China or Russia. And Finland got screwed either way.
And as for the European theatre, I suppose Monty would have run circles around Rommel just the same without the American landings in North Africa. Right. So much for El Alamein. The only victories Britain managed without American help was the sinking of a few Nazi battleships-- Graf Spee and Bismark-- early in the war. By yourselves you had great success at Dunkirk, Norway, the Balkans, Greece, Crete and Singapore. With American help, you managed to recapture Europe and North Africa, but never without American armies at your side.
The pointer arithmetic example just illuminates why there's a distinction between a high-level languages and assembly language. A high-level language should allow you to not have to pick out hidden operations and resequence instructions to use accumulators, registers, memory or cycles efficiently. A basic and correct compiler could do a load and a store to/from memory every time you do an i++ rather than keeping the loop variable in a register. But recognizing that a loop condition variable shouldn't have to be fetched from memory is so trivial it's not really considered much of an "optimization" to avoid it. However, the code is technically correct without. In fact, a load-store-load-etc. on the same address is so ugly that modern processors with ridiculous amounts of instructions in flight and out of order execution would basically ignore the explicit instructions but guarantee things look correct in the end. Intel's so fed up with making optimizing processors that they've decided to mandate hyper-intelligent EPIC compilers with IA64, guaranteeing that well-compiled assembly will bear no resemblence to elegant program code.
What editors? Some code hack in Bangalore put this article together.
No. I may be missing you point because you say "unpowered," but I can't make sense of what you mean here.
SRAM doesn't need to be refreshed, so data retention in the DRAM sense is a non-issue. If anything, colder temperatures lower resistance and increase leakage and power consumption. Cold in fact increases problems with SRAM cell stability (mismatched cross-couple strengths), and increases the soft error rate from alpha particles. Space applications where cold and radiation are problems avoid SRAM for this reason.
IPv6 itself is a good counterpoint to the "upgrades are inevitable" aphorism. And we all know mainframes aren't dead, another misnomer. IPv4 and mainframes and COBOL and everything else-- they're here to haunt us forever.
Benevolent Microsoft deigns to license its wonderful proprietary technologies to foster interoperability.
Shhh!! Don't let everyone else into the sekrit Kucinich Kabal. Don't forget to meetup in the streets outside the next WTO or G7 meeting. Wear all black and bring golf balls.
Michael Crichton a credulous luddite? No way, you say. Read the foreword to Prey and the book Travels. The guy's a whack-job.
Prey was better the first times I read it: Sphere and The Andromeda Strain.
No, not seriously. ;) I was being facetious.