Merced - and the ol' Unix story (was Re: OT, but info needed: RAM uprade)

From: Hans Franke <Hans.Franke_at_mch20.sbs.de>
Date: Wed Jan 20 09:29:54 1999

> Don't tell me about fixing the binary -- doing tech support for Tandy
> I did binary patches regularly, there were areas left unused in the
> TRSDOS (_all_ TRSDOSs on _all_ models -- actually also in most
> application binaries as well) so that a patch jumped to the former
> empty space, executed the repaired instructions, jumped back to
> continue past the break. They did that from day one, apparently they
> realized that software can have problems that show up after the product
> ships (and it was expensive to ship everybody a new disk in those days,
> the price of media was high then). Xenix and OS-9 fixes requirered
> recompiles, so patches for those showed up on disk to replace modules
> or programs.

Some OSes have a build in patch support support at different level.
Maybe to run one time patches, that is you start a patch utility,
to install (developer delivered) patches, or other even offer a
patchservice that is startet every time a module, or application
is loaded. this will look in a OS database for fiting patches and
apply them before start the programm.

> RPM has the ability to cover most of the details in the complaint,
> it's a powerful programming system on its own. But with the constant
> and rapid evolution of the various distributions, it's impossible to
> build a package before things move around or switch versions somewhere
> else. If Linux would _hold still for a minute_ RPM would keep up. Of
> course, that's not a problem with a monolithic single-vendor OS like
> Windoze, since MS issues patches during beta test less often than the
> folks in Fort Worth did after everything was stable and shipping.

Thats it. But in a Linux world, distributions, especialy the big
and fat ones (like SuSE) take the role of the OS vendor. But now
in a dezentralized manner rather than beeing the single source.
You will get the full developed easy usage like Windows only within
a distribuition, and toward this distribution orientated packages,
but ionstead of building up a propritary environment (like Windows,
Mac, Be, OS/2, etc.) with only a slow and weak influence, they will
interchange new developments or formats _very_ fast ("breed like
a rabbit"). Just remember how fast RPM has been adopted by other
than Red Hat (after it reached a certain level of usability). Since
the 'fat' distributions offer a gigantic number of already configured
packages (for their environment) and most user applications don't
need changes within system configuration files, from an end users
view the gap to Windows (et al) will close - at least (and now we
are back to my first statement) in the x86 Linux, where you can get
all apps in binary packages - BUT I still doubt that on other
processors (than the x86) this goal will reach - Just take a look
at the RedHat Alpha distribution - althrough simmilar to the x86
version, the amount of offered ready to run packages is smaller.
And after all, this will be simmilar for the Merced.

> (I'd mentioned a while back
> that my Samba server had rebooted four times in three years due to
> power failures, it's now five, we had an outage this past Friday).

Hey, where you are livin ? FIVE times power down in just 3 years ?
Gee - you should shorten the payment - I had one within the last
12 years (My mother had none within this time).

Servus
Hans

--
Ich denke, also bin ich, also gut
HRK
Received on Wed Jan 20 1999 - 09:29:54 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:07 BST