The State of Alpha Linux

[Oliver Falk]

Hi Matt!

Matt Turner wrote:
[ ... ]
>>> We're all subscribed to this list because we use a dying platform.
>> You think it's dying? :-P
>>
>>> We do what we can to keep it going, but in recent months the State of
>>> Alpha Linux has been deteriorating at an accelerated rate.
>>>
>>> Let me outline some issues facing us today:
>>>   1.We have no glibc/Alpha maintainer [1]
>> What can we do here? Who can take over this job. What skills are required to
>> take over the job? How much time does one have to spend to do the job? If
>> someone would volunteer, whom does he or she have to contact?
> 
> I mailed glibc's libc-ports mailing list recently about this.
> 
> http://sources.redhat.com/ml/libc-ports/2009-01/msg00002.html
> 
> Gentoo's Mike Frysinger was the only one to respond.

For me it's fine to have it in ports, if that only means it's not 
actively tested. I can understand it will then not hold up a release. 
It's up to *us* to take over the job of testing and fixing. That's fine.

But Mike also stated, that he doesn't know who is going to merge the 
patches... But this is the most important part!

> If you think there's a chance you might be able to take over the job,
> I encourage you to mail libc-ports, as I don't know the answers
> myself.

As I said, since I don't know what skills one must have, I'm not sure if 
I might be able to take over the job. But I'm willing to try, of course.

>>>   2.Kernel development for Alpha is comatose
>> I do see some commits from time to time... Well, not much enhancements of
>> course... But there would be a few things that should be ported from x86 to
>> alpha...
>>
>>>   3.We can't run modern X.Org [2]
>> At the moment. I guess it's just a fair bit of work and then we would be
>> able to run modern xorg.
> 
> It's actually just one non-trivial bug (we hope). Kernel bug 10839.
> 
> Also, see http://alphalinux.org/wiki/index.php/Bugs_to_watch

It depends on what we want. If we just want a fallback method in 
libpciaccess, I think it shouldn't be too much work - for someone who 
knows how to do it... I've read that a fallback method would be 
unacceptable slow. That might be true, but would give us at least the 
chance to *have* it. A more robust and faster method - of course - would 
be appreciated, but that actually seems to be the non-trivial thing...

>>> To make things worse, for such a small group of users, we're much too
>>> segregated and disorganized. For instance, how many (of the only four)
>>> Gentoo/Alpha maintainers are subscribed to this list? Debian/Alpha?
>> I don't know if any other Alpha distribution maintainer is subscribed here,
>> but I do include debian-alpha m/l now and klausman (I think he's one of the
>> Gentoo Alpha maintainers).
> 
> Yes, klausmann subscribed to this list after I told him to recently. :)

Great :-)

>>> How many realized we were without a glibc maintainer? That we can't
>>> use X.Org 7.4?
>> I can say, I did.
>>
>>> If this trend continues, we will completely first lose X.Org support.
>> AFAIK, Ivan works on this, isn't he?
> 
> Well, he has in the past.
> 
> According to marc.info, after a 6 month absence on LKML, he sent a
> message yesterday. This absence also coincides with the time he
> stopped responding to kernel bug 10893.

I guess he has a real job as well :-)

>>> I even had an X.Org developer tell me he didn't care [about Alpha
>>> support] when I pinged him about an Alpha bug he had originally filed
>>> [3]!
>> What is the problem for the developers? They don't have alphas they can
>> access? We can help in this case.
> 
> No, I don't think this is the problem at all. jcristau, the developer
> who told me he didn't care, has at least one alpha.

OK.

> None of the top tier X.Org developers seem to care at all about alpha.
> David Airlie told me he thought some of the problems we'd experience
> on Alpha with kernel modesetting would be very similar to problems on
> the Itanium, which he has to support. So he would be willing to put a
> little bit of effort into supporting Alpha, since the heavy lifting
> would already be done for Itanium.

Oh yes... Lot of Itanium work helped me already :-)

>>> We'll later lose glibc support. As it stands now, Alpha isn't even in
>>> the main tree [4]. I'm not sure what version Debian ships, but Gentoo
>>> is 3 versions behind at 2.6.1. Newer than that and the test suite
>>> causes a hard lock [5]. How much longer is it going to be before 2.6
>>> is incompatible with the latest version and we begin to lose the
>>> ability to use other modern software?
>> 2.9 runs fine and I'm trying to keep up 2 date with trunk to find bugs as
>> early as possible and patch it so it works. Also I'm using Gentoo and Debian
>> patches and post bugs in glibc bugzilla.
>>
>> So from my perspective glibc is not a problem.
>> gcc (as of 4.3.x) isn't a problem as well. From time to time there are build
>> problems, but normally easy to fix and I 'zilla them...
> 
> The real problem is that nothing is going to get better in regards to
> glibc, it's only going to get worse as long as we have no upstream
> support.

That's correct, it's not going to get any better...

> Unfortunately, some of the tests either fail or hang the system completely.

The problem with hanging the system is gone - since 2.8. 2.9 works great!

Some fail, right.

> This makes me think there are probably some corner cases where glibc
> would fail in normal applications.

I think the same. However, I'm working with Alphas every day and don't 
see glibc related problems.

>>> While we may never lose kernel support, it will certainly begin to lag
>>> behind other platforms more and more.
>> We do already lag behind; Eg. uptrace/ptrace, Execshield (only as dummy
>> functions at the moment). I don't know the current state of selinux, but it
>> might be horrible... I don't use selinux, so I don't worry to much...
>>
>>> Bugs begin to take longer and
>>>
>>> longer to be fixed [6]. Release candidate kernels as late in the cycle
>>> as rc-8 of the 2.6.28 series fail to compile on Alpha [7]. This is
>>> definitely a worrying sign.
>> Right. Time to worry. Fedora Alpha is currently at 2.6.26.3. I've never
>> tried anything newer than that yet...
>>
>>> It is certainly expected that as a platform ages, it slowly loses its
>>> users and developers. In 1999, many average users knew or we're
>>> interested in learning Alpha assembly language, were interested in
>>> support for Alpha among Free Software, and were interested in
>>> programming for the platform. Obviously this cannot be the case today.
>>> We don't expect that it should.
>> Right. But for some mysterious reasons, Alphas are still very expensive and
>> if you put one on ebay, you will sell it.
> 
> I attribute this to sellers who try to hit the lottery. That is, they
> hope that a corporate server with no back up fails and someone with
> access to the company's expense account spends 7000 GBP (as I was
> recently quoted for an ES47) to get a replacement immediately.

:-) That's possible.

>>> We, the ones who do wish to see our platform live on, even if only a
>>> little longer, should focus on fixing what we can and maintaining what
>>> we already have.
>> Sure! I'm trying to be as transparent in my work as I can. 'zilla every
>> little bug. Have packages in koji, ... Try to keep modified packages with
>> tagged with AXP and add appropriate changelog entry...
>>
>> I hope this already helped other people out there... But I don't know.
>>
>>> Whether Fedora adds Alpha as a Second Tier Architecture is trivial in
>>> comparison to these issues. We should focus on making sure we have
>>> working software for Fedora/Alpha before we consider how to properly
>>> market it.
>> Right. But at this point I must say. It's hard for me/us to keep patches
>> locally. I can not send in a bugzilla report for everything and wait for the
>> maintainers to actually DO it... I don't know what a good solution for this
>> would be?
> 
> I assume you mean that currently you can't file Alpha related bugs in
> the Fedora bugzilla?

No. I *can* file Alpha related bugs. However, most bugs are ignored. 
Today I've received 5 bz-auto-responses, that bugs will be closed, 
because they where filed against F8. Most bz's where simple specfile 
changes!!!

I need to do these simple fixes myself, directly in cvs.

> I can (and probably would) counter by questioning the benefit of all
> the duplicated effort to make Fedora/Alpha.

Duplicated effort? I don't see any (real) *duplication*!

>>> We, the small band of Alpha users, need to work together. We have the
>>> same problems, why should we work separately on them?
>> We should not and we should have a central point to discuss problems... This
>> list would be fine - at least for me.
>> Can we ask all kind of Alpha maintainers (eg. kernel, gcc, xorg, ... ) to
>> subscribe to this list?
> 
> Absolutely, but I'm not sure how many would actually do so.

Well. We should try at least.

> I've probably sent five emails to Ivan Kokshaysky and Richard
> Henderson each. Neither has responded to any, even when I offered free
> hardware.

Maybe they have enough hardware? :-)

[ ... ]

-of