🚀 go-pugleaf

Maynard Handley <maynardh@apple.com> wrote:

>Something the people in this thread don't seem to understand:
>UNIX and NT are multi-user OS's. MacOS is (and will be for the 
>foreseeable future) a personal OS.
>[...]
>However a personal system is a different sort of beast. When one is 
>playing a game, or capturing video for example, one does NOT want other 
>processes sneaking in and grabbing time. The user is the only person 
>using the CPU and the user cares about other issues than "Fairness" in 
>sharing time among processes. This means the OS is in many ways more like 
>a realtime OS than a traditional timeshare OS like UNIX. But it's a 
>realtime OS with a whole lot of extra stuff that realtime OSs usually 
>don't have to deal with. It is simply airheaded to say that mac OS 
>designers should be able to look at UNIX/NT/VMS and produce a new OS like 
>that. They are not INTERESTED in producing yet another timesharing 
>OS---if that's what you want, go buy NT, run LInux, whatever. 
>
>As an example of the sorts of new issues that a future MacOS will have to 
>deal with where UNIX/VMS/NT are no help whatsoever, how does one deal 
>with screen access?
>The UNIX/NT model is a screen server. The result is pathetically slow 
>screen access. Sure, the network part of X is nice---if that's what you 
>need. If you need a snappy screen more than networked graphics, X is not 
>too exciting. How many DOS or Windows action games run well (if at all) 
>under NT?
>But if you don't have a screen server, how can you enforce at least some 
>control over what happens on the screen? A single semaphore for the 
>screen? But then what happens if the process that acquires the semaphore 
>simply never gives it up?
>
>These are the sorts of issues that have to be resolved, not bonehead 
>issues like how to do VM or IPA or trivial things that any CS junior 
>knows. For God sakes, give the company credit---workstation companies and 
>MS do not have some monopoly on bright OS engineers.
>
>Maynard Handley

After having seen different types of expensive graphics software (where
some have had a price tag of a couple of years decent salary) running
on quite fast SGI workstations, I am disappointed in the interactivity
and responsiveness of locally run X applications.

None of the replies to Maynard Handley's article has touched on the
problems of fast interactive graphics, and I am curious, is it true
that bad responsiveness is more or less an inherent flaw of serialised
screen servers? Maybe it would be better to do it in parallell with
one "graphics server" per window (since only changes of the position
or size of windows could change the screen area that each window server
owns, and only then would the drawing be postponed).

What are the preferred methods of an OS which wants to support complex
interactive graphics as a simultaneous control of, and feedback from
heavy number crunching? For instance, think about virtual reality (no
that's not what I am into, but I guess my programming problems are
similar).

-Anders
--
 Anders Sundin, Org. Chem. 2, Lund University, Box 124, S-22100 Lund, Sweden
 e-mail: Anders.Sundin@orgk2.lth.se  voice: +46 462224185 fax: +46 462228209