omeer@neabbs.UUCP (OSCAR VAN.DER.MEER) (05/28/90)
I am suprised that there is no news about SCO's Open Desktop. Am I in the wrong area for message? If not could anybody who is using the product send me a short review of their experiences with the Open Desktop. What I am particulary interested in is, how much effort it cost to write a decent Motif based program. And also what the performance is of the X-Windows/Motif combination, for instance compared to Microsoft Windows on the same machine. I would welcome any messages about Open Desktop. Oscar van der Meer Uilenstede 201-6 1183 AD Amstelveen UUCP: omeer@neabbs.nl
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/28/90)
In article <394080@neabbs.UUCP> omeer@neabbs.UUCP (OSCAR VAN.DER.MEER) writes: | I am suprised that there is no news about SCO's Open Desktop. | Am I in the wrong area for message? If not could anybody who is using | the product send me a short review of their experiences with the | Open Desktop. ODT seems to work well, but if you are running in a network environment you will probably need the multiuser version, since the two user version doesn't let you run two users under all conditions (see my many previous posts). Other than that, and some problems with TCP (see other's posts) it looks pretty good. | What I am particulary interested in is, how much effort it cost to | write a decent Motif based program. And also what the performance is | of the X-Windows/Motif combination, for instance compared to Microsoft | Windows on the same machine. At work we have not gotten either the multiuser update or the X development set, which were ordered FedEx weeks ago. We got the MU package on a machine in for evaluation, and it seems to be okay. Speed is acceptable on a 20MHz 386, really good on a 33MHz 486! We're evaluating lots of toys right now, so those are the boxes I've run more than a few minutes. I really like the MOTIF setup, and use it a lot. The copies we have will not run X on an X terminal, just on the console. SCO tells us that this works in the multiuser version, but ours didn't. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
jmd@n4hgf.uucp (John Dashner WA4CYB) (05/29/90)
In article <394080@neabbs.UUCP> omeer@neabbs.UUCP (OSCAR VAN.DER.MEER) writes: >I am suprised that there is no news about SCO's Open Desktop. >Am I in the wrong area for message? If not could anybody who is using >the product send me a short review of their experiences with the >Open Desktop. Well, not really since there isn't one for it YET ;-> > What I am particulary interested in is, how much effort it cost to >write a decent Motif based program. And also what the performance is >of the X-Windows/Motif combination, for instance compared to Microsoft >Windows on the same machine. > [remainder of msg delete] Oscar, I just spent a week this weekend installing and getting ODT up on a 20 Mhz Premium 386 and after adding 4 MB of ram was able to see ODT-View as the X11 part is called. But first, let me make sure that you and others understand that ODT by itself does not enable one to develop X applications -- you need another package which I believe is called Open Desktop Development Kit and be prepared to drop alot of change when you buy it - ~$3000US if memory serves me right. I did find some lib's that may have the basic Xtlib stuff in them but just haven't had time to check this out. Perhaps more on this later after I get comfortable with it. Another point is that this is "early release" code. Read as BETA. As for a report on ODT-View's performance, I would say that it very nearly models Windows 2+ behavior and is of course familiar since Motif is roughly based on Microsoft Windows (all the familiar quick-keys are the same for instance). The radio buttons are approximately the same as well. The most striking difference is the 3D effects that Motif implements. Starting an Xterm gives you a much larger screen area to work with (if applications know how to take advantage of it) and I would say that no really noticiable performance hits were experienced. With 9 megs of memory, I only saw swap in use when I had Merge86 DOS and several Xterms running. Think about that: Multiple Xterms on Multiscreens......... This has run on too long and I am only just beginning - One bug I think I have uncovered is that every man page I read while in view wound up copied to /tmp and as much as I was having to read, it could soon blow the disk - don't know about that just yet.... All the best, John "Pappy" Dashner ============================================================================== John Dashner - WA4CYB - {tdmfed,n4hgf,wa4cyb}!jmd - dashner_john@tandem.com ARRL/ARC/SEDXC "...always being right is a pleasant burden to bear" -me ==============================================================================
danielw@wyn386.mi.org (Daniel Wynalda) (05/30/90)
>In article <394080@neabbs.UUCP> omeer@neabbs.UUCP (OSCAR VAN.DER.MEER) writes: >>I am suprised that there is no news about SCO's Open Desktop. >>Am I in the wrong area for message? If not could anybody who is using >>the product send me a short review of their experiences with the >>Open Desktop. > I agree with most of what was replied in the first response on Open Desktop. We had SCO ODT running here at the Grand Rapids Business Expo about a week ago. We were running on a DELL EISA 80486/25 machine. This machine really ran nice. We tried installing a BUNCH of packages to see what would/could run under ODT. We had 16MB RAM with a SuperVGA card in it. The ODT wasn't able to use the SuperVGA modes at this time, just standard VGA I believe... The DOS emulation appears to work quite well (DOSMERGE) as I was able to pop up a DOS window, load MICROSOFT WINDOWS in the WINDOW, and load Lotus 123 from Windows. All ran and worked on a dynamically sized screen. Graphs worked to the screen as well. All of the Xenix stuff we loaded was able to run. We had representatives out from SCO to the show. They brought the 80486 Server version of the NFS and TCP/IP. We didn't ever use it but I imagine it is similar to the Xenix TCP/IP implementation. I've never played with NFS so I won't pretend to comment on that yet... One nice thing I ran into -- you can use all of the standard Unix multiscreens even if you are in ODT on some screens. --- thus, multiple sessions with multiple windows. The version of ODT we had was loaded with toys to demo the X-window capabilities. I don't know if the release version is... We had X-eyes (eyes that watch your mouse pointer), xclock, dclock, alot of the PIC, and GIF files with a viewer, some games, etc. I had never used Microsoft Windows up till this point but the windows were all very intuitive to the computer types... As far as performance goes, I didn't see any real degradation due to the graphics interface.... Of course I wasn't serving 16 terminals or anything either.... In short, (coming from a first time X-Windows user), the package appears to be quite robust. Nothing I loaded up trashed the windows server at all. The system never locked up on my beyond where I could just close a window and watch it go bye bye. There are about 100 copyright notices you see on boot. I find it amazing all of this stuff integrates and runs without the usually massive EASY TO FIND bugs (like VP/ix had/has). If you need X and are interested in running it on an 386/486 platform, I'd look into it. For our needs at this time, we have to continue to run Xenix. Both for lack of faith in a prototype operating system and because I need to feed lots of terminals. I have 2 Xenix machines running TCP/IP now with Xenix-Net on it. I might think of adding another machine to the net running SCO Unix or ODT and tying it in with the ethernet in one way or another. -- Daniel Wynalda | (616) 866-1561 X22 Ham:N8KUD Net:danielw@wyn386.mi.org Wynalda Litho Inc. | It's soon to be a united, neutral, mediocre world. 8221 Graphic Ind Pk. | You know you're losing your freedom when everything you Rockford, MI 49341 | like to do is taxed, charged "user" fees, or banned.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/31/90)
In article <706@n4hgf.uucp> jmd@n4hgf.UUCP (John Dashner WA4CYB) writes: | Another point is that this is "early release" code. Read as BETA. No, I have had SCO beta releases, and this is not it. The point of early release is to limit the # of calls to support until the people get up to speed (so SCO tells me). The product has been usefully robust. We have just started running a reasonable user load, having gotten a working server upgrade, and we will be running a number of user on it. Only problems of note so far are that the 2 user system will only run one user (for us, SCO says it works), and we haven't gotten it to work with a nameserver yet, a must on a net with net changes daily (2k+ nodes). -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
shwake@raysnec.UUCP (Ray Shwake) (06/01/90)
In article <1061@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <706@n4hgf.uucp> jmd@n4hgf.UUCP (John Dashner WA4CYB) writes: > > The product has been usefully robust. We have just started running a >reasonable user load, having gotten a working server upgrade, and we >will be running a number of user on it. Some people are luckier than others. Among the problems I've encountered: - Corruption of some critical files if I change the default root shell from Bourne to Cshell - MMDF II regularly leaves undelivered messages in its spool dir - ODT-View will leave a server process running if I shut it down using the System menu "Close" option, rather than "Stop Desktop" within the Desktop menu. - Bootup problems after power loss when Korn Shell has been substituted for /bin/sh (We're still working to narrow this problem down) - Custom will not load Xenix/386 Software Dvlpmt (and SCO says they don't support it under SCO UNIX!) Not saying ODT is NG, but we'll be looking at alternatives before we settle on a standard implementation for UN*X/386.
caf@omen.UUCP (WA7KGX) (06/03/90)
In article <43@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: :In article <1061@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: :>In article <706@n4hgf.uucp> jmd@n4hgf.UUCP (John Dashner WA4CYB) writes: :> :> The product has been usefully robust. We have just started running a :>reasonable user load, having gotten a working server upgrade, and we :>will be running a number of user on it. : :Some people are luckier than others. Among the problems I've encountered: : : - Corruption of some critical files if I change the default root : shell from Bourne to Cshell I suggest bin/sh remain Bourne shell, see below. : : - MMDF II regularly leaves undelivered messages in its spool dir You have to have the "deliver" program running: mmdf 244 1 0 02:25:11 ? 0:00 /usr/mmdf/bin/deliver -b -clocal : : - Bootup problems after power loss when Korn Shell has been : substituted for /bin/sh (We're still working to narrow this : problem down) Check out the history files. I keep /bin/sh as /bin/sh, this allows boot-up to use Bourne shell, yet I can set the shell in the login to Korn so I have the "better shell" when multi user. It helps to keep the KSH history files on the root FS, makes it easier to keep "my" file system squeaky clean (fsck-wise). : : - Custom will not load Xenix/386 Software Dvlpmt (and SCO says : they don't support it under SCO UNIX!) I still run the Xenix compiler to compile a certain 286 program. Possible to do with shell scripts and setroot. Otherwise I use the ODT development system, or assorted and sundry DOS compilers as needed.
shwake@raysnec.UUCP (Ray Shwake) (06/04/90)
In article <22@omen.UUCP> caf@omen.UUCP (WA7KGX) writes: >: - Corruption of some critical files if I change the default root >: shell from Bourne to Cshell >I suggest bin/sh remain Bourne shell, see below. This may well be the case, but why should it be so? I've been able to redefine the root shell under both SCO Xenix/386 and ISC 2.0.2. >: - MMDF II regularly leaves undelivered messages in its spool dir >You have to have the "deliver" program running: > mmdf 244 1 0 02:25:11 ? 0:00 /usr/mmdf/bin/deliver -b -clocal This solution will not clean out the spool directory, nor will running the foreground counterpart "deliver -w -clocal". Checkque still reports no messages in the queue, and cleanque does nothing. >: - Bootup problems after power loss when Korn Shell has been >: substituted for /bin/sh (We're still working to narrow this >: problem down) >Check out the history files. I keep /bin/sh as /bin/sh, this allows >boot-up to use Bourne shell, yet I can set the shell in the login to Korn History file shows nothing out of the ordinary. >: they don't support [SCO Xenix SDS] under SCO UNIX!) >I still run the Xenix compiler to compile a certain 286 program. Possible to >do with shell scripts and setroot. Otherwise I use the ODT development >system, or assorted and sundry DOS compilers as needed. I'm attempting to run SCO Xenix SDS (licensed for this system) only because I've not been able to obtain the UNIX/ODT Development system. I question how SCO can promote binary compatibility between the Xenix and UNIX environments when they won't even support one of their own packages across such an environment. Appreciate the input and suggestions.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/05/90)
In article <43@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: | - Corruption of some critical files if I change the default root | shell from Bourne to Cshell That can cause trouble with many systems. I have a Korn shell login which lets me do stuff, but the default for root is sh. | - Bootup problems after power loss when Korn Shell has been | substituted for /bin/sh (We're still working to narrow this | problem down) I strongly suggest not doing that. There are just enough thing which aren't quite the same to bite you. Change the default for users, have a ksh or csh superuser login, but don't cause yourself trouble. | | - Custom will not load Xenix/386 Software Dvlpmt (and SCO says | they don't support it under SCO UNIX!) This can be done by hand, but I don't have my notes on it here. Offhand why do you want to run the Xenix DS (other than you paid an arm and a leg for it). -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me