• 0 Posts
  • 9 Comments
Joined 9 months ago
cake
Cake day: April 21st, 2024

help-circle

  • In an American vacuum I could see where you are coming from. In comparison with literally the entire rest of the world, it is clearly a flawed standpoint.

    The American Democratic party is the oldest standing political party in the entire world. It last changed it’s political stances in the 1960’s and not because they wanted to, but because they needed to respond to the Republicans flipping the entire south in their favor.

    Other countries have real leftist parties that actually get government members elected.



  • I vote for them, they move right. I don’t vote for them, and vote third party, they move right. I join their party and vote in their primary’s for progressive candidates, they move right.

    It’s almost like a bunch of really old, well off, lifetime establishment government folks just actually want to be conservative authoritarians. At BEST they are stuck in a mindset of 1969’s ideas of what progressive politics are because that is when they became politicians.



  • This is a patch from the hardware vendor so I am assuming that the ask is not that the hardware vendor take responsibility but that they not release buggy hardware. That is what I mean about the validation issue.

    The attack vector is shared in the patch so it isn’t entirely a theory.

    There is a comment from Linus about how this patch is only needed for some hardware and doesn’t apply to others but I don’t get his relevance there as different hardware validates against different use cases and their source logic might be entirely disparate.

    So my validation talk is simply saying that bugs happen. My concern here is what more should a hardware vendor do beyond submitting a kernel patch? You can’t just not have the bug, and if you recall the part someone else will just keep theirs in the field and take all the market share and roll the dice that their bugs don’t get exploited.


  • Is this really the hardware vendor’s problem though? It’s the consumers problem.

    I bring up full validation because the concern here is putting in a speculative fix. If the ask is, why was the hardware like that in the first place the answer is because it can’t be fully validated. If the ask is why should a speculative fix go into the Kernel it is because the consumers are not on top of tree and if a fix has a chance of never being exploited it needs to be pulled in years ahead so it goes into an LTR that customers migrate to BEFORE the issue comes up.


  • Fully validating hardware is an insane task that hasn’t been really done in years. It would mean 5 years between chip releases and a 2-5X in cost to produce, and people wouldn’t follow the validated configs anyways. If we followed the validated hardware spec we would have 50 min boot times and not go past a 3.5Ghz clock.

    People have the choice today on if they want to run on validated hardware. You can opt in to get a 2.8Ghz part that supports 2666MT/s that is mostly tested and validated, or you can get a 5Ghz part that supports 6000MT/s that is only partially validated. They cost the same price. What do folks think people pick?