Re: The State of Alpha Linux
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
Reply to: