Slashdot Mirror


Intel's Reworked Microcode Security Fix License No Longer Prohibits Benchmarking (theregister.co.uk)

An anonymous reader quotes a report from The Register: Intel has backtracked on the license for its latest microcode update that mitigates security vulnerabilities in its processors -- after the previous wording outlawed public benchmarking of the chips. The reason for Intel's insistence on a vow of silence is that -- even with the new microcode in place -- turning off hyper-threading is necessary to protect virtual machines from attack via Foreshadow -- and that move comes with a potential performance hit. Predictably, Intel's contractual omerta had the opposite effect and drew attention to the problem. "Performance is so bad on the latest Spectre patch that Intel had to prohibit publishing benchmarks," said Lucas Holt, MidnightBSD project lead, via Twitter.

In response to the outcry, Intel subsequently said it would rewrite the licensing terms. And now the fix is in. Via Twitter, Imad Sousou, corporate VP and general manager of Intel Open Source Technology Center, on Thursday said: "We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here. As an active member of the open source community, we continue to welcome all feedback and thank the community." The reworked license no longer prohibits benchmarking.
Long-time Slashdot reader and open-source pioneer, Bruce Perens, first brought Intel's microcode update to our attention. In a phone interview with The Register, Perens said he approved of the change. "This is a relatively innocuous license for proprietary software and it can be distributed in the non-free section of Debian, which is where is used to be, and it should be distributable by other Linux distributions," he said. "You can't expect every lawyer to understand CPUs. Sometimes they have to have a deep conversation with their technical people."

76 comments

  1. Thanks slashdot by hcs_$reboot · · Score: 2

    The power of the media.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
    1. Re:Thanks slashdot by r1348 · · Score: 1

      I think they just forgot a licence from a preview version for partners only into the mainstream release.

    2. Re:Thanks slashdot by Anonymous Coward · · Score: 0

      Just like they forgot to mention industrial strength cooler system and extreme overclocking that time. Really, they are far beyond the point where giving them benefit of the doubt makes any sense.

      This "forgetfulness" is very consistent with disgusting way they handle Meltdown and Spectre problems.

    3. Re: Thanks slashdot by Anonymous Coward · · Score: 0

      The chiller setup was visible. If the tech press can't recognise a chiller setup without actually seeing the chiller, there's bigger problems.

  2. or MS? by Anonymous Coward · · Score: 0

    Wouldn't that have meant Microsoft would have had to turn off the Windows score thingie?

    Perhaps that didn't go over well ?!?

  3. Forget microcode, you have a micropenis by Anonymous Coward · · Score: 0

    and everyone knows about it now

  4. Thanks, Bruce by Anonymous Coward · · Score: 5, Insightful

    Slashdot may be a bully pulpit, but Bruce Perens desrves the credit.

    1. Re:Thanks, Bruce by Tough+Love · · Score: 2

      Slashdot may be a bully pulpit, but Bruce Perens desrves the credit.

      Seconded.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:Thanks, Bruce by Tough+Love · · Score: 5, Informative

      Slashdot may be a bully pulpit...

      More accurately, TheReg was the bully pulpit, Slashdot was an amplifier.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    3. Re:Thanks, Bruce by UnknownSoldier · · Score: 3, Informative

      > bully pulpit

      Before anyone else gets their panties in a knot, that's a horrible coining by Theodore Roosevelt. I doubt most people know the difference between:

      * bully, the adjective; which means "fine; excellent; very good."
      * bully, the noun; which means "a blustering, quarrelsome, overbearing person"

    4. Re:Thanks, Bruce by Anonymous Coward · · Score: 1

      Pretty sure Intel already said on the Ubuntu mailing list a week or so ago their intention to reupload with a different license

    5. Re:Thanks, Bruce by Bruce+Perens · · Score: 4, Informative

      Thank you! Obviously Debian and friends were after Intel before I saw that other Linux distributions had accepted the license and decided that the people needed some education on the topic. I can't say for sure that Intel wasn't already working on the improved license before I got involved.

      This is still a proprietary software license, and it's unfortunate that if you want the security fixes you have to load a binary blob on your nice otherwise-100%-Free-Software system every time you boot it up.

      If you'd like to help me do stuff like this, there's my brand-new Patreon site, follow me on Twitter and re-tweet me when I'm working on things like this, keep watching Perens.com and my submissions to Slashdot (which are often rejected).

    6. Re:Thanks, Bruce by Anonymous Coward · · Score: 0

      They just forgot to include the clause about sacrificing the firstborn.

      It is very hard to believe Intel is up to something good considering their insistence on using doublespeak: "we have simplified the Intel license to make it easier to distribute CPU microcode updates". Right.

    7. Re:Thanks, Bruce by Z00L00K · · Score: 1

      In which case it's worth considering a completely different CPU since the CPU contains proprietary software anyway - the microcode that controls the hardware.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    8. Re: Thanks, Bruce by Bruce+Perens · · Score: 1

      And that is probably some future flavor of Risc-V.

    9. Re:Thanks, Bruce by ls671 · · Score: 1

      Goof for you but I won't make that call before hearing Bennett Haselton opinion on the matter.

      --
      Everything I write is lies, read between the lines.
    10. Re:Thanks, Bruce by _merlin · · Score: 1

      This really makes no sense to me. The "free software" crew seems to be largely OK with proprietary firmware baked into devices, but the moment it's loaded from a driver it becomes evil. If the firmware is loaded by the driver, at least you have some chance of being able to modify/replace it even if the supplied firmware is proprietary. If it's baked into the device you have no control over it at all.

    11. Re:Thanks, Bruce by The+Finn · · Score: 1

      modern x86 hardware is a binary blob these days. even if you don't load any microcode on your CPU, default microcode is present in mask ROM.

      --
      NetBSD: the cathedral vs the bizzare.
    12. Re: Thanks, Bruce by Bruce+Perens · · Score: 1

      Yes. It is possible to make a fully-disclosed hardware platform using something like Risc-V, but not very practical yet.

  5. Bad for intel, good for AMD at least by Anonymous Coward · · Score: 4, Interesting

    If there's one silver lining to this shitstorm it's that AMD should continue to get more and more sales.
    I know my next upgrade is going to be a ryzen because of spectre/meltdown and also to spite intel for basically preventing >4 cores becoming mainstream. If they'd have worked on jamming more cores into affordable cpus maybe we'd be seeing far more heavily multithreaded games & programs.

    1. Re:Bad for intel, good for AMD at least by Tough+Love · · Score: 2

      It's good for Intel to be seen at work on the issue. Bad that it's basically impossible to fix in microcode without losing massive performance. Bad luck that the issue exists in the first place. Good for AMD as you say, but even without this AMD was already the sweet spot for me, and getting sweeter methinks.

      Intel needs to fix this at the transistor level, that will take months for the 14nm fabs and who knows how much additional delay it means for 10nm. Just copying AMD's design would likely hit a patent minefield. If I was Intel, at this point I would bury the hatchet and license at least part of AMD's speculative execution design. Given that Intel already hired Ryzen's lead architect, maybe that's exactly what is happening.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:Bad for intel, good for AMD at least by Anonymous Coward · · Score: 0

      Whether or not it's useful to add more cores depends on other factors as well, such as memory bandwidth and the how easy it is to get lots of data from disparate places in main memory, and the nature of the game. If the game performance is limited by how fast the CPU can act on small sets of data (so that there isn't a lot of cache thrashing), then more cores (and likely higher clock rates) helps. If the bottleneck is the main external buses (getting data to/from main memory or other external devices), then more cores is not necessarily so helpful. In a heavily threaded application that I'm working on I'm finding that a 6-core Ryzen (12 threads) is only marginally faster than an overclocked i5-4670K. In other words, more cores is not necessarily a panacea.

    3. Re:Bad for intel, good for AMD at least by Tough+Love · · Score: 1

      If the bottleneck is the main external buses (getting data to/from main memory or other external devices), then more cores is not necessarily so helpful.

      Of course, that is why AMD came up with Mantle, aka Vulkan/DX12. Now, more cores is most definitely the way to go for gamers, except for obsolete single threaded 3D engines. I don't know about you, but I don't like to invest a whole lot in obsolete stuff, I can't even remember the last time I bought a new buggy whip.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    4. Re:Bad for intel, good for AMD at least by Anonymous Coward · · Score: 0

      For meltdown, all they need to do is check permissions before executing speculative branches. AMD does this already, and it's not some super-secret proprietary technique. Intel chose to check after the speculation instead of before -- to increase speed. Now, they're paying the performance penalty of having to work around that decision.

      As for the other fixes, partitioning memory in shared caches won't be particularly easy, but adding additional address lines and hashes will help verify what each program can access.

      It will be interesting to see what future designs are created to fully mitigate against these security flaws. I suspect in a few years, we might see a separate register and/or cache for speculation storage with controlled access... or maybe multiple L1, L2 caches - separate ones for each core -- with a combined L3 and logic to keep memory mapped from processes confined to the local caches to help prevent snooping. A lot of code would have to be re-written to take advantage of that partitioned architecture well, though.

    5. Re:Bad for intel, good for AMD at least by Anonymous Coward · · Score: 0

      The real question is if they can implement permissions checks without taking a negative IPC or power consumption hit. I would expect them to pair such a change with a node transition in an attempt to mask the performance hit with the uplift from a more advanced process node. The nightmare scenario would be for them to see the entire process node transition performance uplift effectively lost to security enhancements.

    6. Re:Bad for intel, good for AMD at least by Anonymous Coward · · Score: 0

      AMD is just glad there recent stuff sucked, and does not have the numbers to make it worth investigating beyond a cursory does it work with AMD / ARM.

      Now that they have a competitive product, I'll bet they're glad they had a chance to grasp the issue before they had a lot of it out in the field.

    7. Re:Bad for intel, good for AMD at least by Tough+Love · · Score: 1

      For meltdown, all they need to do is check permissions before executing speculative branches.

      I don't think that's quite right. Stalling every speculative branch for a permission check would suck enormously, and the branch itself is not the issue, it is whether the branch touches cache or not. I am pretty sure that AMD's approach is more complex than you suggest.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    8. Re:Bad for intel, good for AMD at least by thegarbz · · Score: 1

      I know my next upgrade is going to be a ryzen because of spectre/meltdown

      My next upgrade is going to be Ryzen because of performance per dollar. Spectre / Meltdown isn't relevant.

    9. Re:Bad for intel, good for AMD at least by Anonymous Coward · · Score: 0

      This latest stupid move by Intel has made me want to switch. It's assinine that anyone in the company thought this was a good move after all the bad press they have already been getting. Are the secretly investing in AMD /s

    10. Re:Bad for intel, good for AMD at least by Agripa · · Score: 1

      The real question is if they can implement permissions checks without taking a negative IPC or power consumption hit. I would expect them to pair such a change with a node transition in an attempt to mask the performance hit with the uplift from a more advanced process node. The nightmare scenario would be for them to see the entire process node transition performance uplift effectively lost to security enhancements.

      The data for the permission check already exists. The difference between Intel and AMD is that AMD executes the permission check during the load and Intel executes the permission check later during instruction retirement which is when other faults are generated. The speculated code never generates a visible fault in either case because it only executes during a (deliberately) mispredicted branch.

      Any difference in performance in hardware comes from correctly predicted faults but this is much less performance loss than the software remedies. Specter is a whole different problem however because it is a flaw in software which CPU access control cannot do anything about. The solution there is to convert the Specter problem to a Meltdown problem on a CPU not vulnerable to Meltdown.

  6. Already been re written by Intel by Anonymous Coward · · Score: 0

    Intel alsready ammended the wording to allow benchmarking and licensing so it can be installed now in any OS. Looks like probably a Little over 10 percent slowdown but could be much less depending on work load. So what are we up to in speed reduction? I guess for most around 10 to 20 % if everything is enabled.

    1. Re:Already been re written by Intel by arth1 · · Score: 1

      So what are we up to in speed reduction? I guess for most around 10 to 20 % if everything is enabled.

      Average speed reduction is uninteresting. What matters is how much the bottlenecks that hurts you the most, now or in the future, are going to be affected. To know that, you need to look at the worst case numbers, not "most".

      Because this is slashdot, the obligatory car analogy is that if a car manufacturer installed a top speed limiter of 75 mph as a firmware update, and then said it would not affect most users much, given that the average speed is 35 mph.

    2. Re:Already been re written by Intel by cstacy · · Score: 1

      Because this is slashdot, the obligatory car analogy is that if a car manufacturer installed a top speed limiter of 75 mph as a firmware update, and then said it would not affect most users much, given that the average speed is 35 mph.

      2008 called -- they want their Slashdot back.

      No, really. We want it back!

      (Imagine a Beowulf cluster of "I for one..." car analogies! I would like that. Rather than the rampant technological ignorance most of the comments illustrate these days. Present commentary excluded naturally.)

      Not kidding!

    3. Re:Already been re written by Intel by Anne+Thwacks · · Score: 1
      Sometimes they have to have a deep conversation with their technical people.">

      They are lawyers - sometimes they need a kick in the crotch.

      --
      Sent from my ASR33 using ASCII
  7. And now we see the true Intel by Anonymous Coward · · Score: 3, Insightful

    No faster than AMD's offerings, but at a 50% higher price. And they've been doing this for over a decade, knowingly putting out flawed CPUs just to beat the performance charts.

    You like that Intel Inside bragging right? Open up your wallet then, the lying cheating fuckers at Intel would like to take as much as you're willing to give.

    1. Re:And now we see the true Intel by Tough+Love · · Score: 3, Insightful

      they've been doing this for over a decade, knowingly putting out flawed CPUs just to beat the performance charts.

      Intel has done many slimy things, but I don't think that is one of them. Putting out flawed CPUs, yes, but knowingly... I doubt it. AMD was lucky on this one, or maybe somebody at AMD actually did realize the security ramifications of the interaction between speculative execution and protection levels. If so then they richy deserve bragging rights, I would really enjoy hearing the details whole story. But I doubt it happened.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:And now we see the true Intel by Anonymous Coward · · Score: 0

      They knowingly did it for YEARS, despite mailing lists noting this was a possible attack - 20+ years ago. They also played the compiler gimp game.

    3. Re:And now we see the true Intel by trek00 · · Score: 1

      AMD was lucky and IBM was lucky and ARM was lucky... or simply Intel done some shit design

    4. Re:And now we see the true Intel by Dagger2 · · Score: 1

      Based on this article, I can believe they shipped flawed CPUs without knowing about the flaws. However, if so, it's because they deliberately stopped investing as much effort into finding the flaws in the first place.

      And they certainly knew what they were doing when they scaled back their validation.

  8. How to avoid future licensing issues: by Gravis+Zero · · Score: 3, Insightful

    Only buy AMD.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:How to avoid future licensing issues: by bill_mcgonigle · · Score: 1

      I'm not buying it.

      Happy AMD owner here but I've never seen AMD say it will always provide microcode fixes and that the microcode will never come with a shitty license.

      I do think AMD has a good opportunity here to say they will offer microcode fixes and that they will offer them with a free license, but as far as I know both AMD and Intel could screw us at any time here, legally.

      Granted, only Intel has tried.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:How to avoid future licensing issues: by Gravis+Zero · · Score: 2

      Intel has a long history of shady and illegal business practices. AMD is a far better bet than Intel will ever be.

      --
      Anons need not reply. Questions end with a question mark.
    3. Re:How to avoid future licensing issues: by swb · · Score: 1

      This seems naive, like that somehow AMD isn't a business motivated primarily by increasing the wealth of its executives and shareholders.

      As gross underdogs in terms of market share they may *appear* to be completely customer focused, delivering a superior product because its the right thing to do but it would seem like that they would become less like this as their market power increases. Would the market share with Intel be flip-flopped, I'm sure they would face the same moral hazards and economics leverage that led Intel to be a "bad actor".

    4. Re:How to avoid future licensing issues: by Gravis+Zero · · Score: 1

      Intel has been a bad actor since the day it got in the x86 business. I think you need to look at this history of Intel because anticompetitive behavior has and always will be their modus operandi. AMD could have locked Intel out the x86_64 market by refusing to license AMD64 instruction set but they chose fair competition over splitting the market.

      AMD acts in it's own interest but Intel acts exclusively it's own interest, the rest of the world be damned.

      --
      Anons need not reply. Questions end with a question mark.
    5. Re:How to avoid future licensing issues: by swb · · Score: 1

      It's funny, because I've always preferred Intel motherboards (when they made them) and network cards over the competition because their parts always had good documentation and software support.

      I mean, maybe in some big sense they've been a bad economic actor and this specter/meltdown thing seems a real mess they can't easily fix for parts in the field, but Intel always seems less worse than so many other big technology companies.

    6. Re:How to avoid future licensing issues: by Gravis+Zero · · Score: 1

      I've always preferred Intel motherboards (when they made them) and network cards over the competition because their parts always had good documentation and software support.

      I don't know about motherboards but I do know that the reason for their well supported network cards is because of Linux. The internet is mostly Linux servers and servers are their most lucrative market, so ensuring it's well supported is necessary.

      maybe in some big sense they've been a bad economic actor

      Clearly you don't know the half of it but hey, I didn't either until more recently. here's a good video that explains their bad deeds that we know about.

      Intel always seems less worse than so many other big technology companies.

      They do have a great PR department but make no mistake, they are the greater evil.

      --
      Anons need not reply. Questions end with a question mark.
  9. Accomplishing just the opposite by alvinrod · · Score: 5, Insightful

    This was utterly stupid of them. They had to know that this would only draw more attention to the fact and they had to know that they couldn't prohibit benchmarking. That simply wasn't going to happen. And now that they've had to retract this idiotic policy, they've practically ensured that every tech site is going to do loads of benchmarking when they might not have otherwise been interested (there were a few when Meltdown and Spectre first came out, but I haven't seen a lot of benchmarks for the newer varients), but because Intel turned this into a big story, now everyone is going to want to do benchmarks to ride the renewed wave of interest.

    This was like getting pulled over by a cop and shouting, "Nothing suspicious in the trunk!" before the cop has even had a chance to ask for your license and registration.

    1. Re:Accomplishing just the opposite by Tough+Love · · Score: 2

      This was utterly stupid of them

      It was a stupid mistake, yes, but it was smart to fix it as quickly as possible. I can't say I don't enjoy seeing their legal beagles squirm a bit. Lawyers always think they know how to run the tech industry and they are always wrong.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:Accomplishing just the opposite by Anonymous Coward · · Score: 0

      This was utterly stupid of them. They had to know that this would only draw more attention to the fact and they had to know that they couldn't prohibit benchmarking. That simply wasn't going to happen. And now that they've had to retract this idiotic policy, they've practically ensured that every tech site is going to do loads of benchmarking when they might not have otherwise been interested (there were a few when Meltdown and Spectre first came out, but I haven't seen a lot of benchmarks for the newer varients), but because Intel turned this into a big story, now everyone is going to want to do benchmarks to ride the renewed wave of interest.

      This was like getting pulled over by a cop and shouting, "Nothing suspicious in the trunk!" before the cop has even had a chance to ask for your license and registration.

      Zero people will benchmarking these firmware updates that were not already planning on it. The performance degradations were entirely anticipated, given turning off HT is part of the solution.

    3. Re:Accomplishing just the opposite by Anonymous Coward · · Score: 0

      Tough love, Intel's CEO sold a bundle of stock after he learned (about 6-9 months before the public) about the flaws but before they were public. That alone proves you're being naive as hell. Stop shilling for Intel frauds you moron.

    4. Re:Accomplishing just the opposite by Tough+Love · · Score: 1

      Don't be an idiot, I am no Intel shill. But hyperbole is stupid, whichever direction it is aimed. If you think that you know something the SEC does not then feel free to notify them. BTW, you're an asshole, how does it feel to be you?

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    5. Re:Accomplishing just the opposite by AHuxley · · Score: 2

      When the wider public is not allowed to talk about a product and its performance thats not a "mistake".

      --
      Domestic spying is now "Benign Information Gathering"
    6. Re:Accomplishing just the opposite by Tough+Love · · Score: 1

      It was a mistake to attempt it. I presume that some minor legal minion will receive a wrist slapping over this and their work will be audited more carefully in future.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    7. Re:Accomplishing just the opposite by jezwel · · Score: 2

      Zero people will benchmarking these firmware updates that were not already planning on it. The performance degradations were entirely anticipated, given turning off HT is part of the solution.

      Wrong. Our hardware evaluation team are now interested in benchmarking as Intel made too big a deal out of this.

    8. Re: Accomplishing just the opposite by Anonymous Coward · · Score: 1

      REdHat has performance numbers published last week, with the new firmware.

    9. Re:Accomplishing just the opposite by Anonymous Coward · · Score: 0

      I think the suspicion is rather that some lawyer dug out some standard software license and had it slapped onto it (or as others noted, a pre-release license, you don't want to get bad press because someone ran a benchmark on unfinished software).
      It is an unfortunately consequence of lawyers in most companies considering it to be their job to protect their company, and at the same time it's entirely acceptable to not give a shit about the customer.
      Legal is unfortunately often on the forefront in the "the customer is the enemy" movement. I find it really sad how many companies treat their customers like that - and get away with it.
      (so for those complaining about Google, yeah, being the product instead of the customer is bad enough. Being the enemy is worse though)

    10. Re:Accomplishing just the opposite by Anonymous Coward · · Score: 0

      Just because something is not accidental, doesn't mean it can't be a mistake.

      For example, it was probably a mistake to include so many negatives in that sentence but it wasn't accidental.

  10. Refund please. by Anonymous Coward · · Score: 1

    My chip will now become something I did not pay for.
    To put it into a car analogy: it’s like when you buy a car that does 1000 miles before refueling only to find out they cheated emissions and after updates now only gets 700 miles.

    I bought my chip for HT. Even my mobo is useless now, because I want a full refund and I will be switching to AMD.

    See you in Australian court INTEL.

    1. Re: Refund please. by Anonymous Coward · · Score: 0

      Kangaroo court?

    2. Re:Refund please. by m0hawk · · Score: 1

      You don't have to install the microcode update ya galah.

      I doubt anybody would have sympathy for you if you install the update knowing about the performance hit/reduced features and then cry "it doesn't work like it should!". That's not to say I don't think Intel are assholes, because I think they are.

    3. Re:Refund please. by bill_mcgonigle · · Score: 1

      Intel sold him a chip with security features that offered no security. To get what was advertised he has to hobble the performance he was sold as well.

      No, lots of people will have sympathy for his situation - this is not of his own making. This is something Intel should have been on top of shortly after Rowhammer was discovered.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    4. Re:Refund please. by Anonymous Coward · · Score: 0

      So you are suggesting I leave the keys in the ignition instead?

      Wow, really?!

  11. Seriously? by franzrogar · · Score: 5, Insightful

    On a binary blob, closed source, forbidden to decompile, study or whatever they wrote this: "As an active member of the open source community"?

    Shame on them!

  12. See? by Greyfox · · Score: 0

    Turns out it was just some dumb fucking lawyer and as soon as the mistake was pointed out, they corrected it. We really didn't need jump to calling them "bitches" and "goat fuckers" right out of the gate like we did! I'm sure there are almost no goats being fucked over there!

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:See? by Anonymous Coward · · Score: 0

      Not goats, but users. That'$ lawyers job and this bullshit with benchmarks

    2. Re:See? by Anonymous Coward · · Score: 2, Insightful

      Where did you get "dumb fucking lawyer" part? Nothing in Intel's response indicates there was any error: "we have simplified the Intel license to make it easier to distribute CPU microcode updates".

      They corrected it after it become news and topic of embarrassing public discussion. What other choice did they have?

  13. Tough love, stop being a denialist faggot. by Anonymous Coward · · Score: 0

    Read about this if you're going to have doubts moron "tough lover" - your ignorance of what happened is remediable. Stop shilling FUD and READ ABOUT THIS STUFF if you want a valid opine on it. Jesus. Clue in.

  14. How stupid can you be? by Opportunist · · Score: 3, Interesting

    Intel, I have no idea what bozo is responsible for this, but please do yourself and the world a favor and fire him. Out of a cannon. What this idiot managed to do with the "must not benchmark" bullshit was that everyone wants the benchmark results.

    This stupidity now makes sure that everyone can get them legally, too.

    Unless this microcode patch actually causes no performance hit, which would make it a great PR stunt, but is very unlikely considering what we've seen so far, this is about the worst kind of PR disaster you could possibly have gotten into.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  15. Buy a different CPU by AHuxley · · Score: 2

    When a company does not want people looking into its products and talking about its products?
    Its time to find a new company with better products they allow full and open discussion of.

    --
    Domestic spying is now "Benign Information Gathering"
  16. Unacceptable: should have released code & free by Anonymous Coward · · Score: 0

    I'm sick and tired of these mega corporations getting a way with bullying us. They should have released a complete set of code and cooperated with those of us looking to ship hardware that respects a user's ownership over the computer. I can't wait until there are more designs and devices based around EOMA68- a modular computing standard that reduces the costs of designing and manufacturing devices that the users and community have full control over every bit of code. This is why you got to put your money where you mouth is and buy from companies like ThinkPenguin who have been pushing for and getting code released for critical chips (ath9k-htc), funding totally free operating systems (Trisquel, LibreCMC, etc), and generally funding/promoting/assisting with/pushing these sorts of effort forward (EOMA68).

  17. Misunderstanding by Anonymous Coward · · Score: 1

    > "You can't expect every lawyer to understand CPUs.

    Well, I would think it is sort of a prerequisite for lawyers representing a fucking CPU manufacturing company to understand the licensing issues surrounding cpu microcode.

    So, I'm not buying it. They knew the implications. Intel just wasn't expecting pushback on the licensing of their already nonfree proprietary software.

    1. Re:Misunderstanding by DCFusor · · Score: 1
      I think that was just a way to let them save some face if they then did the right thing. Of course a lawyer might not understand the details of possible internal CPU interactions. They should, or not have been hired, but hey...I liked that "fire from a cannon" remark above.
      What's absolutely not acceptable is a lawyer who doesn't understand the law, the customer base, the Streisand effect...and a bunch of other similar things - that's supposedly their expertise.
      These things are demonstrably NOT the expertise of whatever management probably drove this. Who also need the cannon treatment, maybe more than some wet-behind-the-ears new-hire inexpensive lawyer.

      .

      I think these things are probably well understood by all parties except the unwashed who don't think about things like this in detail. EG, as I said above, it was probably a sound-bite suggestion on how to save a little face, which indeed often facilitates then doing the right thing. Not a stupid way to get things to happen, even if it IS stupid that such diversions are helpful at all.

      --
      Why guess when you can know? Measure!
  18. Summer time by Anonymous Coward · · Score: 0

    The sun is hot and INTC will be in shorts all the way to the bottom of the pool.

  19. Purchase contract by Anonymous Coward · · Score: 0

    The time limited fixing of a not properly working product by the producer or vendor should be an obligational part of each purchase contract for new goods. As a consequence such an update would be subject to the original contract and any new conditions inapplicable. To my knowledge this is mandatorily implemented in EU states.