zlacker

> In the end, x86 systems didn't become any more locked down.

I realize it was only introduced as of ~2012 and it's been 10 years, but I'm not sure we can draw a conclusion on this one just yet. Windows 11 took a huge leap in that direction so for all I know it might take another decade; it certainly doesn't look like they've given up on the idea of locking down the desktop just yet.

>>datafl+(OP)
They attempted to lock down the boot process with 32-bit ARM, but backtracked with 64-bit ARM. If the intention was to keep eventually lock it down, why backtrack and open it back up? It's not as if Linux on ARM was a major selling point for their ARM devices.

>>messe+x
I actually don't have knowledge of that. Do you know what the reason for the backtracking was?

>>datafl+(OP)
>it's been 10 years, but I'm not sure we can draw a conclusion on this one just yet.

seriously? 10 years is an eternity in tech, and if they really did lock down the desktop a few years from now with some new system (eg. pluton), I'm not really sure that you could say "I told you so" or "TPM caused the platform to be more locked down". It'd be like predicting some sort of smallpox attack by china in 2010, then claiming you got it right in 2020 because of corona. The only plausible scenario where you could plausibly blame TPM/UEFI is if OEMs suddenly decided to remove the ability to add user keys and/or disable secureboot.

>>datafl+K
To be quite honest, I'd be interested myself to find out. I can't see the motivation for changing it, other than they found it not to be beneficial. It seems like opening it up again would just create more problems in the long run if they intended to close it down eventually.

I might look into it, as it sounds like an interesting rabbit hole.

>>datafl+K
Microsoft's 32-bit ARM devices were being sold as appliances, their 64-bit ones are being sold as general purpose computers.

>>gruez+41
In fairness, I think they have a point. 10 years is usually an eternity in tech, but we're talking about a system that's still compatible with systems from the 80s; so I think that expecting things to occur on extended timelines isn't unreasonable.

>>gruez+41
> 10 years is an eternity in tech

Maybe if you're talking Java versions, but not in the desktop OS space. (Look at so many old machines running Windows 7 or earlier right now, and look at long old OSes are officially supported, and how long they're still used afterward.) And besides, even if it was, this wouldn't mean anything. Look at the whole Default Browser fiasco that happened in the last few months. Microsoft went back to engaging in practices they had already settled with the Justice Department two decades ago.

Also look at how they finally made Windows 11 64-bit-only. And even now it still runs 32-bit programs, just the OS is 64-bit. It took two decades after 64-bit CPUs came out to get to this point.

They take their time and meander, and it takes a while. Possibly due to corporate sluggishness, possibly due to wanting to boil the frog slowly, possibly due to wanting to test the waters for a while... who knows why. But speed isn't the main criterion.

>>messe+22
How long computers can last isn't really relevant here. What's relevant is how fast new systems get developed, and whether a given system can be blamed for some action a few decades down the road. For instance, let's look at HTTPS. It was implemented to secure web traffic, but also plausibly can be used to lock down who can publish websites (eg. by refusing to issue certificates). However, in its current form it's not really problematic because there are many easy workarounds (eg. using http, adding an exception, etc.). Suppose 5 years from now all the browser/OS vendors go rogue and lock everything down. All web traffic must be conducted via HTTPS with a valid certificate, and all of the workarounds are removed/patched. Can you point to the introduction of HTTPS and say "see I told you! 1994 was the beginning of the end for the open web. We really should have opposed it when we had the chance!"?

>>datafl+32
>Maybe if you're talking Java versions, but not in the desktop OS space. (Look at so many old machines running Windows 7 or earlier right now, and look at long old OSes are officially supported, and how long they're still used afterward.)

see: https://news.ycombinator.com/item?id=29860320

>They take their time and meander, and it takes a while. Possibly due to corporate sluggishness, possibly due to wanting to boil the frog slowly, possibly due to wanting to test the waters for a while... who knows why. But speed isn't the main criterion.

But in this case it's not really boiling the frog because it's not really getting worse? All we know so far is that it's TPM but it's easier to update. I suppose this could be used to oppress users by patching jailbreaks faster, but the security benefits at least makes it plausible that they're not doing it as some sort of plan to oppress users.