Here's my unasked for two cents worth on possible future directions for
GB operating media:
How about a "simple" form of media independance? Here is how I envision
it:
GB would reside as a single file on a DOS (MS-DOS, Caldaera OpenDOS,
FreeDOS, whatever) file system (use your favorite!). The machine would
boot up DOS, and an executable program would be run which would load the
GB file into the top of the system RAM. Once loaded, the GB boot
process would be started from this location in the system RAM,
obliterating DOS. Once GB is booted, the RAM used by the GB file image
is now available for use by the state tables, NAT tables, whatever.
On the simple version of this system, configuration information could be
stored on a floppy disk.
There is lots of president for this type of boot -- some network boot
ROMs do something similar, and my first exposure to this was a technique
of booting a home-brew (or home-ported) OS on a S-100 Compupro 8086
system back in the very early 1980s -- boot the OS you have, use it to
boot the "new" OS. Here, DOS is used basicly as a boot loader, a task
it is pretty well suited for. 8-)
This has the advantage of allowing substantually larger boot "disks",
and also allows virtually ANY storage medium, with NO change in
programming with new medium. Got an itch to use LS120? Zip? CD-ROM?
Hard disk? Potentially, the loader program could load pieces at a time,
so you could even use multiple floppies ("Insert disk 2 of 5 now,
please"). The memory overhead would be virtually zero.
I have a more "deluxe" version of this system. 8-)
This starts with the above boot sequence, but rather than overwriting
DOS, DOS is just "disabled" -- disconnected from all the system
interrupts and sits there dormant. Why? Well, so that configuration
changes could be written back out to a selected media. When a write or
read is required, DOS would be "re-enabled" and used to write (or read)
the configuration files, then disabled again. GB would have a command
line option or a config file in the same directory as the "boot image"
file which would tell it where to retrieve and store configuration
files, this way the boot image could be on a CD-R, but the configuration
could be on a floppy -- a DOS floppy, improving ease of maintenance. Or
it could be on ANY other DOS accessable writable media! GB doesn't have
to understand the media, it just knows it was told to use a config file
on drive J:, so it requests DOS to read and write it to there. It could
also be set up so that there were two configuration files -- a "default"
configuration in the same directory as the boot image file, another file
containing only changes to the default at a RW location. In this way,
the system could be set up on a bootable CDR, with the "standard"
configuration. If "emergency" updates need to be done, they are made to
(say) a floppy. The system reboots off the CDR and reads its config off
the CDR, but checks for any changes on the floppy. This way, should the
floppy fail, you still have the earlier configuration information
available. This system does have a penalty of keeping most of DOS in
memory, but this is probably under 300k of RAM, and if older versions of
DOS were used, way less than that.
This model, I get from Novell Netware 3 and up. Netware used to be a
free-booting OS (v2.2 and before) but re-configuration issues created
all kinds of troubles (nightmares) and delays in repair. Using DOS as a
bootloader and keeping it around to load new drivers has made Netware
one of the most rapidly "repairable" network OSs around.
Both these methods permit almost unlimited growth (this is _not_ a
recomendation!) of the GNATbox program without predefining any
particular storage medium. Floppies are nice and standard, but their
size is very limiting. Nothing else is really completely standard.
This solution frees GTA from worrying about that -- the storage medium
must be DOS accessable, but that is someone else's problem.
The one complaint I have with GNATbox is the boot floppy (well, that and
the 3c509 support 8-). I think it is marvelous how much functionality
has been crammed into one 1.4M floppy disk. Impressive is the only word
for it. However, I don't like relying on floppy disks. They fail too
often, and there are too many interchange problems between machines.
Unfortunately, I'm not convinced any other currently available removable
media is any better, and NONE of it is resembling standard, which would
really make the programmer's job a nightmare (unless one thinks about
leaving that task to others).
I'll admit the biggest gripe I have about going to any other medium is
it hides the efficiency of the GB programming!
Other ideas:
1.7M format (that @#$ format MS used on some of their floppy based
programs). You can get more than 1.44M on a 3.5" floppy. There are
probably boot problems -- they got around this on 8" floppies by
formatting the first track at one density and formatting the rest at the
higher density.
Restrict the network drivers. GB supports a LOT of different NICs. Is
this *really* necessisary? My thought is rather than supporting all
kinds of different NICs, I would find it quite acceptable if the
documentation said "GNATbox supports NE2000 and 3c509 ISA cards, RealTek
8139 and 3c905 PCI cards, and whatever Gigabit Ethernet cards. No, it
doesn't support anything else". If the information is presented up
front, I don't know that people would have grounds to complain. We
already know that to use GNATbox, you must have certain other
requirements met (i.e., 5 or fewer users for GB Lite, $xxx for the full
version, 16+M RAM, and NE2000 users have to have the cards set at
predefined locations). NE2000 and RealTek cards are available for less
than $15 new for tightwads, and good network cards are also supported
for better performance (and they aren't that expensive, anyway). It
would also decrease GTA's debugging and testing cycle. Yeah, it is cool
to be able to build a fantastic firewall out of a junk pile, but I don't
think it is unreasonable to require the use of particular NICs. GB is
not a full-featured OS, I don't think it has to support every NIC under
the sun. The competition often requires the purchase of a particular
machine, I don't think restricting the choice of NICs would hurt
anyone. Others may disagree, however. I'm a little concerned when I
saw the Token Ring support dropped due to lack of space... I don't know
anyone using token ring, nor do I wish to, but I got to believe it is
still out there.
Drop PCMCIA support. I'm really having trouble coming up with a reason
for a Laptop to be a firewall, and yes, it might be cool to have a
network appliance with PCMCIA cards, but I don't think PCMCIA devices
offer good performance and cost. Again, others may have strong
disagreements on this and I might be missing something, but it might be
worth considering.
Nick.
