Hi all.

I don't think I expected to ended up on this path,
but I didn't really have a path and here I am.

I have a new version of PDOS/386 that ships with
essential Linux ELF executables to provide a toolchain.
Search for "Linux" at http://pdos.org and download
pdosl.zip .

Nothing more than that. You are then in a position to
compile whatever you want so long as it is C90-compliant.
So it is sort of a public domain mini Linux clone - able
to run certain Linux executables (and build infinite more).

As an alternative to running PDOS/386 directly, I would
like to have a very minimal (real) Linux distribution.
ie a disk just containing the kernel and a shell and I
will (at least initially) need some minimal tools like
ls and more - I believe busybox is a one-stop-shop for
that?

So that's like 3 files on the entire disk.

And this would likely be run under Virtualbox, and then
I would have PDOS/386 as a second hard disk under
Virtualbox. And that's where you get the toolchain from.

I'm not actually very familiar with Linux. I have Kylin OS
successfully (to some extent) installed, and I would
basically like to replace it. I tried installing Puppy
Linux before but was not successful. Can't remember why.

I tend to "learn by doing", so I'd like to start by
creating my own distro. Mainly for developers who want
to see if their executables run under Linux. Exactly
what I was trying to do myself in fact.

Note that the toolchain is very simple with everything
being C90-compliant. I spent a lot of effort making
gcc 3.2.3 C90-compliant so that it can be compiled with
basically any C compiler instead of needing a massive
infrastructure. If you would like to see the ELF version
of gcc 3.2.3 built, you can do so under either PDOS/386
or Linux. Here are the instructions for PDOS/386:

cd \devel\pdos\pdpclib
pdmake -f makefile.lnp
pdptest abc def
cd \devel
unzip \misc\custom gcc-sta*
unzip gcc-sta* (fill this in)
del gcc-sta*
cd gcc\gcc
xcopy config\i386\genfiles\*.* /s /e /y
(don't forget that step above)
pdmake -f linuxp.mak

A very simple (if long) set of C files to build.

Instructions for Linux are basically the same except
using Linux syntax (cp instead of xcopy etc) plus a
shortcoming (hopefully resolvable with /proc/pid/environ)
in PDPCLIB means that you can't run just pdmake, you
need to use the "-n" option, like:

pdmake -n -f linuxp.mak >temp.sh
chmod 755 temp.sh
../temp.sh

Annoying (likely one of many annoying things, like
needing aliases or softlinks for the executables to
drop the .exe), but not a show-stopper in any way.

So.

How simple is it to create a minimal Linux distro?
Someone once made a comment that I need to distinguish
between "Linux" (good) and "distros" (all shit). I'm
sure my distro will be considered shit by many too,
but it will at least be minimal.

BTW, the minimal PDOS/386 distro (able to boot and
provide a (small but sufficient depending on needs)
Windows, OS/2 and Linux API, fits on a 360k floppy.

Thanks. Paul.

On 3/18/2024 11:33 PM, Paul Edwards wrote:
> Hi all.
>
> I don't think I expected to ended up on this path,
> but I didn't really have a path and here I am.
>
> I have a new version of PDOS/386 that ships with
> essential Linux ELF executables to provide a toolchain.
> Search for "Linux" at http://pdos.org and download
> pdosl.zip .
>
> Nothing more than that. You are then in a position to
> compile whatever you want so long as it is C90-compliant.
> So it is sort of a public domain mini Linux clone - able
> to run certain Linux executables (and build infinite more).
>
> As an alternative to running PDOS/386 directly, I would
> like to have a very minimal (real) Linux distribution.
> ie a disk just containing the kernel and a shell and I
> will (at least initially) need some minimal tools like
> ls and more - I believe busybox is a one-stop-shop for
> that?
>
> So that's like 3 files on the entire disk.
>
> And this would likely be run under Virtualbox, and then
> I would have PDOS/386 as a second hard disk under
> Virtualbox. And that's where you get the toolchain from.
>
> I'm not actually very familiar with Linux. I have Kylin OS
> successfully (to some extent) installed, and I would
> basically like to replace it. I tried installing Puppy
> Linux before but was not successful. Can't remember why.
>
> I tend to "learn by doing", so I'd like to start by
> creating my own distro. Mainly for developers who want
> to see if their executables run under Linux. Exactly
> what I was trying to do myself in fact.
>
> Note that the toolchain is very simple with everything
> being C90-compliant. I spent a lot of effort making
> gcc 3.2.3 C90-compliant so that it can be compiled with
> basically any C compiler instead of needing a massive
> infrastructure. If you would like to see the ELF version
> of gcc 3.2.3 built, you can do so under either PDOS/386
> or Linux. Here are the instructions for PDOS/386:
>
> cd \devel\pdos\pdpclib
> pdmake -f makefile.lnp
> pdptest abc def
> cd \devel
> unzip \misc\custom gcc-sta*
> unzip gcc-sta* (fill this in)
> del gcc-sta*
> cd gcc\gcc
> xcopy config\i386\genfiles\*.* /s /e /y
> (don't forget that step above)
> pdmake -f linuxp.mak
>
> A very simple (if long) set of C files to build.
>
> Instructions for Linux are basically the same except
> using Linux syntax (cp instead of xcopy etc) plus a
> shortcoming (hopefully resolvable with /proc/pid/environ)
> in PDPCLIB means that you can't run just pdmake, you
> need to use the "-n" option, like:
>
> pdmake -n -f linuxp.mak >temp.sh
> chmod 755 temp.sh
> ./temp.sh
>
> Annoying (likely one of many annoying things, like
> needing aliases or softlinks for the executables to
> drop the .exe), but not a show-stopper in any way.
>
> So.
>
> How simple is it to create a minimal Linux distro?
> Someone once made a comment that I need to distinguish
> between "Linux" (good) and "distros" (all shit). I'm
> sure my distro will be considered shit by many too,
> but it will at least be minimal.
>
> BTW, the minimal PDOS/386 distro (able to boot and
> provide a (small but sufficient depending on needs)
> Windows, OS/2 and Linux API, fits on a 360k floppy.
>
> Thanks. Paul.

If you can't get Puppy to work, there are other 32-bit ones.

https://itsfoss.com/32-bit-linux-distributions/

But one of the messages someone should pass along to you,
is the need to upgrade your hardware. (The 32-bit distros
might be looking for i686 rather than i386, some of
the applications want SSE2 or SSE4 support.)

You don't really want to be using Puppy any more. It's
getting too hard to do non-mainstream stuff. There are
500 distros, plenty of stuff to sample and evaluate.

If you look at the refurb market, there are machines
with quad cores for sale now. To give you some idea
what "recycled" hardware looks like. They're really
recycling quite capable machines. Refurb machines are
off-lease, and have come from large enterprise organizations
(like GM). Grade-A ones, should lack scratches and dents
and they're supposed to be in good cosmetic condition.

Mine came with 8GB of RAM in it.

The refurb I got (for $200), had only a 2 core E7500 processor,
and integrated graphics (in the chipset, Q45). The price
of these items, varies with time, and if you watch the
price numbers, you may be able to catch an item when
it is at a slightly lower price. This time of year is
a reasonably good time to be looking for a refurb.
(The price could be higher in August.)

As for the memory they use, DDR3 went out of production
one year ago, and stock of new DDR3 modules will be
into the less-desirable brands by now. I wanted to
upgrade my laptop, but there were no good modules left
for it.

While there may be a few DDR4 refurb machines, a lot of
them might still be DDR3. A DDR4 machine, you can still
find RAM modules for one of those. The machine I'm typing
on uses DDR4.

A refurb machine can be cheaper than building a machine
from parts. Going from parts, might cost you $500 to upgrade,
while best-case, a refurb could be $200.

Paul

On 19/03/24 22:32, Paul wrote:

> But one of the messages someone should pass along to you,
> is the need to upgrade your hardware. (The 32-bit distros
> might be looking for i686 rather than i386, some of
> the applications want SSE2 or SSE4 support.)

Sorry for not specifying clearly enough.

This is not a hardware question.

I'm looking for an x64 version of Linux, but I'm
initially only going to run the 32-bit software
on it (that will indeed run on an 80386 also - but
that's somewhat irrelevant).

The 32-bit software is already capable of producing
64-bit Win64 executables, but 64-bit ELF is still
pending. And that's actually one of the purposes -
to test changes to pdld to support 64-bit ELF, not
just 32-bit.

As to "some of the applications needing SSE2/4" -
I do not have a requirement to run any applications
other than those produced by the provided toolchain,
or a new toolchain that was built with the provided
toolchain (or some descendant like that).

Basically - "here's a valid Linux, here's a C90
compiler - you're on your own from here".

It's not meant to be for normal end users, it's
meant to fill a development niche (or a university
challenge niche - something along those lines).
Possibly some integrity chain - a lineage of how
to build Linux starting from "Sector C". With gaps
to be filled in.

BFN. Paul.

On 3/19/2024 11:05 AM, Paul Edwards wrote:
> On 19/03/24 22:32, Paul wrote:
>
>> But one of the messages someone should pass along to you,
>> is the need to upgrade your hardware. (The 32-bit distros
>> might be looking for i686 rather than i386, some of
>> the applications want SSE2 or SSE4 support.)
>
> Sorry for not specifying clearly enough.
>
> This is not a hardware question.
>
> I'm looking for an x64 version of Linux, but I'm
> initially only going to run the 32-bit software
> on it (that will indeed run on an 80386 also - but
> that's somewhat irrelevant).
>
> The 32-bit software is already capable of producing
> 64-bit Win64 executables, but 64-bit ELF is still
> pending. And that's actually one of the purposes -
> to test changes to pdld to support 64-bit ELF, not
> just 32-bit.
>
> As to "some of the applications needing SSE2/4" -
> I do not have a requirement to run any applications
> other than those produced by the provided toolchain,
> or a new toolchain that was built with the provided
> toolchain (or some descendant like that).
>
> Basically - "here's a valid Linux, here's a C90
> compiler - you're on your own from here".
>
> It's not meant to be for normal end users, it's
> meant to fill a development niche (or a university
> challenge niche - something along those lines).
> Possibly some integrity chain - a lineage of how
> to build Linux starting from "Sector C". With gaps
> to be filled in.
>
> BFN. Paul.
>

Is your hardware 64-bit capable ?

You seem to emit a lot of older breadcrumbs in text, implying
older equipment and environment.

I would have gladly selected a 64-bit OS for you,
if there was a sign you could actually use it. There's
no point wasting a posters time with an ISO that
won't boot. The ISO will generally tell you right away,
that the hardware is a problem.

A 64-bit ISO will not boot on a 32-bit computer.
For example, a Pentium 3 is a solidly 32-bit CPU, and
it won't boot a 64-bit ISO. Whereas a Core2Duo E8400
can boot either a 32-bit disc or a 64-bit disc. Since
the Linux discs are hybrid and have both UEFI and Legacy
boot support, they will work on either kind of setup.

https://distrowatch.com/

You were, after all, screwing with Puppy, and that's a sign
a person has older equipment. Nobody selects Puppy for
its smooth mainstream operation. (You would use FatDog64
if sampling the Puppy ecosystem, with a capable 64-bit computer.)

Puppy is what you use when you have older computers (like
the ones I have in this room, in my collection). Puppy uses
XVesa as an X11 driver, taking video cards of unknown qualities
and running the card as a frame buffer (no OpenGL or the like).
Puppy also uses a 2.x kernel. It has drivers that match older
machines well. If you run Puppy on a modern machine, almost
no drivers at all load when it comes up. It's not actually
a good match for new kit.

To get a relatively old Knoppix DVD to boot on a modern
machine, you enter "noacpi" as a boot line parameter and
then it will come up. I discovered that by accident one
day, having given up on ever seeing it boot on the newer
machines.

Paul

On 20/03/24 01:07, Paul wrote:

> Is your hardware 64-bit capable ?

I am running Windows 10 on an x64.

Then I run Virtualbox.

I normally do development on Windows 2000, running
under Virtualbox. Always running 32-bit tools.
But sometimes producing a 64-bit executable, which
is then transferred to the Windows 10 host to briefly test.

Another thing I run under Virtualbox is Kylin OS.

I went with this because I bought a computer with
a Zhaoxin x64 processor and it came with Kylin
installed. I did this because I wanted to test
PDOS/386.

I also wanted to test Windows 10 64-bit.

This was a bit of a struggle, but ended up working
sufficiently well.

> You seem to emit a lot of older breadcrumbs in text, implying
> older equipment and environment.

My software all targets the older equipment,
while also running on modern equipment.

That's what I expect from my software. ie for
it to be upwardly compatible.

> I would have gladly selected a 64-bit OS for you,
> if there was a sign you could actually use it. There's

I already have one - Kylin OS.

But I wish to replace it (with a massive downgrade -
but still x64).

> You were, after all, screwing with Puppy, and that's a sign
> a person has older equipment. Nobody selects Puppy for
> its smooth mainstream operation. (You would use FatDog64
> if sampling the Puppy ecosystem, with a capable 64-bit computer.)

I was selecting Puppy (before) because I was after a
minimal Linux.

I can't remember if I was looking for 386-only, as my
software to test is mostly 386.

But I do actually have the capability to produce 64-bit
Linux executables on my PDOS/386 ecosystem. But they are in
COFF format, so require an objcopy step when arriving on
the x64 Linux.

I am expecting to be able to generate 64-bit ELF directly
in due course, and the person (author of pdld) who does
that work will need to be able to test it. He asked me
how to test his ELF executables, and I wanted to give him
the simplest possible answer. ie a very simple system
designed for developers to test. Not end users to use.

(Although at the same time I like the thought of - "hey,
what can we do with this C90 compiler?")

I'm not expecting an existing distribution to do what
I want, as I have a narrow target audience.

Anyway, I have made some progress. I am selecting Linux 6.6
since it is advertised as having long-term support.

On my Kylin system I have produced a bzImage with this config:

CC arch/x86/boot/video-bios.o
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
OBJCOPY arch/x86/boot/vmlinux.bin
HOSTCC arch/x86/boot/tools/build
BUILD arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready (#1)
kerravon@kerravon2-pc:~/scratch/linux-6.6.22$ make allnoconfig

-rwxrwxr-x 1 kerravon kerravon 3837012 Mar 20 14:23 vmlinux

kerravon@kerravon2-pc:~/scratch/linux-6.6.22$ ls -l arch/x86/boot/bzImage
-rw-rw-r-- 1 kerravon kerravon 1503744 Mar 20 14:24 arch/x86/boot/bzImage

But I'm not sure what this (bzImage) is.

I can tell from looking at it that it has a 55AA disk
signature, but as far as I can tell this is not a FAT32
image with a bootx64.efi, nor is it an MBR with 8086
code, and nor is it an ISO CD.

It could be GPT (which I'm not familiar with), but I
don't think so.

Regardless, I don't want to use Grub, so I am expecting
a bootx64.efi (PE format executable) to load this bzImage
into memory.

I am hoping to only have FAT32 physical disks. If an
ext4 or whatever is required it can be done as a ramdisk.
If Linux needs a plethora of files to operate it can
create them in its own ramdisk (which this bzImage may be
designed to do already).

But the Linux build process hasn't produced a bootx64.efi.

So what's the official source of one of those?

I can potentially provide my own - I do that in my UCX64
distribution. So the infrastructure exists. I could read
this bzImage file into memory, and then ... what?

Thanks. Paul.

On 20/03/24 14:44, Paul Edwards wrote:

> I am hoping to only have FAT32 physical disks. If an
> ext4 or whatever is required it can be done as a ramdisk.
> If Linux needs a plethora of files to operate it can
> create them in its own ramdisk (which this bzImage may be
> designed to do already).

I followed a video tutorial, and although it
didn't work for me, I managed to cobble together
an initial attempt at a Linux distro.

I'm waiting for feedback from the pdld author to
see if it is good enough for him to proceed with
64-bit ELF support.

Search for the last occurrence of "Linux" at http://pdos.org

One good thing is it can only go up from here ...

BFN. Paul.