Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running.
There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel ME system rely on a couple of proprietary third party code, that has on contract with Intel explicit prohibitions of Intel ever letting anyone seeing their source, or the keys needed to sign them.
Also, Intel ME can't be really trusted, the code is not really "reverse-engineeringable", and it works as a full second OS of sorts, it even has its own JVM running, if someone somehow decide to inject spy software into it, you will never know, also I assume that the first destructive virus to latch into that stuff, will take the world truly by surprise depending on when it triggers (for example if it spreads silently but triggers the destructive payload on a specific date).
Also, these features can be abused to abuse the market itself, for example by intentionally making the hardware underperform, and then sell "superior" hardware that has the only difference some software.
I think you're supposed to be able to distinguish the message from the medium. Certain styles can definitely make that harder, but ultimately if you can't examine an issue by the facts presented, the failure falls on you, as do the consequences.
To be clear, I also think the referenced bit is childish and detracts from the message. I just don't think that should affect your belief in whether it's important.
If a piece is written with a confusingly inappropriate tone for the subject matter, you can't solely blame the reader for being confused since it was the expressed intent of the author to instill that state.
Well, it's a wiki, so "author" is very loose (and when I checked at the time of my original comment, the change to add some of that verbiage was the most recent change, if still quite old). Ultimately, much of the information on the internet is presented without reference, so tone is the least of our problems. We need to be able to read what is being presented, and decide whether it's important enough to use that we should verify it. In this case, the tone shifts, but the message is along the same lines (the ME is your adversary), if very crudely done.
I do think you have a point though. It's not entirely up to the reader, there is a minimum threshold of clearly communicating facts that needs to be met by the author. But I don't think it's safe to say something that's unclear in tone means it was the expressed intent of the author to cause confusion. Humor can add quite a bit to an argument if done right, as humor often has the ability to cut through some of our preconceptions. Humor done wrong might be confusing, but that could very well be unintentional.
It seems there are just some basic begining steps on the site. It's far from the fully dissaembled ME. So it seems we still don't even know what's inside of ME.
Sounds like rich, fertile ground for the NSA, KGB, and other state agencies. They could be deploying such code right now and I'm not sure we would know it.
Not entirely---it's still around in Belarus. And Transnistria and South Ossetia, too, though those may be more of imitators than actual remnants of the original.
That would be far too provable and suspicious, since it'd have to be done 24/7 and would rule out the heisenbug route.
If you were to do such a thing, you'd do it by making the machine overclock itself too much occasionally (after the 'artificial use-by date' has passed, thereby incurring physical damage at random intervals. Although really, it would be easy to do without blob, too, if you're doing the design of the physical chip.
I'd think it would be easier and more profitable (more convenient for "customers" than buying new hardware) to sell the "speed unlock" solution, much like cryptolocker does with your personal data.
"The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called "ThreadX". The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC's HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems."
Java has precedent for running on low-performing devices; see J2ME[0], which ran on a whole bunch of old mobile phones, and Java Card[1], which ran on smart cards.
I doubt it. The powerpc to Intel switch was really painful because the desktop platform has the perpetual ball and chain of backward compatability. I doubt Apple would try to beat Intel at their own high performance game anyway.
I don't think that's necessarily the case - I think that if Apple switched architectures now, there would be a lot fewer issues than there were with the Intel switch.
Over the past few years, Apple's done a lot of work in making the same system APIs available across multiple processor architectures; at a base level, iOS and OS X have very similar cores. You can see this with the ease of the transition from ARMv7 to ARMv8, which in most cases just required a new compilation.
As general-purpose applications have been migrated to higher-level APIs, the difficulty of porting those applications to a new processor architecture decreases; if an application is Cocoa-based and compiled for x64, then if those Cocoa APIs are available on an ARMv8 platform, they can be compiled natively for that platform.
Apple has started requiring Mac App Store apps to be submitted in the immediate representation form, allowing Apple to recompile. If that's not a glaring hint at working towards ARM, what would be?
Having previously gone through the 68k-PowerPC switch, the PowerPC-x86 switch seemed to me like a non-event. The desktop platform most certainly does not have a perpetual backward compatibility obligation; Apple has always been far more willing than Microsoft to break old stuff after a few years if it happens to conflict with their new stuff.
I would expect that they have already been building OS X for ARM internally for several years, and that they'd prefer to avoid switching again but would certainly do it if they ever felt like the use of Intel's architecture was creating a problem for their business.
> Apple has always been far more willing than Microsoft to break old stuff after a few years if it happens to conflict with their new stuff.
Sidetracking this conversation a little, but I'm more and more wondering whether MS actually has a retrocompatibility track record that is that good, or if it is just a nice story. Granted, they communicate a lot on how hard they work on that subject, and they even have a guy who blogs about that and about how great he is because he injects patches in third parties programs to let them work on new OS versions, but the end result is just... random. -- Well, maybe that guy should work on compat between MS products before those of others...
First no medium/big company would think of upgrading the OS without months or even years of studies and tries -- they likely could do and already are doing the same with OS X, then MS actually actively deprecate a lot of stuff all the time (and even whole subarchs, like Win16 not avail on Win64 installs), they also have so much tech and product birth fail it is not even funny anymore, and finally even when they don't mean to, their very own products in more or less the same line are often broken by next versions supposed to be able to install side-by-side or even just patches (example: Windows SDK 7.1, which is upset if you try to install it with anything else than the .NET 4 RTM preinstalled, and then is very upset again during builds if you upgrade your .NET to 4.6 -- or on a completely different subject compat of recent Words with old .doc which is not stellar)
And finally on the technical design side, some choices are just plain complete crap and stupid. Why would you, I don't know, leverage UMDF (that is especially well suited for USB drivers, for example) to allow 32 bits drivers to run on 64 bits Windows when you can just not give a fuck and force people to use their old consumer or dedicated pro hardware with their old computer, and let them throw everything in the trash when it eventually fails. I mean, during the 16 -> 32 bits transition they actually made far more insane things working (at least kind of working) while here everything would be neatly isolated yet they manage to... not even attempt to do it.
I'll not even begin to talk about the .dll story, which is just even more complicated each time they try to fix it because you still have to support the old methods, sometime by some kind of virtualisation. And then, like I said, they just decide to change their mind and use the old replacement method again, (ex: the .NET 4 => 4.5/4.6 mess explained before) which breaks again because they are still not THAT good at backward compat. (In a cringeful way: have anybody heard about symbol versioning?)
So maybe Apple is doing worse (I don't know much about them), but on a Linux system you can actually administer it carefully if you are skilled enough to make any random old application crap REALLY work on a modern install (you might need to duplicate a complete userspace to do that, but not all the time thanks to symbol versioning, and it is not necessarily huge when you do, and at least you can).
At one point AppKit and FoundationKit supported 4 architectures (68k, x86, HP, and Sparc), most Cocoa based applications were just a recompile away.
The main issue with the PowerPC to x86 was Carbon which was never designed to be a cross-platform toolkit in the same away that Cocoa was. Given that Carbon 64 never got off the starting blocks and Carbon 32 was deprecated way back in 10.8 switching architectures will be less painful this time around.
The macbooks were never supposed to be a "power" machine. The whole purpose was a very portable, long batter life laptop. And it dose that very very well.
I would not call that giving up on performance...they just designed something for a purpose and it fits that purpose well.
Dude it has a 5 watt processor and a mobo the size of a raspi. I don't think their featherweight offering is appropriate to enter in the performance fight.
Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running.
There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel ME system rely on a couple of proprietary third party code, that has on contract with Intel explicit prohibitions of Intel ever letting anyone seeing their source, or the keys needed to sign them.
Also, Intel ME can't be really trusted, the code is not really "reverse-engineeringable", and it works as a full second OS of sorts, it even has its own JVM running, if someone somehow decide to inject spy software into it, you will never know, also I assume that the first destructive virus to latch into that stuff, will take the world truly by surprise depending on when it triggers (for example if it spreads silently but triggers the destructive payload on a specific date).
Also, these features can be abused to abuse the market itself, for example by intentionally making the hardware underperform, and then sell "superior" hardware that has the only difference some software.