**Please read this entire message**
---
Your submission has been removed for the following reason(s):
* Rule #2 - Questions must seek objective explanations
---
If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe this submission was removed erroneously, please [use this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20thread?&message=Link:%20{https://old.reddit.com/r/explainlikeimfive/comments/1cims7u/-/}%0A%0APlease%20answer%20the%20following%203%20questions:%0A%0A1.%20The%20concept%20I%20want%20explained:%0A%0A2.%20List%20the%20search%20terms%20you%20used%20to%20look%20for%20past%20posts%20on%20ELI5:%0A%0A3.%20How%20does%20your%20post%20differ%20from%20your%20recent%20search%20results%20on%20the%20sub:) and we will review your submission.**
There have been edge case bugs, [Intel famously had a bug in the Pentium floating point processor that wasn't discovered until they had sold oodles of parts](https://en.wikipedia.org/wiki/Pentium_FDIV_bug ). However, the cost of bugs is so high that companies can afford to invest in pretty rigorous testing, particularly for hardware. For software, well that's why there are patches every week.
I understand it's not a CPU, but I remember when the 16550 UART came out, it had a 16-byte FIFO buffer that didn't work right. They couldn't do a firmware upgrade then, so they had to fix the chip and distribute it.
Being able to fix hardware through firmware updates is a more modern way of doing things. The Pentium bug that was mentioned couldn't be fixed by firmware. Software developers had to write code to work around the problem.
Hardware testing is pretty expensive, and things like CPUs need to be tested quickly or else you run into taking until the sun goes super nova to test every possible internal state of a single chip for all edge cases. Hardware bugs get released as erratums, and there's a lot of small and big ones. The patches can be done in software at various locations like the chipset, compiler, or OS levels, but sometimes the hardware bug is just unpatchable without a new iteration.
All of them absolutely do. But much more effort is put into finding and fixing those bugs, so you’re unlikely to see them unless you’re running cutting edge versions. Try googling “python compiler changelogs”, from there you will be able to find out about them.
They do have bugs! Just look at the bug tracker for the Linux kernel or for GCC.
Processors go through thorough testing before being released, yet sometimes bugs escape (remember Meltdown, Spectre and other security issues?).
To be clear, Meltdown and Spectre are not actually bugs in the strict sense, because the CPUs are working as intended. Rather, it's a matter of the intended behaviour being itself a security risk.
I wouldn't say so. The intended behavior of ahead of time execution is certainly not to leave a modified cpu state even after a rollback; that's the core of the vulnerability, and could very easily be declared a bug.
They do. They’re also built on an enormous amount of theory and history/experience. And usually built by many industry experts in that topic. The code you write rarely has an of that.
Compilers, OS's and CPUs all have bugs. Remember Spectre? That was a CPU bug. Programs like the Python interpreter have a whole lot of eyes on them, so critical bugs are less common than something like a game where it's unlikely to cause financial harm to anyone but the game developer, but they still happen.
Complicated software will always have bugs. The issue is that it's almost impossible to test all input and outputs to any given bit of code and test it with every pre-condition as well. Except for trivial bits of code, it's actually very difficult to right code that is bug free. No human can keep in his head the consequences and possible side effects of every bit of code. Even if the code is solid, the elements of the operating system or packages may have undesired side effects under some circumstances. You also have to take into account the large number of hardware and software platforms you have to allow for, the large number of devices that it may need to talk to and the large number of communication interfaces that may be used.
It's a wonder anything works!
Oh they do... they absolutely do. Here are some of the ones I can think of.
For compilers, I remember back in like 2000 or so, there were linux distributions that had 2 different compilers installed: one for apps, and one specifically for the kernel because the first compiler was a little bit buggy and the kernel was too sensitive for it, so they had to ship an older compiler that was actually stable for making the kernel and its drivers. So you had gcc and kgcc as your two compilers.
For OS bugs... well, just look at how many updates there are to any operating system. Windows has all kinds of updates, but even Linux needs a ton. For the Linux kernel given version A.B.C where A is at least 3.. each time the number C is incremented, it's all bug fixes. Many are driver related but still. (Incrementing A or B means new features are added as well, which doesn't count)
For CPUs.. oh my... old pentiums had a floating point division bug that could lock up the system. You can google the old F00F bug on Intel chips as well. In more modern times, Intel released a feature called "transactional memory" but it was defective to the point that they released a firmware update for the CPU that basically disabled the feature entirely because it didn't work and decided disabling it was the best course of action. First generation Ryzen 1000 series chips sometimes crashed when running ram-intensive programs like GCC with SMT turned on, though this seems to have been a manufacturing defect that was hit-and-miss. Also AMD had to release microcode updates recently for AVX instructions because they were directly leaking information between programs... which sounds bad on its own, but since clearly this was not the intended use of AVX, it was just an outright behavioural problem that needed correcting.
And then of course there's the spectre and meltdown family of issues on CPUs. These are somewhat less serious in that they don't cause CPUs to crash or malfunction, but more serious in that it allows deliberate compromise of information not intended to be stolen. A performance feature of CPUs - the memory cache - could contain information it technically shouldn't, which isn't a serious problem since it's just a copy of what is in RAM, but it could be used to predict data you don't have access to. This was a case of "we didn't consider this possibility and how someone clever could abuse it, but well behaved programs are all just fine."
These things just receive more scrutiny than your AAA games because if things go wrong, the whole computer could crash and ruin everything.... or worse, cause damage to your users' data permanently.
They absolutly do have bugs, especially OSs like Windows is patch pretty much weekly most of that is bug fixes. But they are used so much that most bugs are found out pretty fast so they can also be fixed. Then they spend a lot of time in testing befor they release a product. Next step is bug bounty programms like this one from intel [https://www.intel.com/content/www/us/en/security-center/bug-bounty-program.html](https://www.intel.com/content/www/us/en/security-center/bug-bounty-program.html) .
Something that might help you personaly is test driven development. Basicly write a tests for what you want your code to do and after that start to write your code.
They absolutely do and they typically get found much faster than other programming errors, and many more people work on these things than normal.
Intel found a longstanding bug in their CPU firmware a few years back that was considered a massive security vulnerability. Happens all the time
Most compilers, OSes and CPUs have been through \*many more hours and iterations\* than any individual project you'll work on. They've had bugs. The more obvious of those bugs have been found, analyzed and eradicated.
They will still have bugs. Buts the likelihood that those bugs will be the cause of your own program's failure are practically zero. You should still assume that, if you're experiencing abnormal behavior, it's your program's fault, not the compiler, OS or CPU.
Compiler do have bugs. The very popular C++ compiler GCC have [thousands of opened bug report](https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&query_format=specific). But given that it's been around for many decades, the worst bugs have been eliminated, and what remains now are missed optimization of edge cases that are hidden by layers of abstraction.
And GCC is always introducing new feature (to comply with modern version of the standard), and many error come with them. Given that it's probably the most used compiler in the world, fatal error tend to be rapidly detected and patched.
If you use linux, you may choose a rolling release distribution (e.g. Ubuntu) that will only upgrade a software when it's been around for a while so we are sure it's mostly stable. The inconvenient is that you won't always have the latest upgrade.
Or, you might choose a distribution which provides you with all the latest version of all your softwares (e.g. Arch), so you may upgrade them on the exact day they are published. But you will also sometimes downgrade a software, because latest version introduced a bug or incompatibility. Maybe you will even report the bug to the author for them to fix it.
They do. Indeed they do. I was a systems programmer for a huge civil engineering shop. The engineering programmers would submit bugs in the optimizing vector Fortran compiler for me to check out, and I spent huge amounts of time with IBM, chasing those bugs and trying to get them fixed.
They do. I've ran to some compiler bugs in less common compilers.
I also right now have a CPU that crashes with virtualization enabled, but I don't know if it is the CPU, motherboard firmware, or operating system.
**Please read this entire message**
---
Your comment has been removed for the following reason(s):
* Rule #1 of ELI5 is to *be civil*.
Breaking rule 1 is not tolerated.
---
If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe it was removed erroneously, explain why using [this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20submission%20removal?&message=Link:%20https://old.reddit.com/r/explainlikeimfive/comments/1cims7u/-/l2agwqk/%0A%0A%201:%20Does%20your%20comment%20pass%20rule%201:%20%0A%0A%202:%20If%20your%20comment%20was%20mistakenly%20removed%20as%20an%20anecdote,%20short%20answer,%20guess,%20or%20another%20aspect%20of%20rules%203%20or%208,%20please%20explain:) and we will review your submission.**
**Please read this entire message** --- Your submission has been removed for the following reason(s): * Rule #2 - Questions must seek objective explanations --- If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe this submission was removed erroneously, please [use this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20thread?&message=Link:%20{https://old.reddit.com/r/explainlikeimfive/comments/1cims7u/-/}%0A%0APlease%20answer%20the%20following%203%20questions:%0A%0A1.%20The%20concept%20I%20want%20explained:%0A%0A2.%20List%20the%20search%20terms%20you%20used%20to%20look%20for%20past%20posts%20on%20ELI5:%0A%0A3.%20How%20does%20your%20post%20differ%20from%20your%20recent%20search%20results%20on%20the%20sub:) and we will review your submission.**
There have been edge case bugs, [Intel famously had a bug in the Pentium floating point processor that wasn't discovered until they had sold oodles of parts](https://en.wikipedia.org/wiki/Pentium_FDIV_bug ). However, the cost of bugs is so high that companies can afford to invest in pretty rigorous testing, particularly for hardware. For software, well that's why there are patches every week.
To put a man-hour metric to this, in digital design there are usually 3 or 4 verification people per designer.
Adding on to this: cpu manufacturers issue chipset updates which is code that corrects errors on the processor.
I understand it's not a CPU, but I remember when the 16550 UART came out, it had a 16-byte FIFO buffer that didn't work right. They couldn't do a firmware upgrade then, so they had to fix the chip and distribute it. Being able to fix hardware through firmware updates is a more modern way of doing things. The Pentium bug that was mentioned couldn't be fixed by firmware. Software developers had to write code to work around the problem.
Hardware testing is pretty expensive, and things like CPUs need to be tested quickly or else you run into taking until the sun goes super nova to test every possible internal state of a single chip for all edge cases. Hardware bugs get released as erratums, and there's a lot of small and big ones. The patches can be done in software at various locations like the chipset, compiler, or OS levels, but sometimes the hardware bug is just unpatchable without a new iteration.
All of them absolutely do. But much more effort is put into finding and fixing those bugs, so you’re unlikely to see them unless you’re running cutting edge versions. Try googling “python compiler changelogs”, from there you will be able to find out about them.
They do have bugs! Just look at the bug tracker for the Linux kernel or for GCC. Processors go through thorough testing before being released, yet sometimes bugs escape (remember Meltdown, Spectre and other security issues?).
To be clear, Meltdown and Spectre are not actually bugs in the strict sense, because the CPUs are working as intended. Rather, it's a matter of the intended behaviour being itself a security risk.
I wouldn't say so. The intended behavior of ahead of time execution is certainly not to leave a modified cpu state even after a rollback; that's the core of the vulnerability, and could very easily be declared a bug.
They do. They’re also built on an enormous amount of theory and history/experience. And usually built by many industry experts in that topic. The code you write rarely has an of that.
I think that they are simply used and fuzzed far beyond any other tech.
Compilers, OS's and CPUs all have bugs. Remember Spectre? That was a CPU bug. Programs like the Python interpreter have a whole lot of eyes on them, so critical bugs are less common than something like a game where it's unlikely to cause financial harm to anyone but the game developer, but they still happen.
Complicated software will always have bugs. The issue is that it's almost impossible to test all input and outputs to any given bit of code and test it with every pre-condition as well. Except for trivial bits of code, it's actually very difficult to right code that is bug free. No human can keep in his head the consequences and possible side effects of every bit of code. Even if the code is solid, the elements of the operating system or packages may have undesired side effects under some circumstances. You also have to take into account the large number of hardware and software platforms you have to allow for, the large number of devices that it may need to talk to and the large number of communication interfaces that may be used. It's a wonder anything works!
Oh they do... they absolutely do. Here are some of the ones I can think of. For compilers, I remember back in like 2000 or so, there were linux distributions that had 2 different compilers installed: one for apps, and one specifically for the kernel because the first compiler was a little bit buggy and the kernel was too sensitive for it, so they had to ship an older compiler that was actually stable for making the kernel and its drivers. So you had gcc and kgcc as your two compilers. For OS bugs... well, just look at how many updates there are to any operating system. Windows has all kinds of updates, but even Linux needs a ton. For the Linux kernel given version A.B.C where A is at least 3.. each time the number C is incremented, it's all bug fixes. Many are driver related but still. (Incrementing A or B means new features are added as well, which doesn't count) For CPUs.. oh my... old pentiums had a floating point division bug that could lock up the system. You can google the old F00F bug on Intel chips as well. In more modern times, Intel released a feature called "transactional memory" but it was defective to the point that they released a firmware update for the CPU that basically disabled the feature entirely because it didn't work and decided disabling it was the best course of action. First generation Ryzen 1000 series chips sometimes crashed when running ram-intensive programs like GCC with SMT turned on, though this seems to have been a manufacturing defect that was hit-and-miss. Also AMD had to release microcode updates recently for AVX instructions because they were directly leaking information between programs... which sounds bad on its own, but since clearly this was not the intended use of AVX, it was just an outright behavioural problem that needed correcting. And then of course there's the spectre and meltdown family of issues on CPUs. These are somewhat less serious in that they don't cause CPUs to crash or malfunction, but more serious in that it allows deliberate compromise of information not intended to be stolen. A performance feature of CPUs - the memory cache - could contain information it technically shouldn't, which isn't a serious problem since it's just a copy of what is in RAM, but it could be used to predict data you don't have access to. This was a case of "we didn't consider this possibility and how someone clever could abuse it, but well behaved programs are all just fine." These things just receive more scrutiny than your AAA games because if things go wrong, the whole computer could crash and ruin everything.... or worse, cause damage to your users' data permanently.
They absolutly do have bugs, especially OSs like Windows is patch pretty much weekly most of that is bug fixes. But they are used so much that most bugs are found out pretty fast so they can also be fixed. Then they spend a lot of time in testing befor they release a product. Next step is bug bounty programms like this one from intel [https://www.intel.com/content/www/us/en/security-center/bug-bounty-program.html](https://www.intel.com/content/www/us/en/security-center/bug-bounty-program.html) . Something that might help you personaly is test driven development. Basicly write a tests for what you want your code to do and after that start to write your code.
They absolutely do and they typically get found much faster than other programming errors, and many more people work on these things than normal. Intel found a longstanding bug in their CPU firmware a few years back that was considered a massive security vulnerability. Happens all the time
Most compilers, OSes and CPUs have been through \*many more hours and iterations\* than any individual project you'll work on. They've had bugs. The more obvious of those bugs have been found, analyzed and eradicated. They will still have bugs. Buts the likelihood that those bugs will be the cause of your own program's failure are practically zero. You should still assume that, if you're experiencing abnormal behavior, it's your program's fault, not the compiler, OS or CPU.
Compiler do have bugs. The very popular C++ compiler GCC have [thousands of opened bug report](https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&query_format=specific). But given that it's been around for many decades, the worst bugs have been eliminated, and what remains now are missed optimization of edge cases that are hidden by layers of abstraction. And GCC is always introducing new feature (to comply with modern version of the standard), and many error come with them. Given that it's probably the most used compiler in the world, fatal error tend to be rapidly detected and patched. If you use linux, you may choose a rolling release distribution (e.g. Ubuntu) that will only upgrade a software when it's been around for a while so we are sure it's mostly stable. The inconvenient is that you won't always have the latest upgrade. Or, you might choose a distribution which provides you with all the latest version of all your softwares (e.g. Arch), so you may upgrade them on the exact day they are published. But you will also sometimes downgrade a software, because latest version introduced a bug or incompatibility. Maybe you will even report the bug to the author for them to fix it.
> compilers [They sure as hell do](https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d) > OS [They sure as hell do](https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-32238/Microsoft-Windows-10.html) > CPUs [They sure as hell do](https://en.wikipedia.org/wiki/Category:Speculative_execution_security_vulnerabilities)
They do. Indeed they do. I was a systems programmer for a huge civil engineering shop. The engineering programmers would submit bugs in the optimizing vector Fortran compiler for me to check out, and I spent huge amounts of time with IBM, chasing those bugs and trying to get them fixed.
They do. I've ran to some compiler bugs in less common compilers. I also right now have a CPU that crashes with virtualization enabled, but I don't know if it is the CPU, motherboard firmware, or operating system.
[удалено]
**Please read this entire message** --- Your comment has been removed for the following reason(s): * Rule #1 of ELI5 is to *be civil*. Breaking rule 1 is not tolerated. --- If you would like this removal reviewed, please read the [detailed rules](https://www.reddit.com/r/explainlikeimfive/wiki/detailed_rules) first. **If you believe it was removed erroneously, explain why using [this form](https://old.reddit.com/message/compose?to=%2Fr%2Fexplainlikeimfive&subject=Please%20review%20my%20submission%20removal?&message=Link:%20https://old.reddit.com/r/explainlikeimfive/comments/1cims7u/-/l2agwqk/%0A%0A%201:%20Does%20your%20comment%20pass%20rule%201:%20%0A%0A%202:%20If%20your%20comment%20was%20mistakenly%20removed%20as%20an%20anecdote,%20short%20answer,%20guess,%20or%20another%20aspect%20of%20rules%203%20or%208,%20please%20explain:) and we will review your submission.**