My point exactly. They have different ISA, and as such cannot be compared on the transistor count alone.
They each correspond to a different era, with different needs, as BCD clearly tells.
If today's HW engineers had a chance to implement a small cpu core with the same tr count, would they come up with the same ISA as the ARM1 or 8086? Would they choose to implement integer division (DIV and IDIV in x86), or not and leave it to software (ARM)? Would they pick CISC, RISC, VLIW, or something else?
> 29000 transistors? But it's the same as an ARM2 which apparently was full 32bit and had an integer multiplier.
It's a very good point. I think it's worth to ask a few questions in return.
How many years separated the two designs?
Does ARM2 support an equivalent ISA, in terms of features (not encoding)?
For instance, the 8086 has support for BCD integers, specialized instructions for loops, the ability to use its registers as 16 bits or 8bits (doubling the register count in the later case).
> Does the microcode contain any "junk code" that doesn't do anything?
> It seems to! While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM
Could it be the signature of the microcode implementor?
I decided to search for SMP, which stands for Symetric Multi Processing, to verify its definition. This acronym is used for hardware sporting several identical CPUs, which is what we've seen so far in the x86 world.
The opposite is called AMP, for Asymetric Multi Processing. The Wikipedia article on the subject describes several OS level strategies to handle that sort of hardware.
> Plainly named but patently cool, eFuel is a synthetic gasoline that burns exactly like the traditional stuff yet has minimal environmental impact.
> But how is eFuel made? [...] the hydrogen is combined with carbon dioxide captured from the air, and through the magic of chemistry it all gets synthesized into methanol, which is then converted into gasoline.
How can this be carbon neutral if it burns like traditional gasoline? Doesn't it produce CO2? Does the synthesis process capture exactly the same amount of CO2 than what is released from combustion?
Also, if it is possible to do this, isn't there also a fuel that would not release CO2 at combustion while consuming CO2 for synthesis?
Wouldn't it be possible for a process to ask to be pinned to a specific CPU core, or the OS to handle programs with extra tags indicating their ISA requirements, so that it could restrict the scheduling to those cores matching the requirements?
> Most of the good features that people associate with Ubuntu are actually in Debian, with none of the proprietary weirdness that creeps into Ubuntu year over year.
A lot of what you find in Debian also comes from what Ubuntu does. In fact, I believe that many people hired by Ubuntu in the early days were experienced maintainers for Debian.
20 years ago, the problem was all about getting Linux consumer desktop friendly. On the server side, it was mostly OK, people there were not afraid of a TTY, because it was the primary entry point to learning Linux, and Unix in general, whereas in the Windows world, people first approach was (and still is) the GUI. Debian wasn't as good as it is today in the desktop area.
Ubuntu appeared on the market mainly to solve that problem (they were not the first ones to do that), and "leverage" on the acquired expertise to make money.
Nowadays, the money is in servers and IoT, so they are focusing to that segment of the market.
The nature of open source meant that of course, Debian benefits from their work.
The main advantage of Silverblue isn't just toolbox (which isn't originally an Ubuntu tool, btw).
The main advantage of Silverblue is its readonly root fs. Toolbox comes as the provided way for devs to be able to work on top of that feature.
I think Debian has/had some energy devoted to turn the root fs read-only as an option (perhaps in order to move to an ostree based distro, ostree being already available as a package in Sid). Hopefully they'll manage to get it working.
Also, please note that it's not a silver bullet. An immutable FS is a good feature for security (both from malicious adversaries and an oblivious self), but of course it's not enough.
> I got tired of running `pacman -Syu`, rebooting, and having my machine not turn on due to some new kernel change or some video driver change, or something else.
I was trying to point out that quoting parameters or not could bring a different meaning for a shell (as one could see it with Bash), with the implied consequence that one would have to carry over that nuance somehow to a shell where all parameters would have to be quoted.
> Does anyone actually do that in a production code?
Would you accept teaching code as production code? Specifically, if you were to teach programming to young non English speakers, wouldn't you accept them to use words of their native tongue for variables and such?
> I'd actually consider it a bad idea, as it limits significantly who can manage that code in the future.
Wouldn't you say that solely using roman letters in code would impose a similar limit? In countries where these letters are seldom used (like for instance greek letters in western countries), only those accustomed to them would be able to handle code (as it has been the case until the last decade perhaps).
They each correspond to a different era, with different needs, as BCD clearly tells.
If today's HW engineers had a chance to implement a small cpu core with the same tr count, would they come up with the same ISA as the ARM1 or 8086? Would they choose to implement integer division (DIV and IDIV in x86), or not and leave it to software (ARM)? Would they pick CISC, RISC, VLIW, or something else?