Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ncoast.UUCP Path: utzoo!linus!decvax!cwruecmp!atvax!ncoast!bsa From: bsa@ncoast.UUCP (The WITNESS) Newsgroups: net.unix-wizards Subject: Re: Bug in Unix System V C compiler Message-ID: <219@ncoast.UUCP> Date: Tue, 7-Aug-84 12:38:06 EDT Article-I.D.: ncoast.219 Posted: Tue Aug 7 12:38:06 1984 Date-Received: Fri, 10-Aug-84 07:55:25 EDT References: <806@ut-ngp.UUCP> <4180@utzoo.UUCP> Organization: North Coast XENIX, Cleveland Lines: 47 Come on, guys! I have complained about 4.2BSD in the past, but mainly because I have been working with Unix for only 8 months and the system manager here expects me to take every program we get with BSD stuff in it and get it running on here -- while Rich thinks I'm a wizard, apprentice sorceror comes a little closer to the mark. (What the heck is a SIGTSTP, anyway?) The past few weeks or so have seen the coming of wars between System V users and Berkeleyites. Personally, I like what I hear of 4.2 more (and am eagerly awaiting an upgrade to it (on a new system) here), but then I have yet to hear SysV people come out and tell us what their system really does, as opposed to LOTS of 4.2 articles all over the net. Will someone please tell me why it matters which is "better", anyway? And why we compare them at all, given that 4.2 is a programming environment and SysV is a runtime business environment? After all, there are not that many com- panies that really need the C language, make, and so on (not to mention f77, which we don't have, and lex and yacc, which we do). Why would Widget Mfg. Co. which has purchased a full business package (Micro Manufacturing Systems' MCS package, requiring RM-COBOL runtime but nothing else, for example), need to play with /usr/include/sys/callo.h? Or "symbolic links"? (I speak from experience here; I do some business programming... mainly because the mfg. package we use is not compatible with the customer order entry package; we don't have the room on our current system to run the compatible one.) If System V people want to do development work, they probably can, with AT&T "add-on" packages. Bugs? System V is still fairly new; let them get worked out by being reported; with enough pressure brought to bear, even AT&T will bend. And 4.2, from all accounts, has a few bugs of its own. If you guys have time to burn (by flaming each other), why don't you come up with a standardized way of easily making 4.2 and SysV source compatible? Maybe some kind of alternate -lc with simulations for those functions that can be simulated, such things as the Berkeley compatibility library to present the "old-style" Unix directory in the "new" Berkeley format, and such? Those without source licenses might not be able to use them, but there could be a way to get object code for "standard" systems, and source-licensed sites for the others could provide object versions on their own; maybe a hex-type protocol could be used to post them to the net for VAXen, etc. (Look out: Intel hex format rides again! :-) Not only will it give you something to do, it would benefit all of us (including both Berkeley and AT&T). <<<>>> -- Brandon Allbery: decvax!cwruecmp{!atvax}!bsafw 6504 Chestnut Road, Independence, OH 44131 Witness, n. To watch and learn, joyously.