roskos@csed-1.UUCP (Eric Roskos) (02/09/88)
In article <19658@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > > (Responding to a note from Eric Roskos) > > Actually, I disagree. Well, generally I agree with your comments, so it may be that I have not explained my original comments very clearly. > > >In terms of the "modern needs" above, how much of that is *really* > >necessary? For example, remote file systems [should be transparent]. > > Unfortunately in practice there are these "little" nits (eg. > statelessness vs statefulness, perhaps new error codes or mount > options), I suppose one could come up with an abstract super-set, so > let's leave all that for a moment. I'll agree with that in part. I would be really reluctant to see new error codes that described non-routine, network-specific errors as other than a generic "I/O Error" simply because the number of error codes of that class which other device types could contribute is so large. As I stated before, I do agree that things like new mount options could be necessary. > The real issue is from the vendor's point of view. If I want to > support a remote file system > I have to pick one, the fact that they're all roughly alike and don't > interoperate is a problem, not a solution. I'll agree with this too, but as I said, this should be a separate standard. What the current committees are mostly addressing now are things that the user sees. How one machine communicates filesystem requests to another machine is a protocol issue, and should be addressed in a protocol standard. > Windowing I think is an easy issue to respond to. It's critical. I avoided this issue because it is a hard one, but I will expand on it here. This is more of an architectural issue, though, and I am reluctant to discuss it in unix.wizards. Anyway: > Again, you're a vendor, you're planning an interactive software > product which could use windows effectively. What do you choose to > code? To > improve marketability you want to choose something standard. In fact, > this particular issue is so bad that the truism going around > is one reason you don't see > products like [Microsoft] Excel on Unix workstations is simply that they're > waiting until Unix presents a standard window interface so they can > port their code once and just sell it, not port it over and over again ... Well, I worked on Excel for a year, and although there's really nothing I can say about that, as far as portability issues are concerned there are a lot more issues confronting microcomputer applications developers than that. In general, the state of the art is far from the state of the practice as far as microcomputer developers are concerned. The problem with windowing, the problem I didn't address before, is that it is still too much an open field in terms of basic architectural concepts. By way of analogy, particularly on microcomputers, windowing is at the level of development that programming was at when everyone programmed in assembly language. That is to say, each windowing implementation provides a very wide variety of primitives simply because people haven't yet decided what a minimal set of primitives should be. That's what led me to say "I don't think one should standardize too early." In a sense it's true that > a standard just says you should support > this to claim you are standard, not that you don't have anything else, > so it shouldn't limit anyone other than the time and trouble to get > the standard working correctly (if it's truly a successful standard > the effort should be worthwhile.) but also it's true that standards (a) tend to discourage improvements since people are all trying to be standards-compliant, (b) tend to constrain technology, especially if they are not abstract enough, since often by the time the standard comes out, the technology on which it was based is obsolete, and (c) tend to bias the way people think. On this machine I am using now (a Sun), we have two different windowing environments I have to use to get my work done, and it does irritate me. But I wouldn't want to see either one of them become a standard at this point. One of them doesn't have the support for a certain standard displayed-text representation language which one application I use needs; the other one is too slow and has a clumsy process model. This is not to say that a standard couldn't be created that has the best of both, rather that the way standards get created, it is highly unlikely it would, at this point, partly because the standards-makers tend to be partially unaware of how much context they carry with them into their thinking on how a system should work. I agree with you that windowing is essential; but I don't think it's time to standardize it yet. > What's the problem anyhow? TCP/IP is a de facto standard, almost all > vendors offer it as a primary product anyhow, it's available, it works > etc. You are outside my area of expertise now, but I seem to recall reading a paper just about a week ago that indicated that TCP/IP was being phased out in some critical areas because there is another standard that is more widely used. I'll have to leave that for somebody else. Underlying my argument, though, is a more general concept, having to do with changes I see in Unix recently. It perplexes me when I read comp.arch to see that the same people who are strong advocates of RISC architectures seem to be the strong advocates of complex Unix-like architectures. I remember reading in one of Dennis Ritchie's speeches in response to some award he was being given that he said something like "I must admit feeling uncertain about this award, since I have had nothing to do with what's considered mainstream Unix for many years." There's a fundamental principle to that. The ideas Ritchie and Thompson set forth in their original papers on Unix, the ones explaining its philosophy, seem to have disappeared in a lot of areas; first in Berkeley Unix, later in other forms of it. Specifically, the "kernel as a soapbox" idea, or, the idea behind that one. It's easy to design a system that does everything anybody wants, although getting it to work may be a problem, and keeping it working an even bigger problem; but it's hard to design a system that does useful things well, and succeeds in providing something better than what people first wanted, the sort of thing they end up wanting in the end, but without carrying along all the intermediate features indefinitely in the process. That was what I was referring to, a sort of architectural discipline. ---- Microsoft Excel is a trademark of the Microsoft Corporation. Unix is a trademark of AT&T. -- Eric Roskos, IDA (...dgis!csed-1!roskos or csed-1!roskos@HC.DSPO.GOV) "Only through time time is conquered." -- Burnt Norton
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/09/88)
In article <263@csed-47.csed-1.UUCP> roskos@csed-1.UUCP (Eric Roskos) writes:
-I agree with you that windowing is essential; but I don't think it's time
-to standardize it yet.
Hear, hear!
-It's easy to design a system that does everything anybody wants, although
-getting it to work may be a problem, and keeping it working an even bigger
-problem; but it's hard to design a system that does useful things well, and
-succeeds in providing something better than what people first wanted, the
-sort of thing they end up wanting in the end, but without carrying along all
-the intermediate features indefinitely in the process.
I wish we heard more like this in the so-called "Unix wizards" newsgroup.
Anyone want to comment on how Plan 9 is coming along, or is it too early?dmt@ptsfa.UUCP (Dave Turner) (02/10/88)
In article <7230@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <263@csed-47.csed-1.UUCP> roskos@csed-1.UUCP (Eric Roskos) writes: >-I agree with you that windowing is essential; but I don't think it's time >-to standardize it yet. > >Hear, hear! > >-It's easy to design a system that does everything anybody wants, although >-getting it to work may be a problem, and keeping it working an even bigger >-problem; but it's hard to design a system that does useful things well, and >-succeeds in providing something better than what people first wanted, the >-sort of thing they end up wanting in the end, but without carrying along all >-the intermediate features indefinitely in the process. > >I wish we heard more like this in the so-called "Unix wizards" newsgroup. > I think that Ken Thompson said it best in an article on "UNIX Implementation": "... The kernel is the only UNIX code that cannot be substituted by a user to his own liking. For this reason, the kernel should make as few real decisions as possible. Rather, it means to allow only one way to do one thing, but have that way be the least-common divisor of all the options that might have been provided. "What is or is not implemented in the kernel represents both a great responsibility and a great power. It is a soap-box platform on "the way things should be done." Even so, if "the way" is too radical, no one will follow it. Every important decision was weighed carefully. Throughout, simplicity has been substituted for efficiency. Complex algorithms are used only if their complexity can be localized." Add to this a quote by Dennis Ritchie from "A Stream Input-Output System": "... In spite of these limitations, the stream I/O system works well. Its aim was to improve design rather than to add features, in the belief that with proper design, the features come cheaply. This approach is arduous, but continues to succeed." -- Dave Turner 415/542-1299 {ihnp4,lll-crg,qantel,pyramid}!ptsfa!dmt
rbj@icst-cmr.arpa (Root Boy Jim) (02/18/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> Anyone want to comment on how Plan 9 is coming along, or is it too early? Plan 9 From Outer Space? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Maybe we could paint GOLDIE HAWN a rich PRUSSIAN BLUE--