Interesting perspective. sysinst could certainly use better ergonomics, but I wonder whether he’s really approaching NetBSD like a typical user would - someone after a classic Unix experience on modern hardware.
With an old-school Unix mindset myself, I’ve always found the CLI installers of OpenBSD and Alpine Linux cleaner, more straightforward and in line with that philosophy. Honestly, I’d rather see sysinst replaced by something along those lines.
I've had the classic Unix experience. It's not something that a typical user of the 21st century would either want or enjoy. There was everything from modem line noise to whether it was BS or DEL this week that actually erased a character. And yes, things like what is pointed out in the article: output from other places randomly overwriting the UI of a full-screen (curses) program.
We who lived through the classic Unix experience also remember how at the time MS/PC/DR-DOS had things that we 300 BPS terminal users could but dream of, like an Alt key that just worked and highlighted menu option accelerators when one pressed it. And function keys that didn't just cause a mess, or beeps, or surprise commands to happen.
Typical users of the 21st century would be appalled when faced with it. And there's probably no retrocomputing enthusiast that is quite that masochistic. (-:
Much of what sysinst does is just farmed out to tar, pkg_add, ifconfig, and other programs. It even handily prints their command lines at the top of the screen when they are running. So someone who wants a CLI rather than a TUI, and not really the actual "classic Unix experience", could just run those programs. And there's probably room for an installer that does the same thing as sysinst but in the old text-adventure-game style of print-menu-prompt-for-line-with-selection for people with printer terminals. (-:
But don't knock full screen TUI programs like sysinst. There's definitely a place for them, and on the commercial Unices, where the vendors had gone to some effort to make the installation and configuration programs user-friendly, they were the "classic Unix experience". SCO had one, for example. They even managed to have it recognize F1 for help.
Function keys. F1 for help. This stuff for contemporary Unix people was like the "Classic MS-DOS experience", but at the time when PC users were using GUI installation programs in DOS+Windows 3. (-:
I'm not sure anyone invoking "classic Unix" is pining for modem noise or line printers, though that seems to be how you're interpreting it. That’s more a caricature of early computing than what defines the Unix philosophy or what NetBSD preserves.
When I say classic Unix, I really mean "simple software":
- Text-first, scriptable interfaces where tools do one thing well and can be composed
- Human-readable configuration in plain files, no XML or opaque binary blobs
- Predictable, minimal system design where you can understand what’s happening under the hood without chasing abstraction layers
- Manual pages that matter, and a userspace that favors understanding over wizard-driven opacity
- A system that’s BSD-like in spirit: clean, coherent, documented, and built by people who care more about correctness and clarity than flash or trends
This is in contrast to modern Linux distributions where systems are often a tangled mess of systemd units, layers of more or less obscure daemons and processes, unpredictable behaviors, and YAML/JSON/XML-based abstractions that sit between you and the actual system.
So no, I'm not glorifying the past or pretending users in 2025 would enjoy a serial terminal setup from 1984. I’m saying that a clean, simple, consistent, modular Unix, in the traditional sense, is still valuable and NetBSD is one of the few OSes that still embodies that ethos.
Ironic you use that term when a number of systemd units is often the simplest way of cleanly, reliably orchestrating services and daemons, doubly so when theres any level of complexity or limitations you want to confine one too.
Its cute to romanticize a bunch of scripts to run and orchestrate things but its a nightmare I'd not wish upon my enemies. Less moving parts, yet conceptually more complex to properly manage beyond the basics with far more that can and likely will go wrong.
Systemd has its challenges in real world situations; it has given me enough downtime that I don’t run it on any servers that I am responsible for-I use Devuan which is a systemd-free Debian or preferably a BSD.
I will save you my further comments which descend into a rant :-)
I agree with that. Modern Unix is a 6-of-one-half-dozen-of-another type situation. Yes, terminal emulators and the termcap database are improved. But now, the traditional Unix user might be surprised at how things are done. I have accepted that ... systemd ... manages my networking now (ok, it's networkd or something I guess?). But if you can't accept that, it's good to have some option that just uses ifconfig.
That romanticizes a vision of Unix that hasn't existed for like four decades, aside from maybe Xenix bitty boxes from Radio Shack servicing two terminals in auto shops, video stores, and the like. People bought Unix workstation and server systems specifically to run large, complex applications. Applications that did many things and kept their configuration in binary blobs or XML files. Stability, security, comprehensiveness, and ease of administration are stronger selling points for these systems than simplicity.
As an example of how comprehensive beats simple in the real world, consider Microsoft Outlook. Not just email, but calendaring and contact management. Microsoft's engineers discovered that in the business world, these things go together and bundled them into one, well-integrated program. Outlook ate everybody's lunch, including Windows-based mail clients like Eudora. Integration with Exchange let these services be provided together on an organizational level, fully integrated with Active Directory, and Exchange came to dominate email server deployments over Unix-based solutions which were more piecemeal. Easier to administrate as well.
NetBSD is a fantastic tinkerer's operating system, one of the most hackable ones out there. But let's not kid ourselves here. The philosophy it supposedly embodies hasn't really served real needs in a long time, if ever. Customers want solutions, not hacks held together with shell and Perl scripts.
This is hilarious because I am finishing up the installation of an extremely large complex and expensive project that is fully N+1 fault-tolerant and it uses Perl scripts for nearly everything; it’s a telecom grade SS7 phone switch with custom hardware and the supervisor part is Linux based.
All the customization and service startup is done in plain text and Perl, from what I’ve seen so far.
It's an impossible task to meet what typical 21st century users expect. For that, the OS would have to come pre-installed.
Furthermore, most typical users today are so entrenched in commercial software, and their walled gardens they wouldn't even attempt to use an OS without that software.
The OpenBSD and Alpine Linux CLI installers are honestly a high-water mark for me when it comes to high risk applications where getting it wrong might mean a bricked installation. More people should book out 20 minutes to just spin up a VM and try them out for themselves, to see how nice a good old fashioned command line approach can be!
I had never seen this before. Although I am now trying out lagrange and seeing what it can do.
Sorry for hijacking the thread on what is a great post, but is gemini common these days? This is literally the first time I have ever seen it, and it seems fairly interesting, albeit deliberately limited.
Many HN users can’t seem to get past some minor issues about the spec. Despite this, it’s a working protocol that has a critical mass of real world users, mostly bloggers (which is what the spec author mostly had in mind). One of my blogs on Gemini has a “like” button and it gets several clicks a week, indicating that people are indeed reading my content in Gemspace.
Really? Is that actually really true that they cannot get past the spec?
Because I followed the Wikipedia article to the article on The Register. Whoever wrote Wikipedia summarized El Reg's entire article as how gemini has been critized for excluding people. 1 sentence. But that's only what the headline says, for clickbait. The actual article body paints a very different picture, including the rather subtle (by Register standards) rebuttal of that criticism by pointing out that WWW browsers and the Internet are not in an everything-is-a-nail-and-I-have-this-hammer situation.
So I wonder how true it really is that there's this wave of criticism, and how much that is rather inferred from people reading headlines and nothing else beyond them. Like the Wikipedia author did.
That said, having discovered the existence of Gemini today, I am now wondering how much of a doddle it would be to add a gemini UCSPI-TCP server (which would obviously have to sit behind something like Hoffmann's sslserver) to Bernstein publicfile. The publicfile way would of course have a separate off-line tool to turn index.gopher into index.gemini, once at content generation time instead of over and over at runtime.
Hmmm.
Stop giving me distractions, people! I'm supposed to be getting the next djbwares running on NetBSD. (-:
P.S. I have had the GOPHER server that I added to publicfile running for some time. I use it to publish a not-very-secret list of packages and source archives. It gets some quite odd requests in its logs.
That would be one way to do it, certainly. It's boring, though. (-:
There is another. In NetBSD one can, at least according to the manual, open the wsdisplay of the relevant terminal and read out the display contents, with the WSDISPLAYIO_GETWSCHAR I/O control. sysinst is just a full-screen TUI program.
(The manual says that character values are "ASCII", but the data structure uses a 16-bit unsigned integer for them. So I wonder whether this is UCS-2 or NetBSD has been saddled with some 512-entry character set mess from back in the 1990s.)
Presumably there is a third one if the virtual terminal's wsdisplay is in graphics mode and one can access its frame buffer.
There was also a fourth for the serial console screenshots, although they were clearly done the boring way by screenshotting a GUI window, as its scrollbars are visible in the images. Presumably the terminal emulator at the other end of the connection had some sort of direct screen shotting functionality. That was definitely something that serial device DTE emulator programs in the days of yore used to have.
That's an interesting thought, actually. I wonder whether one could do that at all with many Unix/Linux tools, like GNU screen in its serial terminal mode. One could with (some of) the terminal emulators that used to be available for MS/PC/DR-DOS. There would be some "dump screen to file" menu option, or in extremis a TSR program that could do that. (-:
Did not have "being jelaous of NetBSD wscons framework" on my bingo card.
How does one make a "screenshot" of a TUI program? The classic terminal APIs don't have a "framebuffer" (or "textbufffer" I guess) from what I can tell.
I could use such a mechanism to create automated screenshots of a TUI program (using Terminal.GUI in this case) for documentation generation.
Don't be too envious. Linux kernel virtual terminals have "vcsa" devices that one can read for this sort of thing. And it's right there in the manual page how one does this.
They suffer from being straight copies of CGA, which has historically had a lot of conflation of boldness and brightness, as well as a very limited colour gamut that will make you weep at what your 256-colour TUI programs are reduced to. The NetBSD ioctl supposedly has a bold attribute in a separate field of the structure to a bright colour. Which in the backwards-thinking world of terminals where some people still have the CGA Think that bold=bright, is almost heresy. Still. In 2025. (-:
If you are looking for this sort of thing in a GUI/TUI terminal emulator that is a user application program, rather than the terminal emulators that are built into the NetBSD kernel or into Linux, then that's a different kettle of fish entirely. I know of one that provides a direct vcsa workalike. I wrote it.
GNU screen works by having a server maintaining a buffer, and a client that attaches to the server and then renders that buffer's contents onto the client's own terminal. So in theory one might be able to access the display of GNU screen in a similar manner by making something that pretends to be a client. But how much of this mechanism even operates when GNU screen is in serial terminal mode, I don't know off the top of my head.
The same goes for tmux, of course. And indeed mosh. Although the documentation of the actual protocol was a not-done to-do item, promised in the early publicity for mosh but never delivered, for years. I kept checking back for quite a while to see whether they'd documented it as promised.
There's at least one GUI terminal emulator that stores its scrollback area to file, but only the scrollback area. GUI terminal emulators generally do not expose this sort of thing, though. It's some complex private data structure in the emulator process's memory, usually.
All that said, wscons is a fairly good-looking API. Certainly better than the undocumented mess that is fbio.
I assume NetBSD supports some sort of multiplexing for the local console? In which case it will need to have some sort of text buffer for each virtual terminal to maintain state when it’s off screen, and I guess they’ve decided to expose it to the outside world?
That's what I understood as well. Also, the author mentions:
> The installation succeeded, but the system would panic during boot. *Bhyve is more of a niche thing and not among the hypervisors supported by NetBSD*, [...]
I am guessing what he meant was rather "the support of NetBSD (as a guest OS) by the hypervisor Bhyve", because Bhyve is an hypervisor running on FreeBSD. Given the other posts on the blog, it would not be surprising if the author was daily driving FreeBSD while doing this experiment, and Bhyve is well maintained and probably the best fit in the BSD world for this. I don't even know if OpenBSD's vmm can virtualize something else than OpenBSD.
> Q: What VM operating systems does bhyve support?
> A: bhyve supports any version of FreeBSD i386/amd64. OpenBSD, NetBSD, illumos and GNU/Linux are supported using the UEFI and the sysutils/grub2-bhyve port.
You also can set timeouts and switch between virtual terminals.
PS: I’m love good TUIs. Clean and concise and it is surprising how well user can use them. If - they’re well made. I think the installer of Debian or Linux menuconfig are good examples.
Cheapest HDMI splitters are ~$10 and compressing capture cards are ~$5, it's not hard or expensive anymore to capture display contents at emergency or illustrative use quality if these weren't VM screenshots or taken through OS feature.
For completeness, as I pointed out on the FediVerse: The article has things backwards when it comes to partition table schemes. It's the older firmwares that place the requirement on what partitioning scheme is used; not the newer ones. So the suggested change to one of the forms, as it stands, would be telling users the wrong thing.
And Ed Maste has confirmed that FreeBSD is quite happy to accept non-U.S. keyboard layouts, contrary to the implication that NetBSD accepts them where FreeBSD has not. Even more ones, that is. (-:
A rather fair review and the partitioning step can be confusing to new users. A first time user should read the Guide a few times and maybe refer to it during install. It renders fine on a smartphone.
This is the same question as: Why does changing the number of items to zero in an item line in an order on one's on-line shopping cart delete the entire item line? And the answer lies in the same user expectations from collective experience of this, rightly or no, being the model.
From the perspective of the pure techicalities, disregarding the shared user experience model, a size zero partition will break a lot of stuff, as there's a lot of stuff that assumes that DASD slices have at least one block, a VBR or a superblock of some kind that determines the volume format.
There's probably an enormous amount of code in firmwares, boot loaders, operating systems, and applications programs that does not check that block 0 is legally within the DASD slice limits. Although the ones that look for superblocks in other than block 0 might do such range checks, there's almost always an assumption that of course there is a block 0.
A case in point is the MBR in block 0 of the entire DASD, used by old firmwares to load the VBR of the bootable volume. There's often no check for a non-zero size in such code.
Here's OpenBSD's MBR code, just for starters. It has no range checking for zero size partitions.
With an old-school Unix mindset myself, I’ve always found the CLI installers of OpenBSD and Alpine Linux cleaner, more straightforward and in line with that philosophy. Honestly, I’d rather see sysinst replaced by something along those lines.
We who lived through the classic Unix experience also remember how at the time MS/PC/DR-DOS had things that we 300 BPS terminal users could but dream of, like an Alt key that just worked and highlighted menu option accelerators when one pressed it. And function keys that didn't just cause a mess, or beeps, or surprise commands to happen.
Typical users of the 21st century would be appalled when faced with it. And there's probably no retrocomputing enthusiast that is quite that masochistic. (-:
Much of what sysinst does is just farmed out to tar, pkg_add, ifconfig, and other programs. It even handily prints their command lines at the top of the screen when they are running. So someone who wants a CLI rather than a TUI, and not really the actual "classic Unix experience", could just run those programs. And there's probably room for an installer that does the same thing as sysinst but in the old text-adventure-game style of print-menu-prompt-for-line-with-selection for people with printer terminals. (-:
Like AIX 7's installer:
* https://ibm.com/docs/en/aix/7.3.0?topic=system-using-bos-men...
But don't knock full screen TUI programs like sysinst. There's definitely a place for them, and on the commercial Unices, where the vendors had gone to some effort to make the installation and configuration programs user-friendly, they were the "classic Unix experience". SCO had one, for example. They even managed to have it recognize F1 for help.
* https://sco.com/products/openserver6/reviewers_guide2.html
Function keys. F1 for help. This stuff for contemporary Unix people was like the "Classic MS-DOS experience", but at the time when PC users were using GUI installation programs in DOS+Windows 3. (-:
When I say classic Unix, I really mean "simple software":
- Text-first, scriptable interfaces where tools do one thing well and can be composed
- Human-readable configuration in plain files, no XML or opaque binary blobs
- Predictable, minimal system design where you can understand what’s happening under the hood without chasing abstraction layers
- Manual pages that matter, and a userspace that favors understanding over wizard-driven opacity
- A system that’s BSD-like in spirit: clean, coherent, documented, and built by people who care more about correctness and clarity than flash or trends
This is in contrast to modern Linux distributions where systems are often a tangled mess of systemd units, layers of more or less obscure daemons and processes, unpredictable behaviors, and YAML/JSON/XML-based abstractions that sit between you and the actual system.
So no, I'm not glorifying the past or pretending users in 2025 would enjoy a serial terminal setup from 1984. I’m saying that a clean, simple, consistent, modular Unix, in the traditional sense, is still valuable and NetBSD is one of the few OSes that still embodies that ethos.
Ironic you use that term when a number of systemd units is often the simplest way of cleanly, reliably orchestrating services and daemons, doubly so when theres any level of complexity or limitations you want to confine one too.
Its cute to romanticize a bunch of scripts to run and orchestrate things but its a nightmare I'd not wish upon my enemies. Less moving parts, yet conceptually more complex to properly manage beyond the basics with far more that can and likely will go wrong.
I will save you my further comments which descend into a rant :-)
As an example of how comprehensive beats simple in the real world, consider Microsoft Outlook. Not just email, but calendaring and contact management. Microsoft's engineers discovered that in the business world, these things go together and bundled them into one, well-integrated program. Outlook ate everybody's lunch, including Windows-based mail clients like Eudora. Integration with Exchange let these services be provided together on an organizational level, fully integrated with Active Directory, and Exchange came to dominate email server deployments over Unix-based solutions which were more piecemeal. Easier to administrate as well.
NetBSD is a fantastic tinkerer's operating system, one of the most hackable ones out there. But let's not kid ourselves here. The philosophy it supposedly embodies hasn't really served real needs in a long time, if ever. Customers want solutions, not hacks held together with shell and Perl scripts.
All the customization and service startup is done in plain text and Perl, from what I’ve seen so far.
Yes, do consider it: Outlook is great at ticking checkboxes, resulting in a product that is widely adopted and sucks to use.
emacs
> Human-readable configuration in plain files, no XML or opaque binary blobs
emacs
> Predictable, minimal system design where you can understand what’s happening under the hood without chasing abstraction layers
Maybe emacs
> Manual pages that matter, and a userspace that favors understanding over wizard-driven opacity
Probably emacs. Do I care about man when there is info?
Furthermore, most typical users today are so entrenched in commercial software, and their walled gardens they wouldn't even attempt to use an OS without that software.
People don't own their devices anymore.
If an OS has to be installed by the end user, it is niche.
The perspective of an otherwise knowledgeable user who is new to something is incredibly valuable.
Sorry for hijacking the thread on what is a great post, but is gemini common these days? This is literally the first time I have ever seen it, and it seems fairly interesting, albeit deliberately limited.
Annoyingly the learn more about it link https://gemini.circumlunar.space/ is now dead, as possibly might be protocol.
Because I followed the Wikipedia article to the article on The Register. Whoever wrote Wikipedia summarized El Reg's entire article as how gemini has been critized for excluding people. 1 sentence. But that's only what the headline says, for clickbait. The actual article body paints a very different picture, including the rather subtle (by Register standards) rebuttal of that criticism by pointing out that WWW browsers and the Internet are not in an everything-is-a-nail-and-I-have-this-hammer situation.
So I wonder how true it really is that there's this wave of criticism, and how much that is rather inferred from people reading headlines and nothing else beyond them. Like the Wikipedia author did.
That said, having discovered the existence of Gemini today, I am now wondering how much of a doddle it would be to add a gemini UCSPI-TCP server (which would obviously have to sit behind something like Hoffmann's sslserver) to Bernstein publicfile. The publicfile way would of course have a separate off-line tool to turn index.gopher into index.gemini, once at content generation time instead of over and over at runtime.
Hmmm.
Stop giving me distractions, people! I'm supposed to be getting the next djbwares running on NetBSD. (-:
P.S. I have had the GOPHER server that I added to publicfile running for some time. I use it to publish a not-very-secret list of packages and source archives. It gets some quite odd requests in its logs.
Edit: no it just redirects to https://geminiprotocol.net which seems to be the new official site
Some links:
https://geminiprotocol.net/docs/specification.gmi
https://en.wikipedia.org/wiki/Gemini_(protocol)
There is another. In NetBSD one can, at least according to the manual, open the wsdisplay of the relevant terminal and read out the display contents, with the WSDISPLAYIO_GETWSCHAR I/O control. sysinst is just a full-screen TUI program.
* https://man.netbsd.org/wsdisplay.4
(The manual says that character values are "ASCII", but the data structure uses a 16-bit unsigned integer for them. So I wonder whether this is UCS-2 or NetBSD has been saddled with some 512-entry character set mess from back in the 1990s.)
Presumably there is a third one if the virtual terminal's wsdisplay is in graphics mode and one can access its frame buffer.
There was also a fourth for the serial console screenshots, although they were clearly done the boring way by screenshotting a GUI window, as its scrollbars are visible in the images. Presumably the terminal emulator at the other end of the connection had some sort of direct screen shotting functionality. That was definitely something that serial device DTE emulator programs in the days of yore used to have.
That's an interesting thought, actually. I wonder whether one could do that at all with many Unix/Linux tools, like GNU screen in its serial terminal mode. One could with (some of) the terminal emulators that used to be available for MS/PC/DR-DOS. There would be some "dump screen to file" menu option, or in extremis a TSR program that could do that. (-:
How does one make a "screenshot" of a TUI program? The classic terminal APIs don't have a "framebuffer" (or "textbufffer" I guess) from what I can tell.
I could use such a mechanism to create automated screenshots of a TUI program (using Terminal.GUI in this case) for documentation generation.
* https://man7.org/linux/man-pages/man4/vcsa.4.html
They suffer from being straight copies of CGA, which has historically had a lot of conflation of boldness and brightness, as well as a very limited colour gamut that will make you weep at what your 256-colour TUI programs are reduced to. The NetBSD ioctl supposedly has a bold attribute in a separate field of the structure to a bright colour. Which in the backwards-thinking world of terminals where some people still have the CGA Think that bold=bright, is almost heresy. Still. In 2025. (-:
If you are looking for this sort of thing in a GUI/TUI terminal emulator that is a user application program, rather than the terminal emulators that are built into the NetBSD kernel or into Linux, then that's a different kettle of fish entirely. I know of one that provides a direct vcsa workalike. I wrote it.
* http://jdebp.info./Softwares/nosh/guide/commands/user-vt.xml
GNU screen works by having a server maintaining a buffer, and a client that attaches to the server and then renders that buffer's contents onto the client's own terminal. So in theory one might be able to access the display of GNU screen in a similar manner by making something that pretends to be a client. But how much of this mechanism even operates when GNU screen is in serial terminal mode, I don't know off the top of my head.
The same goes for tmux, of course. And indeed mosh. Although the documentation of the actual protocol was a not-done to-do item, promised in the early publicity for mosh but never delivered, for years. I kept checking back for quite a while to see whether they'd documented it as promised.
There's at least one GUI terminal emulator that stores its scrollback area to file, but only the scrollback area. GUI terminal emulators generally do not expose this sort of thing, though. It's some complex private data structure in the emulator process's memory, usually.
All that said, wscons is a fairly good-looking API. Certainly better than the undocumented mess that is fbio.
Maybe also something like
will work> Both installations will be in VMs just for the sake of convenience.
> The installation succeeded, but the system would panic during boot. *Bhyve is more of a niche thing and not among the hypervisors supported by NetBSD*, [...]
I am guessing what he meant was rather "the support of NetBSD (as a guest OS) by the hypervisor Bhyve", because Bhyve is an hypervisor running on FreeBSD. Given the other posts on the blog, it would not be surprising if the author was daily driving FreeBSD while doing this experiment, and Bhyve is well maintained and probably the best fit in the BSD world for this. I don't even know if OpenBSD's vmm can virtualize something else than OpenBSD.
From https://wiki.freebsd.org/bhyve :
> Q: What VM operating systems does bhyve support?
> A: bhyve supports any version of FreeBSD i386/amd64. OpenBSD, NetBSD, illumos and GNU/Linux are supported using the UEFI and the sysutils/grub2-bhyve port.
https://github.com/GunnarMonell/fbgrab
You also can set timeouts and switch between virtual terminals.
PS: I’m love good TUIs. Clean and concise and it is surprising how well user can use them. If - they’re well made. I think the installer of Debian or Linux menuconfig are good examples.
And Ed Maste has confirmed that FreeBSD is quite happy to accept non-U.S. keyboard layouts, contrary to the implication that NetBSD accepts them where FreeBSD has not. Even more ones, that is. (-:
* https://mastodon.social/@emaste/114625612735189948
https://www.netbsd.org/docs/guide/en/
One thing to note, if you create a separate /usr and/or /var partition, y0u really should (must) add this line or similar line to /etc/rc.conf
critical_filesystems_local="/var /usr"
otherwise you will get odd boot errors/warnings, Dir order does not matter.
Why would the installer discard them if you created them ? Do what i mean, not what i say ?
From the perspective of the pure techicalities, disregarding the shared user experience model, a size zero partition will break a lot of stuff, as there's a lot of stuff that assumes that DASD slices have at least one block, a VBR or a superblock of some kind that determines the volume format.
There's probably an enormous amount of code in firmwares, boot loaders, operating systems, and applications programs that does not check that block 0 is legally within the DASD slice limits. Although the ones that look for superblocks in other than block 0 might do such range checks, there's almost always an assumption that of course there is a block 0.
A case in point is the MBR in block 0 of the entire DASD, used by old firmwares to load the VBR of the bootable volume. There's often no check for a non-zero size in such code.
Here's OpenBSD's MBR code, just for starters. It has no range checking for zero size partitions.
* https://github.com/openbsd/src/blob/9213be19d4b9057bbb074ab1...