What open source support? Just because they have a FOSS driver for their integrated GPU doesn't mean their platform is supportive of FOSS overall. AMD actually beats Intel in this regard. Not only AMD releases and develops a free driver for Radeon, the only discrete GPU lineup with such drivers, and for a market that is way more complicated and reluctant to release FOSS drivers. Moreover, AMD provides more specs for their chipsets, they employ free software developers to work on Coreboot support too.
Originally Posted by mendieta
On the other hand there's Intel, whose rampant blob-ridden CPUs need binary blobs initialize memory and BOOT AT ALL. Many of their processors are being released with theft protection features (AMT) (read remote backdoors). Some mobo's firmware do not even expose this settings to the user, and the ones that do are using proprietary code anyway.
There's also something else to consider. AFAIK, most applications are being developed on Intel machines. This means that generally, any program that's written to take advantage of 8 threads will really benefit from Intel's hyper-threading because it would treat those as if they were being hyper-threaded. I'm just guessing here, but I'm fairly certain that it means higher memory speeds/bandwidth and because the CPU automatically balances loads so it's performing the best it can 95% of the time.
Originally Posted by IsacDaavid
Example: Two processes on separate threads. Both need to be completed before the next job can be started. With a dual core it used 100% of the first core and 25% of the second. Assume you have a single core with hyper-threading and the same total processing power as the dual core. It would do the same task but faster because:
(percentages in comparison to a single core in the dual core system)
Really, even if AMD has faster processors than Intel, it doesn't matter if these programs can't make use of 100% of these many cores, and from what I remember, it's easier to treat one core as multiple cores (threads) than have multiple cores act together as a single core (thread)
That makes Intel procs with AMT unusable when security against police is needed
The presence of any kind of firmware "antitheft" backdoor is enough to blacklist a chip from any use where any police agency or intelligence service in a nation friendly to the source country is a potential adversary. Remember, anti-theft software is policeware by definition!
Originally Posted by IsacDaavid
A real-world example is GM's "OnStar" service in cars: if it is physically present in the vehicle police can turn it on, track the vehicle, even listen to conversations inside thanks to cooperation between GM and the cops. This is routinely used today in things like tracking stolen cars, and works with or without an OnStar subscription. This means a GM vehicle driven by someone not friendly to police and national "security" agencies for which OnStar was offered must be physically searched and all OnStar components unplugged from the wiring harness. They are usually present even if OnStar service was not purchased at first sale, as it's cheaper for GM not to build the cars two different ways. Hopefully GM didn't set the engine computer to refuse to start the engine if OnStar is not present.
Thanks for the warning about this, if I ever need a new netbook I will have to research the model in question to ensure that there are no "anti-theft" features in firmware or hardware, even if that becomes so common as to force me to seek a used machine instead. The sole exceptions would be coreboot support plus proof that the "feature" would not work without its binary blob in the firmware, or if it could be proven that removing the original network hardware and using only a USB connection would disable the backdoor in question by denying access between the network adapter and the PCI-e bus. The latter case is true of Core 2 era Intel v-Pro out of band management firmware on server boards, which depends on the combination of an enabled CPU, an enabled chipset, and Intel's network hardware to function.