[ale] SASIxp System Req'ts Interpreted (was Re: [ale] New Twikitopic LinuxInGASchools)

[James P. Kinney III]

Oodles of old DOS apps are so simple minded that they can be redone with
a few hundred lines of tcl/tk in a text window.

Generating a replacement app is not the hardest issue. Migrating the
data over such that the existing staff is comfortable with the new setup
is the issue.  

Wine may be a usable "glue" to let existing client apps run on Linux.
But wine code is headed for bug-to-bug compliance with the M$ API. It
has even been reported to be affected by some virus'. For this reason
alone, I advocate avoiding emulating a M$ environment.

On Mon, 2002-08-12 at 23:21, Jeff Hubbs wrote:
> As I mentioned earlier, they appear to run an app called SASIxp in
> Gwinnett.  SASIxp appears to handle large-scale school admin stuff and,
> if it's well-written, probably works very well for the whole county and
> saves them a lot of admin overhead.
> 
> I went looking through their stated "System Requirements" looking for
> possible Linux-ization.  Here's what I found and my supposition thereon.
> 
> 
> 
> 
> "LAN Client Hardware
> 
> Microsoft® Windows® Configurations
> 
>     * Minimum: Intel® Pentium® 166, 32 MB RAM, color display, 250 MB
> free hard disk space, Microsoft Windows 95, 98, NT® 4.0, Ethernet or
> token ring adapter.
>     * Recommended: Intel Pentium 350, 64 MB RAM, color display, 500 MB
> free disk space, Windows 95, 98, 2000, or Windows NT client, Ethernet or
> token ring adapter."
> 
> Ok, nothing noteworthy there - probably no need for overclocking :-)
> 
> "Macintosh® Configurations
> 
>     * Minimum: Power Mac™ 120 MHz, 48 MB RAM, color display, 250 MB free
> disk space, Mac® OS 7.5, Ethernet or token ring adapter.
>     * Recommended: Power Mac G3 300 MHz, 96 MB RAM, color display, 250
> MB free disk space, Mac OS 7.5, OS 8, or OS 9, Ethernet or token ring
> adapter."
> 
> Nothing noteworthy there either.  These two together and the fact that
> no mention of browser other other software is made suggests that they
> supply a client app for Win32 and another for Mac.  As far as using a
> Linux client, looks like you're looking at Wine or something of that ilk
> and hoping for the best.
> 
> "School Server Hardware...
> 
> Note: School server specifications listed are based on a dBase® IV
> implementation. Oracle®, Microsoft SQL Server™, and IBM® DB2®
> implementations are supported and require customized configurations."
> 
> Ah, this tips me off.  dBase IV was a DOS app that simply opened and
> accessed data files, index files, etc. and it was possible to have those
> files be on a file server and access them from more than one client at
> once, at least up to the point where multiple updates started to wreck
> things (I never had occasion to run dBase IV networked, so I don't
> know).  My expectation is that they've written the SASIxp app to simply
> open, read, and modify dBase files that are stored on a file server. 
> This implies that Linux plus Samba and/or NFS could handle Win32, Mac,
> or "Wined" SASIxp client apps.
> 
> Furthermore, it appears they have client apps for Win32 and Mac with
> different back ends coded to talk to RDBMSses instead of just working
> with dBase IV files.  If they can handle these RDBMSses, it ought to be
> a fairly short hop to be able to handle MySQL or PostgreSQL.  This would
> take vendor intervention unless it turned out that the calls made by the
> client app for Oracle, etc. were understood and acted upon perfectly by
> PostgreSQL, etc.
> 
> Reading on...
> 
> "Microsoft Windows or Mixed Windows and Macintosh Client Environment
> 
>     * Minimum: Intel Pentium 166...
>     * Recommended: Intel Pentium 350...
> 
> All Macintosh Client Environment
> 
>     * Minimum: Power Mac 120 MHz...
>     * Recommended: Power Mac G3 300 server..."
> 
> No special software requirements at all.  This reinforces my suspicion
> that the basic SASIxp implementation is simply nothing but client apps
> hitting on shared-out files.
> 
> My conclusions:
> 
> 1.  A complete SASIxp implementation can be run ENTIRELY on Open Source
> software (e.g., Linux, Samba) as long as the client app can be run
> effectively in Wine or something similar (this opens up the door to a
> LTSP implementation)
> 
> 2.  If the client app absolutely must run under Win32/Mac, then
> Linux/Samba/AppleTalk can probably completely handle the server
> requirements while the client apps run on their native OSses.
> 
> 3.  1 and 2 above presuppose that the baseline approach of using dBase
> IV files to store data is utilized.  To switch to a genuine
> client-server model and still use Open Source software, the client app
> would have to be modified by the vendor to interoperate with Open Source
> RDBMSses such as MySQL or PostgreSQL.  A server running such an RDBMS
> would be used instead of a file server (although a file server might
> still be used to distribute the client app).
> 
> 4.  Even in the likely-worst-case scenario described in #2, significant
> cost reduction may be possible by the elimination of server operating
> system license costs and client access license costs associated with a
> SASIxp deployment.
> 
> 5.  By running the file server using Linux and Samba, steps can be taken
> to maximize the server's performance by compiling the Linux kernel,
> other operating system software, and server daemon software (e.g.,
> Samba) for the server's specific CPU and configuring the server without
> extraneous kernel code employed or unused services.  This means that
> pre-existing or surplus hardware can be used whereas otherwise new
> equipment might be required.  
> 
> 
> ---
> This message has been sent through the ALE general discussion list.
> See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
> sent to listmaster at ale dot org.
-- 
James P. Kinney III   \Changing the mobile computing world/
President and CEO      \          one Linux user         /
Local Net Solutions,LLC \           at a time.          /
770-493-8244             \.___________________________./

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7 



 This is a digitally signed message part