[deaddodo]

BIOS is deprecated. All of its functionality on new motherboards is basically emulated via the UEFI; and it's certainly not being extended upon.

Deprecated doesn't mean deleted, it just means "no longer updated/developed with a goal towards removal".

[livrem]

This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

[jasaldivara]

> I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

Not sure why would you want a single-process OS on modern hardware, but there are some alternatives that run much less things on the background than regular Linux: Haiku, FreeBSD, NetBSD, OpenBSD, or some lightweight non-glibc, non-systemd Linux-based like Adelie or Alpine.

[nineteen999]

Or, you know, just booting the Linux kernel with init=/bin/sh with /bin/sh being a statically linked binary. You're overthinking things.

[rwmj]

What's the reason why FreeDOS can't use the CSM (the BIOS compatibility mode of UEFI)?

[EvanAnderson]

AFAIK it can. I believe some UEFI implementations don't have CSM.

[p_l]

a Type 3 UEFI implementation has no CSM, Type 2 has CSM available, Type 1 enforces booting into CSM (what many "BIOS"es actually was in later days)

[EvanAnderson]

Thanks for that. That sent me down an enjoyable rabbit hole. I got started with PCs back in the 80s and became fairly familiar with how boot worked back then. UEFI happened while I was paying attention to other things and I've never become as familiar with it as I should be. This was a good excuse to do some reading.

[deaddodo]

Just for clarification's sake, the proper terminology is "UEFI class" not "type".

Otherwise, this is accurate.

[cl91]

> the next-best single-user, single-process, non-bloated OS

is UEFI.

[trueismywork]

Linux in single user mode

[mschuster91]

That's still multi-process though, there's an awful lot of background tasks running in pretty much every non-fossil kernel version, not to mention userspace daemons (udev, dbus, dhcp) without which most normal userspace stuff doesn't even work.

[Brian_K_White]

None of that exists in single user. When you say init=/bin/foo, then that's it, the only process is /bin/foo.

[ryandrake]

/bin/foo is the initial process. It can fork and/or exec other processes, right?

[Brian_K_White]

Sure the facility to fork still exists. So what? Observing that the kernel still provides fork() is like observing that the cpu still provides JMP.

It won't fork random processes you don't explicitly tell it to. I thought it was obvious that if you don't want unsolicited processes, then don't specify /bin/init as /bin/foo. The practical example is /bin/sh, but it could be any other executable.

Up to you to specify a binary that does what you want, and doesn't require a bunch of other processes like gdbus to function itself.

init=/bin/sh is more or less like ms-dos loading command.com

[p_l]

As much as DOS allowed multiple processes, even if only one was executed at the time and there was no multitasking outside of ill-fated MS-DOS 4.0 and various Concurrent DOS products.