rjg@umnstat.uucp (Robert J. Granvin) (02/01/91)
DEC has talked a bit about Ultrix 4.2. At the Usenix BOF on Ultrix, the phrase "Ultrix 4.2" was used commonly. In un-organized discussions, anywhere, Ultrix 4.2 was bandied about exclusively. Simple question: What's the timeframe on Ultrix 4.2? (Will it also be released similarly to 4.1, full install, followed later by a method to update previous versions...?) As we're considering skipping 4.1 and just wait for 4.2, I'm trying to get a handle on how long it will be necessary to wait... :-) Robert J. Granvin E/Mail: rjg@umnstat.stat.umn.edu User Services Specialist AT&T: +1 612 625 9224 School of Statistics University of Minnesota
fnddr@acad3.alaska.edu (Rice Don D) (02/02/91)
In article <1991Jan31.222728.26557@cs.umn.edu>, rjg@umnstat.uucp (Robert J. Granvin) writes... > ... >Simple question: What's the timeframe on Ultrix 4.2? (Will it also be >released similarly to 4.1, full install, followed later by a method to >update previous versions...?) Is there a shortcut to go from 4.0 to 4.1 without doing a full install? I upgraded a 3.1 system to 4.1 by doing the full install, and it was sufficiently laborious that I really don't want to go through it again on our 4.0 systems. I called DEC tech support to see if there was a special upgrade path, and the answer was an uncertain-sounding I-don't-think-so. Part of the problem is that the installation guides for our 4.1 tapes either weren't supplied or were promptly lost. So far I haven't had any luck getting the part numbers for all of them from DEC so I can order a set. Anyone know what they are? I presume there are basic, advanced, and mandatory upgrade manuals as in 4.0. > >As we're considering skipping 4.1 and just wait for 4.2, I'm trying to >get a handle on how long it will be necessary to wait... :-) > If it takes 4 hours to go from 4.0 to 4.1 as it did to upgrade from 3.1, I'd be inclined to wait. I am tempted, though, by the new product announcements for Ultrix 4.1 C and Fortran. It would be nice to know if 4.2 is due this spring or this summer, or this fall, or next year... One thing that would speed up the upgrade is if the installation process wouldn't newfs all of the file systems it sees, making it necessary to restore all the user files. But unless there is some trick to bypass it in advanced installation, I don't see how to avoid it. Don Rice Internet: ddr@flux.gi.alaska.edu Geophysical Institute E-mail: fnddr@alaska.bitnet University of Alaska Phone: (907) 474-7569 Fairbanks, AK 99775 Loran: 64.86N 212.16E
brian@cimage.com (Brian Kelley) (02/07/91)
In article <1991Feb1.195843.28684@ims.alaska.edu> fnddr@acad3.alaska.edu writes: >One thing that would speed up the upgrade is if the installation process >wouldn't newfs all of the file systems it sees, making it necessary to restore >all the user files. But unless there is some trick to bypass it in advanced >installation, I don't see how to avoid it. I did the upgrade from 4.0 to 4.1 a couple of weeks ago. The machine was a system 5400 with three ra type disks. Disk 0 had all of our system on it, disk 1 had swap and user files and disk 2 just had user files. My user partitions were _not_ newfs'd. I did the advanced install. Reading the installation notes (actually, I believe it may have been in the early portion of the basic installation guide), I recall reading that only system partitions would be re-made. I backed up everything anyway, of course. However, if you are going from a pre-4.0 release, it could be different. I'm not aware of any filesystem changes that occurred which would require them to be newfs'd (ala SunOS 4.0.3 -> 4.1), but then again, I don't have any experience with pre-4.0 Ultrix. >Don Rice Internet: ddr@flux.gi.alaska.edu >Geophysical Institute E-mail: fnddr@alaska.bitnet >University of Alaska Phone: (907) 474-7569 >Fairbanks, AK 99775 Loran: 64.86N 212.16E --- brian@cimage.com
glenn@herald.usask.ca (Glenn Hollinger) (02/28/91)
From article <1991Jan31.222728.26557@cs.umn.edu>, by rjg@umnstat.uucp (Robert J. Granvin): > Simple question: What's the timeframe on Ultrix 4.2? (Will it also be > released similarly to 4.1, full install, followed later by a method to > update previous versions...?) I have no information on Ultrix 4.2, but we are still waiting for the Ultrix 4.1 update-only, some many months after the release of Ultrix 4.1 full install. I have learned to never trust a DEC release date, even one as widely publicized as the 45 day time. Glenn Hollinger, glenn@herald.usask.ca University of Saskatchewan, Saskatchewan, Canada.
rjg@umnstat.uucp (Robert J. Granvin) (03/01/91)
In article <1991Feb28.043948.16370@herald.usask.ca> glenn@herald.usask.ca (Glenn Hollinger) writes: |From article <1991Jan31.222728.26557@cs.umn.edu>, by rjg@umnstat.uucp (Robert J. Granvin): |> Simple question: What's the timeframe on Ultrix 4.2? (Will it also be |> released similarly to 4.1, full install, followed later by a method to |> update previous versions...?) | |I have no information on Ultrix 4.2, but we are still waiting for |the Ultrix 4.1 update-only, some many months after the release of |Ultrix 4.1 full install. I have learned to never trust a DEC |release date, even one as widely publicized as the 45 day time. Personally, I'm still trying to get answers to either of those delivery date estimate questions. What I seem to be finding is that I can get a lot of discussion about things until I ask "when?" :-) So, a second call for release estimates: What's the approximate, hopeful, if all goes really really well, estimated quarter of release for Ultrix 4.2? Is there any estimates set for it at all? Robert J. Granvin E/Mail: rjg@umnstat.stat.umn.edu User Services Specialist AT&T: +1 612 625 9224 School of Statistics University of Minnesota
bird@sevior.physics.ubc.ca (Tony Ambardar) (05/31/91)
Could someone in the know please tell me what some of the improvements of 4.2 are over earlier versions? In particular, does dbx work with fortran now? Please send any e-mail to bird@triumfcl.bitnet Thanks.
mbelshe@gauss.elee.calpoly.edu (Mike Belshe) (06/04/91)
Anybody know when Ultrix 4.2 is going to be officially released? Thanks -- Mike Belshe mbelshe@gauss.elee.calpoly.edu EL/EE System Administrator Cal Poly San Luis Obispo
ajc@thendara.pa.dec.com (AJ Casamento) (06/04/91)
Mike Belshe writes: >> Anybody know when Ultrix 4.2 is going to be officially released? Ultrix v4.2 has made First Customer Ship as of last week (according to the Ultrix Product Management group). You should contact your local office to find out the status of your standard Update kit. thanx, AJ ********************************************************************** * AJ Casamento "The question is not whether or * * Digital's TRI/ADD Program not the opinions are mine; but * * 100 Hamilton Ave. UCO1-B rather, which of my personalities * * Palo Alto, CA 94301-1616 do they belong to?" * * 415.853.6744 * * ajc@decwrl.dec.com * **********************************************************************
avolio@decuac.dec.com (Frederick M. Avolio) (06/04/91)
In article <AJC.91Jun3174908@thendara.pa.dec.com> ajc@thendara.pa.dec.com (AJ Casamento) writes: > > Ultrix v4.2 has made First Customer Ship as of last week (according to > the Ultrix Product Management group). You should contact your local office > to find out the status of your standard Update kit. No you should not. The kits started shipping on Friday, two business days ago. What you should do is wait a bit. They don't *ALL* go out the very first hour. If you don't see 4.2 show up in a week or so, have it checked out. But it isn't late yet. (And I hate to see the word "Update" used... someone might think that it is an Update installation... which it is not....) Fred
grr@cbmvax.commodore.com (George Robbins) (06/04/91)
In article <1991Jun04.030107.25038@decuac.dec.com> avolio@decuac.dec.com writes: > In article <AJC.91Jun3174908@thendara.pa.dec.com> ajc@thendara.pa.dec.com (AJ Casamento) writes: > > > > Ultrix v4.2 has made First Customer Ship as of last week (according to > > the Ultrix Product Management group). You should contact your local office > > to find out the status of your standard Update kit. > > No you should not. The kits started shipping on Friday, two business > days ago. What you should do is wait a bit. They don't *ALL* go out > the very first hour. If you don't see 4.2 show up in a week or so, > have it checked out. But it isn't late yet. How long does it actually take service an Ultrix "upgrade"? Do the kits all go out withing a week or so; or does it take a month or two to work down to the Z's? I've always wondered... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
avolio@decuac.DEC.COM (Frederick M. Avolio) (06/04/91)
I have no direct knowledge. practical experience tells me that everyone should get their kits within 2 weeks (and most in the first week). Field Test customers and Contract customers get shipments first, usually. Then all others.
sfleming@cs.hw.ac.uk (Stewart Fleming) (06/05/91)
Re : delivery dates for Ultrix. We received a tape set for Ultrix 4.1 last Friday. The release date was when ? February ? Actually, we received an Ultrix 4.0 tape set the day afterwards, but that's another story. 2 weeks ? Don't make me laugh. STF ps Not a flame against DEC in general, just a particular service site... -- sfleming@cs.hw.ac.uk ...ukc!cs.hw.ac.uk!sfleming "There is always a thunderstorm going on, somewhere."
mra@searchtech.com (Michael Almond) (06/05/91)
In article <1991Jun3.233336.8356@petunia.CalPoly.EDU> mbelshe@gauss.elee.calpoly.edu (Mike Belshe) writes: > >Anybody know when Ultrix 4.2 is going to be officially released? We just got our 4.2 tape in the mail yesterday, June 4. -- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. mra@searchtech.com 4725 peachtree corners cir., suite 200 uupsi!srchtec!mra norcross, georgia 30092 (404) 441-1457 (office)
schemers@vela.acs.oakland.edu (Roland Schemers III) (06/06/91)
We just received the Ultrix 4.2 tapes (both RISC and VAX) and they are MAJOR installs. Is there an 'upgrade' tape coming out to upgrade exist 4.1 systems to 4.2? (like there was for 4.0 to 4.1). Also, has anyone run into any problems with the intall or 4.2 yet? Thanks! Roland -- Roland J. Schemers III Systems/Network Manager schemers@vela.acs.oakland.edu (Ultrix) Oakland University schemers@argo.acs.oakland.edu (VMS) Rochester, MI 48309-4401 OU in Michigan! Say it slow: M-i-c-h-i-g-a-n (313)-370-4323
yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) (06/06/91)
In article <1991Jun04.030107.25038@decuac.dec.com> avolio@decuac.dec.com writes: >In article <AJC.91Jun3174908@thendara.pa.dec.com> ajc@thendara.pa.dec.com (AJ Casamento) writes: >> >> Ultrix v4.2 has made First Customer Ship as of last week (according to >> the Ultrix Product Management group). You should contact your local office >> to find out the status of your standard Update kit. > >(And I hate to see the word "Update" used... someone might think that >it is an Update installation... which it is not....) Yeah! But I wish it *were* an update! I want an update! Do you know how much man-days we are going to spend to install 4.2 on all our machines?? Grrrrrrrrrr!!!!!!! -- Philip Yzarn de Louraille Internet: yzarn@chevron.com Research Support Division Unix & Open Systems Chevron Information & Technology Co. Tel: (213) 694-9232 P.O. Box 446, La Habra, CA 90633-0446 Fax: (213) 694-7709
mark@loki.une.oz.au (Mark Garrett) (06/07/91)
From article <933@lhdsy1.chevron.com>, by yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille): > In article <1991Jun04.030107.25038@decuac.dec.com> avolio@decuac.dec.com writes: >>In article <AJC.91Jun3174908@thendara.pa.dec.com> ajc@thendara.pa.dec.com (AJ Casamento) writes: > > Yeah! But I wish it *were* an update! I want an update! Do you know how > much man-days we are going to spend to install 4.2 on all our machines?? > Grrrrrrrrrr!!!!!!! > Can anybody tell me whats so good about 4.2 that I should upgrade. I have 4.1 running quite nicely. It will take quite a lot of time to get things back to normal after an upgrade! WHY SHOULD WE ? PS. my plans were to what for Ultrix 5.0 which I believe is the OSF . -- Mark Garrett Internet: mark@loki.une.edu.au Phone: +61 (066) 20 3859 University of NewEngland, Northern Rivers, Lismore NSW Australia.
grr@cbmvax.commodore.com (George Robbins) (06/07/91)
In article <1560@loki.une.oz.au> mark@loki.une.oz.au (Mark Garrett) writes: > From article <933@lhdsy1.chevron.com>, by yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille): > > In article <1991Jun04.030107.25038@decuac.dec.com> avolio@decuac.dec.com writes: > >>In article <AJC.91Jun3174908@thendara.pa.dec.com> ajc@thendara.pa.dec.com (AJ Casamento) writes: > > > > Yeah! But I wish it *were* an update! I want an update! Do you know how > > much man-days we are going to spend to install 4.2 on all our machines?? > > Grrrrrrrrrr!!!!!!! > > > Can anybody tell me whats so good about 4.2 that I should upgrade. > I have 4.1 running quite nicely. It will take quite a lot of time to get things > back to normal after an upgrade! Well, see Appendix B of the release notes. If you're really happy with 4.1 then there is probably minimal reason to upgrade, with the most notable improvements being (finally) the current MIPS C-compiler and X11R4 based servers. On the other hand, if you're like me and still running 3.1C and waiting/hoping for a more gain than pain 4.X release then 4.2 looks pretty decent. Overall, after scanning the release notes, it looks like a pretty nice release. Some of the ancient bugs fixed, new hardware support, new facilities and some rough edges trimmed off of the 4.x features. It even looks liked they fixed the > 8 groups NFS bug! -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
dbgwab@edp130edp.arco.com (Bill Bailey) (06/11/91)
You asked why you should upgrade from 4.1 to 4.2... I personally encountered numerous problems with 4.1 and DS5000 systems. If you don't have any 5000s then you "might" be ok. I wouldn't RISC it though... -- Bill Bailey <dbgwab@arco.com> Voice : (214) 754-6779
archerb@kuhub.cc.ukans.edu (06/13/91)
I was so disappointed that Xtm and Xtm2d aren't X11R4 in 4.2 I forgot
to mention that I do find 4.2 to be a nice improvement. And I too
found the installation from CD ROM to be less of a hassle.
One last thing on X11R4 and 4.2 - I was assuming that Motif 1.1 would
provide a X11R4 session manager on the PX/PXG displays. If it will I *might*
have a shot at getting my boss to go for it. But I'd like to be sure before
making my pitch...I do not have the time to try and build the MIT code...
:-(
Barry
archerb@gawain.umkc.edu
archerb@kuhub.cc.ukans.edumattf@cac.washington.edu (Matthew Freedman) (06/14/91)
In article <1991Jun13.140545.31423@kuhub.cc.ukans.edu> archerb@kuhub.cc.ukans.edu writes: > > I was so disappointed that Xtm and Xtm2d aren't X11R4 in 4.2 I forgot >to mention that I do find 4.2 to be a nice improvement. And I too >found the installation from CD ROM to be less of a hassle. Are you *sure* that the new Xtm and Xtm2d are not R4? After I saw your first post, I asked a DEC support person about this, and he assured me that all the servers are now R4 based. He also said that the new Xtm solves the problem with the incredibly, embarassingly, bad performance of Xtm with images. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = Matthew M. Freedman = = U. of Washington Information Systems mattf@cac.washington.edu = = 4545 15th Ave. NE; 4th Floor (206) 543-5593 = = Seattle, WA 98105 = -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
archerb@kuhub.cc.ukans.edu (06/14/91)
In article <1991Jun13.203055.16375@milton.u.washington.edu>, mattf@cac.washington.edu (Matthew Freedman) writes: > In article <1991Jun13.140545.31423@kuhub.cc.ukans.edu> archerb@kuhub.cc.ukans.edu writes: >> >> I was so disappointed that Xtm and Xtm2d aren't X11R4 in 4.2 I forgot >>to mention that I do find 4.2 to be a nice improvement. And I too >>found the installation from CD ROM to be less of a hassle. > > Are you *sure* that the new Xtm and Xtm2d are not R4? After I saw your > first post, I asked a DEC support person about this, and he assured me > that all the servers are now R4 based. He also said that the new Xtm > solves the problem with the incredibly, embarassingly, bad performance of > Xtm with images. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > = Matthew M. Freedman = > = U. of Washington Information Systems mattf@cac.washington.edu = > = 4545 15th Ave. NE; 4th Floor (206) 543-5593 = > = Seattle, WA 98105 = > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Both the release notes for 4.2 and replies to me from DEC people state that the PX and PXG graphics are not supported currently with X11R4 servers. The X11R4 versions are apparantly in alpha test. The libraries and everything else is X11R4 compliant. Since Digital Review indicates that when to switch over to DECwindows/Motif for Ultrix is under discussion at DEC, I'll throw my $.02 worth in and ask that it be sooner rather than later...why wait? Barry Archer archerb@gawain.umkc.edu archerb@kuhub.cc.ukans.edu
avolio@decuac.DEC.COM (Frederick M. Avolio) (06/14/91)
In article <1991Jun13.203055.16375@milton.u.washington.edu>, mattf@cac.washington.edu (Matthew Freedman) writes: |>Are you *sure* that the new Xtm and Xtm2d are not R4? After I saw your |>first post, I asked a DEC support person about this, and he assured me |>that all the servers are now R4 based. ... He was mistaken. According tothe UWS V4.2 Software Product Description (SPD), only the servers for color frame buffers are X11R4. To be specific: Workstation and graphics Server Base Extensions DS5000 CX and MX Xws X11R4 Shape, DPS DS5000 PX Xtm2d X11R3 DPS, DS5000 PXG, PXG Turbo Xtm X11R3 DPS, PEX DS3100 mono and 8 plane color Xws X11R4 Shape, DPS DS2100 mono and 8 plane color Xws X11R4 Shape, DPS
mra@searchtech.com (Michael Almond) (06/17/91)
In article <1991Jun13.140545.31423@kuhub.cc.ukans.edu> archerb@kuhub.cc.ukans.edu writes: >...I do not have the time to try and build the MIT code... Maybe we could put the binaries up on the net somewhere. I've have the MIT code installed here. -- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. mra@searchtech.com 4725 peachtree corners cir., suite 200 uupsi!srchtec!mra norcross, georgia 30092 (404) 441-1457 (office)
envbvs@epb7.lbl.gov (Brian V. Smith) (06/18/91)
|> Maybe we could put the binaries up on the net somewhere. I've have the MIT |> code installed here. In reading the "Ultrix and UWS Release Notes", on page 4-11, it says (and I quote): "The graphics driver structure has changed such that it is no longer possible to build or run the MIT X11 Release 4 sample server. Because of driver structure changes, header files needed to build the MIT X11 Release 4 sample server no longer exist. Instead, use the servers providev by Digital." It goes on to say that after "final submission of this product Digital will provide the MIT release with the information and code needed to build MIT servers with this version of ULTRIX Worksystem Software." Whats the scoop here? Is it really not possible to buld the MIT server for Ultrix 4.2? -- Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL; they don't pay me enough for that.
mellon@nigiri.pa.dec.com (Ted Lemon) (06/19/91)
>Whats the scoop here? Is it really not possible to buld the MIT server >for Ultrix 4.2? Anything is possible. However, it won't build trivially. You'd probably have to be a pretty moby X server hacker to get it all working with all the changes that have been made in Ultrix since X11R4 came out. I believe that our changes will have been merged back in by the time R5 comes out (but the X Consortium would have better information on that, since they're the ones doing the release). In the meantime, the servers for the DECstation [23]100, the Colour Frame Buffer on the 5000, and the Monochrome Frame Buffer on the 5000, are X11R4 servers, so the only reason for building the MIT server is to get rid of the huge, clunky and useless Display Postscript extension. (Ooh, I'm going to get flamed for this! :') If you make sure not to use DPS, it should just stay swapped out anyway, so it doesn't seem to be worth the extra effort to build a special server without it. Plus, the MIT server doesn't do multiscreen. _MelloN_
lutmann@geocub.UUCP (Patrice LUTMANN) (06/19/91)
n article <14411@dog.ee.lbl.gov> envbvs@epb7.lbl.gov (Brian V. Smith) writes:
:"The graphics driver structure has changed such that it is no longer possible
:to build or run the MIT X11 Release 4 sample server. Because of driver
:structure changes, header files needed to build the MIT X11 Release 4 sample
:server no longer exist. Instead, use the servers providev by Digital."
Is it because the MIT sample server is more efficient?
Is it because the MIT sample server is less buggy?
Or is it because DEC does not care about us? What a cheek!
S H A M E
[Pat]jarrell@vtserf.cc.vt.edu (Ron Jarrell) (06/20/91)
Maybe it's because they feel they have an obligation to their customers to make the stuff that they BOUGHT work, i.e. DECwindows, and have a lower obligation to arrange their system so that public domain software that people may or may not have access to, or the inclination/ability to use works? -- Ron Jarrell Virginia Tech Computing Center jarrell@vtserf.cc.vt.edu
gringort@wsl.dec.com (Joel Gringorten) (06/20/91)
In article <3459@geocub.UUCP>, lutmann@geocub.UUCP (Patrice LUTMANN) writes: |> n article <14411@dog.ee.lbl.gov> envbvs@epb7.lbl.gov (Brian V. Smith) writes: |> :"The graphics driver structure has changed such that it is no longer possible |> :to build or run the MIT X11 Release 4 sample server. Because of driver |> :structure changes, header files needed to build the MIT X11 Release 4 sample |> :server no longer exist. Instead, use the servers providev by Digital." |> |> Is it because the MIT sample server is more efficient? |> Is it because the MIT sample server is less buggy? |> Or is it because DEC does not care about us? What a cheek! |> |> |> S H A M E |> |> [Pat] Shame yourself. Evidently you missed Ted Lemon's very complete followup to this article I'll include it below just for your benefit. The bottom line is that the server/driver interface was completely redesigned for Ultrix 4.2 for multiscreen workstations. The changes were given to MIT and will appear in MIT R5. Digital is one of the first companies to release multiscreen workstations (perhaps *the* first?) We're proud of this work and it's being received quite well by our customers. Digital and MIT don't synchronize their software releases for obvious reasons. Therefore, interface changes cause incompatibilities for a while until things get synched up. What would you do differently? -joel -------------------------------------------------------------------------- Newsgroups: comp.unix.ultrix Path: pa.dec.com!granite.pa.dec.com!mellon From: mellon@nigiri.pa.dec.com (Ted Lemon) Subject: Re: Ultrix 4.2 In-Reply-To: envbvs@epb7.lbl.gov's message of 18 Jun 91 16:41:08 GMT Message-ID: <MELLON.91Jun18142804@nigiri.pa.dec.com> Sender: news@pa.dec.com (News) Organization: Digital Equipment Corporation References: <1991Jun13.140545.31423@kuhub.cc.ukans.edu> Date: 18 Jun 91 14:28:04 Lines: 21 >Whats the scoop here? Is it really not possible to buld the MIT server >for Ultrix 4.2? Anything is possible. However, it won't build trivially. You'd probably have to be a pretty moby X server hacker to get it all working with all the changes that have been made in Ultrix since X11R4 came out. I believe that our changes will have been merged back in by the time R5 comes out (but the X Consortium would have better information on that, since they're the ones doing the release). In the meantime, the servers for the DECstation [23]100, the Colour Frame Buffer on the 5000, and the Monochrome Frame Buffer on the 5000, are X11R4 servers, so the only reason for building the MIT server is to get rid of the huge, clunky and useless Display Postscript extension. (Ooh, I'm going to get flamed for this! :') If you make sure not to use DPS, it should just stay swapped out anyway, so it doesn't seem to be worth the extra effort to build a special server without it. Plus, the MIT server doesn't do multiscreen. _MelloN_
mellon@nigiri.pa.dec.com (Ted Lemon) (06/20/91)
In article <3459@geocub.UUCP>, lutmann@geocub.UUCP (Patrice LUTMANN) writes: |> Is it because the MIT sample server is more efficient? |> Is it because the MIT sample server is less buggy? |> Or is it because DEC does not care about us? What a cheek! And in article <1991Jun19.105814@wsl.dec.com>, Joel Gringorten writes: |The bottom line is that the server/driver interface was completely |redesigned for Ultrix 4.2 for multiscreen workstations. The changes were |given to MIT and will appear in MIT R5. Digital is one of the first |companies to release multiscreen workstations (perhaps *the* first?) |We're proud of this work and it's being received quite well by our |customers. In addition to the above work that Joel mentions, allow me to point out that a lot of the colour speedups in the R4 servers came from Digital, and a lot of the code in the R4 release either came from Digital, was worked on at Digital, or was funded by Digital. There are a lot of things in our product offering that we'd like to improve on. I'm sure you've run into one or two of them. However, your assertion that we don't care about our customers is completely untrue. Circumstances sometimes prevent us from releasing the latest Consortium code in sync with our code, and circumstances sometimes prevent the Consortium from releasing our latest contributions when we make them, but this is indicative of different release schedules, not a lack of desire to make things right for the customer. If we didn't care about the customer, we wouldn't be reading this newsgroup. _MelloN_
yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) (06/20/91)
In article <MELLON.91Jun18142804@nigiri.pa.dec.com> mellon@nigiri.pa.dec.com (Ted Lemon) writes: > >without it. Plus, the MIT server doesn't do multiscreen. C'mon! Do you think the DEC server does multi-screen? It really does not, it emulates multi-screen! You need to run a window manager per screen you are using and you cannot move a window from one window to another. I do not call this a multi-screen server, not by a long shot, especially after seeing a *real* multi-screen machine like the Mac. -- Philip Yzarn de Louraille Internet: yzarn@chevron.com Research Support Division Unix & Open Systems Chevron Information & Technology Co. Tel: (213) 694-9232 P.O. Box 446, La Habra, CA 90633-0446 Fax: (213) 694-7709
klee@wsl.dec.com (Ken Lee) (06/20/91)
In article <984@lhdsy1.chevron.com>, yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: |> C'mon! Do you think the DEC server does multi-screen? It really does |> not, it emulates multi-screen! |> You need to run a window manager per screen you are using and you cannot |> move a window from one window to another. Many window managers can handle multiple screens. Motif mwm is an example. The X Window System specifications do not permit windows to be moved across screens. The DEC servers do not add additional restrictions. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
jg@crl.dec.com (Jim Gettys) (06/20/91)
And it is clear people don't read.... I've posted on this topic many times over the last six months... I said I'd package up the new driver interface routines, and I will; this should happen next week, and I'll make an announcement. I should have done this by now, but I got busy, and have been out of the country for the last week, and won't be able to get to it until early next week. In the meanwhile, I don't think you'll have many complaints about our servers... - Jim Gettys Digital Equipment Corporation Cambridge Research Lab.
mellon@nigiri.pa.dec.com (Ted Lemon) (06/20/91)
In article <984@lhdsy1.chevron.com> yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: >In article <MELLON.91Jun18142804@nigiri.pa.dec.com> mellon@nigiri.pa.dec.com (Ted Lemon) writes: >> >>without it. Plus, the MIT server doesn't do multiscreen. > C'mon! Do you think the DEC server does multi-screen? It really does > not, it emulates multi-screen! > You need to run a window manager per screen you are using and you cannot > move a window from one window to another. I do not call this a > multi-screen server, not by a long shot, especially after seeing a > *real* multi-screen machine like the Mac. Actually, no. Twm, mwm and dxwm all support multi-screen displays. The reason you can't move windows from screen to screen is because the screens are considered distinct by the X protocol - an application can't be told through the X protocol that it should free all its resources and reallocate them on a new screen, and there's no clean way to do that freeing and reallocation process anyway. It would be possible to implement an X server that considered multiple physical screens to be the same virtual screen, but there are problems with this. For one thing, in order to avoid violating the X protocol specification, you would have to make the colormaps on both screens identical. This would mean that an application on one screen changing the colormap would affect applications on the other screen. Another problem is that you can theoretically support frame buffers with different depths, and the X protocol doesn't define any way to say that a certain portion of a screen is monochrome, while another portion is colour. That said, I agree that it would be nice to have the choice between the current implementation and some version of the implementation that I described above, where you are constrained to using frame buffers of the same depth, and where such frame buffers have their colour tables kept in sync. I had heard at one point that an MIT grad student was hacking such a server, but I haven't heard anything about it for quite some time. Finally, this doesn't seem like a good excuse for DEC-bashing. At least we support the form of multiscreen that the X protocol is most receptive to. Many of our competitors do not. The current X Consortium release does not. If you want to bash DEC, I'm sure you can come up with something much more compelling - plenty of other people on this newsgroup have been successful at it in the past. :') _MelloN_
avolio@decuac.dec.com (Frederick M. Avolio) (06/20/91)
Soooooooooo what about those Orioles? :-)
yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) (06/21/91)
In article <1991Jun19.145218@wsl.dec.com> klee@wsl.dec.com writes: >In article <984@lhdsy1.chevron.com>, yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: >|> C'mon! Do you think the DEC server does multi-screen? It really does >|> not, it emulates multi-screen! >|> You need to run a window manager per screen you are using and you cannot >|> move a window from one window to another. > >The X Window System specifications do not permit windows to be moved >across screens. The DEC servers do not add additional restrictions. I stand corrected. But who wrote such simplistic requirements for the X Server????? -- Philip Yzarn de Louraille Internet: yzarn@chevron.com Research Support Division Unix & Open Systems Chevron Information & Technology Co. Tel: (213) 694-9232 P.O. Box 446, La Habra, CA 90633-0446 Fax: (213) 694-7709
jg@crl.dec.com (Jim Gettys) (06/21/91)
In article <987@lhdsy1.chevron.com>, yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: > In article <1991Jun19.145218@wsl.dec.com> klee@wsl.dec.com writes: > >In article <984@lhdsy1.chevron.com>, yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: > >|> C'mon! Do you think the DEC server does multi-screen? It really does > >|> not, it emulates multi-screen! > >|> You need to run a window manager per screen you are using and you cannot > >|> move a window from one window to another. > > > >The X Window System specifications do not permit windows to be moved > >across screens. The DEC servers do not add additional restrictions. > > I stand corrected. But who wrote such simplistic requirements for the X > Server????? All of us did; as to who the guilty are, see the X protocol acknowledgements. The general problem is VERY hard. Think about the case of a one bit monochrome display, and a 32 bit double buffered 3D display with geometry pipe hardware. After taking 4 tylenol, come back and ask again if you think you need to. Requiring this in the core protocol seems like asking for the almost impossible (unless you posit that you don't support both screen types, which we couldn't). This is not to say one can't implement a server that would make several homogenous frame buffers look by one screen, or add an extension to allow windows to be moved between screens under appropriate circumstances. But we haven't gotten around to doing so (at least yet). - Jim
reha@cunixf.cc.columbia.edu (Reha Elci) (06/21/91)
In article <3459@geocub.UUCP>, lutmann@geocub.UUCP (Patrice LUTMANN) writes: >|> Is it because the MIT sample server is more efficient? >|> Is it because the MIT sample server is less buggy? >|> Or is it because DEC does not care about us? What a cheek! FLAME ON!! What is this anal retentive wish to build the MIT server anyway?? DEC's servers are faster, more reliable, and supported!!!! Extensions like DPS & PEX are supported and avaliable which the public domain stuff does not have and not likely to have working for quite some time!! On top of all that you have working multi-head support. With the extensions they have out in field test which are very close to production, the servers are so far ahead of anything else that its ridiculous to insist on the public domain stuff. I also do not agree with the guy from DEC who dismissed DPS as useless! Here is finally an extension that brings the obsolete bitmap & pixel based X architecture to modern day standards and he dismisses it as clunky & useless. What is wrong with you people?? FLAME OFF......
ggm@brolga.cc.uq.oz.au (George Michaelson) (06/21/91)
reha@cunixf.cc.columbia.edu (Reha Elci) writes: >I also do not agree with the guy from DEC who dismissed DPS as useless! >Here is finally an extension that brings the obsolete bitmap & pixel based X >architecture to modern day standards and he dismisses it as clunky & useless. >What is wrong with you people?? DPS is sweet, but really really costly on memory to run. If you fire up one instance of cda or dxpsview and play around, your X server grows very significantly. Cheapskates like me who have acquired workstations on university discounts and now try to use them to support multi-user applications, or tasks better suited to DECsystems (which are (surprise surprise) not being discounted nearly so heavily) find Xgrowth is a problem. I run 1 application semi- continuously that has to be over 15Mb big. if X is getting upto 4Mb big, and I'm swapping between the two, and the kernel steals 2Mb and I have a coupla dozen windows/icons open I start to swap. DEC MIPS boxes are fine but swapping kills anything. The box (3100) takes 24Mb and thats the limit. I have already blown that away a couple of times (try running dbx over the 15Mb image and xdbx in front of that...) But to return to context, If I have any complaint about Ultrix 4.2 it's the need to mung standard X11 clients Imakefiles to get them to compile. I bet more of us build stuff that needs -I/usr/include/mit than would have suffered from DEC making the DECplications like dx* have to do -I/usr/include/DEC-X11 to make cleanly. I still don't have a finalized site.def and ultrix.def which fixes this. anyone have one? -George -- George Michaelson G.Michaelson@cc.uq.oz.au The Prentice Centre | There's no market for University of Queensland | hippos in Philadelphia Phone: +61 7 365 4079 QLD Australia 4072 | -Bertold Brecht
grunwald@foobar.colorado.edu (Dirk Grunwald) (06/21/91)
I concurr with your opinion DPS -- I find it very useful, but I have to admit that I often use ghostscript, because it doesn't swell my server so much. In some ways, I had hoped that DPS would run as a distinct process/layer that programs would invoke, and that it would then be usable on e.g., X terminals connected to your DECstation.
grr@cbmvax.commodore.com (George Robbins) (06/21/91)
In article <987@lhdsy1.chevron.com> yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: > In article <1991Jun19.145218@wsl.dec.com> klee@wsl.dec.com writes: > >In article <984@lhdsy1.chevron.com>, yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: > >|> C'mon! Do you think the DEC server does multi-screen? It really does > >|> not, it emulates multi-screen! > >|> You need to run a window manager per screen you are using and you cannot > >|> move a window from one window to another. > > > >The X Window System specifications do not permit windows to be moved > >across screens. The DEC servers do not add additional restrictions. > > I stand corrected. But who wrote such simplistic requirements for the X > Server????? A bunch of clever people trying very hard to build a usable window system. Please remember that the Mac multi-screen support is something of a jonny- come-lately. Maybe they had the advantage of seeing what X could do before designing their multi-screen support, maybe their underlying software architecture lent itself to it whereas X's didn't. Don't let a single feature determine your view of the overall system. [ BTW, I consider X to be a colossal joke grafted onto unix that is about 180 degrees away from the software engineeering goals expressed by the early unix developers, but that doesn't stop me from using it and demanding that graphics applications be X based. 8-) ] -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) (06/24/91)
In article <1991Jun20.224006.25645@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes: ...deleted stuff... >The general problem is VERY hard. Think about the case of a one bit monochrome >display, and a 32 bit double buffered 3D display with geometry pipe hardware. >After taking 4 tylenol, come back and ask again if you think you need to. > >Requiring this in the core protocol seems like asking for the almost impossible >(unless you posit that you don't support both screen types, which we couldn't). > >This is not to say one can't implement a server that would make several homogenous >frame buffers look by one screen, or add an extension to allow windows to be moved >between screens under appropriate circumstances. But we haven't gotten around >to doing so (at least yet). Apple has... (well, I'm not sure about the 32 bit double buffered 3D display with geometry pipe hardware, but because there are very hard cases does not mean that simpler ones cannot be implemented, especially if a vendor already has such software technology already out on the market.) I am disappointed on the X server specs, and I am also disappointed by the speed (or lack of) it takes DEC to release the X11r4 servers. The specs for release 5 will be out soon, I guess we will see DEC release the X11r5 servers in 1993-4? I also agree that some hardware situations might be *very hard* to code. But is that a reason for releasing simple minded specs? I think not. That it might take times to release servers that would do everything that the specs require is understandable, but one can always release code that does not do everything, as long as it is documented. -- Philip Yzarn de Louraille Internet: yzarn@chevron.com Research Support Division Unix & Open Systems Chevron Information & Technology Co. Tel: (213) 694-9232 P.O. Box 446, La Habra, CA 90633-0446 Fax: (213) 694-7709
yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) (06/24/91)
In article <1991Jun20.234113.12858@cunixf.cc.columbia.edu> reha@cunixf.cc.columbia.edu (Reha Elci) writes: >FLAME ON!! > ...deleted text... >working multi-head support. With the extensions they have out in field test >which are very close to production, the servers are so far ahead of >anything else that its ridiculous to insist on the public domain stuff. ...deleted text... >What is wrong with you people?? > >FLAME OFF...... Don't make me laugh. Also, are you testing these "servers that are so far ahead of anything else"? How do you know that they are really "very close to production"? Just because you started the FLAMES. It is not good to be an evangelist for a product still in field (beta, some users would say alpha) test, you could get your wings burnt. -- Philip Yzarn de Louraille Internet: yzarn@chevron.com Research Support Division Unix & Open Systems Chevron Information & Technology Co. Tel: (213) 694-9232 P.O. Box 446, La Habra, CA 90633-0446 Fax: (213) 694-7709
gnn@heisenberg.Berkeley.EDU (George Neville-Neil) (06/24/91)
In article <991@lhdsy1.chevron.com> yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: > >Apple has... (well, I'm not sure about the 32 bit double buffered 3D >display with geometry pipe hardware, but because there are very hard >cases does not mean that simpler ones cannot be implemented, especially >if a vendor already has such software technology already out on the >market.) Apple has only one hardware platform to worry about which they spec out themselves. Even taking third party boards into account Apple wrote the spec for how they would intereact with other components. The X system runs on a lot of dissimilar hardware, a feat that is of no little consequence. >I am disappointed on the X server specs, and I am also disappointed by >the speed (or lack of) it takes DEC to release the X11r4 servers. The >specs for release 5 will be out soon, I guess we will see DEC release >the X11r5 servers in 1993-4? Well, since X was written circ. 1983 and was written to be machine independant then one might expect to be dissapointed with a certain servers performance on a certain machine. Tuning an X server for a specific platform takes a considerable amount of work. Even if you get the server Just Right for a Dec 3100 w/monochrome that server will have to be tuned again when it is ported to a Dec 5000/200 w/color. Well, just a thought in defense X :-) Later, George -- George Neville-Neil Kinky is as kinky does. gnn@mammoth.berkeley.edu Life is like a sewer, you get out of it what you put into it. -- T. Lehrer
reha@cunixf.cc.columbia.edu (Reha Elci) (06/25/91)
In article <992@lhdsy1.chevron.com> yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: >Don't make me laugh. Also, are you testing these "servers that are >so far ahead of anything else"? How do you know that they are really >"very close to production"? I am using PRODUCTION servers at the moment (standard Ultrix 4.1) which have excellent implementations DPS & PEX. Just looking at that puts it ahead of anybody elses! There are ample number of calls in the protocol of dps & pex to allow you to see what has been implemented and not. Write a program to do this and get machines of any vendor to do the comparison and bring up program -display host:0. If you're very lucky, the vendor will have the extension; take a look at the what it implements & not... Reha Elci
trost@reed.edu (06/25/91)
What is this anal retentive wish to build the MIT server anyway??
DEC's servers are faster, more reliable, and supported!!!!
1) Because I'd rather run X, and not this "DECWindows" thing somebody
dreamed up. Occassionally we play with DECWindows a bit when we
install a new release of Ultrix. The server under Ultrix 4.0 was
either painting or scrolling both xterms and emacses improperly,
and every once in a while a moved window would leave behind an
immovable region. Sorta sounds like a violation of the spec to
me....
(I'd be interested to hear what people know about this problem, by
the way)
2) Because DEC decided to be obnoxiously cute with some of the
software. You disable the DIGITAL banner on the login screen by
setting the correct resource, and the session manager inserts a
sleep of several seconds before starting the user's session. I
don't need this kind of sleazy cruft.jg@crl.dec.com (Jim Gettys) (06/25/91)
In article <TROST.91Jun24174840@brahma.reed.edu>, trost@reed.edu writes: > > What is this anal retentive wish to build the MIT server anyway?? > DEC's servers are faster, more reliable, and supported!!!! > > 1) Because I'd rather run X, and not this "DECWindows" thing somebody > dreamed up. Occassionally we play with DECWindows a bit when we > install a new release of Ultrix. The server under Ultrix 4.0 was > either painting or scrolling both xterms and emacses improperly, > and every once in a while a moved window would leave behind an > immovable region. Sorta sounds like a violation of the spec to > me.... > > (I'd be interested to hear what people know about this problem, by > the way) DECwindows is only a name for the whole pile of software we provide, all based on X. What does running our X server have to do with DECwindows? You can run any/all or none of the applications we provide as you choose... You seem to be tying together things that are by design independent. 4.2 finally has R4 clients for the MIT apps; the stuff before was antique R3 clients with plenty of MIT bugs... I suspect that is what you were seeing with xterm; I never had any problems with R4 clients. As to the "immovable regions"; that sounds like an out and out server bug; did you report it? > > 2) Because DEC decided to be obnoxiously cute with some of the > software. You disable the DIGITAL banner on the login screen by > setting the correct resource, and the session manager inserts a > sleep of several seconds before starting the user's session. I > don't need this kind of sleazy cruft. You don't need to run the DECwindows session manager if you don't want to. I have no problems with running whatever you want; as I said before, I'll try to get the new driver interface bits together later this week (probably Friday); I'd like to confirm they still run under R4 (since they've been integrated for release as part of R5), and won't have the spare time for a few days. - Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory
archerb@kuhub.cc.ukans.edu (06/25/91)
In article <1991Jun25.122442.12089@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: > In article <TROST.91Jun24174840@brahma.reed.edu>, trost@reed.edu writes: >> >> What is this anal retentive wish to build the MIT server anyway?? >> DEC's servers are faster, more reliable, and supported!!!! >> >> 1) Because I'd rather run X, and not this "DECWindows" thing somebody >> dreamed up. Occassionally we play with DECWindows a bit when we >> install a new release of Ultrix. The server under Ultrix 4.0 was >> either painting or scrolling both xterms and emacses improperly, >> and every once in a while a moved window would leave behind an >> immovable region. Sorta sounds like a violation of the spec to >> me.... >> >> (I'd be interested to hear what people know about this problem, by >> the way) > > DECwindows is only a name for the whole pile of software we provide, > all based on X. > > What does running our X server have to do with DECwindows? You can run > any/all or none of the applications we provide as you choose... You seem > to be tying together things that are by design independent. > > 4.2 finally has R4 clients for the MIT apps; the stuff before was antique R3 > clients with plenty of MIT bugs... I suspect that is what you were seeing > with xterm; I never had any problems with R4 clients. As to the "immovable regions"; > that sounds like an out and out server bug; did you report it? > >> I have had few problems with the DECwindows session manager, except that we bought a DECstation largely to run some NCSA programs that are X11R4 and which don't appear to like the Xtm/Xtm2d servers which aren't X11R4 yet. If the UWS 4.2 pre-release info mentioned that, then I missed it. I would *love* a version of the Xtm or Xtm2d servers that we could use. > > You don't need to run the DECwindows session manager if you don't want to. > If I can find someone at DEC that will tell me if the Ultrix DECwindows/Motif servers will support the PX/PXG cards at X11R4, then we'll just go ahead and get the developers kit. I figure they probaby do, but my boss would like to hear someone say it - the DECDriect folks are nice, but I doubt they have the answer without asking you either. :-) After the past week or so, I do have a much better idea of some of the issues involved in getting everything working. > I have no problems with running whatever you want; as I said before, I'll > try to get the new driver interface bits together later this week (probably > Friday); I'd like to confirm they still run under R4 (since they've been > integrated for release as part of R5), and won't have the spare time for > a few days. > - Jim Gettys > Digital Equipment Corporation > Cambridge Research Laboratory I'd be happy to alpha/beta test out here, if that would help. Otherwise, I'll look forward to seeing it when its released. Barry Archer, UMKC Network whosit archerb@gawain.umkc.edu ! Ultrix archerb@vax1.umkc.edu ! VMS archerb@sgi.bls.umkc.edu ! IRIX archerb@kuhub.cc.ukans.edu ! guest of KU (816)-235-1187 ! voice (816)-235-1717 ! FAX University of Missouri - Kansas City 5100 Rockhill Road CH-2 Kansas City, MO 64110
alg@CS.Cornell.EDU (Anne Louise Gockel) (06/26/91)
Will MIT X11R4 servers built under Ultrix 4.1 continue to work under Ultrix 4.2? Can the MIT X11R4 libraries, client programs and window managers (everything but the server) still be built under Ultrix 4.2? We use the X11R4 distribution in order to maintain virtually identical environments for users and programmers among a number of different workstations. I have no desire to enter religious wars over the quality of any given server or distribution. Thanks in advance for any information. -Anne Louise Gockel Cornell Computer Science Internet: alg@cs.cornell.edu UUCP: cornell!alg