mintsuki

A new snapshot of the Gloire distro using the Ironclad OS/kernel written in Ada (https://ironclad-os.org/) is out, featuring work on porting the MATE DE and fastfetch, amongst other things.

Because they do know about them. At least some of them do, of course.

Ideally, BIOS/CSM systems should not care about what type of partition table format a disk uses, and just boot by loading the boot sector (the 1st sector), and passing control to it.

In the real world, some machines will check for whether an MBR exists (by MBR meaning the partition table contained in the first sector, also called "msdos" partition table, naming varies depending on who you ask), some of them will check whether there is any partition set as active in said MBR, some of them will, indeed, check if there is a GPT (past any protective MBR), and ignore such disks - possibly because firmware writers thought that no GPT disk should be bootable on BIOS systems (Windows doesn't support it, so...), to avoid passing control to an empty protective MBR and possibly crash or hang as a result.

I know every word of what I said in the message you're replying to. While what you said is mostly accurate, as in MBR != BIOS and GPT != UEFI, never in my original message have I stated that that is the case. And the rest of what you said is incorrect, as per my original message.

I invite you to read what I said again.

Indeed! Which is why the only portable solution is to not do this.

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.

That is a very niche use case, and also won't really work on most real BIOS machines as they actually check for a proper MBR and/or BPB (and no GPT), which is also why GPT on BIOS support is very spotty, since a lot of BIOSes will detect the GPT and refuse to boot, or refuse to boot in legacy (CSM) mode.

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.

By spec, UEFI is required to support both MBR and GPT, so there is literally nothing stopping you from using MBR.

I don't know much about nim but I have seen my fair share of Rust and Zig code. Out of these 2, I'd personally pick Zig if I had to choose. Rust's syntax doesn't resonate with me very much and I feel like it tries to hand hold too much at times.

That said I am a programmer and as such I am more into what I can get done with these tools rather than the tools themselves. Whatever I feel can get the job done for whatever I need to do is okay with me. In Vinix's case, I can confirm from personal experience that V has been able to get the job done so far effortlessly.

I basically said that V lends itself better to this kind of development; and the modular, headerless structure gets less messy than C codebases.

I also said that while I was skeptical of V (I have read all the criticism many times and I was also critical of the language for the longest time), it lends itself relatively well to kernel development and I am generally having a good time developing Vinix, only encountering minor compiler-related issues here and there, mostly with inline assembly.

I also said that the language, by virtue of it currently being a relatively thin wrapper over plain C, resonates with me more as a C developer than somewhat similar alternatives like Zig or Rust.

Matter of opinions, really.

Hello, I am the maintainer of Vinix and main contributor. Feel free to ask me anything about the project!