rclark@bgphp1.UUCP (Roger N. Clark) (05/05/88)
There have been several articles recently about how some code from Suns does not port easily to HP-UX. The main reason seems to be HP-UX is System V and Sun is BSD. Now coming up is POSIX. I haven't seen the specs yet, but I get the impression that POSIX is more like System V. Can someone comment on this? In particular, what systems are currently closer to POSIX (i.e. which programmers are going to have to change more to be POSIX compatible)? I know HP is committed to standards (so is Sun; there are so many standards to choose from ;-), but does anyone know when HP, Sun, etc might reasonably be POSIX compliant? When that does happen, will some of these problems go away? Roger N. Clark bgphp1!rclark
donn@hpfcdonn.HP.COM (Donn Terry) (05/11/88)
I can't quote dates (even if I knew them), but I'm quite sure that Sun
and HP both (along with everybody and his uncle) will be POSIX compliant
"very soon"; it's very important in the marketplace to be that.
Sun is BSD based, and HP is System V based, and almost ALL of the
flamage in this group comes from that difference. (The fact that HP has
a lot of Berkeley features and Sun has a lot of System V features may in
fact cause further flames because the distinction isn't as blatantly
obvious as it is between a pure System V and a pure BSD system.) The 14
character limit, for example, exists because a very large number of
System V applications (not provided by HP) hardwired 14 into their
programs, and they would have broken had that changed earlier; as
it is the 800 supports both possibilities, and it was painful to
figure out how to best protect the investment in the 14-character
programs. (Yes, there is a valid argument that such programs
are broken, but they do exist, and in large numbers; NFS and POSIX
are making it obvious that they are broken, and they are now getting
fixed.)
However... POSIX won't help all the problems, as the current standard
does not cover all the areas of difference between System V and
Berkeley. The "fancy" terminal features, and datacomm in general, are
not covered. Like it or not, POSIX is close to a least common
denominator standard for Sections 2 and (parts of) 3. At least reliable
signals and job control are present in it.
Applications writers, who are the ones who really need the help provided
by the standard, are in significantly short supply in the standards
business. Mostly vendors are represented, and whether it is "right"
or not, much of the vendor representation is directed at protecting
current investment in the system the way it is. Applications writers
should participate actively; those that currently do have a significant
influence in getting the features they need to do their job into
the standard. (I'm sure those POSIX participants who are application
writers and who read this are taking my name in vain right now: yes,
we really DO listen to you, but like everyone else you don't get
everything you want, particularly if you consider "no change" to be
something that vendors often want.)
All this leads up to an invitation (again...). Please participate in
the standards process if you have something useful to contribute.
You don't have to attend meetings; you can participate by mail as well.
The next meeting is at the Denver Tech Center Marriott in July.
(It isn't "free" any longer; the cost of mailings was driving IEEE
into poverty. Considering that you get umpteen copies of draft
standards per year, it's well worth it.)
Contact me if you are interested enough to actively participate.
Donn Terry
Co-Chair, IEEE P1003.1
HP
{hplabs!}hpfcla!donn
Speaking (mostly) with my standards hat on.