Ariadne Conill 🐰
AMD is the only x86 CPU vendor I will remotely bother with at this point, but folks shouldn't use x86 anyway if they can avoid it: https://www.theverge.com/2024/6/14/24178751/intel-raptor-lake-crash-fix-etvb-not-yet
and for the love of all things, apply CPU microcode updates on your machines, *especially* with x86, where basically *zero* x86 cores have been taped out in the past 20 years that did not immediately need bugfixing in microcode
KATastrophE@ariadne and then you have the gnu libre people who remove any microcode blobs, even though there is one running on there cpu anyway... might as well update it to get security fixes
Julius Schwartzenberg - Юліус@kate @ariadne if you're only running free software and you have all the sources, the security fixes are not that relevant given one really does curation of all the software they end up running :)
Security fixes would be relevant if you do end up running untrusted code (for instance in a JavaScript sandbox). But then you're letting non-free software in without curation.
I would say the main reason for the microcode updates would be to solve bugs, stability issues for this group.
@jschwart @ariadne but all open-source software is basically untrusted code, or do you really read through all the billions of lines of code that run on your machine? you might have a feeling of security, but i think it's wrong to think you automatically have security if you only run open-source software (see the xz exploits)
Iron Bug@ariadne @jschwart @kate updating microcode is a big thing. it may
- introduce new vulnerabilities
- significantly slow down performance
- have inlaid backdoors for vendor
and not all vulnerabilities are exploitable in every particular case. sometimes the use case of CPU excludes the possible attacks and performance is more important than some fast and dirty fix.
of course, this all does not lift the fact that CPU must be designed and tested more carefully to avoid such BS we see more and more often nowadays. the problem is aggressive and idiotic management that forces engineers to throw semi-raw products to the market. nobody cares for quality and security. users pay for some cat in a bag that may have absolutely broken performance after a serie of skew firmware workarounds for CPU architecture errors.
- introduce new vulnerabilities
- significantly slow down performance
- have inlaid backdoors for vendor
and not all vulnerabilities are exploitable in every particular case. sometimes the use case of CPU excludes the possible attacks and performance is more important than some fast and dirty fix.
of course, this all does not lift the fact that CPU must be designed and tested more carefully to avoid such BS we see more and more often nowadays. the problem is aggressive and idiotic management that forces engineers to throw semi-raw products to the market. nobody cares for quality and security. users pay for some cat in a bag that may have absolutely broken performance after a serie of skew firmware workarounds for CPU architecture errors.
@ariadne @jschwart @kate the problem is that fixing hardware design fuckups with microcode crutches is wrong in its root.
and the most problems they discover and try to patch are hardware architecture related ones.
sometimes they have to go down to software level and "fix" compilers code generation, etc to skip buggy instructions. and this is perfectly wrong way.
and the most problems they discover and try to patch are hardware architecture related ones.
sometimes they have to go down to software level and "fix" compilers code generation, etc to skip buggy instructions. and this is perfectly wrong way.
@ariadne @jschwart @kate theoretically :)
the devil is in the details.
I think it's not the problem of development per se. it's the problem of the system that pushes the unfinished projects to the market. they impose impossible deadlines to developers and then get botched production. the thing that changed is not the complexity of technologies. but the process of normal development, that implies designing, testing and debugging. the past two may repeat again and again, until it works stable and fine. but nobody is interested in stable and fine hardware. they sell BS because they get more money from selling BS. they push new and more bugggy chips on market and make more profit from every bug they cannot fix.
the devil is in the details.
I think it's not the problem of development per se. it's the problem of the system that pushes the unfinished projects to the market. they impose impossible deadlines to developers and then get botched production. the thing that changed is not the complexity of technologies. but the process of normal development, that implies designing, testing and debugging. the past two may repeat again and again, until it works stable and fine. but nobody is interested in stable and fine hardware. they sell BS because they get more money from selling BS. they push new and more bugggy chips on market and make more profit from every bug they cannot fix.
@ariadne @jschwart @kate and RISC chips are totally different from general CPU. they have their niche in RTOS and embedded devices. but barely can substitute the robust processors that are used on high load tasks. and this world has really many heavy computational tasks that cannot be performed with simple and light processors.
we're in a dead end of a kind. we need a mighty single cores. instead, we get hundreds of tiny weak cores with dim and errors prone bus sychronization. and the very orgranization of modern development process is absolutely sick and is not intended for quality output.
we're in a dead end of a kind. we need a mighty single cores. instead, we get hundreds of tiny weak cores with dim and errors prone bus sychronization. and the very orgranization of modern development process is absolutely sick and is not intended for quality output.
@ariadne @jschwart @kate when I hear "Apple" I get an allergy. I don't trust those cons that sell BS that is overpriced like 5-10 times. no way. but they can sell a dead rat to their fanatics, I swear. they will buy any BS because it's Apple.
as a software and electrinics developer I never buy anything from Apple. and I use open source for 20+ years. no proprietary software. so Apple is out of my hardware list in all ways.
as a software and electrinics developer I never buy anything from Apple. and I use open source for 20+ years. no proprietary software. so Apple is out of my hardware list in all ways.
@ariadne @jschwart @kate I had seen many things. Intel and IBM mainframes, Fujitsu, EMC, Hitachi data storages, etc, etc. I had seen Cisco, HP, Juniper switches, Ericsson telecommunication equipment. even original old SUN servers with Solaris, but no Apple. I think they have never did anything serious. all they did was PR or their very mediocre end-user gadgets and selling them majorly overpriced.
Alexandre Oliva (moved to @if a cpu is found to be defective and endangering to users' safety, it should undergo a recall list most everything else. if a recommended microcode update patches a defect at the expense of slowing down the cpu or otherwise making it unable to do things it was purchased for, without the possibility of a proper recall fix, the sale should be considered fraudulent
@lxo yes, this is what I'm talking about.
@lxo and yes, they try to impose SaaS even to CPU! they want users to pay to them endlessly. for "unlocking" CPU features. but why, the hell, features of CPU might be locked from an user that has bought it and have already paid? that's really weird. and that what should be stopped by all means.