daryl@ihlpe.ATT.COM (Daryl Monge) (02/23/88)
In article <1252@eneevax.UUCP>, noise@eneevax.UUCP (Johnson Noise) writes: > In article <2984@metavax.UUCP> chris@metavax.UUCP (Chris Collins) writes: > >... Words about the UNIX linker operation... > >It seems to me that if Unix is _the_ system for programmers, as it has > >been described to me several times, why does this idiocy exist? > BTW Unix is THE system, for programmers or otherwise, it does > have one obvious drawback: it assumes the user is competent. This gets to me every time I see it posted. UNIX is the best development environment IN TOTAL that I have used, but IT IS NOT PERFECT. IT CAN BE IMPROVED. The above smacks as a "If you don't like it, you must be a bozo" message. The UNIX linker leaves much to be desired. And consider the C compiler. Leave off a semicolon and the parser goes nuts. Does this mean I would go back to VMS where a decent compiler and linker exists? Of course not. Lets see more discussion on things to be IMPROVED. - Better syntax directed editing (>emacs has now) - Improved syntactic and semantic compiler recovery - Use of object oriented languages (C++ !) - object oriented data bases for those object oriented languages. - More powerful compiler compilers - Better debugging - Automation of regression testing - Conversion of specification into code. But please, when someone writes "this does not do what I want or expect", don't reply "Its UNIX, love it or lump it". Lets improve it! Or at least discuss the relative merits of possible methods of operation. Daryl Monge UUCP: ...!ihnp4!ihcae!daryl AT&T CIS: 72717,65 Bell Labs, Naperville, Ill AT&T 312-979-3603
breck@aimt.UUCP (Robert Breckinridge Beatie) (02/24/88)
In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes: > In article <1252@eneevax.UUCP>, noise@eneevax.UUCP (Johnson Noise) writes: > > In article <2984@metavax.UUCP> chris@metavax.UUCP (Chris Collins) writes: > > >It seems to me that if Unix is _the_ system for programmers, as it has > > >been described to me several times, why does this idiocy exist? > > BTW Unix is THE system, for programmers or otherwise, it does > > have one obvious drawback: it assumes the user is competent. > > This gets to me every time I see it posted. UNIX is the best development > environment IN TOTAL that I have used, but > IT IS NOT PERFECT. > IT CAN BE IMPROVED. > The above smacks as a "If you don't like it, you must be a bozo" message. Yes, it does smack of "..." but then the original comment about "idiocy" smacks of "Unix is an idiots environment. (substitute favorite monolithic system here) is the system for real programmers." This bothers me about as much as the other message. > Lets see more discussion on things to be IMPROVED. > [Interesting list deleted in the interest of brevity] > But please, when someone writes "this does not do what I want or expect", > don't reply "Its UNIX, love it or lump it". Lets improve it! Or at least > discuss the relative merits of possible methods of operation. Yes, but then isn't it obvious? Isn't the real power of UNIX in that it is an environment that encourages tool building? If a tool (and the linker is just another tool) doesn't do what you want or need, then build a better tool. That is the UNIX philosophy? (well, at least my interpretation) If you want to get something done, then use the tools that UNIX provides to build a better tool. The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!". Don't add "just one more system call", especially not just because it seems "a neat idea". The more baroque the kernel gets, the less clear it becomes. The UNIX kernel provides a delightful interface to an abstract machine. It seems an awful shame to sew a bag on its side. -- Breck Beatie {uunet,ames!coherent}!aimt!breck "Sloppy as hell Little Father. You've embarassed me no end."
raveling@vaxa.isi.edu (Paul Raveling) (02/27/88)
In article <644@aimt.UUCP> breck@aimt.UUCP (Robert Breckinridge Beatie) writes: >In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes: > >Yes, but then isn't it obvious? Isn't the real power of UNIX in that it >is an environment that encourages tool building? No. It REQUIRES tool building because the operating system itself doesn't offer good solutions to large sets of problems. > >The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!". Many of the problems with Unix can't be solved without a different kernel. I favor a substantially different kernel with a Unix compatibility layer over it to accommodate existing applications. I'd write new applications for the new kernel's native facilities. To pick a few examples: We need asynchronous i/o. What we did in EPOS was to issue a request as a signal (NOT like a Unix signal) to a device driver process; the device driver then issued an answering signal at completion. These signals included event data and were queued if the destination process wasn't ready for them. Lurking behind this terse description are about half a dozen things the Unix kernel can't do. We need GOOD interprocess communication. The only Unix mechanisms that are standard enough to have some hope to contribute are pipes and signals. There's nothing which efficiently communicates a small set of paramaters, such as those in typical C function calls, between processes. Unix signals don't queue event data, and pipes are slow -- our benchmarks show that either the setup overhead for pipe i/o or context switching is easily an order of magnitude slower than it should be. We need to share memory among processes in a multi-process application. There's no way to do this and keep application software portable between Unixes with different extensions. We need a single i/o interface with mutually consistent functions. We really don't want to have to check stream status, call Xpending, etc. before knowing it's safe to call select. In fact, it can never be totally safe to use select with streams or X connections without a polling time interval; if a context switch and input completion intervene between the stream/X connection check and the select, the select can leave the calling process blocked. We need to spawn processes without creating another copy of the entire address space (as in fork) and without having to fetch the new process from a disk file (as in vfork). The first part is especially important, since much of our project's software is Lisp running in a 40-megabyte address space, and we don't have enough swap space for another copy of it. I haven't even mentioned the question of user interfaces, but the problems there are equally dismal. Give Me Liberty or Give Me Unix! --------------------- Paul Raveling Raveling@vaxa.isi.edu
bill@wsccs.UUCP (Bill Housley) (03/13/88)
In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes: > Lets see more discussion on things to be IMPROVED. > - Better syntax directed editing (>emacs has now) > - Improved syntactic and semantic compiler recovery > - Use of object oriented languages (C++ !) > - object oriented data bases for those object oriented languages. > - More powerful compiler compilers > - Better debugging > - Automation of regression testing > - Conversion of specification into code. > Add to your list: - More modern user interface Now I know that some of you are saying "That should be discussed else where, not on comp.software-eng". But a system "... for programmers..." should also be "...for users..." somewhere, otherwise we're all just a bunch of geeks writing games for ourselves to play, on systems nobody else understands or wants to. I take the attitude "UNIX (user interface) sucks, but it's so widly used that I guess I'd better learn it and use it anyway". I agree with you, if this is the small systems (my emphisis) multi-user operating system of the future, let's fix it so it acts like it. Otherwise, we'll have another MS-DOS out there pissing off users on tomorrow's super machines and they'll say "Why are we using this $#%%&$@(}^@#^ criptic %&*@#!*^ machine!!?" (because to users the terms hardware and software are synonomus with '...this flipping silly machine I'm using...). To which us the programmer will respond "Because it's the best 'machine' for ME to do MY job on". To which a dozen pencils, paper weights, coffee cups and other assorted office furniture responds "THUD! WHAK! SMACK! SMASH!" on your head. Kirk: But this planet is destroying it's self around us!!! Kruge: Invigerating, isn't it!! --------------------------------------------------------------------- UUCP !ihup!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!bill {WSC Utah} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Disclaimer: These opinions are my own, not those of my wife who neither selects, sensurs, understands, nor cares about what I write here.-