Tony Duell wrote:
>
> > > How would an enduser tell the difference between a Windows installation
> > > program that copies files to the right places and modifies some
> > > configuration files, and a linux one that copies some files to the right
> > > places, modifies some configuration files and runs make to build the
> > > binaries from the C source. It doesn't require _any_ more knowledge.
> >
> > If the installation does this all for me, without any problems
> > (like different header files, unimportent, but ill behavied defines
> > or a different compiler version - not to mention different libc's)
>
> So what you're really complaining about is poorly done source kits. OK, I
> can agree there. But perhaps I've been lucky as a lot of things just
> build with no problems...
>
> > _and_ without any unnecersary interacion (like start the package manager,
> > change directory, change environment settings, change script files,
> > start 3 make runs, change /stc/* setings, etc.), I'm completly fine
> > with that, but in fact, I never had the luck - I _can't_ remember
> > any situation where I installed a source level package in an unix
>
> Point is, if the source is that badly behaved, then the binary probably
> is as well (depends on a particular version of libc, requires
> files in specific places, etc). And more people can fix the source than
> fix the binary.
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.
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.
(Me? I look at the RPM and edit it as needed for my machine(s). I
don't try to get anything universal, since on a couple of my boxes I
play with the development kernels, this one I keep at the level of the
latest Caldera CD, and my Samba server hasn't been updated in three
years, since once I got Samba working I don't want to risk screwing it
up, though when La Esposa decides to upgrade I'll _have_ to because of
the change in treatment of passwords -- and when I have to upgrade
Samba I'll probably update the OS and likely some hardware, since it's
a 386/25 with a 200Mb Rodime drive). (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).
--
Ward Griffiths <mailto:gram_at_cnct.com> <http://www.cnct.com/home/gram/>
WARNING: The Attorney General has determined that Alcohol, Tobacco,
and Firearms can be hazardous to your health -- and get away with it.
Received on Wed Jan 20 1999 - 00:08:35 GMT