Alpha Source Code?

Tue Dec 7 17:43:20 UTC 2004

Could you share with us the relative breakdown in shipments
of 32bit vs 64bit Redhat?

And of the 64 bit how does it look with AMD64/ia64/PPC64/s390x ?

>-----Original Message-----
>From: axp-list-bounces at redhat.com [mailto:axp-list-bounces at redhat.com]On
>Behalf Of Mike A. Harris
>Sent: Tuesday, December 07, 2004 9:32 AM
>To: Linux and Red Hat on Alpha processors
>Subject: Re: Alpha Source Code?
>
>
>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
>
>_______________________________________________
>axp-list mailing list
>axp-list at redhat.com
>https://www.redhat.com/mailman/listinfo/axp-list
>