From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-22 10:49:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!nf3.bellglobal.com!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3F4657AD.1040908@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <20030822020403.625ffbf5.david@realityrift.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc04 1061574581 24.34.139.183 (Fri, 22 Aug 2003 17:49:41 GMT) NNTP-Posting-Date: Fri, 22 Aug 2003 17:49:41 GMT Organization: Comcast Online Date: Fri, 22 Aug 2003 17:49:41 GMT Xref: archiver1.google.com comp.lang.ada:41794 Date: 2003-08-22T17:49:41+00:00 List-Id: Stephane Richard wrote: > But like you say, no matter what, the back end should definitaly be > done in Ada...:-)....no two ways about that I strongly believe in using the right tool for the job. For a lot of an accounting system, that seems to be databases or spreadsheets. But not necessarily. Let's imagine creating a double-entry bookkeeping system in Ada. You would have a generic that you instantiated to create a journal, and all the underlying complexity of transactions, journalling, and backup would be hidden from view. Now you could implement the interface as a binding to say ODBC, but let's go a bit further. If the system were to have guarenteed restore properties, the actual operation could be all done in memory. (Say journalling and periodic backup to hard-disk, possibly on two physically separate disks.) Now for 90+% of the actual use, the file system is not involved. (Completing a transaction forces a journal write.) But let's go a bit further, the journalling can be to NVRAM, for example a Compact Flash card. The effort to memory map such a card would not be too great, and now we have an accounting system that is hard-disk (and file-system) free in operation. Why do that? Because in the next few years, NVRAM is going to replace DRAM. I can't tell you WHICH variety of NVRAM, AMD has a very nice polymer memory developed with Coatue, which AMD just bought. Motorola, IBM and others are working on MRAM. Molecular electronic memory is unlikely to be the first to market, but may eventually be the winning entry in the race. So an open source accounting system that gets away from dependencies on file systems and DBMSs will be very attractive down the road. How to make money on the idea? My leaning would be fairly simple. Have a loosely organized group of developers and maintainers who retain certain rights. (To sell the software or modified versions thereof, but free distribution and use would be permitted.) This group could sell "shrink wrapped versions of the software, but I see that as only an alternative to selling books to users (with CD-ROMs in the back) The group could also sell support both by individuals and through the group. I've probably said enough for now... -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh