peter@ficc.uu.net (Peter da Silva) (01/04/90)
> >Now it may be that Sun, AT&T, and Berkeley have forgotten their roots. > I believe the above three define the label UNIX. I don't. UNIX is a family of operating systems based on a uniform device interface concept, with a common programming interface and a common set of utilities. I'm writing this message on a System-III based Xenix box. I could be using anything from a PC-XT running Minix to a Sequent Balance running whatever they run... and the system would look pretty much the same. Here you are saying "X is just a label", when it's even more closely tied into the implementation than UNIX, and then pegging UNIX as BSD+SYSV. I wish you were right. Because X is a horrible design. The first rule of system design is: make the easy things easy, then make the hard things possible. This is best done by providing a simple unifying concept that defines the system. I've not heard a lot about Apollo Domain, but what I have heard is typical of pre-UNIX proprietary systems: lots of complex system calls and data structures, I/O tied closely to the hardware. And X is certainly complex to use. Am I wrong? What's the simple unifying concept for DomainOS? Or X? -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / `-_-'\ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org> \_.--._/ v
davidh@dent.Berkeley.EDU (David S. Harrison) (01/05/90)
In article <.3ZB2Cxds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > The first rule of system design is: make the easy things easy, then make > the hard things possible. This is best done by providing a simple unifying > concept that defines the system. I've not heard a lot about Apollo Domain, but > what I have heard is typical of pre-UNIX proprietary systems: lots of > complex system calls and data structures, I/O tied closely to the hardware. > And X is certainly complex to use. > > Am I wrong? What's the simple unifying concept for DomainOS? Or X? Personally, I don't see a simple unifying concept in NeWS either. Basically, window systems are complex because they are asked to provide a wider range of functionality than most systems. I am also not convinced of your rule of system design. Complex tasks are most often successfully tamed using a layered approach. I like to think of networking protocols as a good example. TCP/IP is built on a number of protocol layers each providing a higher level of abstraction. Building TCP/IP from scratch is quite difficult and error prone. Good layered systems tend to use the concept of mechanism vs. policy. The low-level framework of your system should be designed so that *all things are possible* (mechanism) and higher levels should use this lower level to provide convenient, application dependent access to your system (policy). This way, if someone wants functionality that is not present at higher levels, they can use lower levels to implement it. I claim both X and NeWS are the low-level framework of a user-interface system. As such, I think X is the better design because it allows greater freedom (through lower-level access) to design high-level toolkits. I won't belabor the point since much of this discussion is highly religious and I doubt anyone is about to change their convictions. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh)
peter@ficc.uu.net (Peter da Silva) (01/09/90)
> Personally, I don't see a simple unifying concept in NeWS either. What about PostScript? > I am also not convinced of your rule of system design. Complex tasks > are most often successfully tamed using a layered approach. Certainly. > I like > to think of networking protocols as a good example. TCP/IP is built > on a number of protocol layers each providing a higher level of > abstraction. Building TCP/IP from scratch is quite difficult and > error prone. But using it isn't. I guess I need to make this point clearer. Design the system to make simple things simple *for the users* of the system. In the case of a window system, there are two sets of users: the people who sit in front of he screen, and the people who program the applications. > This way, if > someone wants functionality that is not present at higher levels, > they can use lower levels to implement it. That's the second half... making the hard things possible. But you should start by making the easy things easy first. The way X is set up it's like (to get back to your TCP/IP example) putting all of NFS into every program on the system. You can certainly get the overhead down with shared libraries and such, but I hardly think you would claim that was a better design. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org> \_.--._/ v "Have you hugged your wolf today?" `-_-'