Re: RDBMS for DOS and Windows
- Posted by Kat <gertie at ZEBRA.NET> Feb 24, 2000
- 423 views
----- 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.