cs_bob@gsbacd.uchicago.edu (05/03/89)
in New Orleans last week. Among the lowlights: 1) During their Monday morning marketing hype, several exexcutive types ballyhooed the large number of various UNIX flavors they run on. No one mentioned the fact that version 6 Ingres no longer works under BSD Unix. 2) New Ingres 6.2 features were announced. Absolutely no mention was made of the fact that although version 6.1 is in production, it is only available to a very limited number of sites. Very few users have version 6, although the features it provides were announced in the October *1986* IUA. The execs focused on the future of RTI, stressing their connectivity products. Judging from the experience with version 6, they were focusing on the very distant future. 3) The IUA Membership voted to incorporate and sever themselves from RTI. RTI brass claimed that they wanted a 'strong independant users organization', while IUA board members indicated that their primary interest was a fear of personal liability for the actions of the IUA. Board members were unable to circulate the resolution, saying they didn't have the time to make copies. Voters in favor of the proposal were asked to raise their hands. No one was allowed to vote against the resolution (that is, they were never asked to vote). This creates an interesting situation. In our recent Ingres support license, update, one of the announced benefits is a free membership in the IUA. As it turns out, IUA membership costs nothing, and RTI does not want the IUA to charge anything for membership. 4) RTI refused to release a list of the attendees of the conference. Apparently, the IUA has never even been provided with a list of their own membership. If the IUA board wishes to make a mailing, they must submit it to RTI for censorship and handling. RTI claims that the list of IUA membership is their property, and that it contains sensitive marketing information. If that's their idea of supporting a strong, independant user's organization, I can't wait to see how they'll act if and when the IUA ever starts to rock the boat.
consult@osiris.UUCP (Unix Consultation Mailbox ) (05/03/89)
Interesting to see comments on the IUA meeting here. I hope someone from RTI (Dave?) will comment on some of the technical points contained in cs_bob's message. I too was surprised that a list of attendees was not distributed. The fact that registration exceeded 860, making it by far the largest NAIUA ever (the last conference was thought to be well-attended at about half that number) may have had something to do with this change, though marketing issues could certainly have something to do with it (I have gotten considerable quantities of DBMS-related junk mail at an old address which was lifted from an IUA registration list so I know that people use them). I wanted to take this opportunity to remind all Ingres users on the net that there are two groups within the North American IUA which were more-or- less formed in San Diego (April, 1988 - the Love Boat conference :-) and which might prove helpful to both new and experienced users of Ingres. The first is the User Request Group, which was created to provide an official channel from the North American Ingres user community to RTI for requests for enhancements and comments on other features of current and future Ingres releases. At their meeting in New Orleans, lines of communication between the Group (chaired by Eric Palmer of The Palmer Group, an Ingres consulting company in Atlanta) and RTI were proposed and discussed as well as anyone can discuss anything at 7:30am the morning after the conference dinner/dance/bacchanal. The other group (which did exist prior to the San Deigo conference, though in a much smaller and less organized form) is the Ingres Tools Committee, which is still accepting submissions of useful DBA and application tools and techniques for on-demand distribution to NAIUA members. Request forms exist now (after much discussion with various lawyers about liability issues), although some of the details have changed, and submission forms will be available soon. Complicating any short-term dealings with the Tools Committee is the fact that the original chairperson, Tom Lyttle of Los Alamos, has resigned his post. A quorum was not available as the committee meeting to elect or appoint a new chairperson, so this group is temporarily headless. In any case, Tom assured me that the process of completing the forms and organizing the distribution process will be done very soon. I am the primary UNIX specialist on both the User Request Group and the Tools Committee. There is not currently an established communication channel for the User Request Group. RTI needs to make some decisions about how to handle requests before this will be done. I can accept requests from users for forwarding to the Group, however. I can also send copies of the current tools distribution request form to interested parties. Phil Kos ...!uunet!pyrdc!osiris!phil, ...!mimsy.cs.umd.edu!aplcen!osiris!phil UNIX Specialist, NAIUA Tools Committee and User Request Group Technical Support, Information Services Organization The Johns Hopkins Hospital
jkrueger@daitc.daitc.mil (Jonathan Krueger) (05/05/89)
In article <3044@tank.uchicago.edu>, cs_bob@gsbacd writes: >in New Orleans last week. Among the lowlights: > >1) During their Monday morning marketing hype, several exexcutive [sic] >types ballyhooed the large number of various UNIX flavors they run on. >No one mentioned the fact that version 6 Ingres no longer works under >BSD Unix. Were we at the same conference? At the conference that *I* attended a decision was reached and announced that INGRES front ends and INGRES/Net will be supported on BSD Unix on VAXes. Front and back ends will be supported on BSD derived systems such as Ultrix and SunOS. New Orleans was a lot of fun, and most of us indulged in the local color and flavor, but some of us managed to get the correct information about RTI's products and plans and bring it back to our sponsors. -- Jon --
saks@manta.NOSC.MIL (Joel A. Saks) (05/05/89)
In article <3044@tank.uchicago.edu> cs_bob@gsbacd.uchicago.edu writes: >in New Orleans last week. Among the lowlights: > >... No one mentioned the fact that version 6 Ingres no longer works under >BSD Unix. > During the RT presentation entitled simply "UNIX", Mitch Bishop, UNIX Product Marketing Manager for RT, announced that RT has no plans to port the backend of INGRES version 6 to BSD UNIX. However, Mitch also announced that RT has agreed to port the 6.2 frontends to BSD UNIX. The release date for this frontend-only port to BSD is 1st Quarter 1990. Thanks go to Mitch for orchestrating the BSD port in the three weeks before and during the IUA meeting. Joel Saks saks@nosc.mil Computer Sciences Corp., San Diego (619) 225-8401
cs_bob@gsbacd.uchicago.edu (05/06/89)
In article <506@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes... >In article <3044@tank.uchicago.edu>, cs_bob@gsbacd writes: >>in New Orleans last week. Among the lowlights: >> >>1) During their Monday morning marketing hype, several exexcutive [sic] >>types ballyhooed the large number of various UNIX flavors they run on. >>No one mentioned the fact that version 6 Ingres no longer works under >>BSD Unix. > >Were we at the same conference? At the conference that *I* attended a >decision was reached and announced that INGRES front ends and >INGRES/Net will be supported on BSD Unix on VAXes. Front and back >ends will be supported on BSD derived systems such as Ultrix and >SunOS. > As far as I'm concerned, if the back end doesn't run on the machine, Ingres doesn't run on the machine. Ingres is supposedly an RDBMS. If they can't get you the database engine, I think it's fair to say that they can't give you an RDBMS. The annoucement you refer to was definitely not made during the Monday morning session, nor was the decision 'reached and announced' at the conference. We've known about it for a long time - the problem is that BSD doesn't support shared memory, and Ingres 6.x requires it. (As an aside, someone, I think Marty Sprinzen, made a comment to the effect 'so far, all of our bugs have been coding errors, not architecture errors.' This seems to be an architecture error if there ever was one. Does anyone else know of another multi-platform DBMS system that REQUIRES shared memory?)
jkrueger@daitc.daitc.mil (Jonathan Krueger) (05/07/89)
In article <3082@tank.uchicago.edu>, cs_bob@gsbacd writes: >As far as I'm concerned, if the back end doesn't run on the machine, >Ingres doesn't run on the machine. Ingres is supposedly an RDBMS. If >they can't get you the database engine, I think it's fair to say that >they can't give you an RDBMS. Have you heard the phrase "the network is the computer"? What do you think it means? The machine, in this case, consists of a vax, a network, and one other processor from {sequent, sun, mips, pyramid, . . .} INGRES runs on the machine. One configuration of the machine is to hang terminals off the vax, and disks off the other processor. RTI has said they will support this. >The annoucement you refer to was definitely not made during the Monday >morning session, nor was the decision 'reached and announced' at the >conference. We've known about it for a long time - the problem is that >BSD doesn't support shared memory, and Ingres 6.x requires it. Please don't confuse previous general discussion on the issue with the specific progress and public commitments made at the conference. >(As an >aside, someone, I think Marty Sprinzen, made a comment to the effect >'so far, all of our bugs have been coding errors, not architecture errors.' >This seems to be an architecture error if there ever was one. Does anyone >else know of another multi-platform DBMS system that REQUIRES shared memory?) Yes, I know of others. As does anyone who bothers to get the facts and report them correctly. Look, would you care to research different methods of ensuring atomicity and serializability, support for them in commercially available operating systems, and their tradeoffs in performance, development, installation, scalability, portability, multiprocessor support? If some technically qualified person (which I am not, by the way) were to post a summary on this topic, we'd all be most grateful. -- Jon --
bin@primate.wisc.edu (Brain in Neutral) (05/08/89)
From article <509@daitc.daitc.mil>, by jkrueger@daitc.daitc.mil (Jonathan Krueger):
< In article <3082@tank.uchicago.edu>, cs_bob@gsbacd writes:
<>As far as I'm concerned, if the back end doesn't run on the machine,
<>Ingres doesn't run on the machine. Ingres is supposedly an RDBMS. If
<>they can't get you the database engine, I think it's fair to say that
<>they can't give you an RDBMS.
< Have you heard the phrase "the network is the computer"? What do you
< think it means? The machine, in this case, consists of a vax, a
< network, and one other processor from {sequent, sun, mips, pyramid, .
< .. .} INGRES runs on the machine. One configuration of the machine is
< to hang terminals off the vax, and disks off the other processor. RTI
< has said they will support this.
That helps a lot if your only machine or machines are BSD machines,
doesn't it?
Paul DuBois
dubois@primate.wisc.edu rhesus!dubois
bin@primate.wisc.edu rhesus!binjkrueger@daitc.daitc.mil (Jonathan Krueger) (05/10/89)
In article <258@indri.primate.wisc.edu>, bin@primate (Paul DuBois) writes: >[a heterogeneous network] helps a lot if your only machine or machines >are BSD machines, doesn't it? Of course, you're SOL. Or, to be more precise, your options are (in rough order of increasing cost and pain): 1. convert one of your vaxen to Ultrix 2. move to some other DBMS (that supports BSD) 3. buy a non vax processor, and add it to your network 4. add system V style shared memory to BSD Unix Lots of tradeoffs here. If your applications are many or large or both, or make extensive use of RTI-specific features, or if you're significantly more productive with RTI tools than with others running on BSD, you might find option 3 cheaper than option 2. Although option 4 is easily the most expensive (figuring in support costs), it also is the only option with profit potential, from selling it to RTI and others, presumably. In fact, you might call option 3 "net retrofit" and option 4 "net profit". -- Jon -- --
tim@phobos.sybase.com (Tim Wood) (05/11/89)
In article <512@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: >In article <258@indri.primate.wisc.edu>, bin@primate (Paul DuBois) writes: >>[a heterogeneous network] helps a lot if your only machine or machines >>are BSD machines, doesn't it? > >Of course, you're SOL. Or, to be more precise, your options are (in >rough order of increasing cost and pain): > > 1. convert one of your vaxen to Ultrix > 2. move to some other DBMS (that supports BSD) > 3. buy a non vax processor, and add it to your network > 4. add system V style shared memory to BSD Unix > >Lots of tradeoffs here. [...] >Although option 4 is easily the most expensive (figuring in support costs), it >also is the only option with profit potential, Oh, great. Yet another UNIX variant. Disclaimed by AT&T, OSF and UCB alike! :-) Fulfills the dream of most DBMS-application users to get into the ever-fun, ever-changing software business! :-) >from selling it to RTI and others, presumably. Yes, profiting from customer confusion has been demonstrated. >In fact, you might call option 3 "net >retrofit" and option 4 "net profit". Option 4 is ludicrous (unless you like penny-stock ventures :-) Option 1 is likely the only economical alternative for most DBMS users. Ultrix contains most of the BSD UNIX interfaces, supports shared memory and is available out of the box from DEC. No rewriting DBMS applications, no new command sets/system call sets to learn. Heck, you can probably run the BSD filesystems unchanged after installing Ultrix (that was our experience going from MORE/BSD 4.3 to Ultrix). > >-- Jon Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim Voluntary disclaimer: This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.