hege@abo.fi (01/12/91)
A few months ago there was an ad in misc.jobs.offered (I think) where Digital looked for people to develop a U*IX that was supposed to be "The U*IX of the 90's". In Digital Review (was it December 10, 1990?) the editor in chief rumoured something about U*IX/OSF-version from DEC within 6 months. Does anybody have any information about this? Cheers. -=HeGe=- ------------------------------------------------------------------------------ Kaj Haggman INTERNET : Hege@abo.fi ! "Music is VAX System Manager BITNET : Hege@finabo ! reversible, Abo Akademi University Decnet : ABOVAX::HEGE ! but time is Computing Center Phone : +358-21-654467 ! not" FINLAND Telefax : +358-21-654497 ! (Jeff Lynne) ------------------------------------------------------------------------------
fkittred@bbn.com (Fletcher Kittredge) (01/12/91)
In article <7177.278f2835@abo.fi> hege@abo.fi writes: >A few months ago there was an ad in misc.jobs.offered (I think) where >Digital looked for people to develop a U*IX that was supposed to be >"The U*IX of the 90's". In Digital Review (was it December 10, 1990?) >the editor in chief rumoured something about U*IX/OSF-version from >DEC within 6 months. Does anybody have any information about this? This is the announcement I received from DEC. This seems general knowledge, so I am passing it on. regards, fletcher Received: by decpa.pa.dec.com; id AA04967; Thu, 27 Dec 90 09:24:35 -0800 Date: Thu, 27 Dec 90 09:24:39 PST Subject: OSF Development Kit ANNOUNCING OSF/1 ADVANCED DEVELOPMENT KIT =================================================================== o Digital is the first OSF member to ship OSF/1 o Kit offers support for the DECstation 3100 and 2100 o Early binary version of OSF/1 to be available Q3/Q4 FY91 =================================================================== PRODUCT DESCRIPTION Digital reinforced its commitment to OSF technology by announcing in October that it would ship the OSF/1 Advanced Development Kit for the DECstation 3100 and 2100 in Q1CY91. Digital will be the first OSF member to ship a version of OSF/1. We are providing this Kit in response to customer and ISV requests for early access to OSF/1 technology. The kit is a preview of future versions of ULTRIX, which will be based on OSF/1 technology. The goals of the Advanced Development Kit are to provide market impact and underline Digital's leadership in delivering OSF technology. The kit can be used to attract new customers and ISVs by capitilizing on the growing acceptance of OSF/1 in the UNIX marketplace, and to provide a leading edge development platform for early evaluation purposes. The kit is a binary version of "pure" OSF/1 as shipped by OSF, and will include the GNU C compiler and development tools, which are included on the OSF/1 tape. With the exception of an installation procedure, there will be no Digital enhancements to OSF/1 in the Advanced Development Kit. Customers who order the OSF/1 Advanced Development Kit from Digital should be innovators who want to begin investigating the OSF Application Programming Interface (API). Typically, these innovators are in academic and research institutions, software houses (such as CSOs and ISVs), and strategic accounts that have endorsed our ULTRIX/OSF strategy and want to begin evaluating the technology. Customers will use this kit for advance development and evaluation purposes only: it is not a deployment platform for applications, and is not an end-user system. FEATURES The OSF/1 Advanced Development Kit includes an advanced kernel based on Mach technology. Innovative kernel functions include an advanced virtual memory management system, secure interprocess communications, loadable kernel modules, and thread scheduling. Compatibility with key industry specifications (like POSIX 1003.1, FIPS 151-1 and the XPG 3 base level) is included for application portability. In addition, the OSF/1 Advanced Development Kit includes compatibility with other UNIX environments including the Berkeley BSD 4.3 Operating System and the System V Interface Definition (SVID) Issue 2 base and kernel extensions, System V accounting features and a SVR3.2 compatible STREAMS framework. It is not a goal of the Advanced Development kit to provide binary compatibility with ULTRIX, although a number of applications will run without modification. When an OSF-based version of ULTRIX is delivered, programs developed with the Advanced Development Kit should only require a recompile. Binary compatibility with the current ULTRIX release is a goal for the merged ULTRIX-OSF offering. The file system architecture included with the Advanced Development Kit is based on the Berkeley 4.4 Virtual File System (VFS) and includes the following file systems: o Berkeley 4.3 Tahoe Fast file system o NFS-compatible distributed file system o System V file system o XENIX file system In addition, the OSF/1 Advanced Development Kit provides logical volume management and disk mirroring. Logical volume management allows file systems to span multiple physical disks. Disk mirroring helps protect against data loss due to media failure. Networking features include the Internet Protocol Suite (TCP/IP), the BSD socket interface, a System V-compatible STREAMS framework, and the X/Open Transport Interface (XTI). The programming environment included with the OSF/1 Advanced Development Kit includes language tools based on the Free Software Foundation's GNU C compiler and debugger. Strict adherence to the ANSI standard for C should ensure portability to future releases of ULTRIX and Digital C compilers. In addition, OSF/1 supports position-independent shared libraries, callable program loading, and the standard UNIX exec facility. The OSF/1 Advanced Development Kit includes support for internationalization in conformance with the Native Language System (NLS) in the XPG3 specification. This support includes eight-bit clean commands, collating sequences, character classification functions, messages catalogs, date and time formats, monetary formats and numeric conventions. Although the OSF/1 operating system is capable of providing security features at the B1 level, configuration is available only at compile time. For this reason, the OSF/1 Advanced Development Kit will offer only those security features common to all UNIX operating systems, including login controls and discretionary access protection. Mandatory access controls, labeling, auditing, access control lists, and discrete privileges will not be provided in binary form with this kit. WHAT ARE OTHER VENDORS DOING WITH OSF/1? OSF/1 is initially available from the Open Software Foundation for three OSF-supported reference implementations: Intel 302 (80386-based), Digital's DECstation 3100, and the Encore Multimax multiprocessor system (National Semiconductor-based). Also included on the OSF/1 distribution tape are three vendor-contributed implementations: HP/Apollo DN2500, Intergraph 6000, and an Intel 860-based system. OSF distributes OSF/1 in source code format. This distribution mechanism requires an AT&T source code license and is therefore cost prohibitive for many small software developers. IBM IBM has formally announced plans to release OSF/1 on the PS/2 line some time in 1991. The next machine in the IBM line to support OSF/1 will be the System/370. They have announced a committment to utilize OSF/1 technology on the IBM RS/6000. No timeframe has been specified. Hewlett-Packard HP aggressively announced its intention to be the first company to ship OSF/1 code, but is targetting OSF/1 at the workstation-only market right now. HP will evaluate each machine on a case-by-case basis. HP has committed to delivering OSF/1 on the new PA RISC line in 1991. The HP 400 series will probably be supported in 1992. HP will port OSF/1 to the Apollo DN series, but will not support the Apollo PRISM machines. HP has no firm plans to support OSF/1 on the HP900/800 series. Bull Bull recently announced an agreement with MIPS and could well announce OSF/1 on their Intel or MIPS line. Sun Sun has no intention of supporting OSF technology. Sun's strategy is to migrate from their current Berkeley-based SunOS to System V Release 4. PRICING/ORDERING INFORMATION The OSF/1 Development Kit is a media and documentation kit only. For tracking and royalty purposes, a separate media kit is required for each CPU. In addition to purchasing the media, all customers will be required to sign a Customer Services agreement for support. Digital will act as the customer's agent, consolidating bug reports and passing them on to the Open Software Foundation. Digital will not distribute maintenance releases for the Advanced Development Kit. Instead, Digital will include bug fixes in the first release of an OSF-based version of ULTRIX. This kit will be retired on introduction of an OSF-based version of ULTRIX. Additional pricing, licensing, and ordering information will be published as soon as it is finalized. RESOURCES Open Software Foundation OSF/1 Information Sheet will be available early Q3FY91 through Northboro. This information sheet is written by OSF, not Digital. ------- End of Forwarded Message Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
mike@raven.uss.tek.com (Mike Ewan) (01/13/91)
In article <7177.278f2835@abo.fi> hege@abo.fi writes: >A few months ago there was an ad in misc.jobs.offered (I think) where >Digital looked for people to develop a U*IX that was supposed to be >"The U*IX of the 90's". In Digital Review (was it December 10, 1990?) >the editor in chief rumoured something about U*IX/OSF-version from >DEC within 6 months. Does anybody have any information about this? (This is all from memory, I don't have the article in front of me.) In "Insight" a few months ago there was an article by the Ultrix product manager about the directions of Ultrix. He stated that with the next major release (5.0?) Ultrix will be completely OSF/1 with the Mach distributed processing kernel. He also said that they are putting a lot of effort into making the whole thing look and work the same as it does now. What I gather from the article and experience, the 5.0 release should be around the middle of this year or maybe fall. Any comments from DEC folks out there? Mike -- Michael Ewan (503)627-6468 Internet: mike@raven.USS.TEK.COM Unix Systems Support UUCP: ...!tektronix!puffin!raven!mike Tektronix, Inc. Compuserve: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart
jg@quabbin.crl.dec.com (Jim Gettys) (01/13/91)
In article <7179@tekgen.BV.TEK.COM> mike@raven.uss.tek.com (Mike Ewan) writes: >In article <7177.278f2835@abo.fi> hege@abo.fi writes: >>A few months ago there was an ad in misc.jobs.offered (I think) where >>Digital looked for people to develop a U*IX that was supposed to be >>"The U*IX of the 90's". In Digital Review (was it December 10, 1990?) >>the editor in chief rumoured something about U*IX/OSF-version from >>DEC within 6 months. Does anybody have any information about this? > >(This is all from memory, I don't have the article in front of me.) >In "Insight" a few months ago there was an article by the Ultrix product >manager about the directions of Ultrix. He stated that with the next >major release (5.0?) Ultrix will be completely OSF/1 with the Mach >distributed processing kernel. He also said that they are putting a >lot of effort into making the whole thing look and work the same as >it does now. What I gather from the article and experience, the 5.0 >release should be around the middle of this year or maybe fall. >Any comments from DEC folks out there? Folks are certainly working on it (hard). Thankfully, not me :-). (I gave at the X bloodbank). As to when, I think the only statement to date has been "1991", i.e. sometime this year. And given experience here at CRL with earlier snapshots, OSF/1 can indeed provide Ultrix compatibility, so one's existing code runs just fine barring the ususal exceptions of programs that open /dev/kmem and grovel through kernel data structures that have traditionally broken between releases (though OSF/1 provides clean interfaces to kernel data structures, that should even reduce this problem in the future.). We certainly ran large piles of exiting executable we have here on it last spring and summer (like lots of DECwindows application, etc.), and were quite pleased. Jim Gettys Digital Equipment Corporation Cambridge Research Lab. -- Digital Equipment Corporation Cambridge Research Laboratory
jg@quabbin.crl.dec.com (Jim Gettys) (01/13/91)
In article <1991Jan12.174914.26621@crl.dec.com> jg@quabbin.crl.dec.com (Jim Gettys) writes: > >And given experience here at CRL with earlier snapshots, OSF/1 can indeed >provide Ultrix compatibility, so one's existing code runs just fine >barring the ususal exceptions of programs that open /dev/kmem and grovel >through kernel data structures that have traditionally broken between >releases (though OSF/1 provides clean interfaces to kernel data structures, >that should even reduce this problem in the future.). >We certainly ran large piles of exiting executable we have here on it last Boy, some folks give me grief over typo's; I meant executables, of course... And they didn't even exit execept when they were supposed to :-). >spring and summer (like lots of DECwindows application, etc.), and were quite >pleased. I sur kan't spel gud... :-). - Jim -- Digital Equipment Corporation Cambridge Research Laboratory
fingerhu@ircam.fr (Michel Fingerhut) (01/13/91)
Jim Gettys writes: >Folks are certainly working on it (hard). Some questions arise... 1. Will it work on *all* of DEC's platforms, i.e., the famous 58x0 as well as DECstations 3100, for instance? We have both, and it would be unthinka- ble to upgrade one type of machine without the other and have users lost with yet another brand of U*ix. 2. If it does, does this mean it's a multiprocessor U*ix? One that works ade- quately with the 58x0? 3. If so, what about the other rumors about SCO UNIX? 4. What about the *reliability* of OSF/1 tools? *If* I am not mistaken, their compiler is derived from gcc, which has known problems with DEC/MIPS archi- tecture, and provides less debugging options than cc (which has some problems too). (Is this why Jim Gettys says "We certainly ran large piles of exiting executable we have here "... ) ^^^^^^^ 5. Will this software be supported by DEC? I'd much like to understand DEC's strategy -- after all we (the end users) have to plan ahead too... Michael Fingerhut
jg@quabbin.crl.dec.com (Jim Gettys) (01/13/91)
In article <1991Jan13.070816.24882@ircam.fr> fingerhu@ircam.fr (Michel Fingerhut) writes: >Jim Gettys writes: >>Folks are certainly working on it (hard). > >Some questions arise... > >1. Will it work on *all* of DEC's platforms, i.e., the famous 58x0 as well > as DECstations 3100, for instance? We have both, and it would be unthinka- > ble to upgrade one type of machine without the other and have users lost > with yet another brand of U*ix. > That's the point of the real Ultrix release; the developer's release is just DS3100/DS2100, and is basically a packaging of close to exactly what the OSF shipped, but when the full release happens, will run on all machines that Ultrix runs on. >2. If it does, does this mean it's a multiprocessor U*ix? One that works ade- > quately with the 58x0? Mach (which OSF/1 is derived from) is an SMP system. One of the systems OSF/1 was developed on is the Encore Multimax, which has many more processors than a 58x0. "Works adaquately" is a subjective statement, and as I haven't seen OSF/1 running on the machine yet, I can't say. We have every reason to believe it should work fine. > >3. If so, what about the other rumors about SCO UNIX? Unfounded rumors. > >4. What about the *reliability* of OSF/1 tools? *If* I am not mistaken, their > compiler is derived from gcc, which has known problems with DEC/MIPS archi- > tecture, and provides less debugging options than cc (which has some > problems too). (Is this why Jim Gettys says "We certainly ran large piles > of exiting executable we have here "... ) > ^^^^^^^ So I can't type :-) :-(. The sentence was supposed to read "..of executables..". The OSF used GCC for its work (and did mucho work on GCC to make it work well on the MIPS architecture). If I'm not mistaken, not all of this work has yet been reintegrated by the GNU folks. Gcc is in the developer's release; there was no statement that we expect it to be the production compiler when the full release occurs. The kinds of things we have to do to ship OSF/1 as Ultrix, for example include integrating all our compilers and machine support, most of which the OSF does not have, not to mention extensive field testing, and making sure customer's existing executables continue to run, just to mention a few. As you may or may not have gathered by now, Digital has a new suite of compiler technology coming, as evidenced by the new DEC Fortran on RISC compiler announced last week, which, from talking to some friends that have it, is a good improvement over the existing MIPS compiler. There is a lot of work to do to get from the developer's kit to the full release. Please read the caveats on the developer's kit before deciding if you want it; it is intended for people who need an advance look at the new functionality OSF/1 provides, not as a production system. >5. Will this software be supported by DEC? > Not sure precisely which software you mean... If you mean gcc, I don't think so. If you mean OSF/1, yes. >I'd much like to understand DEC's strategy -- after all we (the end users) >have to plan ahead too... > The strategy is simple: have the best Unix system in the market. We believe that OSF/1 provides the best base system to work with. History will judge if the strategy is correct. Hope this helps. I'm not in the Ultrix group, so this is to the best of my personal understanding. - Jim -- Digital Equipment Corporation Cambridge Research Laboratory
fkittred@bbn.com (Fletcher Kittredge) (01/13/91)
In article <1991Jan13.070816.24882@ircam.fr> fingerhu@ircam.fr (Michel Fingerhut) writes: >Jim Gettys writes: >>Folks are certainly working on it (hard). > >Some questions arise... I have no relationship with DEC, but even I know the answers to some of these questions. >1. Will it work on *all* of DEC's platforms, i.e., the famous 58x0 as well > as DECstations 3100, for instance? We have both, and it would be unthinka- > ble to upgrade one type of machine without the other and have users lost > with yet another brand of U*ix. > >2. If it does, does this mean it's a multiprocessor U*ix? One that works ade- > quately with the 58x0? If you don't know that OSF/1 is based on Mach and Mach has become the operating system of choice for MIDI multiprocessors such as DEC's 58x0 series, then you don't deserve one of these computers and should have your wizard licence removed(;-). Since current versions of Mach are much more highly parallelized than Unix, OSF/1 will work much better on 58x0s than current the DEC offering (which is not saying much from what I hear). >3. If so, what about the other rumors about SCO UNIX? What rumors? I read several places the announcement that DEC is selling SCO Unix on their 386 boxes. Doesn't seem like a rumor to me. >4. What about the *reliability* of OSF/1 tools? *If* I am not mistaken, their > compiler is derived from gcc, which has known problems with DEC/MIPS archi- > tecture, and provides less debugging options than cc (which has some > problems too). (Is this why Jim Gettys says "We certainly ran large piles > of exiting executable we have here "... ) > ^^^^^^^ Well, you are mistaken. If you had been following gcc on the MIPS systems at all, you would have noticed over the last year a stream of high quality patches for gcc for DEC RISC systems emerging out of Michael Meissner at OSF. In fact, the DECStation is one of the OSF's reference ports for OSF/1. As for less debugging options, I don't believe you. There are many more error checking and debugging options for gcc than for MIPS cc. However, I am open to persuasion, could you list the debugging options available with MIPS cc and not with the gcc OSF ships? In addition, DEC will probably offer both compilers on their Ultrix-OSF/1 merge. >5. Will this software be supported by DEC? Give me a break. >'d much like to understand DEC's strategy -- after all we (the end users) >have to plan ahead too... Strategy, what strategy? Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
meissner@osf.org (Michael Meissner) (01/15/91)
In article <62062@bbn.BBN.COM> fkittred@bbn.com (Fletcher Kittredge) writes: | In article <1991Jan13.070816.24882@ircam.fr> fingerhu@ircam.fr (Michel Fingerhut) writes: | >4. What about the *reliability* of OSF/1 tools? *If* I am not mistaken, their | > compiler is derived from gcc, which has known problems with DEC/MIPS archi- | > tecture, and provides less debugging options than cc (which has some | > problems too). (Is this why Jim Gettys says "We certainly ran large piles | > of exiting executable we have here "... ) | > ^^^^^^^ | | Well, you are mistaken. If you had been following gcc on the MIPS systems | at all, you would have noticed over the last year a stream of high quality | patches for gcc for DEC RISC systems emerging out of Michael Meissner at | OSF. In fact, the DECStation is one of the OSF's reference ports for OSF/1. Flattery will get you everywhere :-) | As for less debugging options, I don't believe you. There are many more | error checking and debugging options for gcc than for MIPS cc. However, I | am open to persuasion, could you list the debugging options available with | MIPS cc and not with the gcc OSF ships? | | In addition, DEC will probably offer both compilers on their Ultrix-OSF/1 | merge. Let me try to add some light to the discussion. Note that I'm speaking for Michael Meissner here, not for OSF and/or DEC in any offical capacity. The OSF/1 tapes that we ship contain GCC as a reference compiler on the Free Software Foundation tape (ie, GCC is not offically a part of OSF/1, which means a vendor can supply his/her own compilers). In order to better support our shared libraries, we use a new object file format called OSF/rose. At present, we use the normal Berkeley style .STABS for debugging support, which means the debug support is equivalent to what you get elsewhere. As part of my changes to GCC, I did also supply debug support for the vendor supplied ECOFF debug format. This involved writing a cover program for the assembler which ran the real assembler and stuffed the debug information into the object file (the MIPS assembler provides no way to pass symbolic debug information). The codegen changes that I did were incorportated into revision 1.38 of GCC, but the 'new' features, such as debug support are being delayed until revision 2.00 at the behest of the FSF. I can't say whether DEC will support both compilers or not, or what object file format they will use. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
grunwald@foobar.colorado.edu (Dirk Grunwald) (01/15/91)
I'd also like to point out that if you use optmization, the gcc hacked by OSF appears to be as/more reliable than the 'cc' from MIPS, and it does provide debugging support. It just produces slightly slower executables.