[SLUG] Re: AT&T Testing Linux as Windows Replacement

From: Bryan J. Smith (b.j.smith@ieee.org)
Date: Tue Oct 05 2004 - 19:40:44 EDT


On Tue, 2004-10-05 at 18:24, Steven Buehler wrote:
> Most of AT&T's server environment is Windows or UNIX-based.

If I say I believe you on that point (I don't know either way), can we
stop talking about servers? From the article I read:
http://quote.bloomberg.com/apps/news?pid=10000103&sid=aZ2JnBlm5tOs&refer=us

It looks like the current testing is a _desktop_ consideration for its
70,000 PCs. I don't want to argue, and I'm trying to be nice. But I'm
kinda shocked when I see Linux enthusiasts not realizing just how far
Linux adoption has _already_ gone. This isn't about just servers
anymore, we're talking widespread adoption on the enterprise _desktop_.

Linux has already infiltrated the server, control and embedded systems
market. And this is more than just as a web server, but as a server and
services platform for everything from aerospace to, indeed, the major
telecom carriers. Really the only remaining users are the SMBs (small
to medium businesses) and consumers that have not brought Linux
internally (although a majority outsource various IT capabilities to 3rd
parties who run Linux).

> Does Windows Server 2003 ring a bell?

NT 5.1 (XP/2003) is no different than NT 5.0 (2000) in its scalability.
There are extremely few vendors who offer the Datacenter version. The
main reason is that the Intel AGTL+ (IA-32/Xeon) platform does not scale
well beyond 2 CPUs or 4GB of RAM. Not even IA-32e "64-bit extensions"
does, and won't until Intel puts IA-32e processors on the AGTL+
(32/36-bit) to Infiniband (50-bit) platform that was actually designed
for a 64-bit processor (hence why it is used by Itanium).

Until then, even IA-32e is still "4GB server platform."

As such, Windows is still years away from competing with traditional
UNIX from the traditional RISC vendors.

Now Intel does offer the full Infiniband/IA-64 (50-bit Itanium)
platform, at extraordinary cost. Some have gone that route, as Itanium
_did_ offer a compelling option before Opteron appeared. Now that the
HyperTransport/x86-64 (48-bit Opteron) platform is here, even Sun is
phasing out SPARC, let alone Infiniband/IA-64 co-designer HP is now
dropping IA-64 products due to lack of sales while introducing more
Opteron solutions. Basically everyone but IBM, who is sticking with
Power/AIX and, to a lesser extent, Power/Linux.

Many RISC/UNIX vendors already have codebases that scale quite well.
They were designed for NUMA, point-to-point and segmented interconnects,
etc... Concepts that are very foreign to Windows releases -- all but
Datacenter that must be heavily customized by the OEM (not Microsoft).
Must of this was already built on Digital's Alpha work in the late '90s,
but it's still not anywhere near what VMS or Tru64 could do.

Even the Linux kernel is not comparable to these solutions ... yet. Now
Linux 2.6 really "changes the ballgame" with its inherent support for
processor affinity -- both for programs and memory scheduling as well as
I/O, among other major VM/Scheduler overhauls. Especially in the case
of HyperTransport/x86-64's I/O memory management unit, I/O MMU --
something both the current Win/x86-64 beta release and IA-32e processors
lack alike. It's "getting there."

The big issue with Windows is that Win32 has never been very "64-bit
clean" -- let alone Microsoft has relied on the fact that IA-32 (x86)
has _never_ required any considerations for data alignment, until x86-64
"Long" mode (among other issues with the 48-bit addressing of x86-64 in
an attempt to maintain i486 TLB compatibility). So most vendors are
left to develop not only the 64-bit applications, but the 64-bit library
support for themselves unfortunately, because Microsoft does not and
cannot address the issue themselves (much like they didn't for Win16
when NT 3.1 came out with Win32). And as long as Microsoft continues to
play games with its NT release for HyperTransport/x86-64 (48-bit
Opteron) platform, just like NT 3.1/3.5 a decade earlier, we're getting
things like WoW (Win32 on Win64) aren't going to cut it (just like Win16
on Win32 didn't either).

Which brings me to NT 6.0 "Longhorn." .NET was a great new API
introduced in 2001, with the eventual plan that it would replace Win32
by the release of "Longhorn" by mid this decade. But so was Win32
introduced in 1991, with the eventual plan that it would replace
DOS/Win16 by the release of "Cairo" by mid last decade. But like Win32,
compatibility started to reign supreme, and the new "NT" codebase took a
backseat to the DOS "Chicago" team and "Cairo" never came to be.

We are now seeing a 100% repeat of this with "Longhorn" -- a main
difference being that Microsoft did not even attempt to introduce a
"pure .NET" platform, because they knew it would only be tainted with
Win32 hacks, just like NT was with DOS/Win16 hacks into Win32. The
result is no scalability, no security and no control over a spagetti
API.

By its very nature and completely reliance on security-ignorant APIs
across the entire line, it is technically impossible for Windows Server
to be "high-end" period. Hence why Microsoft bought VirtualPC, and has
pushed for Intel and AMD to introduce hardware-based virtualization,
because it knows the only way to scale is to virtualize. Because
Windows is incapable of scaling to typical offerings of UNIX shared
memory systems.

The GNU/POSIX API and Linux platform is, however, capable. It's just
not there yet, but closing fast on most mature UNIX codebases.

-- 
Bryan J. Smith                                  b.j.smith@ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik

----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:12:02 EDT