From Newsgroup: comp.misc

Bedrock Platform
================

A bedrock platform is a hardware platform or a universal
virtual machine that can be expected to remain compatible with any
software that has ever been written for it. Bedrock platforms can
be used to prevent software rot.

Note that this is not a "shopping list" or a list of "allowed"
hardware. Bedrock platform support is simply a way of maximizing the probability that a program can be run in an indefinite future and a
way to keep its dependencies reliable. The concept of bedrock
platform is not relevant to e.g. embedded-system-type projects that
are designed for a very specific hardware, or the kind of software
that is known to have a short lifespan.

A simple bedrock platform guide based on the IBM PC line:

* Can you compile and run the program in FreeDOS?

If yes, you have the bedrock support (just make sure that the
compiler and other needed tools are archived somewhere).

If not, can you create an x86 operating system image that compiles
and runs the program without accessing any external resources?

If yes, you have the bedrock support (just archive the image and/or
everything you've put in it).

If you can only run it in these environments but not compile it, it
is still far better than nothing.

Some possible criteria for bedrock hardware:

* The hardware has been popular and commonly available at some point
of history (and preferably remains that way).

* Every detail of the hardware is well-known and fully documented.
(Having a 100% compatible open-source emulator can be considered
full documentation.) [There's a sucker born every minute.]

* There have been several independent manufacturers for each
component.

* Multiple emulators for the platform are commonly available for many
different environments.

* There are no copyright issues in regards to the hardware design,
firmware IP, etc.

* It is possible to pinpoint a "standard configuration" that is
supposed to run all the programs and can be used for testing
software compatibility (usually this means the original version of
the hardware or the de-facto most popular variant).

Candidates for bedrock hardware
===============================

IBM PC
------

Widely cloned, remains ubiquitous, every type of common component has
had multiple manufacturers in different parts of the world (with the
exception of OPL2/OPL3 common in classical soundcards). Can be
emulated by open-source software such as QEMU, Dosbox, or Bochs.
There are also several different DOS-compatible operating systems,
including FreeDOS. Standard configurations may be difficult to
pinpoint.

NES/Famicom
-----------

Widely cloned especially in China/Taiwan without any of the original
Japanese components. Huge amount of available emulators, and running
a ROM file with one is very straightforward. No software dependencies
(as there's no internal firmware ROM).

ZX Spectrum
-----------

Simple design that was easy enough to duplicate in Eastern-block
countries even with 100% non-Western components. Clones are still
manufactured, emulators are widely available.

MSX
---

Standardized platform, every chip used in MSX-1 computers has had
both U.S.American and Japanese manufacturers. (MSX-2 on the other
hand depends on specific Yamaha chips). Emulators widely available.
The firmware ROMs may pose issues as long as Microsoft exists. Also,
there's no obvious standard configuration.

* * *

Raspberry Pi is an example of a platform that fails the criteria. It
depends on a single-manufacturer SoC chip (Broadcom BCM2835) that
doesn't have full documentation available. QEMU emulates some versions
of the platform to some extent but this emulation does not cover the undocumented parts of the chip (e.g. running the GPU firmware code).

For virtual bedrock hardware, the main criterion is that the
specification is simple enough that it can be implemented in a small
effort for commonly available computers, and that the specification
is unambiguous and frozen.

Even though optimal resource use is not a major point in bedrock
platforms, having that as well would be ideal. Not only should it be
possible to make minimal-overhead emulators, but to read,
[15]?analyze, [16]?decompile and recompile the code in order to use
it on arbitrary future computers. Writers of bedrock-platform
software may want to make sure that it will be easy enough to e.g.
separate code from data even when analyzing binaries.

The Maxwell's Equations of Software
===================================

Alan Kay has famously described Lisp as the
"Maxwell's equations of software". He describes the revelation he
experienced when, as a graduate student, he was studying the
LISP 1.5 Programmer's Manual and realized that the half page of code
on the bottom of page 13 was Lisp in itself.

Yes, that was the big revelation to me when I was in graduate
school--when I finally understood that the half page of code on the
bottom of page 13 of the Lisp 1.5 manual was Lisp in itself. These
were "Maxwell's Equations of Software!" This is the whole world of
programming in a few lines that I can put my hand over.

I realized that anytime I want to know what I'm doing, I can just
write down the kernel of this thing in a half page and it's not going
to lose any power. In fact, it's going to gain power by being able to
reenter itself much more readily than most systems done the other way
can possibly do.

See also:

You have made your bedrock, now lie in it.
<http://www.loper-os.org/?p=55>

From: <https://permacomputing.net/bedrock_platform/>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 8 May 2026 13:38:59 -0000 (UTC), Ben Collver wrote:

Alan Kay has famously described Lisp as the "Maxwell's equations of software". He describes the revelation he experienced when, as a
graduate student, he was studying the LISP 1.5 Programmer's Manual
and realized that the half page of code on the bottom of page 13 was
Lisp in itself.

I wonder where he thought the lexical analyzer was ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver <bencollver@tilde.pink> quoted someone who wrote:

Bedrock Platform
================

A bedrock platform is a hardware platform or a universal
virtual machine that can be expected to remain compatible with any
software that has ever been written for it. Bedrock platforms can
be used to prevent software rot.

[snip]

A simple bedrock platform guide based on the IBM PC line:

* Can you compile and run the program in FreeDOS?

If yes, you have the bedrock support (just make sure that the
compiler and other needed tools are archived somewhere).

If not, can you create an x86 operating system image that compiles
and runs the program without accessing any external resources?

[snip]

* There are no copyright issues in regards to the hardware design,
firmware IP, etc.

[snip]

Candidates for bedrock hardware
===============================

IBM PC
------

Widely cloned, remains ubiquitous, every type of common component has
had multiple manufacturers in different parts of the world (with the exception of OPL2/OPL3 common in classical soundcards). Can be
emulated by open-source software such as QEMU, Dosbox, or Bochs.
There are also several different DOS-compatible operating systems,
including FreeDOS. Standard configurations may be difficult to
pinpoint.

FreeDOS itself relies on the PC BIOS for hardware interactions,
instead of having its own chipset-specific drivers. Even if DOS is
running in an emulator on top of an OS such as Linux which can use
its own specific hardware drivers (if those exist for the specific
chipset used, which often requires that the chip manufacturer wrote
the Linux driver themselves), you still need the BIOS to initialise
the hardware first and boot that OS. The BIOS is therefore an
"external resource" required by FreeDOS, and unless an open-source
replacement such as Coreboot has been installed, it's got the same
"copyright issues" the author is proposing to avoid.

If you do limit this to PCs supported by Coreboot, the platform
becomes far less ubiquitous, since it's a tiny minority of all the
PC hardware that's been made. They're possibly still more
ubiquitous than any general-purpose computer hardware that is
completely open-source and without any "copyright issues" though,
since the latter hardly exists at all.

[snip]

* * *

Raspberry Pi is an example of a platform that fails the criteria. It
depends on a single-manufacturer SoC chip (Broadcom BCM2835) that
doesn't have full documentation available. QEMU emulates some versions
of the platform to some extent but this emulation does not cover the undocumented parts of the chip (e.g. running the GPU firmware code).

Those issues are correct, but they also apply to most PC hardware.
There is an open firmware project for the Raspberry Pi, like
Coreboot for PC, but it's unable to initialise most of the hardware
devices like USB and Ethernet, so not really practical to use (and
not really advancing much towards that goal anymore):

https://github.com/christinaa/rpi-open-firmware/

PCs running Coreboot will still need separate proprietary firmware
for using peripherals like WiFi and graphics, so maybe old model
RPis supported by the open firmware are not much different even to
that sub-set of PC hardware, especially running DOS. The main issue
is you need to access it via serial terminal, since unlike PC BIOS
the RPi firmware doesn't provide a software interface text-mode
display or keyboard inputs to the OS.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-05-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

Ben Collver <bencollver@tilde.pink> quoted someone who wrote:

Bedrock Platform
================

FreeDOS itself relies on the PC BIOS for hardware interactions,
instead of having its own chipset-specific drivers. Even if DOS is
running in an emulator on top of an OS such as Linux which can use
its own specific hardware drivers (if those exist for the specific
chipset used, which often requires that the chip manufacturer wrote
the Linux driver themselves), you still need the BIOS to initialise
the hardware first and boot that OS. The BIOS is therefore an
"external resource" required by FreeDOS, and unless an open-source replacement such as Coreboot has been installed, it's got the same
"copyright issues" the author is proposing to avoid.

You can install FreeDOS in DOSBox or qemu, which both provide BIOS.
That's how HP ships FreeDOS on UEFI-only laptops.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

On Fri, 8 May 2026 13:38:59 -0000 (UTC), Ben Collver wrote:

Alan Kay has famously described Lisp as the "Maxwell's equations of
software". He describes the revelation he experienced when, as a
graduate student, he was studying the LISP 1.5 Programmer's Manual
and realized that the half page of code on the bottom of page 13 was
Lisp in itself.

I wonder where he thought the lexical analyzer was ...

It could be in hardware. That's part of the beauty of the language.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver <bencollver@tilde.pink> wrote:

On 2026-05-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

FreeDOS itself relies on the PC BIOS for hardware interactions,
instead of having its own chipset-specific drivers. Even if DOS is
running in an emulator on top of an OS such as Linux which can use
its own specific hardware drivers (if those exist for the specific
chipset used, which often requires that the chip manufacturer wrote
the Linux driver themselves), you still need the BIOS to initialise
the hardware first and boot that OS. The BIOS is therefore an
"external resource" required by FreeDOS, and unless an open-source
replacement such as Coreboot has been installed, it's got the same
"copyright issues" the author is proposing to avoid.

You can install FreeDOS in DOSBox or qemu, which both provide BIOS.
That's how HP ships FreeDOS on UEFI-only laptops.

And you could run an emulator for a Raspberry Pi just the same, yet
the author rules that platform out.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 9 May 2026 09:36:04 -0400 (EDT), Scott Dorsey wrote:

On Fri, 8 May 2026 21:03:59 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Fri, 8 May 2026 13:38:59 -0000 (UTC), Ben Collver wrote:

Alan Kay has famously described Lisp as the "Maxwell's equations
of software". He describes the revelation he experienced when, as
a graduate student, he was studying the LISP 1.5 Programmer's
Manual and realized that the half page of code on the bottom of
page 13 was Lisp in itself.

I wonder where he thought the lexical analyzer was ...

It could be in hardware. That's part of the beauty of the language.

The fact that there is no fundamental distinction between rCLhardwarerCY
and rCLsoftwarerCY is not something peculiar to Lisp: itrCOs a basic fact of Computer Science.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Computer Nerd Kev <not@telling.you.invalid> wrote:

Ben Collver <bencollver@tilde.pink> wrote:

On 2026-05-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

FreeDOS itself relies on the PC BIOS for hardware interactions,
instead of having its own chipset-specific drivers. Even if DOS is
running in an emulator on top of an OS such as Linux which can use
its own specific hardware drivers (if those exist for the specific
chipset used, which often requires that the chip manufacturer wrote
the Linux driver themselves), you still need the BIOS to initialise
the hardware first and boot that OS. The BIOS is therefore an
"external resource" required by FreeDOS, and unless an open-source
replacement such as Coreboot has been installed, it's got the same
"copyright issues" the author is proposing to avoid.

You can install FreeDOS in DOSBox or qemu, which both provide BIOS.
That's how HP ships FreeDOS on UEFI-only laptops.

And you could run an emulator for a Raspberry Pi just the same, yet
the author rules that platform out.

The problem is that such an emulator doesn't exist.

Many RPi 'emulators' are just emulating a generic Arm target that runs RPi userland, without running the RPi-specific kernel. QEMU does have some RPi targets, on which you can run the correct kernel, but they just implement
a few of the API calls made to the Pi's GPU firmware, only the few that are needed to boot Linux.

None emulate the GPU itself, which means that software that tries to talk to the GPU hardware won't work. Perhaps that isn't such a problem, if you have part of your driver stack able to run GPU ops on the CPU instead.

But that is not the point of a 'bedrock platform' - it's fully hardware emulated so that software can run identically, it doesn't depend on
switching bits of your software stack for others.

The latter only works if you are running an OS that is sufficiently flexible
to do that - this is often possible if you are prepared to compile special kernels or userlands. But it can't necessarily run identical distribution media from real hardware, especially if the OS in question is not Linux.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Theo <theom+news@chiark.greenend.org.uk> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Ben Collver <bencollver@tilde.pink> wrote:

On 2026-05-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

FreeDOS itself relies on the PC BIOS for hardware interactions,
instead of having its own chipset-specific drivers. Even if DOS is
running in an emulator on top of an OS such as Linux which can use
its own specific hardware drivers (if those exist for the specific
chipset used, which often requires that the chip manufacturer wrote
the Linux driver themselves), you still need the BIOS to initialise
the hardware first and boot that OS. The BIOS is therefore an
"external resource" required by FreeDOS, and unless an open-source
replacement such as Coreboot has been installed, it's got the same
"copyright issues" the author is proposing to avoid.

You can install FreeDOS in DOSBox or qemu, which both provide BIOS.
That's how HP ships FreeDOS on UEFI-only laptops.

And you could run an emulator for a Raspberry Pi just the same, yet
the author rules that platform out.

The problem is that such an emulator doesn't exist.

Many RPi 'emulators' are just emulating a generic Arm target that runs RPi userland, without running the RPi-specific kernel. QEMU does have some RPi targets, on which you can run the correct kernel, but they just implement
a few of the API calls made to the Pi's GPU firmware, only the few that are needed to boot Linux.

None emulate the GPU itself, which means that software that tries to talk to the GPU hardware won't work.

I don't know why. The QEMU website says the RPi framebuffer is
supported, and the operation of writing to it is in the "mailbox"
documentation that's been released for the Videocore IV RPis, so
one shouldn't need to reverse-engineer the GPU hardware/firmware
for that any more than for emulating DOS software running on a PC
with a proprietary graphics card.

A quick search found this bare-metal Raspberry Pi 3 framebuffer
animation which claims to work in QEMU as well as on real hardware:

https://github.com/Naevier/VideoCore-FrameBuffer

Perhaps that isn't such a problem, if you have
part of your driver stack able to run GPU ops on the CPU instead.

Like with the PC, the "GPU ops" only get complicated if the
software uses the acceleration features of the GPU. I guess DOSbox
is probably more capable than RPi emulators there, but since you
can choose to write software that just uses the unaccelerated
framebuffer on the RPi, I still don't see why the platform gets
ruled entirely out while PCs are considered valid options.

But that is not the point of a 'bedrock platform' - it's fully hardware emulated so that software can run identically, it doesn't depend on
switching bits of your software stack for others.

You're not likely to _fully_ emulate all the hardware on common PCs
either, but you can emulate enough of either PC or RPi to allow
writing software that will work in all real or emulated
environments.

I'm not sure if either hardware platform avoids the author's issue
with proprietary firmware when using real hardware though. Both
seem the same to me in that regard.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 10 May 2026 12:58:48 +0100 (BST), Theo wrote:

Many RPi 'emulators' are just emulating a generic Arm target that
runs RPi userland, without running the RPi-specific kernel. QEMU
does have some RPi targets, on which you can run the correct kernel,
but they just implement a few of the API calls made to the Pi's GPU
firmware, only the few that are needed to boot Linux.

None emulate the GPU itself, which means that software that tries to
talk to the GPU hardware won't work.

But surely if itrCOs open-source software, using documented interfaces,
those can be correctly implemented in the emulator.

If yourCOre trying to implement a sufficiently faithful virtual GPU that
can load the original proprietary firmware, I would say that is 1)
pointless and unnecessary, and 2) fraught with potential
rCLIP-infringementrCY legal difficulties anyway, so best avoided.
--- Synchronet 3.22a-Linux NewsLink 1.2