Alpha Source Code?

[Mike A. Harris]

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 
perspective.

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
Red Hat.

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 
upcoming decade(s).

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.

TTYL


-- 
Mike A. Harris        ftp://people.redhat.com/mharris
OS Systems Engineer   -   X11 Developer   -   Red Hat