Return to BSD News archive
Xref: sserve gnu.misc.discuss:6390 comp.os.linux:11657 comp.unix.bsd:6030 Path: sserve!manuel!munnari.oz.au!network.ucsd.edu!usc!usc!not-for-mail From: ajayshah@almaak.usc.edu (Ajay Shah) Newsgroups: gnu.misc.discuss,comp.os.linux,comp.unix.bsd Subject: Suggestions for the free Unix projects Date: 3 Oct 1992 11:55:09 -0700 Organization: University of Southern California, Los Angeles, CA Lines: 71 Message-ID: <1akqadINN76c@almaak.usc.edu> NNTP-Posting-Host: almaak.usc.edu I have watched the Linux/BSD/GNU projects with much joy. I have a few suggestions. 0. Packaging ------------ I think the Most important constraint impeding relatively novice users from using Linux (I don't know about 386BSD) is the difficulty of installation. I can think of lots of university folk who have used a Unix account at school with much ease, but are intimidated by the problems of installation. Packages like MCC interim, SLS, etc. are steps in the right direction. I think they are important, and need to be done better. They certainly need better documentation. There may be a role for a profit-making company to make a $50 shrink-wrapped free Unix with a manual and limited support. 1. Binary compatibility ----------------------- >From the end-users perspective, I think binary compatibility is incredibly important. I mean binary compatibility across versions of the OS and across the three major free Unixes. In my ideal world, I would be able to: a) pick a OS -- any OS -- of the three b) grab binaries for programs I plan to run, without regard for my choice at step a c) be able to move versions of the OS or to a different OS without needing to get (say) TeX binaries afresh d) Ideally, be able to run commercial software for 386-Unix too. When Linux was younger there were Major kernel changes being done every month. But maybe it's now possible to talk about ways to ensure that all future kernel releases will be able to run binaries which conform with definition X. Intel has a binary compatibility standard for x86 Unix. Is that too hard to support? A important payoff of supporting it would be easy access to commercial Unix software. The other path to getting access to commercial software would be to write a emulation box (that already exists for Linux, to run Xenix binaries). Talking about commercial software brings me to the next point: 2. Xbase -------- The GNU project is already working on such anti-hacker objectives as a Fortran and a spreadsheet. :-) (I completely agree with the proposition that these need to be done). In that spirit, I think we also need a Xbase clone. Ideally it should be a Xbase compiler, but an interpretor would also be good. It should certainly open .dbf files from out there. (Would it be the ugliest frontend to gcc ever? Or would Fortran still take that prize?). I'm not claiming Xbase has anything to offer to someone who knows Unix. Personally I would not use it ever. I suspect it's the Most important single piece of commercial software out there with a well-defined standard (fileformat and language specn). A good free Xbase implementation would make free Unixes more attractive to the end-user (as would GNU Fortran and Oleo). -- Ajay Shah, (213)749-8133, ajayshah@usc.edu