rhodesii@idaho.uucp (III) (06/06/91)
Immediate disclaimer. I'm an expert in nothing, just a user
who had a chance to demo an HP-720 for 10 days and had a
chance to compare it to our IBM-320 and SUN Sparc2.
These are just my general impressions and if I say something is so,
and it isn't, then it is just my ignorance about HP systems.
We only had the machine for a week and we had no hardcopy documentation.
I'd never touched an HP until last week- but I have worked on
a variety of SUN's, IBM's, STARDENTS, SGI's, GOULD's etc. Also
bear in mind that I do far more FORTRAN than C. Some of these
comments will be old hat for HP old timers and maybe of interest
to IBM-320 or Sparc2 users.
HP Hardware description:
HP-720, 32 megabytes, 19" color, 2*210 megabytes internal,
1*640 meg. external and a 4mm DAT drive running HP-UX 8.0
First impression is what you would expect -the machine is fast!
There is no doubt that it is a hot box. However, as a user I
want a box that is easy to use. I want a machine that can make ME
more productive and not just rack up impressive SPECmarks.
The cost of the man hours involved in many projects often easily
exceeds the hardware costs involved (when talking about current
workstations).
MISC Nice features:
1. It is fast what more can say. If it core dumps, it
core dumps fast! -and we saw plenty.
2. The HP menu driven system administrator, "SAM" seems to
be quite good and much easier to use than the IBM
equivalent "SMIT" which I found just to get in the way
more times than to be helpful. It took very little time
(<0.5 hrs) to get it integrated into our network of
SUN's, IBM, and printers. I guess you could say it
"plays well with others"
3. monitor- The refresh rate is much nicer than the IBM's
and easier on the eyes under fluororescent light.
The colors didn't seem as "saturated" as they are on our IBM.
The monitor doesn't have the huge "footprint" of the IBM either.
4. The HP's X11 graphics is fast. Noticeably faster than an IBM-320's
and somewhat better than a Sparc-2 and the HP X11 is release 4
and the MOTIF1.1 (the IBM X11 is release 3 and MOTIF1.0 and we
run MOTIF1.1.1 on our SUNS)
5. HP-VUE 2.0 -I liked it. The workspace concept is good. I was
also able to blow it away and get my own X environment up easily.
The IBM Desktop manager thing is very poor in comparison.
MISC Bad features:
1. keyboard- had a nice "touch," but the ESC and shift keys are
just too small. Hopefully they will offer it with other keyboards.
2. I'm disappointed that HP doesn't support an 8mm tape drive (EXABYTE) on
the 720. It appears that they have decided that the four formats
they will support will be: CD-ROM, 4mm DAT, 1/2 inch and HP 1/4 inch.
Our HP rep. said of course I could write my own SCSI driver for an 8mm
(and I'm sure somebody will) but I don't want to spend my time doing what
I perceive to be their job. I want to spend my time being productive
developing code in my field.
3. I was also disappointed that I couldn't get a chance to demo the
Interface Architect for producing MOTIF applications.
Our representative said he couldn't find it for a 720 (?).
If not hopefully it will be available soon.
Of course its easier to pick nits than to say nice things
because it is the nits that will irritate you into
non-productivity. Plus it is easy to take for granted
all the good things. You get spoiled quickly.
Hopefully some of these things will be fixed in upcoming releases.
NITS:
A) vi
1.vi does not automatically resize the text when
the window is resized (the IBM does, SUN doesn't).
you have to get out and do an eval resize.
2. vi had lots of trouble with files containing a large
number of lines even if they contained little data.
For example a 1 meg. file consisting of 500,000 lines
(a single X) on each line yielded:
OUT OF MEMORY SAVING LINES FOR UNDO - TRY USING E
(Guess it want me to use ed huh?) An 8 Meg. byte SUN 3/50
had no trouble with this file.
3. Some larger files (>20 meg.) but with fewer lines (about 200k)
would seg. fault and core dump vi.
4. While editing a 250,000 line file, I did a :1,100000 wr hunk1
Upon examination the resulting file hunk1 was scrozzled.
I consider this undesirable.
We are mainly a FORTRAN shop here, so the FORTRAN development tools
are very important to use (the compiler, the debugger, fsplit etc.)
B) fsplit - The fsplit is execptionally primitive.
1. does not have a -e option for splitting out individual routines
2. splits the files out into file names with capital letters (FOO.f)
(reminds me of the ETA10-P* at Purdue).
3. does not handle duplicate sub-program names.
I had a 100,000 line file FOO.f which had subroutine in it called FOO
and when I did %fsplit -f FOO.f, when it came to the subroutine
called FOO it just overwrote the master file FOO.f and quit.
I had to retrieve my complete source from a backup.
C) FORTRAN
1. First off the FORTRAN compiler is gratifyingly fast (which is good
for FORTRAN code developers). We were seeing about
30,000 lines/cpu minute (no optimization) on large monolithic
sources (without comment cards).
2. Porting relatively clean f77 code posed no real problems.
3. Standard error is on unit 7 instead on unit 0.
No real problem unless your application was trying to use unit 7
for something else. I guess this is historical HP (?)
4. Symbolic debugger- The symbolic debugger adb seemed to be powerful,
but I was REALLY discouraged because the syntax is so much different
from the dbx on most other UN*X boxes and the window driven part is
not exactly "point and click." This is really important to us.
Plus you don't get the debugger with the FORTRAN compiler, you
have to get the C-developer's package. In this respect the HP does
not seem to be a good platform for FORTRAN development. In this area
the IBM debugger seems to particularly good (better than SUN's which
doesn't have return command and often gets confused with " too many
levels" just when you're getting down to the interesting part of the
code).
5. The +T option of f77 is nice in that it will provide a trace back for
many exceptions and range errors (NaN generators). You can't
currently do this on the IBM-320. However, the traceback doesn't
provide line numbers but merely routine names and addresses. This is
something that STARDENT did well.
6. The compiler on +O2 level would warn about use of unitialized
variables. This is a nice feature, since unitialized variables
often screw with optimizers assigning variables to registers.
7. The fortran compiler (quietly sometimes) links into the C library.
Sometimes it warns you, e.g.
Warning on line 58354 of testcomp.f: Wrong number of args to intrinsic free
Last time I looked, free was not an f77 intrinsic. This meant that
I had to go in and add external statements so it would use MY
subroutine free. O.K. I know that if trying to write good,
PORTABLE FORTRAN code, one should always declare one's function
to be external, for just this circumstance, but there is a lot of
code out there where people don't.
8. Lack of FORTRAN callable flush and loc functions. I want to be
able to flush my own buffers, and I want to be able to implement
my own memory management routines w/o C calls.
9. When trying to compile a large (268504 lines without comments)
FORTRAN application monolithically (and w/o opt.) I ran into
several problems: The compiler seemed to be in real trouble
over 150,000 lines and gave seg. faults several times:
f77: Signal 11 (segmentation violation) while compiling all.f
and several times just bailed out on me with:
f77: compiler error.
After fsplitt'ing this puppy I then ran into trouble with the
csh file globbing.
f77 *.f
would only work with up to 104 files. Any more and it just gave up.
Well I had about 2100 files and then I couldn't cat' them back together.
duncan:/disc1/rhodesii/ALL>cat*.f > all &
produces:
duncan:/disc1/rhodesii/ALL>Arguments too long.
[1] Exit 1 cat *.f > all
To be fair the Sparc2 couldn't do this either, but the IBM-320 did it
just fine. The IBM FORTRAN compiler (xlf) also was the only one of
the 3 machines that could eat the entire monolithic source. The Sparc2
started seg. faulting when the -Nx option got up to 3000. The HP and the
IBM seem to increase their table sizes "on the fly" and make another
go at it instead of just bailing out like the SUN's.
E) MISC. UNIX
1. Both df and ps are very SYS-V'ish so ps doesn't have the normal
plethora of Berkley options. They do provide a bdf which is o.k.
if you rewite your scripts and top and monitor commands can
kinda substitute for ps but neither of which are as
satisfying as having a clear consise ps (IMHO).
2. For symbolic links ln requires two args instead of
the 2nd being optional. i.e. you can't just ln -s ../foo
but must use ln -s ../foo foo
(I hate extra typing).
3. make can not handle a makefile with over 500 targets.
4. Couldn't find a ulimit,limit or unlimit command in csh.
some of our appplications would only run under the native ksh
(after bailing out complaining about system limits when
run under csh).
The only C-applications I took over were PERL3.0, less, and fsplit,
and my own X applications. No real problem here after finding
where the X11 libraries and include files were.
The interactive on the HP seemed to suffer more when large jobs
were running in the background than on the IBM (long repsonse
time between returns, unable to get its attention to rlogin etc.).
The HP software support seemed to be much better than IBM's
(which has been a nightmare for us since day 1).
I was able to talk to somebody who knew what was going on
right away. It takes hours with the IBM support just to get
a straight answer.
However, overall the HP-UNIX seemed a little crude compared to
the IBM AIX and the SUNOS as well. This surprised me since I
thought after acquiring Apollo that HP acquired a few years worth
of UNIX experience as well and that it would be more robust.
I have found that most of the changes in IBM's AIX really are
improvements in that they add extra functionality or make
something easier (except for things like maybe calling mt, tctl and
f77 (even if it's not BSD f77) xlf. I like the journaled file
system on the IBM much better than the SYS-V file system.
Additionally the IBM seemed more comfortable handling large files,
large numbers of files, and big jobs than either the HP or the SUN.
I am glad to see that HP sells the 720 with a minimum of 16 Meg.
We bought our IBM with 16 and after several frustrating months
increased it to 32 Meg (3rd party). If IBM had been upfront about
the memory requirements before hand we would have just gotten 32
Meg to start with and be done with it. Anyway IBM sells the 320
in an 8 Meg. configuration which I can't believe even has room
for the operating system :-)
Well, you can quote whetstones/dhrystones/livermore loops all you want,
but as a user the bottom line (all I really care about) is how
fast can it run MY application. Here is a small sample of what I saw:
CPU hrs
HP-720 2.7 f77 +O2 +Obb1200 (32 MEG. RAM)
IBM-320 4.8 xlf -qopt=2 -NQ30000 -NT40000 (AIX 3.1.5/xlf 2.1) (32 MEG. RAM)
Sparc2 6.2 f77 -fast -O3 -Nx1500 (SUNOS 4.1)(SUNOS 4.1/f77 1.4) (16 MEG. RAM)
The code in this case was SIMULATE-3, a 3D, nodal, multigroup
diffusion theory nuclear fuel cycle analysis code. This was about
the max. gain that we saw. Realistically (in our applications),
the HP-720 was about 2-2.3 times faster than the Sparc2 and about
1.5 to 1.8 times faster than the IBM-320.
As far as the Livermore loops went we saw an AVERAGE of about
10.8 MFLOPS for the HP, 7.1 for the IBM and 5.5 for the Sparc2
and repsective Whetstones ratings of 35461, 19305, 17513 single
precsion kips, and 31348, 20864, and 15244 double precision kips.
Actually for our applications everything pretty much scales
as the average MFLOPS.
Regardless of the nits expressed above, overall, I was very
impressed with the 720 and since we have a professor
and several summer students visiting us soon and we need another machine,
we probably will go ahead and get an HP-720 (we were told we could get
one in eight weeks). It didn't crash once during the 10 days that we had it
(our IBM used to panic regularly in its early days). We liked its
speed/throughput and it is always nice to have other compilers around,
but there are many small things that they could do to help make
me (the user) more productive.
-joel
--
-----------
Joel Rhodes * rhodesii@othello.studsvik.com
Studsvik of America,INC. * uunet!idaho!othello!rhodesii
Nuclear Code Development * Idaho Falls,ID. USA ph 208-522-8443fangchin@elaine52.Stanford.EDU (Chin Fang) (06/07/91)
In article <1991Jun6.151807.670@idaho.uucp> rhodesii@idaho.uucp (III) writes: > [some stuff delet, ] >MISC Nice features: > [stuff deleted] > 3. monitor- The refresh rate is much nicer than the IBM's > and easier on the eyes under fluororescent light. > The colors didn't seem as "saturated" as they are on our IBM. > The monitor doesn't have the huge "footprint" of the IBM either. > Thanks heaven! Finally another person echoed my feeling too on the net! LOOK! Austin guys, you have done a good job bring out a nice box, why let marketing people forcing you go with a low refresh rate monitor? The current screen refresh rate is at most 60Hz. TOO LOW! Drive it up to at least 70Hz. If anyone at marketing object this, I have a ready fix for you. Grab over this guy, put him/her in front of you BIG flickering SONY Trinitron, open a xterm (Sorry, I rm -rf aixterm looong time ago!) using xterm -bg whie -fg black -geometry 180x66, put this poor animal in front of it for two hours until he/she crys. Then you will get your way. On the other hand, please look at Thomas Roell's outstanding X386 refresh rate design (and the friendly tutorial that comes with it :-) > 4. The HP's X11 graphics is fast. Noticeably faster than an IBM-320's > and somewhat better than a Sparc-2 and the HP X11 is release 4 > and the MOTIF1.1 (the IBM X11 is release 3 and MOTIF1.0 and we > run MOTIF1.1.1 on our SUNS) > Same here. We use Motif 1.1.1 on SUN SPARCs too. Motif 1.1.1 is actually lots bug fixes for Motif 1.1 and now the implication of running Motif 1.0 is VERY clear, isn't it? Regards, Chin Fang Mechanical Engineering Department Stanford University fangchin@leland.stanford.edu
jwright@cfht.hawaii.edu (Jim Wright) (06/07/91)
rhodesii@idaho.uucp (III) writes: >It didn't crash once during the 10 days that we had it >(our IBM used to panic regularly in its early days). Were you running X11, and what window manager (vuewm, mwm, ???). I had a day to put a 720 through its paces. mwm dumped core a couple of dozen times. (No problems with vuewm though, it was sweet. Kicked ass compared to a 425.) -- Jim Wright jwright@cfht.hawaii.edu Canada-France-Hawaii Telescope Corp.
tml@tik.vtt.fi (Tor Lillqvist) (06/07/91)
In article <1991Jun6.151807.670@idaho.uucp> rhodesii@idaho.uucp (III) writes:
When trying to compile a large (268504 lines without comments)
^^^^^^^^^^^^
FORTRAN application monolithically (and w/o opt.) After
fsplitt'ing this puppy I then ran into trouble with the csh
file globbing.
f77 *.f
would only work with up to 104 files. Any more and it just
gave up. Well I had about 2100 files and then I couldn't cat'
them back together.
...
Joel Rhodes
Studsvik of America,INC.
Nuclear Code Development
Eek. This is the kind of programming they do in the nuclear industry?
268504 lines of Fortran (plus some comments, I hope) in one source
file...
Both df and ps are very SYS-V'ish so ps doesn't have the normal
plethora of Berkley options.
Well, at least the SystemV ps has a -u (for a specific user's
processes) option that BSD lacks.
--
Tor Lillqvist,
working, but not speaking, for the Technical Research Centre of Finlandsystem@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/08/91)
In article <1991Jun6.151807.670@idaho.uucp> rhodesii@idaho.uucp (III) writes: >Immediate disclaimer. I'm an expert in nothing, just a user >who had a chance to demo an HP-720 for 10 days and had a >chance to compare it to our IBM-320 and SUN Sparc2. > >MISC Nice features: > 1. It is fast what more can say. If it core dumps, it > core dumps fast! -and we saw plenty. Not my experience! It took 1-2 minutes to dump even small programs from csh (from rlogin sessions). If a background job core dumped, your foreground csh would hang for the duration. >C) FORTRAN > 7. The fortran compiler (quietly sometimes) links into the C library. > Sometimes it warns you, e.g. > > 8. Lack of FORTRAN callable flush and loc functions. I want to be > able to flush my own buffers, and I want to be able to implement > my own memory management routines w/o C calls. These are because there are no BSD libraries, though the IBM has very few BSD F77/I77/U77 routines either, and will happily link C versions with the same name. >However, overall the HP-UNIX seemed a little crude compared to >the IBM AIX and the SUNOS as well. This surprised me since I >thought after acquiring Apollo that HP acquired a few years worth >of UNIX experience as well and that it would be more robust. Apollo has had very little "real" UNIX experience (the kernel of Domain/OS is not real UNIX). Until late 1989, their only OS was Aegis, which is proprietary; they provided some user-level UNIX shells/commands as an overlay on Aegis. Based on the Apollo Users Group meetings, still 75% of their customers run Aegis as their primary environment; UNIX-only sites like ourselves have had a lot of problems. The history of HP-UX is much longer, but it is SYS5-based as you pointed out, which is a BIG pain. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
dhandly@hpcupt3.cup.hp.com (Dennis Handly) (06/08/91)
>/ rhodesii@idaho.uucp (III) / 8:18 am Jun 6, 1991 / > No real problem unless your application was trying to use unit 7 > for something else. I guess this is historical HP (?) I thought IBM did this too? (it has been > 20 years since I used it) > 4. Symbolic debugger- The symbolic debugger adb seemed to be powerful, You probably mean XDB. ADB is an assembly level debugger. > 5. The +T option of f77 is nice in that it will provide a trace back for > many exceptions and range errors (NaN generators). > However, the traceback doesn't > provide line numbers but merely routine names and addresses. I assume that it would work better, display line numbers, if you were debugging it with XDB and got a signal. > Well I had about 2100 files and then I couldn't cat' them back together. > >cat*.f > all & There is a command, xargs, that enables you to break up the number of files on a command to a fixed limit. (Or read them from a file) i.e. you could cat or compile 100 files at a time. >HP-720 2.7 f77 +O2 +Obb1200 ^^^^ How did you pick the value 1200 for the number of basic blocks? Is this big enough such that you didn't get any warnings about dropping to level 1 optimization?? I hope this information is useful. I work on the COBOL and Pascal compilers but I know a little, very :-), about Fortran...
se@IKP.Uni-Koeln.DE (Stefan Esser) (06/09/91)
|> ourselves have had a lot of problems. The history of HP-UX is much longer, |> but it is SYS5-based as you pointed out, which is a BIG pain. Sad to say, at least the HP-PA version of HP-UX is derived from BSD! (Have a look at the system header files, you'll find lots of BSD 4.3 'compatible' structures ...). HP sells it as Sys V.2 compatible, but they had to remove lots of BSD features to achieve this compatibility! While the Sys.V ps commands '-u uid' oprion is very nice, most other changes to make HP-UX Sys.V compatible several times made me quite angry. The print spool system is the worst I've ever seen on Unix. The spool partitions aren't seperated from root and user file system and the spooler has the habit of leaving spool files lying around, if there happens not to be enough disc space to hold the whole file! The user isn't notified, the file isn't removed from the spool dir (thus filling the disc further...) and the job will never be printed. You probably can imagine what happens every time a new user tries to print several big postscript files at once :-(. We had trouble with just about everything different from a vanilla BSD system. (.. archiver with 14 char limit, missing renice(), missing adjtime(), missing ulimit() capabilities, missing kernel config. capabilities, missing variable sized partitions support and so on :-( ) (BTW: the NFS problems reported to HP support more than a year ago aren'tanswered yet !) I got to know HP-UX too well and I'm glad we recently were able to get a nice, (small, cheap) server machine, that not only performs much better than our HP 9000/835, but also doesn't have so braindamaged 'features'. Stefan -- Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany se@IKP.Uni-Koeln.DE [134.95.192.50]
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/09/91)
In article <1991Jun8.170028.156828@rrz.uni-koeln.de> se@IKP.Uni-Koeln.DE (Stefan Esser) writes: > >|> ourselves have had a lot of problems. The history of HP-UX is much longer, >|> but it is SYS5-based as you pointed out, which is a BIG pain. > >Sad to say, at least the HP-PA version of HP-UX is derived from BSD! >(Have a look at the system header files, you'll find lots of BSD 4.3 >'compatible' structures ...). HP sells it as Sys V.2 compatible, but they >had to remove lots of BSD features to achieve this compatibility! Are you sure it is BSD-derived? All the missing utilities that you cite (and I found missing within about 5 minutes of using HP-UX) would point to a SYS5 origin, with some BSD include files added. I can't believe HP would deliberately remove things from a BSD port that did not impact SYS5 compliance (like 'renice', 'msgs', 'talk', ...), or would they ??? "Official" comments, HP? If it is BSD-based, why not still provide the BSD ps (and other) commands in another directory, which can be moved to the head of the $path/$PATH for users who prefer BSD options? -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
se@IKP.Uni-Koeln.DE (Stefan Esser) (06/10/91)
In article <1991Jun9.145014.14005@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: |> In article <1991Jun8.170028.156828@rrz.uni-koeln.de> se@IKP.Uni-Koeln.DE, I write: |> > |> >Sad to say, at least the HP-PA version of HP-UX is derived from BSD! |> |> Are you sure it is BSD-derived? ... |> ... I can't believe |> HP would deliberately remove things from a BSD port that did not impact |> SYS5 compliance (like 'renice', 'msgs', 'talk', ...), or would they ??? |> "Official" comments, HP? If it is BSD-based, why not still provide the |> BSD ps (and other) commands in another directory, which can be moved to |> the head of the $path/$PATH for users who prefer BSD options? Since there exists a version of 'top' (a process monitor for BSD systems) working nice on our HP 9000/835, I wanted to have the renice feature normally found in 'top', but missing in the HP version. It was really quite simple, there is a function to access kmem, I wrote a similar one to write kmem, made 'top' setgid 'kmem' and it works rather nice ... Adjtime can be simulated by a daemon process that patches a kernel variable (part of a HP-UX version of XNTP). If you look into these things, you find lots of BSD kernel structures hidden away and not simply accessible. Look at 'monitor' (in /usr/contrib/bin, not normally installed (?)). Look at 'vmstat', and 'iostat'. BTW since I had lots of trouble with the machine when starts swapping and wanted to get better control over whats happening (HP-UX swaps out all SMALL, ACTIVE processes on our system, when it starts swapping !!!), I took 'pstat' from our BSD Tahoe sources and compiled it with minor modifications. Would you ever expect this to be possible on a Sys.V kernel ??? Didn't you notice the way the kernel config works on the 9000/8xx (7.0) (don't know about 3xx, 4xx) ? Its a config file quite similar to VAX BSD 4.3, with some braces and semicolons added. Look at the VM kernel parameters. They look like BSD, not System V. I'm quite angry, because I miss lots of functionality. Its no fun to have a print spool system, that sometimes is capable of remote printing on BSD lpr systems, but sometimes doesn't send anything and at other times overflows the remote spool directory by sending the same file hundreds of times. Stefan -- Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany se@IKP.Uni-Koeln.DE [134.95.192.50]
martelli@cadlab.sublink.ORG (Alex Martelli) (06/10/91)
rhodesii@idaho.uucp (III) writes:
(a detailed and informative review)
Thanks for the work you put into this! I'd just like to pick a few nits and
contribute my own personal observations and biases...
:Immediate disclaimer. I'm an expert in nothing, just a user
:who had a chance to demo an HP-720 for 10 days and had a
:chance to compare it to our IBM-320 and SUN Sparc2.
On the other hand, I come from years with HP /300, /400, /500, etc etc, as
well as with Sun /3 and /4 and IBM 6150 and 6000 (we ported our apps to the
latter right after GA, at an IBM center). So maybe my viewpoint reflects
more of what one perceives after long experience, rather than first imp.s'...
: 2. The HP menu driven system administrator, "SAM" seems to
: be quite good and much easier to use than the IBM
: equivalent "SMIT" which I found just to get in the way
: more times than to be helpful. It took very little time
Me, I prefer SMIT - apart from the clumsy human interface, at least it
can build a SCRIPT which you can then study and tailor (very necessary
with IBM given the indifferent quality of their rambling, vast docs - on
the other hand HP docs are first-rate, pity you didn't get them!). It
also does logging.
: 5. HP-VUE 2.0 -I liked it. The workspace concept is good. I was
: also able to blow it away and get my own X environment up easily.
: The IBM Desktop manager thing is very poor in comparison.
Yes, but VUE is just TOO MUCH of a RAM hog! Well, maybe with 32megs...
: 1. keyboard- had a nice "touch," but the ESC and shift keys are
: just too small. Hopefully they will offer it with other keyboards.
I'm VERY much used to the HP layout (all the way from HP2393A's...) and I
love it, can't stand those ESC keys way up on the left, I risk left pinky
dislocation on ESC-intensive heavy typing (both vi and Emacs qualify!).
I second your motion for MORE END-USER CHOICE!!! on keyboards, on all
machines - whyohwhy don't they just adopt, say, the IBM-PC/AT kb interface
so one can buy Northgate or whatever keyboards!
: 2. I'm disappointed that HP doesn't support an 8mm tape drive (EXABYTE) on
: the 720. It appears that they have decided that the four formats
: they will support will be: CD-ROM, 4mm DAT, 1/2 inch and HP 1/4 inch.
Ditto, I like exabyte and (for data interchange) *standard* quarter-inch, I
love Sun/Sony/IBM/Olivetti/etc who are all going for those, and weep at HP and
DEC going their way with DAT and (different) proprietary quarter-inch tapes.
: 4. Symbolic debugger- The symbolic debugger adb seemed to be powerful,
: but I was REALLY discouraged because the syntax is so much different
: from the dbx on most other UN*X boxes and the window driven part is
I hope you mean xdb, adb is really NOT for application debugging, but rather
for kernel and assembly-level hacking! Anyway I share your opinion, xdb is
really powerful BUT *impossible* to adapt to coming from dbx with its simple
friendly syntax (and multiplatform guys like me which have to dbx all day on
Sun/Sony/IBM/DEC *HATE* having to switch to completely different syntax for
HP's powerful xdb, just as much as for, say, AT&T's original wimpy sdb...).
PLEASE, HP, GIVE US A DBX-SYNTAX-LIKE FRONT-END TO XDB!!!
: 7. The fortran compiler (quietly sometimes) links into the C library.
: Sometimes it warns you, e.g.
:Warning on line 58354 of testcomp.f: Wrong number of args to intrinsic free
: Last time I looked, free was not an f77 intrinsic. This meant that
: I had to go in and add external statements so it would use MY
: subroutine free. O.K. I know that if trying to write good,
: PORTABLE FORTRAN code, one should always declare one's function
: to be external, for just this circumstance, but there is a lot of
: code out there where people don't.
IBM's even worse in a way - if you do mixed C/Fortran, there are some
duplicate entries in recent xlf, such as SYSTEM(), that will quietly link
a call to system() in your C code to the SYSTEM() entry in the fortran lib,
resulting in weird and wondrous crashes (you have to explicitly put -lc to
avoid this). Whyohwhy don't all Fortran compilers do it like Sun, DEC, etc,
putting an extra underline after the routine name to get the symbol entry -
voila, no more risk of cross-language confusion!
: After fsplitt'ing this puppy I then ran into trouble with the
: csh file globbing.
: f77 *.f
: would only work with up to 104 files. Any more and it just gave up.
Etc etc, well I have a constructive suggestion for you here, use xargs(1): it
will read, for example, filenames from standard input, and pass them on as
commandline arguments in manageable chunks, e.g.:
ls|grep '\.f$'|xargs f77 -c
will turn all of your .f's into .o's, no matter how many there are. You will
then have to similarly collect them onto a few .a's for linking; it can be
done, though of course it's not as convenient as just having unlimited
numbers of args to a command.
: 2. For symbolic links ln requires two args instead of
: the 2nd being optional. i.e. you can't just ln -s ../foo
: but must use ln -s ../foo foo
: (I hate extra typing).
Well, I hate inconsistent interfaces even more! Since, for example, 'cp'
requires the target arg, so should ln, with or without -s. I believe this
is enshrined in the Posix standard, so it's probably coming to all boxes...
:However, overall the HP-UNIX seemed a little crude compared to
:the IBM AIX and the SUNOS as well. This surprised me since I
:thought after acquiring Apollo that HP acquired a few years worth
:of UNIX experience as well and that it would be more robust.
Even since ell before Apollo acquisition, HP has MANY years of unix experience.
I guess you just don't like System-V flavoured Unix... but I bet you will get
more used to it, what with the coming SV-flavoured Posix standards...
:I am glad to see that HP sells the 720 with a minimum of 16 Meg.
:We bought our IBM with 16 and after several frustrating months
:increased it to 32 Meg (3rd party). If IBM had been upfront about
:the memory requirements before hand we would have just gotten 32
:Meg to start with and be done with it. Anyway IBM sells the 320
:in an 8 Meg. configuration which I can't believe even has room
:for the operating system :-)
IBM does not sell 8-meg machines any more, 16 megs is now the minimum
configuration, I believe.
Again, thanks for your informative comments!
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).dlr@hpcndm.CND.HP.COM (Dominic Ruffatto) (06/10/91)
Stefan Esser writes:
(BTW: the NFS problems reported to HP support more than a year ago
aren'tanswered yet !)
I worked on NFS at that time. What was your problem? I may be able to help.mjs@hpfcso.FC.HP.COM (Marc Sabatella) (06/11/91)
>We had trouble with just about everything different from a vanilla BSD >system. (.. archiver with 14 char limit... BSD has this same misfeature. They are working on a solution for 4.4, and it probably will not be compatible with the solution SVR4 has adopted. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
jsadler@misty.boeing.com (Jim Sadler) (06/13/91)
>/ misty:comp.sys.hp / system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) / 7:50 am Jun 9, 1991 / >In article <1991Jun8.170028.156828@rrz.uni-koeln.de> se@IKP.Uni-Koeln.DE (Stefan Esser) writes: >> >>|> ourselves have had a lot of problems. The history of HP-UX is much longer, >>|> but it is SYS5-based as you pointed out, which is a BIG pain. >> >>Sad to say, at least the HP-PA version of HP-UX is derived from BSD! > >Are you sure it is BSD-derived? All the missing utilities that you cite I've been told that it is. >(and I found missing within about 5 minutes of using HP-UX) would point >to a SYS5 origin, with some BSD include files added. I can't believe >HP would deliberately remove things from a BSD port that did not impact >SYS5 compliance (like 'renice', 'msgs', 'talk', ...), or would they ??? They would and did. >"Official" comments, HP? If it is BSD-based, why not still provide the >BSD ps (and other) commands in another directory, which can be moved to >the head of the $path/$PATH for users who prefer BSD options? To steal and paraprase a line "Inquiring minds want to know" I would like know why I've "suffered" all these years. >Mike Peterson, System Administrator, U/Toronto Department of Chemistry ---------- jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
shankar@hpcupt3.cup.hp.com (Shankar Unni) (06/13/91)
In comp.sys.hp, martelli@cadlab.sublink.ORG (Alex Martelli) writes: > Etc etc, well I have a constructive suggestion for you here, use xargs(1): it > will read, for example, filenames from standard input, and pass them on as > commandline arguments in manageable chunks, e.g.: > ls|grep '\.f$'|xargs f77 -c Ah, but beware of xargs. You can't use it, for example, in a Makefile, because: - it will terminate abnormally only if its command argument terminates with -1. No other exit value will cause it to abort. - it returns 1 if it could not execute the command, or if the command returned -1. Else, it returns 0. Always. Regardless of whether any of its invocations of the command failed. This bit one of our customers recently. I couldn't believe it until I read the relevant XOPEN page, but there it was. However, it does make a weird kind of sense. ----- Shankar Unni E-Mail: HP India Software Operation, Bangalore Internet: shankar@india.hp.com Phone : +91-812-261254 x417 UUCP: ...!hplabs!hpda!shankar
jsadler@misty.boeing.com (Jim Sadler) (06/14/91)
/ misty:comp.sys.hp / dlr@hpcndm.CND.HP.COM (Dominic Ruffatto) / 8:10 am Jun 10, 1991 / >Stefan Esser writes: >(BTW: the NFS problems reported to HP support more than a year ago >aren'tanswered yet !) > >I worked on NFS at that time. What was your problem? I may be able to help. How about the ability to export sub-directories only. Not complete file systems. ---------- jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
alek@spatial.com ( Alek O. Komarnitsky ) (06/17/91)
In article <1150073@misty.boeing.com> jsadler@misty.boeing.com (Jim Sadler) writes: >/ misty:comp.sys.hp / dlr@hpcndm.CND.HP.COM (Dominic Ruffatto) / 8:10 am Jun 10, 1991 / >>Stefan Esser writes: >>(BTW: the NFS problems reported to HP support more than a year ago >>aren'tanswered yet !) >> >>I worked on NFS at that time. What was your problem? I may be able to help. > How about the ability to export sub-directories only. Not > complete file systems. >---------- My apologies if I've totally missed this one, but how about some options in the exports file? Specifically: -root=hostname... (and -ro). My current solution is using adb to map nobody to 0 in /hp-ux at boot time, but that's not desireable for obvious reasons. Alek Komarnitsky 303-449-0649 Software Tools Manager, Spatial Technology, Inc. 2425 55th Street, Bldg A alek@spatial.com Boulder, CO 80301-5704
dlr@hpcndm.CND.HP.COM (Dominic Ruffatto) (06/17/91)
> How about the ability to export sub-directories only. Not > complete file systems. > My apologies if I've totally missed this one, but how about some options > in the exports file? Specifically: -root=hostname... (and -ro). > My current solution is using adb to map nobody to 0 in /hp-ux at > boot time, but that's not desireable for obvious reasons. These two features are part of the SunOS 4.0 version of NFS. I agree that they are useful features that I personally would use if they were made available. Remeber the elusive cut line that you keep hearing about? Well, 4.0 enhancements are another victim of the cut line. I am not defending the cut line just stating what happened. The NFS responsibility has moved on to another group. Their organization is better positioned to add enhancements such as these. I will pass your requests on to them hopefully they will have the bandwidth to work on these features. Dom DISCLAMER: The opinions stated above are my own, not my employer.