Mark Hahn wrote:
>
> nit: linux user programs are not limited to 3G, since those constants
> can trivially be adjusted.
I assmume you're talking about the user/kernel division of the 4 GB
address space? This is just a tuning issue. The point of the article
where I talk about the 3/1 GB split is to show commonalities between
Linux and UnixWare. It makes the differences stand out better.
> nit: "dshm" is trivially achievable under Linux, using mmap, as far as
Hmmm, I hadn't thought about that -- obvious in retrospect, really.
Still, I'm missing something: when you unmap a mapped segment to map
something else into your address space, how do you ask the kernel not to
reuse that memory: to leave it alone until you map it again? The man
page does not enlighten. (Not surprising since the man page says it was
last changed four years ago...)
> I'm not sure what you mean by UW making 8G "directly" available.
> do you mean that UW programs are permitted to use some number of
> different 4G segments? do me, "directly" means that they can be
> accessed by a simple pointer dereference, so dshm is clearly not
> direct, since it's just another bank-switching mechanism.
My understanding is that user programs on UnixWare cannot collectively
use more than 8 GB of memory without resorting to dshm, period. If you
had nine processes that all malloc()'d 1 GB, you'd get an out-of-memory
error on a 16 GB machine. This is an extension of the typical SCO modus
operandi: never allow a single program to exhaust all resources.
> I don't understand the point of the bit about fork-style multiprocessing.
> nothing about PAE has anything to do with fork; nor does PAE effect whether
> apps are monolithic or uh, whatever the alternative is.
When I talk about "one program allocating foo gigabytes of memory", that
can mean either a single process or a collection of processes forked
from a single parent. In both cases, you can think of it as "one
program". It's just a distinction I had to put in to preseve accuracy;
I'll review it to see if it causes more problems than being slightly
unclear does. Or, I may abandon the "program" term entirely, and stick
with "process".
> the bit about needing 21 3G processes is just plain silly.
Hmmm, the tact dial isn't cranked very high today, is it? :)
> also, your feature article is wrong about 2G files.
>
> I'm not sure where you get the 128 disk limit, either.
Obviously I've tried to find the right answers: these are what I've
found. If they're wrong, you telling me this doesn't help. Please tell
me what the right values are, and I'll use those instead.
The disk limit I know I'm unsure on: I've also seen 240: 15 devices per
bus, times /dev/sd[a-p], being 16 busses. I can't remember the
justification for 128. Anyway, tell me what the real number is and why,
and I'll use that. Obviously devfs in 2.4 changes this.
As for 2 GB files, it's my understanding that this is going away in 2.4,
as I state in the Future Linux Developments section. If it's gone for
32-bit systems in 2.2, it's news to me.
> it's amusing but sad that most of your complaints about linux
> are strictly complaints about the obsolete 2.2 series. which
> of these features did UW have when 2.2 was released?
"Obsolete"? <amused grin>
You have to understand that the SCO crowd is super-conservative. Using
a development kernel in a production environment simply isn't an option
-- stable or not -- if for no other reason than that support is harder
to find. These aren't the rules Linux typically plays by: they're the
rules of SCO's customers, which you'll have to play by if you want to
sell Linux to them.
> the mindcraft "benchmarks" were not "incindiary". they were asinine.
> surely you know that they were rather dishonest.
There was nothing actually dishonest about what Mindcraft did. The test
was unrealistic, they dragged their feet on explaining their
methodology, and they gave Windows NT advantages they didn't give to
Linux, but none of this is dishonest. Perhaps the term you want is
"immoral". :)
> please explain how "add-on" HA is inferior to built-in.
Neither OS has built-in HA, it's just that SCO's HA efforts are 1) more
mature; and 2) available from the same company that sold you the OS.
Again, understand the SCO mindset here: "lash it together yourself out
of this collection of freeware" does not play in the SCO world. If it
isn't productized (and preferrably integrated), it's inferior.
TurboLinux's clustering stuff is probably getting close to SCO's, but
even then, it's hard to use that as an example without changing the
focus of the article to "UnixWare versus TurboLinux".
> please explain how Linux doesn't support your "very high-end server hardware"
> like 10x SMP.
I understand that Linux has been run on at least 14-processor systems,
but scalability is never covered in these announcements. You have to
give UnixWare credit: it does do a pretty good job of scaling well as
you add processors. Linux 2.2 at least demonstrably tanks when given
more than 4 processors.
SMP scalability is not a binary feature: the tuning never stops. Every
time you reduce contention on one lock, you just bubble another lock to
the top of the hot lock list. Then throw in things like ccNUMA: the
process begins again. Yes, Linux keeps doing better at this, but SCO's
been at it a lot longer, and they keep working on it, too. Keep in
mind, UnixWare as a product goes back to at least 1993 or so, and the
code base goes clear back to System III in 1982.
The final metric is, if you had a 10 CPU box, what would be saner to run
on it, Linux or UnixWare, all else being equal?
> coming with motif and CDE is a good thing? if you think so,
> then you've never programmed with either.
"Motif is ugly, Motif is old, Motif is not Open Source..." I've heard
it for years, but Motif endures. Is that not enough reason to include
commentary on it?
> "pretty admin tools" is entirely a religious issue.
Um, okay. :) If you doubt that it matters, well, it's a good thing
you're not calling the shots.
What do you think would happen if Red Hat stopped including Emacs with
the distro? Let's say the top brass goes and decides vi is better. All
else being equal, their market share would probably drop to a _tenth_
what it is now, even though Emacs "only" accounts for roughly half the
market vis a vis vi. Why? Linux installed on a multiuser machine has
to make all those users happy. If half the users on the machine want
Emacs, they're gonna give this hypothetical Red Hat distro a miss.
The same applies to pretty admin tools.
> again, it's dishonest to talk about "linux's IO scalability limits",
> since you seem to be comparing Linux circa late 1998 to UW (when?)
We'll talk again when solid numbers start coming out for 2.4.
> do you actually have numbers showing that SMP permits UW to catch
> up to Linux networking?
Have you read The Cluetrain Manifesto? The authors point out that the
Internet lets employees talk directly with customers, and that those
employees tell the truth about what's going on. The Internet undermines
the facades that companies try to erect.
I have a few sources inside SCO like that: I trust them absolutely.
Based on reports from these sources, I tell you that SCO's numbers show
that UnixWare takes over in network performance at about the 8 processor
level. Further, those numbers were for UW 7.0, before all the
networking improvements in UnixWare 7.1 and 7.1.1. These latter
developments might well have nullified the relative improvements we'll
see with Linux 2.4, so that both UnixWare and Linux do better on these
tests, resulting in the same overall result.
Understand what this means: Linux may be far faster than UnixWare on a
uni- or dual-processor system, but it loses that advantage through
inefficient use of multiple processors. Big SMP boxes are a fact of
life at the high end: Linux will have to learn to work well on them if
it wants to be called an enterprise OS.
> forget about UDI. it's toast.
I don't agree. UDI might suck like a tornado, but once the drivers
start coming out, there _will_ be pressure to move UDI support into the
main kernel. No doubt the distro makers will do it as an add-on like
pcmcia-cs is in 2.2, but Monterey could make UDI a reality. Given that,
it's important that Linux be able to use those drivers.
> so, why does lack of "extremely tight platform integration" cost Linux?
> I can think of no case where there's any performance or maintenance hit
> for ia32.
Hot swap PCI, multipath I/O, HBA/NIC failover, ccNUMA on IBM/Sequent and
Unisys boxes.... Enough?
> what does "well-placed" mean? how is linux suffering from the fact
> that it does not support the (very traditional) marketing lie that
> "servers" are qualitatively different from PCs?
Has Linux achieved all its platform goals while I wasn't looking?
Turn that statement around, and it says "SCO is happy where it is, but
Linux is entering new markets." As an investor, which is the bigger
growth opportunity?
> you should explore the "quad cost but drop-in" and "single-source
> is better than open-source" issues. or perhaps even the "binary
> kernel interfaces stifle kernel improvements".
I did not say "quad cost", I said "double or triple" and that only when
talking about the Mindcraft stuff. UnixWare and NT are comparable in
their hardware requirements, so I don't think "quad" is justifiable.
That nit aside, you propose an interesting idea, but useful cost
analyses would take a whole book to write up.
As for binary interfaces stifling improvements, sorry, it isn't true.
All of SCO's kernel ABIs are versioned, which lets them change the
interfaces at will: old drivers can ask for and get the old interfaces
while newer drivers use the new interfaces. What this _does_ cause, and
I do mention it, is bloat and complexity: there are now eight different
versions of SCO's device driver interface, for example. I don't know if
UnixWare supports all eight still, but it does support several of them.
I'll consider exploring the sourcing issue in more depth, but at the
moment I think I'm satisfied with just pointing it out.
-- = Warren Young, maintainer of the Winsock Programmer's FAQ at: = http://www.cyberport.com/~tangent/programming/winsock/ = = ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:20 EST