+=============+
                           | MetaDOS 0.1 |
                           |    ERRATA   |
                           +=============+

The main problem (besides lack of developers and zero testers besides
myself) is that I didn't vet every individual source file (thousands!)
or rebuild every binary personally. In case you didn't know,
rebuilding stuff takes a lot of energy and patience. Hey, I like
compiling stuff, but sometimes it's too much of a hassle getting the
proper dependencies or dealing with bugs in the environment or
whatnot.

Hopefully most (if not all) of this will be corrected in later
releases, just by virtue of being more careful. (I've already fixed
most of it for upcoming 0.2.)

  * RTSPKT.COM has no sources

I was mistaken in blindly believing that the public Crynwr .ZIP had
all necessary sources. For whatever reason, RTSPKT sources were not
included nor available. One guy on the mailing list found a newer
version (2006), but even that has no sources. A quick email to two
relevant people didn't produce literally any response, so I have
little hope for fixing that problem.

So, since most of my testing is under VBox or QEMU, I don't need any
packet drivers besides PCNTPK and NE2000, so for future releases, I'm
going to delete all others. Unfortunately, this offloads the
responsibility to the end user, which is horribly inconvenient, but
since there aren't many (or maybe any!), it's less important.

I did actually (minimally) resurrect my old Pentium 4, and it has
Realtek 8139, and it works! I never thought I'd ever test on real
hardware, so that was interesting, but it's not my primary goal. For
now, the main goal is just virtual machines (although any hardware
with bootable medium could similarly work; here I'm using PLoP Boot
Manager and an obviously modified RUFUS-created [FreeDOS] USB jump
drive).

Part of the problem is that the whole idea was that you absolutely
need the network to download the other pieces required. Without
networking, you're again stuck to doing everything manually (or
letting someone else do it for you, which these days isn't much).
While I dislike the idea of constant network updates or "always on"
requirements, it's still better than literally no fixes and no
updates. Honestly, here I was trying to keep things ultra lean and
minimal, if not only just to keep things simple as far as license
compliance! But obviously I didn't check closely enough (ugh), which
just shows how difficult it really is (at least for a solo effort).

  * some source .ZIPs have binaries (and libs), whose sources aren't
    necessarily included

I didn't recompile anything if I didn't have to, so almost all of it
is prebuilt binaries. Which is normally fine, as there isn't a huge
need to rebuild everything from scratch. Most people don't want to do
that, even if they like it, because it's a waste of time. Yet in some
ways it's the only way to prove that things are rebuildable and open
source.

Anyways, the biggest problem here is the FreeCOM shell, aka
COMMAND.COM. (And its dependency, Suppl, which I have no idea how easy
it is to rebuild as it wasn't interesting to me ... hence the
[probably bad] idea of including the binary .LIB verbatim, as well as
sources). For whatever reason, he included some binaries (e.g. DMAKE
[GPL], LIB, XSET) in his source .ZIP. His Dmake port is available
elsewhere on iBiblio, so that's no huge problem overall, but it's
still less than wise to include here without its own sources.

FreeCOM is so huge that it even eclipses the kernel in complexity.
Since .BAT compatibility is important, you need a good shell. I guess
you could use a minimal shell without scripting and just do your
scripting elsewhere, but nobody ever does that. There aren't a lot of
(good) alternatives either, at least none that are free/libre and
easier to build. Heck, FreeCOM even requires TurboC, which isn't even
OSI-approved "open source" (unlike FSF-hated and shunned OpenWatcom).
The OW conversion was never finished nor bugfixed. Too much to do, not
enough volunteers. So no, not even with TC++ did I try to recompile
the shell. Not totally impossible, just too annoying. It'd probably
be easier almost to just heavily improve Centroid's DJGPP-built shell
(a single .c file!), which lacks quite a few features that I'm
depending on here.

I'd rather not quote every single problematic file's name here, but
suffice to say that it's a bad idea to include .COM, .EXE, .SYS, .LIB,
.OBJ, or any similar binary file in a source-only .ZIP. Any required
libs need to be (easily!) rebuildable from scratch, and any
third-party tools needed to rebuild stuff need to be separately
available and ideally not bundled (unless source-only).

Again, it all comes down to everything being rebuildable, not
imaginary problems, but that takes a lot more effort than just getting
something working today. I doubt many people were affected by any of
this (and haven't heard any complaints), but I thought I'd mention
this just to be thorough (since a very small free/libre floppy .img
was the whole point ... it's called FreeDOS for a reason!).

--
rugxulo _AT_ gmail
Monday, April 27, 2015