peter@ficc.uu.net (Peter da Silva) (01/16/89)
<karl@triceratops calls for moderation> Well, I'm not sure if you're flaming me or not. But I'm quite moderate. I believe single-character I/O, asynchronous I/O, and so on all have a place. But that place is not in the 'C' standard. Perhaps a standard set of real-time calls can be decided on. A set more suited to a wider variety of operating systems. Something like: token = start_read(fd, buffer, nbytes, timeout); ... nread = check_io(token); ... nread = wait_io(token); With the caveat that the number returned from check_io may not actually be a count on all systems, or may remain 0 until the buffer is completely full. I think this is implementable on all systems that support async I/O. On System V, where you would use an ioctl to set VMIN and VTIME to nbytes and timeout, these could be cached so they can be left alone for multiple reads of the same size. On a system without asynchronous I/O, start_read would just stuff the parms into token, check_io would return 0, and wait_io would do the actual read. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (01/17/89)
Someone writes: Keywords: begin flame Flames doused. >[loud complaint that <some given OS> doesn't provide a >certain <feature>, thus making it so that...] >...YOU CAN'T, ABSOLUTELY CAN'T write decent software. [Response consisting of several interesting points regarding the relative appropriateness of <feature> in <any given OS>, and how the specific <feature> in question is really quite INappropriate for the specific <given OS> in question, with the possible generalization that the <feature> in question is quite possibly morally wrong in <all OSes>.] Folks, please: Take it easy. Sit back and think about it a while. Get a glass/can/ bottle of your favorite drink and ponder the possibilities a while. Different machines are designed with different purposes in mind. There is software appropriate to those purposes written for such machines. A lot of machines can be asked to generalize to a UNIX-like set of software. A lot can't be asked to do so. Neither situation is Morally Wrong. Machine design, and the attendant software design which follows on with it, is quite possibly the one place in the world where situation ethics is appropriate. If it makes sense to do something, then there is no reason not to do so. If it does not make sense to do something, there is no reason to waste time trying to retrofit concepts that are pointless within the context. 80386-based machines are designed to be small, low-throughput, more-or-less friendly boxes that Joe Average can pick up and carry around to do the day-to-day work of Joe, just Joe, mostly by himself, though multi-user incarnations of 80386 boxes are certainly possible. Retrofitting any number of software concepts into such a box is perfectly reasonable, in order to provide the best set of available contexts in which Joe can work - then he can pick and choose as he sees fit. Minicomputers are designed with different purposes in mind. In general, they seem well-suited to retrofit of UNIX paradigms, but there's no reason they have to be. There's nothing (im)moral about any given set of software concepts which one chooses to implement in any given mini. There are desirability attributes, usually, but not moral attributes. Mainframes and supercomputers are designed with yet another set of purposes, typically related to large quantities of raw throughput. Sometimes, and by no means always, the retrofit of UNIX paradigms into these environments works well. Amdahls apparently work well with UNIX paradigms. Many times they don't. Crays are quite possibly the best example available. Crays are all about number-crunching. (Where else does one get the concept of "strip-mining memory?" Fascinating physical analogies come to mind.) Crays are interested in getting the most computation done, where computation is defined in terms of huge databases of deeply complex numerical relationships with the intent of manipulating them to new relationships with different interpretations. Computation is not necessarily defined within this context as easy-to-get-along-with screen-oriented editors. Those are comparatively low-grade tasks, best suited to the machines that perform front-end functions to Crays. This is because massive numerical computation, for which Crays are designed, is in general not very compatible with massive user I/O interrupts, context switches, and swapping, for which Crays are not designed. It all revolves around the purposes for which the machine is designed. Such a machine may manage to perform "acceptably" when given a set of concepts in software which it was never intended to support (by the designers), but it will not do as well as with those concepts which the designers had in mind in the first place. Hence, a port of pcc to the Cray may work, but it'll perform awfully, if for no other reason than that it won't parallelize. To the extent that it was reasonable, UNICOS has retrofitted those portions of the UNIX paradigm that made sense. They have in fact provided more than was necessary here, because char-at-a-time I/O is available, but it's a disgusting dog of a way to get work done on a Cray. Thus, some of these retrofits would be much better left undone, simply because the purposes for which the machine was designed are not particularly accommodating. And this fact is neither Morally Right nor Morally Wrong. We can all congratulate <large mainframe and supercomputer manufacturers> who have seen fit to perform these retrofits of familiar concepts for us, but let's not get ourselves into the trap of thinking, because we have a certain set of concepts which we hold as wonderful and useful, that those concepts constitute the moral high ground. There is no moral high ground here. There are merely various regions and corners in a flat field, where the corners and regions define intended machine purposes. Think of Venn diagrams defining intended machine purposes, and you're probably on the right track. "Never underestimate raw, frothing, manic hardware." --Barry Shein, 1988 --Karl
eugene@eos.UUCP (Eugene Miya) (01/18/89)
In article <KARL.89Jan16142115@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >Someone writes: > Keywords: begin flame Karl throws some cooling fluid from a bottle (Flames doused.) A generally very good posting. >Different machines are designed with different purposes in mind. >There is software appropriate to those purposes written for such >machines. A lot of machines can be asked to generalize to a UNIX-like >set of software. . . >Neither situation is Morally Wrong. > . . . >Machine design, and the attendant software design which follows on >with it, is quite possibly the one place in the world where situation >ethics is appropriate. >If it does not make sense to do something, >there is no reason to waste time trying to retrofit concepts that are >pointless within the context. [The cheapest, fast components are those that aren't there --ascribed to Gordon Bell (Bentley, 8[78])] > . . . >Retrofitting any number of software concepts into such a box is >Minicomputers are designed with different purposes in mind. > . . . >Mainframes and supercomputers are designed with yet another set of >purposes, typically related to large quantities of raw throughput. > . . . >It all revolves around the purposes for which the machine is designed. > . . . >We can all congratulate <large mainframe and supercomputer >manufacturers> who have seen fit to perform these retrofits of >familiar concepts for us, but let's not get ourselves into the trap of >thinking, because we have a certain set of concepts which we hold as >wonderful and useful, that those concepts constitute the moral high >ground. There is no moral high ground here. There are merely various >regions and corners in a flat field, where the corners and regions >define intended machine purposes. Very astute observations. There are several forces at work here. There is the technology to make and sustain machines. This gives us the the 360/370 line (both good and bad points). We have an incredible diversity of architectures to make uniprocessors. Face it, making hardware is still an art. There are the application programs which require specific software for each of those different pieces of hardware. They are surprising inflexible for something called software. As a few have pointed out, operating systems really differ very little. Lastly there is the human resource which maintains all of this. The problem is that this is the most precious resource (a few companies might think otherwise). The problem is one of intellectual capacity being spread too thin. Originally, Unix was this fad which had a few features/strengths which made it stand out. The problem now is that with growing architectural diversity we are spreading our software talent, too thin. Many existing software systems are too obtuse to teach in a university environment. Lots of stuff didn't generalize from one system to the next. As a part of the fad, a religious fervor grew. ("We was sittin' there, jumpin' up and down...") The problem now is that we have a bandwagon which is attracting lots of people (half-heartedly). We can convert some of these people without being religious (I've even seen physicists convert). But a few people will complain without offering positive contribution. These people (some will say), work for smaller or larger than average sized companies. The point I think I should make to you is that we have reached a second stage in the evolution of Unix. We have be quieter, now. We have to eliminate the religious fever (<-ok?) and take a different approach. Those people who are skeptical, should NOT be converted. In fact, if they can be encouraged to spin their wheels more, so be it. All Unix effort should be directed to more constructive efforts than conversion. This is like Brooks' Mythical Man-Month. Converting people this late in the game will only make positive efforts late. Brooks, himself, was once quite skeptical about the "small is beautiful" approach. In his IEEE "Silver Bullets" article, he comes around. If these people don't see the shifts in the computer industry, tough. But, we should also make an effort to learn what their systems have to offer and integrate them into what is called Unix. If managers do not have foresight to see changes and handle them, and their industries suffer for their decision, so be it. Unix "expertise" is what the university computer science departments are putting out not vendor specific OSes. Maybe in other non-computing departments, but who controls the direction? End users? Manufacturers or Universities? Remember the progression of arguments? First it was Unix versus MVS. Then it was Unix versus VMS, now it's Unix versus PC/DOS and OS/2. Those other systems haven't died. Does nothing else rate comparison? None of those other systems made the transitions of hardware. I had an interesting argument with Sid Fernbach. He wanted commonality, too. When asked what he thought made an good OS, he replied CTSS. Sounds fine to me, let there be CTSS on VAXen, CTSS on PCs, etc. You don't need those fancy software tools? Who needs a screen-oriented editor? Sounds great! Don't try to argue with Sid! The other extreme is to believe there is a OS for every specific manufacturer piece of hardware. Let them churn out operating systems. One for the personal computer, one for the mini, one for the mainframe, one for the super, and let them all have different command languages. For uniprocessors, sure, this is fine. Let these users get bogged down, encourage them to get bogged down. Then OUR users can use commonality to hopefully be more productive. Let them win the grants, Let them get into decision making positions to buy to hardware and software. Right now the pendulum is swinging to commonality, but in ten or twenty years we can seek other ways of doing things. A similar situation was pointed out by Rickover as he left the Pentagon: he said let the 1/3 of the Pentagon go and do good work, and the other 2/3s should be made to sit and write memos to each other in long hand. Note that it was the minority, not the majority which controlled. Go do it. Do good. Do not convert the skeptical anymore. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."
treese@athena.mit.edu (Win Treese) (01/19/89)
Karl and Eugene both make good points. It's also important to realize that there are, in fact, some good ideas in almost every OS. Instead of being religious about, say, UNIX, we should try to evolve it using the best ideas we have. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corporation