Exactly this. The people who designed secure boot and TPMs were not idiots. You can’t trick a properly set up TPM configured with secure boot in any realistic setup.

It won’t refuse to boot. It’s just that any automatic metric based decryption won’t work.

If you are using a TPM to automatically unlock luks and also manually removed the password backup before hand you could lose your data forever. That is true.

But if you kept the password based decryption stuff you could still manually unlock stuff. Just like secure boot was never there.

The difference would be that there could be no secure attestation that the kernel count trust/use without secure boot.

Like secure boot is really cool on Linux if you learn about it. Like sbctl alone is great for verifying backups and stuff.

I recommend reading through the arch wiki if you want to learn more. It covers a lot of stuff. https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot

It won’t brick your system forever??? You just turn it off in your bios. Then you have no secure boot. Just like it was never there.

If you don’t care about boot chain attacks it isn’t bad at all.

If you do care about boot chain attacks it’s bad because it allows someone to replace things like the efi binaries, grub, or your kernel with backdoor-ed versions and there would be no way to detect this from the running system.

Secure boot checks for this stuff. You can read more here:

https://access.redhat.com/articles/5254641

You can but then you don’t have secure boot.

You need to let the scientists know this! I’m sure your insights will be very valuable to them.

I don’t own a car. I just maintain a drivers license for rare cases when I need to go to a place where public transport does not reach.

I just went through the education and have the practical experience regarding driving.

I don’t think this angry approach is the best way to go forward here. Action and advocacy will beat out internet anger all day.

Advocate for and use public transport at you local level.

I suspect you might be telling on yourself here as someone who didn’t drive.

People who go through car education and actually drive learn about system tolerances. Speedometers can be off by up to 10% and radar guns can be off by about the same.

If you actually drive and use cruise control set to 30 and go up a hill to a level section of road, the cruise control will likely bring you up to 33 before it reacts the reduced power needs and brings you down to 30 again.

Cars in real life are not exactly like they are in video games.

Not true. I run them rootless on my server as we speak. :)

The point is, that the answer is 0% by any reasonable metric. I don’t think any more is to be gained here given the question dodge.

So I will say good bye and best of luck again.

Ok. I have one question then. I think we can come to a clear resolution with it.

Debian GNU/kFreeBSD, what percentage is it Linux?

It includes 100% the apps, system tools, GUIs, and libraries that you associate with Linux. It also has 0 lines of Linux code in it.

If you can justify that it is above >0% Linux I will use your definition of operating system going forward.

But we can agree that there are upper and lower limits though. And I believe that we can now agree that system utilities and system libraries are outside of that limit. Just because the edge are fuzzy, don’t mean we can’t come to any conclusions at all.

Any now stepping way way back. I think we can now agree that Fedora, Ubuntu and other distros run the same operating system. That operating system being Linux.

That’s ok! I was just trying to help you see the difference. You do now. It’s a win/win. There was a reason why I kept on brining up Debian GNU/kFreeBSD. It really highlights the difference.

You’re gunna do you and use your own definitions and I respect that. But the first line from the page is

Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD’s kernel, coupled with the regular Debian package set.

It is literally GNU userland using the GNU C library on top of FreeBSD’s kernel, coupled with the regular Debian package set

You can say Debian GNU/kFreeBSD is BSD system tools with a Linux kernel but you would be evidently and clearly wrong.

Anyways. I wish you well. Best of luck.

If you define it that way you are right. Yah. But the common understanding is a bit different than yours.

https://en.m.wikipedia.org/wiki/Operating_system

Really great read.

I urge you to take a look at https://www.debian.org/ports/kfreebsd-gnu/ It’s the exact same utilities and everything but a completely different kernel. It really highlights the difference here. How would your definition account for this?

Would Debian GNU/kFreeBSD be 50% Linux, 50% FreeBSD under your definition even though it has no Linux code? It has all the system libraries and system utilities that you associate with Linux.

But it literally is the same. The only difference is the user space. Debian GNU/kFreeBSD shows this. Different operating system same user space.

Take a look at Wikipedia for more info.

An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs. Time-sharing operating systems schedule tasks for efficient use of the system and may also include accounting software for cost allocation of processor time, mass storage, peripherals, and other resources.

I mean they are all literally the same operating system yah! They all use the same kernel APIs.

The logical conclusion is that from an operating system they are all basicly the same.

The main difference is the user space. The package management and defaults.

Look at Debian GNU/kFreeBSD it’s a whole different operating system with the Debian user space. It’s cool stuff and really highlights the difference between operating system and user space.

Hot take. Under semantic versioning everything after vista has been in essence a new version of vista.

Going from NT 5.x to 6.x was a major jump.

The reason why Vista had no/terrible drivers was because they went from an insecure one driver bug crashed the whole system model to more secure isolated drivers that don’t crash the whole system model. Developers had to learn how to write new drivers and none of the XP drivers worked.

They went from a single user OS with a multi user skin on top, to a full role based access control user system.

They went from global admin/non-admin permissions to scoped UAC permissions for apps.

Remember on Vista when apps constantly had that “asking for permissions” popup? That was the apps not using the 6.x UAC APIs.

Given the underlying architectural situation everything since Vista has been vista with polish added (or removed depending on how you look at it)

Things will go beyond vista when a new major release with new mandatory APIs shows up.

I mean it could be Mutex, or Rwlock or anything atomic. It’s just when I have to put stuff into an Arc<> to pass around I know trouble is coming.

You’ll be fine. You will learn the lifetime stuff and all will work out. It’s not that bad to be honest.