Re: RDBMS for DOS and Windows

new topic     » goto parent     » topic index » view thread      » older message » newer message

----- Original Message -----
From: "Irv Mullins" <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, February 24, 2000 12:21 PM
Subject: Re: RDBMS for DOS and Windows


> On Thu, 24 Feb 2000, Brian Jackson wrote:
>
> > >I can't really speak on behalf of Linux because I simply don't know
near
> > >enough about it.  I do know this.... Linux is generally much more
secure
> > >and stable.  Linux is generally faster under these memory limitations.
>
> erm.. 8 mb is right at the lower limit for anything that will function.
> If you're going to hang 5 client terminals onto this, it's not going to
> be usable.
>
> > And the total cost to convert the entire plant to Linux is labor!  (OK
$70
> > bucks if you want a nice boxed copy to sit on your shelf and look cool).
> > Then you can run SQL for free, no more IPX headaches, TONS of free
> > software... I am a Certified Netware Engineer BUT - I have never run
into a
> > situation where Netware is better than Linux as a total solution (well,
> > maybe if you're a die hard GroupWare user).  But I digress...
>
> > >If you ever get a company hooked on a graphical interface..  They won't
> > >want to go back.  The graphical is usually much easier to use and looks
> > >more pleasant.
>
> Generally speaking, yes. A GUI also makes it much easier to train new
> employees on your software, and less likely they'll screw up royally as
> they flounder around. Employees who are accustomed to the old dos
> program will gripe loudly, for a week or two. After that, you won't be
> able to get them to go back.
>
> > My GUI of choice for Linux is KDE.  I can't confirm it, but I believe
that
> > KDE will run even on the 386 (not sure about the memory requirements
> > though).  It comes with Netscape, so they could even surf the web on
their
> > old 386's.
>
> A 386 is not recommended for any GUI work. Save them for printservers,
they
> can still outrun most printers.

I don't believe the hardware bashing going on here! I had my C64 with 32K of
free ram popping up moveable windows, and  overlaying them, faster than my
586-133 with 8Meg did on win95. The problem is NOT the hardware or the
instruction length, it's the OS. Granted the C64 would be terrible at DB
manipulation of any significant size, but it would not have to spend all the
time doing interfacing to a prebuilt server, or being subject to the whims
of time allocation of the timeslice multitasking OS. Anyone here remember
the days when we picked opcodes based on speed of execution and size, not
just the task? That's what this guy needs, optimized code. I think Eu is up
to the job with a simple custom database, prolly the one he already has. And
for speed, lose the new OSs, go back to DOS, you can GUI in dos when you
need to, and your app has the cpu and the rest of the box all to itself, no
interruptions by the OS saying "you can't go there!". With a fast enough
hardrive, you can prolly access and use my 50Meg DB with the 386, dos,
Euphoria, and 640K of ram. Seriously, if you code it right, the speed of the
harddrive on the database access box is the most important thing,, those
500Meg hardrives are amazingly slow compared to the newer drives. I have a
several drives on the other puter about that size, and i can go fix dinner
while they are being accessed,, and it's a K6-2-300. If you want to run this
net of 386 boxes fast, make the server dos for speed, drop in a new mode4
harddrive,,, and and either put the pretty GUIs in win3.11 on the user
boxes, or write your own GUI with one of the programming languages written
for dos.

Kat,
in my opinion.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu