nazgul@alphalpha.com (Kee Hinckley) (03/31/91)
In article <9103291553.AA09621@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >inovation on the same box. I'll give you a hint. The people who did >the R3 server mostly don't work for HP/Apollo anymore. Right, Kee? ;-) There are not many left. Another left a few weeks ago after GTD (Graphics and Terminals Division?) decided that they didn't believe in parallel tracks for engineers and managers and demoted all the Consulting Engineers. Latest news from the former PE is that he was falling off of bulls in Mexico. I believe the takeover is almost complete. Most all the Apollo components are now in other divisions, leaving very little left of the Apollo division itself except the management. I wouldn't be suprised to hear of changes in the management sometime soon. -- As a total aside. Some people have complained about the lack of a DM editor, transcript pads, and DM editing. I think it would take about 4 man months (say 2 people for 2 months) to do this using existing tools. I would take the Epoch multi-window version of GNU Emacs and build a DM emulation mode that recognized the standard key definitions. It even has a separate "Command Window" like the DM. If you were really feeling adventurous you could try making an elisp DM-command interpreter, but I don't think that would be completely necessary. Then I would take Mwm and add some additional functions and fix the Pop and NextWindow functions to have sensible semantics. Finally I'd take the Korn Shell (this is the *only* shell worth using in a xterm) and add DM editing commands. The Korn shell has two builtin editing modes (vi and emacs) that provide a lot of the functionality that you get in pads - including searching for previous commands. All that's necessary here is to add an additional (hard-coded, but that's better than nothing) emulation mode to get DM style editing and support for the gray keys. Sure you could enhance xterm, create a new editor and all that junk. But what I listed would give you 85% of the functionality, and would furthermore be (for the most part) portable to other systems (the Mwm changes would of course, be fed back to OSF). This would be well worth doing and a fitting transplant of Apollo's experience into the X windowing world. I've been meaning to draw up a more formal description of what would be required and post it (and send a copy to Rose and crew) but this is really all I have time to do now. The main drawback to this proposal is that the only group with the charter to do this kind of work is the UI group in Corvallis, and they of course have no incentive. I think it would take a skunkworks at Apollo to get it done properly. With a little work it could even make SR10.4. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
rees@pisa.citi.umich.edu (Jim Rees) (04/02/91)
In article <1991Mar31.041446.10671@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes:
Latest news from the former PE is that he was falling off of bulls in Mexico.
Actually, his $300 Volkswagon Rabbit made it all the way to Costa Rica,
where he is now soaking up the language. If anyone wants his paper mail
address (he's not on the net down there!), send me mail and I'll send it to
you.
With a little work it could even
make SR10.4.
Will there be another sr before DCE? I've heard the one they're working on
now called both sr10.4 and sr11.reb@quintro.uucp (Roger E. Benz) (04/02/91)
In article <1991Mar31.041446.10671@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >In article <9103291553.AA09621@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >>inovation on the same box. I'll give you a hint. The people who did >>the R3 server mostly don't work for HP/Apollo anymore. Right, Kee? ;-) > >There are not many left. Another left a few weeks ago after GTD (Graphics >and Terminals Division?) decided that they didn't believe in parallel tracks >for engineers and managers and demoted all the Consulting Engineers. >Latest news from the former PE is that he was falling off of bulls in Mexico. > >I believe the takeover is almost complete. Most all the Apollo >components are now in other divisions, leaving very little left of >the Apollo division itself except the management. I wouldn't be >suprised to hear of changes in the management sometime soon. > >-- > >As a total aside. Some people have complained about the lack of >a DM editor, transcript pads, and DM editing. I think it would take >about 4 man months (say 2 people for 2 months) to do this using >existing tools. I would take the Epoch multi-window version of >GNU Emacs and build a DM emulation mode that recognized the standard >key definitions. It even has a separate "Command Window" like the DM. >If you were really feeling adventurous you could try making an elisp >DM-command interpreter, but I don't think that would be completely >necessary. Then I would take Mwm and add some additional functions and >fix the Pop and NextWindow functions to have sensible semantics. >Finally I'd take the Korn Shell (this is the *only* shell worth using >in a xterm) and add DM editing commands. The Korn shell has two builtin >editing modes (vi and emacs) that provide a lot of the functionality >that you get in pads - including searching for previous commands. >All that's necessary here is to add an additional (hard-coded, but that's >better than nothing) emulation mode to get DM style editing and support >for the gray keys. > >Sure you could enhance xterm, create a new editor and all that junk. >But what I listed would give you 85% of the functionality, and would >furthermore be (for the most part) portable to other systems (the >Mwm changes would of course, be fed back to OSF). This would be >well worth doing and a fitting transplant of Apollo's experience into >the X windowing world. I've been meaning to draw up a more formal >description of what would be required and post it (and send a copy >to Rose and crew) but this is really all I have time to do now. > >The main drawback to this proposal is that the only group with the >charter to do this kind of work is the UI group in Corvallis, and >they of course have no incentive. I think it would take a skunkworks >at Apollo to get it done properly. With a little work it could even >make SR10.4. >-- >Alfalfa Software, Inc. | Poste: The EMail for Unix >nazgul@alfalfa.com | Send Anything... Anywhere >617/646-7703 (voice/fax) | info@alfalfa.com > >I'm not sure which upsets me more: that people are so unwilling to accept >responsibility for their own actions, or that they are so eager to regulate >everyone else's. I like this idea. It would give back some of the features that I miss from DM (I'm a X user now) but still allow me to use X. I sure hope that HP/Apollo will see this and act. This could make a lot of apollo customers happier without being non-standard (its still X, mwm and korn shell). -- Roger E. Benz Glenayre/Quintron Phone = (217) 223-3211 One Quintron Way Quincy, IL UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken
nazgul@alphalpha.com (Kee Hinckley) (04/03/91)
In article <50b810fd.1bc5b@pisa.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: > With a little work it could even > make SR10.4. > >Will there be another sr before DCE? I've heard the one they're working on >now called both sr10.4 and sr11. What I've heard is that SR11 is now SR10.4. I don't know what that means wrt DCE. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
lampi@polari.UUCP (Michael Lampi) (04/03/91)
It would be pretty easy for someone at Danford to convert their Full Screen Editor program to X (as opposed to operate within a VT-100 xterm window). FSE already has most of the DM editor commands implemented, along with the soft keyboard and key command syntax (remember the KD command?) of the DM, and does highlighting, cut and paste, multiple windows, infinite undo, etc. The question is, will they do it? For what price? Inquiring FSE author wants to know!! :-) Michael Lampi
rwilkie@APOLLO.COM (Richard Wilkie) (04/04/91)
Kee,
Here's the latest information on releases of Domain/OS for the next
couple of years. Please keep in mind: I have a pretty good idea of what
I am doing tomorrow, an OK idea of next week and a fuzzy (at best) idea
of next year - so the exact schedules should be taken with a grain
(boulder) of salt (+/- 3 months).
PSKs from now 'til 1992:
A PSK will be released in June/July supplying additional graphics
and 68040 support.
The Q3 PSK will be available sometime in July/August and will
contain all base software released til that point. (ie: all you need
to do to get Series 400 support, CD-ROM, X11R4, The Security Fix...
is install SR10.3 and then this PSK)
SR10.4:
SR10.4 will release towards the end of 1991 (Nov/Dec) and will
include support for popular standards (POSIX 1003.1, XPG3, AES,
X11R4...) as well as eliminating the need for all previous PSKs.
SR10.5:
SR10.5 will release mid-1992 and will contain support for the DCE
SR10.6:
I expect SR10.6 to be released around mid-1993 but I have no public
details of it's contents.
All of these releases are to be 100% forward binary compatible.
Hope this helps,
rich wilkie
In article <50b810fd.1bc5b@pisa.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes:
> With a little work it could even
> make SR10.4.
>
>Will there be another sr before DCE? I've heard the one they're working on
>now called both sr10.4 and sr11.
What I've heard is that SR11 is now SR10.4. I don't know what that means wrt DCE.
--
Alfalfa Software, Inc. | Poste: The EMail for Unix
nazgul@alfalfa.com | Send Anything... Anywhere
617/646-7703 (voice/fax) | info@alfalfa.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.kts@quintro.uucp (Kenneth T. Smelcer) (04/06/91)
In article <9104041202.AA15566@xuucp.ch.apollo.hp.com> rwilkie@APOLLO.COM (Richard Wilkie) writes: > >Here's the latest information on releases of Domain/OS for the next >couple of years. Please keep in mind: I have a pretty good idea of what >I am doing tomorrow, an OK idea of next week and a fuzzy (at best) idea >of next year - so the exact schedules should be taken with a grain >(boulder) of salt (+/- 3 months). > >PSKs from now 'til 1992: > > A PSK will be released in June/July supplying additional graphics > and 68040 support. > Question: what is happening with the limit of 64 process slots on the 400 series machines? It was my understanding that when the 040 upgrades were available, this limitation would be removed. Can anyone verify this? Will the fix work on our existing 400t with a 68030? -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Ken Smelcer Glenayre Corp. quintro!kts@lll-winken.llnl.gov Quincy, IL tiamat!quintro!kts@uunet.uu.net
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (04/09/91)
> Question: what is happening with the limit of 64 process slots on the > 400 series machines? From the psk8 release notes: "PSK 8 provides software support that was not available with SR10.3. It includes SR10.3 functionallity and compatibility (including support for a maximum of 1024 concurrent processes) for Domain Series 5500 systems and all HP Apollo 9000 Series 400 systems." Thomas Gilg tomg@cv.hp.com