Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!rutgers!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!wb1.cs.cmu.edu!avie From: avie@wb1.cs.cmu.edu (Avadis Tevanian) Newsgroups: comp.sys.next Subject: Re: -host option (was Re: NeXT alternatives) Message-ID: <4688@pt.cs.cmu.edu> Date: 11 Apr 89 05:05:43 GMT References: <12192@reed.UUCP> <245300010@uxe.cso.uiuc.edu> <688@garcon.cso.uiuc.edu> <41358@tut.cis.ohio-state.edu> <8277@polya.Stanford.EDU> <4683@umd5.umd.edu> Distribution: usa Organization: NeXT, Inc. Lines: 42 In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: >In article <8277@polya.Stanford.EDU> aozer@NeXT.com writes: > While the visual part of the interface appears on the target > machine, sounds are produced on the source machine (I assume that > all DSP-related action run on the source machine). In 0.9, this problem is avoided in two ways. First, we have added a Postscript operator to play a sound, so if your application does something simple like a system beep, it comes out in the right place. If you are making more intense use of sound, then by default, the sound does come out on the machine you run an app. However, the sound library allows you to set which host you wish to have sound come out on. Of course, if you are playing back 44Khz, stereo sound, you best bet is to play it on your local machine and get the data from your local disk, the network just won't cut it. > Using the -host option, anyone can put windows on YOUR NeXT. There > doesn't appear to be an equivalent to the X xhost command. In 0.9 we have added some very nice security features using the fact that Mach provides kernel protected capabilities (ports). In the Preferences application (which will be shipped in 0.9), you can select whether or not your Window Server (Display Postscript) is public or not. If your Window Server is private, then only children of loginwindow may put windows on your screen. This means that you are even prevented from having someone rlogin into your machine, su to you (if they can), and start putting up windows. If you live in a friendly environment, you can make your Window Server public, and anyone can connect. To make a Window Server semi-public, you can write a short program that you would run after logging in, and it would hand out the Window Server port to whomever it decided it wanted to. And of course, since ports are network transparent, they can be handed out to any machine on your network. I'm not sure if we'll be shipping such a program in 0.9, but it will be interesting to see if anyone comes up with interesting ways to do this (like, ask for a password, for example). > Mark -- Avadis Tevanian, Jr. (Avie) Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --