> They already do but by MS license they can put linix in it and still pay
> MS. Till that stops they will be dos boxen.
That's unfortunate indeed.
>
> I'm not in business to write schematic capture or PCB routing software.
His point was just that then your alternative is to wait for someone else
to... BTW, there is schematic capture and PCB layout software but I don't
know if it does routing.
> If I did I'd do it on the VAX before I would for a PC.
And likely there would only be a handful of users after you got it done,
on such an uncommon experimenters' machine.
> I just recently got REDhat version to try in place of the former
> slackeware and it's easier to install but known solid dos apps still
> die in the middle and the few windows apps are unusable. The install
You judge RH by how well it runs DOS and Windows apps? Being able to do
that at all is just a fringe benefit. Emulation is nasty work.
> was easier and it supported fewer devices. The docs were nearly current
> and I'm still trying to understand configuring IP networking. It's
Networking is not hard by any means. Just a couple of lines in your
startup scripts (add the device, add relevant routing). Course, RedHat
may be muddying the water somewhat if their GUIs are not that great.
(I haven't used RH but I know they like GUI control panels for everything...
which is OK except when the GUI's are incomplete, confusing or buggy.)
If you need help with the rc lines let me know.
> potential is there, the implimentation is still "you gotta be a unix
> head". I still find the idea of device drivers as part of the kernel
> requiring a compile to install some new device odious. Loadable drivers
> are done in many OSs. This last item is wy PCs with their nearly the
Linux does loadable drivers too - they're called "modules", and most of them
can even be set up to load and unload automatically; if you don't use the
device for a while, its driver automatically goes away to save memory.
This is especially helpful for dealing with conflicting devices.
But most people aren't yet in the habit of making kernels with every
possible driver module, and like you say below, some must be configured
for particular hardware anyway. Even so, configuring and building a new
kernel is also dead easy.
> same with millions of subtle versions either run well or just sorta.
If you're going to write one driver that works with "millions of
subtle versions" then all the alternatives are somewhat odious -
code to the lowest common denominator; detect all possible subtle versions
and have a lot of conditional workarounds; or configure it for the
particular subtle version at compile-time. Various drivers for various
hardware have taken various approaches, depending on which one the author
felt best solved the problem for the kind of hardware. Personally I like
the middle approach most of the time. But ideally there wouldn't be so
many hardware differences; if you want that kind of world, switch to a Mac
or some other vendor who controls all the hardware made for their computers.
--
_______ KB7PWD _at_ KC7Y.AZ.US.NOAM ecloud_at_goodnet.com
(_ | |_) Shawn T. Rutledge on the web: http://www.goodnet.com/~ecloud
__) | | \__________________________________________________________________
* eschew obfuscation * ham radio * emusic * sci fi * 808 State * Java *
Received on Sat May 23 1998 - 18:12:35 BST