Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: Alpha Source Code?
From: Mike A. Harris (mharrisredhat.com)
Date: Tue Dec 07 2004 - 11:32:03 CST
On Tue, 7 Dec 2004, William H. Magill wrote:
>>> no aparc, mips, or alpha.. what's wrong with these people?
>> Heh. Well, I feel the same as you from an ideological and
>> enthusiast viewpoint, at least as far as Alpha is concerned.
>> We've got a handful of people internally (myself included) who
>> would love to revive Alpha officially, but that would have to be
>> entirely volunteer based on non-work hours to happen. Sadly,
>> non-work hours are rare, and mostly occupied by other things in
>> life by all of us currently it seems. ;o)
>Look at it this way.
>If Red Hat had mainstreamed Alpha, they would have a 64bit clean line
>that could get ported to the other 64 bit platforms, like Power and
>PowerPC with minimal problems.
Alpha and Sparc were dropped purely because there was not any
economic reason for continuing to develop for the platforms. x86
is the only architecture that is economically self sufficient.
Every other architecture in order to be a worthwhile use
of engineering resources, has to justify the opportunity
cost of reassigning scarce engineering resources across
kernel, gcc, glibc, and tools engineering mainly, but it
also affects QA, RELENG and other aspects of engineering.
There has to be a worthwhile business case to do a port to any
other architecture, which has a return on the opportunity cost,
and is good use of our finite engineering manpower.
x86 is viable, simply due to volume, all other things aside.
Out of all of the other architectures, AMD64 has good bang for
buck opportunity cost, as it is the natural successor to x86.
All of the other architectures have lesser value for engineering
hours spent working on them, unless someone is directly
subsidizing their development under contract.
The last Sparc distro was RHL 6.2, after which point there was no
hardware vendor interest in paying to have the OS be ported to
Sparc. For Alpha, the last distro was RHL 7.2, which is also the
last OS release which was developed under contract. Both of
these architectures are dead from a business perspective looking
forward, so any engineering resources spent on porting the OS to
these architectures has high opportunity costs with no equivalent
short or long term bang for the buck. In brief terms, it is not
economically viable to port the OS to these architectures.
This is all speaking in terms of what makes sense businesswise.
By allocating our very finite engineering resources developing
the OS on architectures that bring in revenue, we maximize our
return on investment of engineering hours spent.
So the argument then comes up about endian cleanliness, and 64bit
cleanliness. Porting to Alpha, and keeping an alpha port up and
running would give us the benefit of being more 64bit clean one
might argue. The fact is however, we currently build every
single RPM package on 4 64bit architectures already (AMD64, ia64,
ppc64, s390x), so the OS is already very 64bit clean. We
currently get 32bit little endian testing out of x86, 32bit big
endian testing out of ppc and s390x, 64bit little endian testing
out of AMD64 and ia64, and 64bit big endian testing out of ppc64
and s390x. So the majority of the software is already ported to
run on just about anything.
Rebuilding most RPM packages on any arch, should "just work"
without any porting effort. Why then, if the majority of the OS
"just works" not do an official Alpha or Sparc port? Simple.
Rebuilding the rpms that "just work" is about a day or at best a
few day's work by any random engineer. That is the easy part.
I wouldn't be surprised if 90-95% or more of the entire OS just
rebuilds on any random architecture with little to no engineering
effort. The real work, is porting the latest compilers
technology, toolchain, and other development tools to each
architecture, testing and debugging them, and porting glibc,
kernel, xorg-x11 and other core OS components to the other
architectures. Then getting adequate hardware testing, fixing
architecture and/or endian specific bugs in these components, as
well as other architecture specific oddities, and getting
everything running on as wide a range of hardware as possible.
That is where the real costs lay, and that is where it ceases to
be economically viable.
>Since AMD64 can mask a multitude of 32bit-x86 architecture dependent
>problems, one assumes that the "core" is anything but "64 bit clean."
>(Whatever that means.)
We build on AMD64, PPC64, s390x, and ia64. That combination of
64 bit builds, gives more than adequate testing of the 64bit
cleanliness of the majority of the OS. Any remaining differences
are almost always either architecture specific (not 64bit
specific), or they're hardware specific, such as driver problems,
etc. In that case, porting to Sparc or Alpha would not benefit
anything more than Sparc or Alpha.
>I remember discussions with one of the roving RedHat bus teams several
>years ago, just before RH and Q dumped Alpha, about how 64-bit
>computing was the future and being told, "No, x86 is the future."
Like it or not, that is essentially the bottom line. I am a
hardware enthusiast and I love Alpha as much as the next guy.
>From that perspective, working on Alpha can be fun and exciting.
It can also help to make software more 64bit clean if you use
Alpha as your development platform, which of course will benefit
all other 64bit architectures as long as the problems you're
fixing aren't just Alpha specific issues. However it isn't the
fact you'd be using Alpha specifically that provides these
benefits. It's the fact you're using 64bit hardware to find and
fix 64bit problems, and as mentioned above, we do that already on
4 different architectures.
One might additionally argue that by porting to Alpha, people who
have alpha but no other 64bit arch, would be testing things who
otherwise might not, and so additional problems would likely be
found that could be fixed and benefit other architectures too. I
would have to agree with that sentiment too. However, it isn't
just about fixing more bugs, it is all about the overall picture.
It is about allocating engineering resources in an effective
manner. Spending 1/5 of our available finite
engineering/QA/RELENG resources developing Alpha, is not going to
make our other 7 architecture ports 20% better. It might result
in a handful of bugfixes that apply equally to other
architectures, but at a cost of 1/5 of our engineering, or even
at a cost of 1/10th of our engineering, it doesn't result in an
benefit to us that scales with the effort expended.
Why then, do we develop for the non-x86 architectures we develop
for? Because large hardware vendors contract us and pay us money
to do so, and there are long term benefits for this for some of
these architectures to make it viable to do so from a business
Currently, the commercial interest in Alpha and Sparc are very
small. Small enough to mostly be insignificant aparently, or
I'd expect the hardware vendors producing Alpha and Sparc
hardware to be interested in contracting to have a port
completed. Since both platforms are dead or dying however, the
long term benefits to us are very small for such ports, and so
the costs to do such are likely to be much higher.
One might read this email, and call me the Devil's advocate for
all I know. And if someone feels that way, sobeit. In reality
however, I'm just fairly good at being able to separate my
ideological views from viable business views on what is the best
way to allocate engineering resources within a business such as
When you have finite engineering resources - and all companies
do, you can often choose from spending those resources on 1 of
1000 different projects. Any one of those 1000 projects will
provide you hopefully with some benefit for the resource spent.
A most successful business however will allocate their finite
engineering resources projects that provide the biggest bang to
the company per engineering manhour spent, at the cost of not
spending those engineering resources on projects that generate
fewer benefits in the grand scheme of things.
>From that perspective, x86 and it's offspring very much is the
future, mainly via commoditization. AMD64 is currently the most
likely scenario of what x86 will be 5 years out, and so I see
AMD64 as "the future". Again, while I love Alpha, and am
saddened deeply by seeing it die, the death of Alpha isn't going
to be reversed by an official Fedora Core port.
Legacy architectures, for better or worse, are best left in the
hands of the community who care about them the most, and who have
the time to put elbow grease into the mix to keep their
ideologically favourite hardware up and running well into the
So, in response to your assertion - we already have viable PPC
and PPC64 products, and doing an Alpha port was completely
unnecessary to achieve that goal. If anything, the ia64, AMD64,
PPC64, and s390x ports of our OS do MUCH more to benefit Alpha,
than would doing an official port to Alpha benefit the others,
because we have large customers using this hardware, and large
vendors spending money to ensure we support these architectures.
A 64bit bug fixed on AMD64, ia64, ppc64, or s390x, is highly
likely to be a bug an Alpha user will now never have to see.
Evidence is that the majority of the OS alegedly recompiles
without modification and works on Alpha. The remaining stuff
that does not work on Alpha, is where our engineering resources
would have to be spent, and that's where the real work is - in
architecture specific stuff like the kernel, glibc, gcc, etc.
which for the most part only benefits the architecture being
developed, since it is architecture specific problems.
As such, the community of Alpha enthusiasts (and I'm one of them)
shouldn't be angry at Red Hat for not supporting Alpha platform,
but instead they should be gracious to Red Hat for fixing bugs in
the software on AMD64/ia64/PPC64/s390x which would have also been
bugs on Alpha/Sparc64 per se.
Yes, even though we don't have an official Alpha port, as you can
see, we are doing our part. And the Alphacore project appears to
be doing good filling in the rest of the mix. Any remaining
problems people find are easily fixed with volunteer
elbow-grease, or money.
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - X11 Developer - Red Hat
axp-list mailing list