When will this tired piece of shit known as FUD die.
With that logic then the damn Linux kernel got "unexpected" ties to Microsoft.
>The trend is that its becoming more and more difficult (due to reimplementation costs and dependency lock-ins) to do Linux in the non-Microsoft way.
No idea what this is suppose to mean in this context, that we get new hardware stanards/tech like UEFI/GPT/secure boot or that people choose to use software like systemd?
That these standards are written with the interests of Microsoft in mind. And that the only Linux-side implementation of them is systemd, where an Microsoft employee is the head maintainer. So if you want any of the new "features" you will need to have a linux/systemd/GPT/UEFI stack.
Smells alot like embrace, extend. Extinguish comes next.
All I see from your comment: With a hammer in hand, everything is a nail.
Or to be more specific: If Microsoft is directly or directly involved in OSS or standards, then it's all EEE/compromised.
GPT/UEFI are standards, they are not ruled by Microsoft nor do I even think it was sole written with Microsoft in mind, at best what I can find is that UEFI took the same architecture Windows has with EFI, that's about it.
systemd's only concern with well systemd, no one is stopping you from not using it, or I'm oh so curious how non-systemd distros are able to boot WITH UEFI + GPT.
- ESP is the FAT filesystem, developed in 1977 for DOS
- LFS vfat extensions so the ESP can have directory entries with lowercase letters or longer than 11 characters. This also pulls in the UCS-2 encoding. Stuff from Windows 95.
- EFI executables are actually windows PE executables
- ... which are hacked on top of a MS-DOS MZ executables (The "This program cannot be run in DOS mode" thing)
- ... and use the Windows64 calling convention
So formally, UEFI is not ruled by Microsoft. Somehow yet all this Windows/MS-DOS stuff ended up in it.
>GPT partition uuid's with the "mixed endianess" from Windows COM
From the wikipedia[1]:
>The binary encoding of UUIDs varies between systems. Variant 1 UUIDs, nowadays the most common variant, are encoded in a big-endian format.
>Variant 2 UUIDs, historically used in Microsoft's COM/OLE libraries, use a little-endian format, but appear mixed-endian with the first three components of the UUID as little-endian and last two big-endian, due to the missing byte dashes when formatted as a string
In other words, there are 2 variants, 2 is for Microsoft's COM/OLE, so it's not designed by Microsoft.
>ESP is the FAT filesystem, developed in 1977 for DOS
>LFS vfat extensions so the ESP can have directory entries with lowercase letters or longer than 11 characters. This also pulls in the UCS-2 encoding. Stuff from Windows 95.
FAT is not govern by Microsoft, despite them being the original author, and even then FAT32 patents have expired[2].
>EFI executables are actually windows PE executables
You would need to provide proper source for this, the only source I can only talks about boot loaders, which I would imagine is written with the OS in mind[3].
- Some kind of MS branded Linux, that offers improved security/performance/usability etc. it’ll offer full compatibility with existing distros like Debian that devs are already familiar with, but it’ll come pre-setup on windows and it’ll have an amazing integration with GitHub, VSCode and azure, and probably their K8s product too. Much like VSCode they’ll use their influence to get devs used to using it. They’ll probably sponsor a bunch of major OSS projects to use it and start offering features specific to it, bits of it will be “open sourced soon” or similar. The position of power and control will be exerted over it-much the same way Google does with chrome and how that is “open source”.
- a linux compatible api layer over windows, with the angle of “no reason to need Linux anymore”, they’ll angle for large enterprise customers first, offering a Linux-compatible experience, to convert them. Similar experience with above, where the end to end (local to cloud) experience will be the focus. Once again they’ll integrate with existing tooling and major OSS players with the same goal-be so seamless and tightly integrated, and “works with existing tools” that devs will flock to it the way they do with chrome. Orgs and projects will switch to supporting it, probably because the overall experience is superior.
That’s a couple of ideas off the top of my head, we could probably all come with some more scenarios.
The trend is that its becoming more and more difficult (due to reimplementation costs and dependency lock-ins) to do Linux in the non-Microsoft way.
XDG, UKI and UAPI Standards are also written by people who are getting their paycheck from Microsoft.