But, as okanat says, if the goal is to run legacy operating systems, then modern hardware is going to be challenging in other ways too. IME the biggest thing I want PC BIOS back for is the ability to use non-GPT disk layouts, which this doesn't accomplish as, as to use it you put it on the EFI partition on your GPT disk.
Meanwhile, other implementations will not consider the disk bootable in BIOS mode if the partition in the pMBR is not marked bootable.
For stuff that needs to be bootable by both BIOS and UEFI the only portable solution is to use MBR, not GPT. That means all legacy BIOS systems will boot it, and so will all UEFI systems since UEFI must support MBR.
For ISOs that need to additionally be booted off of optical media (aka ISOHYBRIDs) the story gets more complicated, but ultimately what you need to take away from that is the same: avoid GPT at all cost.
Seems like an inconsistency which could be addressed by adding it to the spec and/or test suite.
I guess the other thing I don’t know, is whether there is any actual real world pressure on firmware vendors to pass the test suite.
For instance, whole-disk btrfs. Or old BSD partition schemes.
In any case that is far beyond the original scope of booting old PC OSes, which MBR support alone serves really well (99.9% of the way there, really), which is why I assumed by default you were thinking of MBR, not some other weird scheme.
MBR is two things with the same name. It is both the format of the storage device and describes a booting mode using a master boot record and up to 4 partitions.
GPT is one thing. It is a format for a storage device. It is the alternative to the MBR format for storage devices. It has nothing to do with (U)EFI.
BIOS or BIOS/csm are not types of formats for storage devices. They are types of boot processes. (U)EFI is another type of boot process.
You can easily mix and match boot types (BIOS/csm vs UEFI) and storage device format types (GPT vs MBR). As others have said, there may be some slight incompatibilities on some rare hardware/software configs, but mostly it just works.
While the space wasted by GPT and partitions and by the arbitrary alignment rules used by various formatting tools is not great, I do not see any reason why it should exist. The space wasted now with GPT and UEFI is several orders of magnitude greater than it was with traditional partition tables, so eliminating it has become more attractive.
Such SSDs and HDDs are not bootable, but for me this is a desirable feature, not a bug. I boot my computers either from Ethernet (e.g. most of my servers) or from a removable USB memory.
The SSDs and HDDs with a whole-disk file system are also wholly encrypted. As in a proper encryption implementation, there is complete separation between the encrypted data and the encryption key. The encrypted disks or their hosting computers do not contain any information about decryption, unlike in many systems of disk encryption. The encrypted decryption keys can be found only on external or remote boot media, which are not normally associated with the hosting computers.
I wouldn't recommend that. It makes the disk appear to be empty to many tools (and possibly some operating systems), which could lead to data loss. That's the reason GPT has the protective MBR: it makes the disk appear to be full to legacy tools which don't understand the GPT format.
Windows frequently overwrites any bootable Linux drive, so it might have even less restraints with an apparently empty drive that does not have GPT structure.
Because of the risk of Windows messing with them, I also do not insert any of my bootable USB memories in a live Windows computer, even when they have GPT structure. For data interchange with Windows, I use only clean and non-bootable exFAT formatted USB memories.
I would really love to know more about this.
I assume it's this VGA driver:
https://github.com/tongzx/nt5src/tree/master/Source/XPSP1/NT...
If it were an Oracle source code leak, I expect they’d have a crack team of lawyers suing people 24x7 until it was all gone… maybe that’s why there haven’t (to my knowledge) been any Oracle source code leaks (I vaguely remember one of Solaris, but that wasn’t such a clearcut case since IIRC it was mostly previously open sourced code)
Well, it wouldn’t surprise me if some unfriendly intelligence agency somewhere had succeeded in stealing some of it, but if they have, they are unlikely to release it publicly
Even weirder is that GitHub hosts all of the tools for activating (i.e. cracking) modern versions of Windows and Office as well. Microsoft really doesn't care.
...of which the tools to disable that invasiveness are also on GitHub, so maybe they just care more about maintaining marketshare.
During the mid-90s, the Unix Wars were raging and Unix System Labs was suing U.C. Berkeley over the intellectual property of Unix source code. Unix had been written at AT&T Bell Labs, but Berkeley had licensed and forked their own, based on improved networking code, and by this time it was ready to run on i386 systems. In fact, USL had borrowed back some BSD code, allegedly without crediting them. Berkeley had been busy removing AT&T code and replacing it, so they could relicense BSD Unix.
USL, part of AT&T (but later purchased by Novell), contended that Berkeley could not easily make a "clean room implementation" of any kernel code or device drivers, if those programmers had read or worked with original AT&T source code. They told the courts (and journalists) that the programmers might be tempted to reproduce proprietary Unix code, consciously or subconsciously, and therefore, these programmers were permanently "Mentally Contaminated" and Berkeley should not be allowed to continue distributing BSD [BSDi] Unix.
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
So when I attended Usenix LISA in 1994, this 3-year lawsuit was at a fever pitch, and someone on the convention floor had manufactured large buttons for attendees to wear, proudly proclaiming "MENTALLY CONTAMINATED", and all the admins and systems programmers had a good laugh about the absurdity of trying to keep a lid on proprietary source code by policing everyone who's ever seen one of its files.
- https://en.wikipedia.org/wiki/Shared_Source_Initiative#Overv...
- https://news.microsoft.com/source/2002/02/21/microsoft-annou...
I don’t know the current status of those source code access programs but I believe at least some of them are still in effect. IIRC, to stop the Chinese government from dumping Windows, they had to give them source code access, but I believe they are planning to dump it anyway, they see relying on US proprietary software for their government operations as too big a risk
Anyways, very cool to see.
> It is based on the SpiderSTREAMS source, stremul\msgsrvr.c.
There's some special history.
Could this be seen a distribution by Microsoft? I mean, if you can sue Pirate Bay for the content they host...
and VESA VBIOS from SeaBIOS project
Unfortunately I believe modern GPUs without a standard VBIOS may not act enough like an IBM VGA for a generic VGA VBIOS to work, so I see another project for someone in the future: a retrofit VBIOS, especially for those GPUs e.g. Intel's for which lots of open-source driver code and documentation is available but later models no longer come with a VBIOS.
Perhaps also injecting a true CSM from an old closed-source UEFI BIOS, before they started removing it, is worth doing as in my limited experience SeaBIOS isn't as quite compatible as the closed-source ones for some edge-cases.
ehutch79•22h ago
p_ing•22h ago
okanat•22h ago
kevin_thibedeau•19h ago
mycall•17h ago
kevin_thibedeau•15h ago
ale42•13h ago
II2II•22h ago
Retr0id•20h ago
axiolite•22h ago
Additionally, it was just 3 years ago that memtest86plus finally got a UEFI version. That was painful for a few years there. (Though the 4GB RAM limit would have made this not an ideal solution.)
I'm sure there are other such self-hosting utilities that haven't been and may not be ported/rewritten to work under UEFI.
sdflhasjd•8h ago
justsomehnguy•1h ago