As always, thanks for the feedback. We HAVE put very serious effort
into squeezing the code into 1 MB, and now we're saying that all that
can be done has been done, and this is the last release our efforts
will keep within 1 MB.
Note that if your old PM-2Es don't have 5 BRI boards, that they still
have some 1MB life left in them. It's the combination of both async
ports and ISDN that is now pushing the limits of memory, and the next
release after this one will likely move from the land of "Some
configurations will require more than 1 MB of memory to run" to "Some
cofigurations will fit in less than 1 MB of memory" so we're giving
plenty of advance notice now, so people can plan accordingly.
We do take pains to keep RADIUS backwards compatible so you can run
both old and new systems with the same RADIUS server.
Yes, we could make a smaller ComOS by leaving out new features, but
what's the difference between running that and running an older ComOS
that doesn't have the features? (OK, bugfixes..., but we don't have
many bugs so we don't have many bugfixes.) The problem with doing a
slimmed-down ComOS is deciding what features to leave out? The little
features wouldn't save much memory by leaving them out, the big
features (OSPF, SNMP) are already software configurable to include or
leave out.
Do we stop adding features to the PM-3 because the PM-2 can't deal with
them? I don't think anyone would be happy about that! The first PM-2
shipped in 1993 and four years is a long, long time in the computer and
networking industry. It's pretty amazing that we've gone this long and
still kept everything in 1 MB while our competitors bloated to 16 or
even 32 MB, but the downside to writing tight code is that when the
limit is finally reached, there's no fat for us to go back and cut
out. And we've already done most of what we can to only load the
features from flash into RAM that are needed for a particular hardware
configuration. Now, if you turn off OSPF or IPX or SNMP and reboot,
the memory those features use is reclaimed. We've already been doing
the hard work to keep things in one megabyte, and now we're saying we
can see the limit to that process, that everything is squeezed as tight
as it can be.
We're keenly aware of our installed base; the pain of going back and
installing memory (even $31 of SIMMs) in existing PortMasters is one of
the reasons we've been very careful not to just add any feature anyone
ever asked for; we realize there's a tradeoff of functionality vs.
effective life.
We're providing notice now (instead of waiting until the next release
and then telling people they'll have to upgrade all of a sudden) so
that people who want to upgrade memory have lots of time to plan
how to do it (typically we do two major release a year, so this is
likely about six months notice). When we built the box 4 years ago we
knew this day would come, which is why it uses standard SIMMs in
easy-to-remove slots, to make the upgrade as painless as possible.
(Another poster has already pointed out that you can do this without
uncabling, sparing a LOT of pain.)
Eventually the compressed ComOS image won't fit into 384K of flash
(although that's a ways off yet), and that's not upgradeable, so
someday there will be a final release.
People who don't want to upgrade memory will still be able to run 3.5.1
forever and do everything they can do now, just as we still have people
with PM-11's (which we shipped in 1990) happily running ComOS 2.3 and
2.4 even today, years later. PM-11's still sell on the used market;
how many networking vendors have 7-year old products that are still useful?
Features require software to implement. Software requires memory.
More software requires more memory. We're not immune to that, so the
best we could do was hold it off as long as we could, and make the
SIMMs standard so they'd be as inexpensive and easy to upgrade as they
could be, to cushion the inevitable.
-- Carl Rigney cdr@livingston.com"To sin by silence instead of protest makes cowards out of men." -- Abraham Lincoln