Hacker News Reader

Hacker News

Comment by swiley | Hacker News Reader

Parent Full thread

swiley

Personal computing is completely dead except for enthusiasts. We've completed our regression to the late 70s.

View on HN

What do you expect when people buy Apple laptops to do GNU/Linux work instead of improving the ecosystem of Linux OEMs?

Or are now rushing to give money to Microsoft and use WSL?

Well, that is how things eventually turn out to be.

> Personal computing is completely dead except for enthusiasts

So you're saying only enthusiasts have smartphones?

What does this even mean? Secure boot has little impact on anything except reducing the complexity of Windows (since it doesn't need as many boot configurations)

It makes Linux more complicated to deploy, for one. And if they ever change their mind and don't allow it on x86 any more, Linux is basically exiled from the PC OEM market.

It shouldn't, as Microsoft made sure that the major distros (Ubuntu, RHEL, Fedora, CentOS, maybe Debian?) have access to a signing key that is trusted by the major OEMs. And you can trust your own keys, per the Microsoft guidelines that require that x86 machines allow their secure boot to be disabled.

https://docs.microsoft.com/en-us/windows-hardware/drivers/br...

What if I'm not a major distro?

Why should I have to go to some company to let me use my hardware they didn't even make?

What happens if one day my distro starts to anger the gatekeeper, or worse, start to compete with them?

This is all wrong. Stop supporting them.

> per the Microsoft guidelines that require that x86 machines allow their secure boot to be disabled.

Yeah but then you can't boot into Windows? Who is actually going to go into the firmware settings to switch settings on and off for every single boot to the other OS?

you can boot debian/redhat/... out of the box without disabling it, as the shim used as part of the boot process has been signed by MS

if you want to sign your own kernels: the shim will also let you do that relatively easily ("machine owner keys")

if you want to own your entire boot process you can replace the platform key and sub-keys with your own, and then trust whoever you want (even adding MS' keys if you wish, so Windows can boot in secure mode)

I'm pretty sure we don't want to be in a world where we can only use one of a few Microsoft-approved Linux distros without it being a pain the the ass to deal with.

we've been in that world for about 10 years now

if you don't like it... turn off secure boot, or enroll your own keys (the mok approach takes about 30 seconds)

> the major distros (Ubuntu, RHEL, Fedora, CentOS, maybe Debian?) have access to a signing key

Those distros also all use systemd. Do you think they'll sign an image that doesn't include it? We're heading down a path where developers need permission to innovate, and the switching cost of running something non-standard becomes too high for even the most technical users.

systemd has nothing to do with secure boot. Gentoo for instance supports it and offers, and maintains OpenRC

https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Inst...

Note that you must add your own keypair for that, as Gentoo is a source based distribution so there isn't anything for Microsoft to sign.

You're thinking at the wrong level of abstraction. Sure, Microsoft is permitting it now, but what about later?

And just wait until all executables signing becomes mandatory with Microsoft and few selected partners holding all the keys. Window 11 will set the tone, and Windows 12 will kill the indies, we will have to go trough Microsoft, steam, ea, origin of whatever stores will be able to pass the bar.

The Steam folks are as worried about this as anyone. They have more to lose than we do, and the same amount of influence at Microsoft (read: none at all.)

Ah, yes, the golden era of the '90s and '00s, when Linux was easy to deploy and PC manufacturers supported you running Linux.

We made it work and we'll make it work again.

DRM such as Secure Boot wasn't viable in those times, nor was interconnectivity expected. This round could be very different if they wanted it to.

I think for x86 you are (at least very close to) correct, but I've been seeing a serious shift towards ARM chips and (my pipe dream) soon RISCV. X86 may just need to fall to the wayside at this point. Maybe PineBooks could be released with ARM chips too! (RISCV as well, but peripherals need to be a real thing(TM) first). Heck, the Pi400 is a good start in that direction (though obviously isn't enterprise ready yet).

Honestly, I vastly prefer OpenPOWER over ARM from a consistency in implementation perspective. Not to mention, at least with POWER9, no mandatory binary blobs or opaque management engine chips that can't be properly audited.

OpenPOWER is extremely expensive though. There is no universe in which I would pay several times the price for a high-powered x86 gaming PC/workstation just to have an open-source CPU and hardware like Talos. It has to be both open and affordable.

The openness situation for ARM is even worse.

Case in point: the countless Android devices out there.

It's really a Qualcomm problem more than an Android problem. Everyone seems to think Qualcomm==Arm though because in the USA it pretty much does.

Not just Qualcomm but the vast majority of ARM SoCs used in Android devices, and in general, have no public documentation.

I guess if the firmware allows users to install their own CA it's ok. I wouldn't be surprised if that feature was neglected by the OEMs or intentionally removed with windows 12.

To their credit, Microsoft has signed a secure boot "shim" that allows the user to do that, with explicit prompting. It's being used in the boot flow of many Linux distributions.

In other words, it was Microsoft who effectively "gave permission" for Linux to run.

One OS company has control over whether they allow competitor's OSs, on hardware that the company doesn't even produce. That should be an absolutely horrifying thing to anyone who believes in software freedom.

You can disable secure boot and add your own keys in the firmware config page. Who knows how long that will last though.

> You can disable secure boot and add your own keys in the firmware config page.

You can disable secure boot or add your own keys because Microsoft required all manufacturers to allow it. If it wasn't mandated by Microsoft, some manufacturers would not allow it. And for ARM devices, Microsoft required the opposite (https://softwarefreedom.org/blog/2012/jan/12/microsoft-confi...). So yes, the only reason we can run non-Microsoft operating systems on our computers is because Microsoft "gave permission".

Also, turning off secure boot doesn't change the boot process on Microsoft's side, they have to ask the firmware after booting if it was disabled.

Sorry for replying twice but I'm almost always stuck on noprocrast so I can't usually edit my comments.

I understand the risk and want to forego secure boot. What's wrong with that?

Nothing wrong with freedom. Not running the master of all telemetry OS increases the possibility to read and study what you want without feeding the data hungry sensors Microsoft has set in stone for you. These datasets are brought to market with your consent (see the thousands of EULA pages you accepted directly and indirectly).

I'm on the Mac side, and I wanted to reinstall macOS. I messed up the hard drive wipe and ended up breaking the chain of trust. That meant Apple could no longer guarantee the correctness of my install, and no longer allowed my laptop to decrypt my data to reach the login screen directly. I had to input the password for my login at an earlier step during boot, which comes with a litany of small caveats.

I'm sure Microsoft hopes to achieve something similar here at some point: secure boot would give them enough trust to decrypt an install upon boot all the way to the login screen.

At least you could recover by simply typing a login password. A similar screwup on a Windows box might require you to resort to BitLocker recovery keys, which add a fair bit of complexity and some users might not have these at all.

Sorry, but 7 was way more stable than 8-10 and it didn't even support SecureBoot.

As much as you want this to be true, it simply isn't.

Any "Windows x was more stable than Windows y" (including the legally mandated "No, it wasn't" replies) is mostly rooted in what drivers the person used and if the hardware had issues, and has less to do with Windows.

Reducing the complexity how? Their Legacy boot code is already written, and legacy BIOSes aren't going to change either. That code basically comes for free to MS.

Maintaining old code has a cost. Any changes Microsoft wants to make need to be compatible with the old code unless they remove it

Things like tests/validation on new hardware is also costly. Microsoft (used to?) have an absolutely massive fleet of physical hardware to test Windows on

Reply on news.ycombinator.com