64bit UNIX
Tim Ruckle
In article <bryDov...@netcom.com> b...@netcom.com (Bryan Althaus) writes:
} : Evan Leibovitch (ev...@telly.telly.org) wrote:
} : : (Dare I suggest that Sun's resistance against NIH technologies such as
} : : Motif, has been a significant contributor to the Unix fragmentation
} : : Jim so despises? This scenario appears ready to repeat itself, as Sun
} : : shuns attempts to forge an industry-wide 64-bit standard.)
Apparently Sun doesn't see a 50% plus share an industry-wide standard (Like
in Jim's case, for them Unix is definable: Solaris ;^).
} Bryan Althaus (b...@netcom.com) wrote:
} : If their is to be an industry-wide 64-bit standard, first Digital and
} : SGI should join in since they are the only companies that *already*
} : have 64bit OS's.
On the other hand, why should Digital and SGI cooperate with rival Sun when
they already have a technological lead? The "fragmentation" occurs because
everybody needs to differentiate with their value-adds (and fundamentally,
these companies don't trust, much less even like, each other very much |^).
BTW, SGI is going to have a seat on the UTG with its acquisition of Cray...
} : It's nice that HP & SCO have decided to form a 64bit standard, but why
} : are they doing anything different than Sun or IBM?
It's nice that Sun & USL agreed to merge SunOS and System V UNIX, but why
did Sun decide to immediately diverge with their own proprietary SVR4.0?
(and BTW, what *is* IBM doing in this regard?)
} : If there is going to be a standard, everyone is going to have to
} : compromise which is not easy when Digital, SGI, Sun, IBM & HP are
} : competitors.
Indeed. But as an independent software systems provider, with no particular
hardware loyalties, SCO is uniquely positioned to broker a real consolidation
(standards are good for the industry, but that doesn't imply a consolidation:
all the major players support all the major standards).
And the reason why OEMs are coming on board with 3DA is that it's incredibly
expensive to maintain, develop and improve a proprietary OS. Upwards of
$100,000,000.00 a year just to stay current (never mind new features and
technologies). You need a very large volume of hardware sales to make up
for that cost, and most of the OEMs just don't have it. Even HP, which is
right up there in the RISC market, came to the realization that doing the
64-bit work just for their own iron would not show a good (or any) return
on the investment.
But with the SCO deal the cost of that work will be amortized over the volume
shrink-wrapped UNIX-on-Intel sales, as well as from other OEMs. There's just
no reason for everybody to separately re-invent the wheel and duplicate their
efforts (particularly with Microsoft presenting the first real challenge in
the SMB space since the DOS-heads went wild with NetWare). The sweat equity
of this industry would be much better spent on real innovation.
} Actually, good news:
}
} A single Unix spec
}
} In August 1995, Intel rounded-up the major Unix vendors to get all of
} them to agree on a few specifications relating to 64-bit computing.
} After six months of work, the "Aspen Group," as the collective was known,
} announced it had "reached consensus on the goal of this initiative to
} seamlessly incorporate 64-bit applications in a single Unix specification.
Again, standards are very useful but do not necessarily imply an industry
consolidation. How many of the UNIX flavors are POSIX compliant?
SCO and HP are jointly driving the development of a modular 64-bit OS
based on ASPEN (that standard 64-bit UNIX API). The difference being
this's a single, consistent and extensible core technology set with
common APIs and ABIs so that apps can run unmodified on both HP and
SCO products.
And while these products will take full advantage of the next-generation
of standard Intel-based (Merced, the so-called ``P7'') CPUs, due to its
3D architecture it can also be optimized for any other advanced silicon
with no degradation or proprietary hoop-jumping: OEMs can add value and
differentiate while *still* maintaining the common source base and ease
the porting burden on the apps developers.
NEC and Hitachi have already committed to adopt this new technology and
provide significant development resources. NEC intends to build a MIPS
"port", and other OEMs are actively involved (Alpha chip support is also
reportedly in the works).
Ultimately, though, the Holy Grail of a single, homogenized ``Unified UNIX''
will likely never be found (at least, not in our lifetimes ;^). Sun will
never adopt a consolidation brokered by SCO and endorsed by arch-rival HP.
But they'll continue to compete aggressively with their quality products,
and competition is a good thing for the industry. And I'm sure SunSoft
will continue to be a technology provider via the "coopetition" we have in
this industry (for instance, SCO's getting Java via their Netscape deal).
And heck, it could be *much* worse: if it were up to Microsoft we'd still
be heatedly debating whether anybody really needs more than 16-bits in the
first place... %'/
At least, that's my opinion (though not necessarily SCO's).
Best Regards,
Tim
--
Everyone will go this way: If you have a monolithic block of code, any
change to any part of the OS could make the whole thing come down like a
house of cards.
--Dan Kuznetsky, director of Unix systems research at IDC
Bryan Althaus
: In article <bryDov...@netcom.com> b...@netcom.com (Bryan Althaus) writes:
: } : Evan Leibovitch (ev...@telly.telly.org) wrote:
: } : : (Dare I suggest that Sun's resistance against NIH technologies such as
: } : : Motif, has been a significant contributor to the Unix fragmentation
: } : : Jim so despises? This scenario appears ready to repeat itself, as Sun
: } : : shuns attempts to forge an industry-wide 64-bit standard.)
: Apparently Sun doesn't see a 50% plus share an industry-wide standard (Like
: in Jim's case, for them Unix is definable: Solaris ;^).
Does *anyone* think SCO is the industry-wide standard. Other than SCO
employess ;)
As for the 50%. I have seen this number range, but no where near 50%.
Let me ask you, if someone buys a SunServer 2000, gets the one license,
and has 1000 users running on it. That is considered one license.
A dentist's office buys a license of SCO to run Dentis 2000, and this
is considered one license.
Only in the first case you have 1000 people using Solaris and in the
second case a hand full of employees.
Going by number of users, SunOS/Solaris is the leader. From Fortune 2000
to Universities, the number of users is quite large.
: } Actually, good news:
: }
: } A single Unix spec
: }
: } In August 1995, Intel rounded-up the major Unix vendors to get all of
: } them to agree on a few specifications relating to 64-bit computing.
: } After six months of work, the "Aspen Group," as the collective was known,
: } announced it had "reached consensus on the goal of this initiative to
: } seamlessly incorporate 64-bit applications in a single Unix specification.
: Again, standards are very useful but do not necessarily imply an industry
: consolidation. How many of the UNIX flavors are POSIX compliant?
Did you read the part about being added to SPEC 1170 which Sun supports?
According to a prepared statement, the 64-bit consensus will
be added to SPEC 1170, which X/Open now calls the X/Open
^^^^^^^^^^^^^^^^^^^^^
Single Unix Specification. The Aspen Group agreed to "LP64,"
a common data representation model, "a common set of
extensions to the POSIX Threads interface, dynamic linking
interfaces to support the emerging class of extensible
self-configuring applications, and agreed to implement common
POSIX APIs for software installation user group management."
The Unix vendors collaborating on the single Unix specification
comprise of industry heavyweights, including Digital Equipment,
Hewlett-Packard, IBM, Intel, Novell, NCR, Santa Cruz
Operation, and SunSoft. --Mark Cappel
^^^^^^^
^^^^^^^
: SCO and HP are jointly driving the development of a modular 64-bit OS
: based on ASPEN (that standard 64-bit UNIX API). The difference being
: this's a single, consistent and extensible core technology set with
: common APIs and ABIs so that apps can run unmodified on both HP and
: SCO products.
: Ultimately, though, the Holy Grail of a single, homogenized ``Unified UNIX''
: will likely never be found (at least, not in our lifetimes ;^). Sun will
: never adopt a consolidation brokered by SCO and endorsed by arch-rival HP.
^^^^^^^^^^^^^^^
Actually, have you read IW column about how HP is going to be telling SCO
what to do. Sum of the article, SCO is just too small a company and will
wind up doing what HP says.
Tim Ruckle
In article <4jp5lu$8...@panix.com> br...@panix.com (Bryan Althaus) writes:
} Tim Ruckle (ti...@sco.COM) wrote:
}
} Does *anyone* think SCO is the industry-wide standard. Other than SCO
} employess ;)
You missed my point (though SCO *is* clearly the industry-wide standard
for UNIX on Intel, as well as in the server market ;^).
} As for the 50%. I have seen this number range, but no where near 50%.
In the server space SCO is near 50% (40% source: IDC) but again you
missed the point. Was I really being that obtuse?
That over 50% of the market number is for those who're on board for
the 64-bit 3DA (SCO, HP and various other OEMs).
} [...]
} : Again, standards are very useful but do not necessarily imply an industry
} : consolidation. How many of the UNIX flavors are POSIX compliant?
}
} Did you read the part about being added to SPEC 1170 which Sun supports?
Yes, and again you missed my point. First off, 3DA *is* being built on the
Aspen work. And more to the point, what about all the standards that SCO
and Sun (and many others) already support? XPG4, SVID3, FIPS/POSIX, etc...
Does this mean that porting/maintaining apps between the various flavors
is trivial?
With SCO and HP the apps will run unmodified. And any way you slice it
that's a lot bigger market share than Sun.
Regards,
Tim
--
We have now sunk to a depth at which the re-statement of the obvious is the
first duty of intelligent men.
--George Orwell
Bryan Althaus
: You missed my point (though SCO *is* clearly the industry-wide standard
: for UNIX on Intel, as well as in the server market ;^).
No question SCO rules UNIX on Intel big time and they deserve it. They
have been around a long time, and managed to keep their customers
happy. As for the server market, what % of internet servers run SCO
or will? This is the biggest growth area for both UNIX and NT.
: } As for the 50%. I have seen this number range, but no where near 50%.
: In the server space SCO is near 50% (40% source: IDC) but again you
: missed the point. Was I really being that obtuse?
: That over 50% of the market number is for those who're on board for
: the 64-bit 3DA (SCO, HP and various other OEMs).
OK, and so your saying Sun, DEC, IBM, and SGI should do what? SCO & HP
teaming up is the same as when AT&T and Sun teamed up. Other OEMS
will account for a small piece of the pie. Are any of the OEM's
DEC, IBM, SGI? Maybe Microsoft?
Every company wants to be in control of their own destiny, and some
companies feel they can develop the technologies that will make
them successful. What are SCO & HP doing when it comes to stuff
like Sun's NEO?
Neither SCO nor HP has a track record for developing industry wide
technolgies.
I'm glad that SCO & HP have teamed up and hope that they hit the 50%
mark. I worked on HP-UX for over 4 years and know that HP-UX 7.0,
8.0, 9.x and 10.x are lacking. HP needs a great OS to go with their
great hardware and that's why they are doing this, period.
: } [...]
: } : Again, standards are very useful but do not necessarily imply an industry
: } : consolidation. How many of the UNIX flavors are POSIX compliant?
: }
: } Did you read the part about being added to SPEC 1170 which Sun supports?
: Yes, and again you missed my point. First off, 3DA *is* being built on the
: Aspen work. And more to the point, what about all the standards that SCO
: and Sun (and many others) already support? XPG4, SVID3, FIPS/POSIX, etc...
: Does this mean that porting/maintaining apps between the various flavors
: is trivial?
We've ported entire projects between UnixWare and Solaris and it was
a dream come true since both were SVR4. About the only thing that would
be a problem porting the code back to UnixWare from Solaris now would be that
the Solaris code is now threaded. With POSIX threads on both UnixWare
and Solaris, this problem would go away. This was before SPEC 1170.
When SCO/UnixWare are merged, I should hope that a port to that platform
would be just as easy, and when the SCO/HP-UX OS appears, the porting
effort hopefully will be similar.
These are good *things*, but its as close to unified as UNIX will get.
Larry Miller [DT]
: We have now sunk to a depth at which the re-statement of the obvious is the
: first duty of intelligent men.
: --George Orwell
Nice quote-- do you know the work in which it was published?
Saludos--
Larry Miller
Administrador de Redes / Network Administrator
Centro de Investigaciones Biologicas del Noroeste, La Paz, BCS Mexico
lmi...@cibnor.conacyt.mx
Jouko Holopainen
>
> Tim Ruckle (ti...@sco.COM) wrote:
> : Does this mean that porting/maintaining apps between the
> : various flavors is trivial?
> We've ported entire projects between UnixWare and Solaris and it was
> a dream come true since both were SVR4. About the only thing that would
> be a problem porting the code back to UnixWare from Solaris now would be that
> the Solaris code is now threaded. With POSIX threads on both UnixWare
I would quess that UW20 has POSIX threads. I do not know about POSIX,
so cannot be sure.
But the biggest question is: How I can plan ahead so that my software
(and hardware) would be as portable as possible? Including devide
drivers. (PCMCIA support? SCO listening?)
> When SCO/UnixWare are merged, I should hope that a port to that platform
> would be just as easy, and when the SCO/HP-UX OS appears, the porting
> effort hopefully will be similar.
I REALLY would like some HW porting possibilities too. With PCMCIA support.
Developing different card for each platform (processor) is just too
expensive.
> These are good *things*, but its as close to unified as UNIX will get.
--
Jouko Holopainen X-Net Oy
Teknologiantie 4 FIN-90570 Oulu
FINLAND GSM: +358 50 5126166
jouko.ho...@xnet.otm.fi
Bryan Althaus
: Bryan Althaus wrote:
: >
: > Tim Ruckle (ti...@sco.COM) wrote:
: > : Does this mean that porting/maintaining apps between the
: > : various flavors is trivial?
: > We've ported entire projects between UnixWare and Solaris and it was
: > be a problem porting the code back to UnixWare from Solaris now would be that
: > the Solaris code is now threaded. With POSIX threads on both UnixWare
: > and Solaris, this problem would go away. This was before SPEC 1170. ?????
: I would quess that UW20 has POSIX threads. I do not know about POSIX,
: so cannot be sure.
Sorry, by problem I meant that before POSIX threads came out, you had
to use each OS's proprietary API. So currently we use the Solaris threads
API. So to create a thread we use : (void *) foo(int arg); int arg;
thr_create(NULL, NULL, foo, (void *) arg, NULL, NULL ); // not portable
instead of the POSIX way to create a thread:
pthread_create( NULL, NULL, foo, (void *) arg); // portable
Once we changed our thread code to use POSIX pthread's, the code will
run on any machine that supports the API.
As for UnixWare 2.x, I know they support UI threads which might be the
same as the Solaris threads. I'm not sure. In any case, porting becomes
easy.
David Stone
Dave Stone
Robert Lipe
>Sorry, by problem I meant that before POSIX threads came out, you had
>to use each OS's proprietary API. So currently we use the Solaris threads
That's certainly dampened the widespread acceptance of them.
>As for UnixWare 2.x, I know they support UI threads which might be the
>same as the Solaris threads. I'm not sure. In any case, porting becomes
>easy.
I've never seen the package in question, but just today in
comp.unix.bsd.freebsd.announce was an article announcing
the release of a POSIX thread library for several UNIXen
including SCO, Linux, and Solaris. I imagine it would work
on UW2 with minimal bludgeoning, but since I've not seen the
code, I can't say. Given the variety of OSes that it supports,
it must be at least moderately portable.
See ftp.cs.fsu.edu:/pub/PART or the original posting in that
group for more info.
This could be a Good Thing to encourage programmers to use
threads....or not.
--
Robert Lipe
Kaleb KEITHLEY
>I would quess that UW20 has POSIX threads.
Your guess is wrong. Unixware 2.0 has SVR4 threads.
--
Kaleb KEITHLEY
Michael Hancock
> API. So to create a thread we use : (void *) foo(int arg); int arg;
>
> thr_create(NULL, NULL, foo, (void *) arg, NULL, NULL ); // not portable
>
> instead of the POSIX way to create a thread:
>
> pthread_create( NULL, NULL, foo, (void *) arg); // portable
>
> Once we changed our thread code to use POSIX pthread's, the code will
> run on any machine that supports the API.
>
> As for UnixWare 2.x, I know they support UI threads which might be the
> same as the Solaris threads. I'm not sure. In any case, porting becomes
> easy.
Solaris threads are UI threads. For a good POSIX threads book that also
covers UI threads get "Programming with Threads" by Steve Kleiman, Devang
Shah, and Bart Smaalders from SunSoft Press/Prentice Hall.
--
Michael Hancock
mich...@cet.co.jp
Li Zhengchun
>
> Jouko Holopainen <jouko.ho...@xnet.otm.fi> writes:
>
> >I would quess that UW20 has POSIX threads.
>
> Your guess is wrong. Unixware 2.0 has SVR4 threads.
Some people call them that, most references call them UI threads (Unix
International threads).
-mh
Tim Ruckle
In article <4jrl0q$6...@cibnor2.cibnor.conacyt.mx>
lmi...@cibnor.cibnor.conacyt.mx (Larry Miller [DT]) writes:
} Tim Ruckle (ti...@sco.COM) wrote:
}
} : We have now sunk to a depth at which the re-statement of the obvious is the
} : first duty of intelligent men.
} : --George Orwell
}
} Nice quote-- do you know the work in which it was published?
Hi Larry,
It is supposed to have been quoted from an interview in the Wall St. Journal
but I don't have an exact date.
Glad you liked it.
Regards,
Tim
--
It was a bright cold day in April and the clocks were striking thirteen.
--George Orwell (psuedonym of Eric Blair), first line of _1994_