Re: lenny+1 and the future of the alpha port?
On Fri, Aug 22, 2008 at 02:16:41PM -0700, Steve Langasek wrote:
> Thanks to all who've replied so far. It sounds like we're generally where I
> thought we would be at this point in time: there are a number of people
> still using alphas (in particular, folks who have newer and better models
> than I), including some who expect to still be running theirs in
> three-years' time, but not so many that I think it makes sense to continue
> supporting a full Debian port of lenny+1 with all that entails (multiple
> always-on buildds+porter machines, ~20G of space used on the mirrors,
> headaches for maintainers when their package fails to build for any reason).
I hadn't noticed too many apha build failures lately. I figured that
was because the alpha is 64bit little endian just like amd64 and hence
the problems should be mostly the same. Making gcc and java work is
always an issue of course.
It is hard to believe that 20GB of disk space matters to anyone these
days, but then again the mirror peopel are probably using much more
expensive disks than I use in my desktop machine. And of course there
would be some extra bandwidth used. Of course based on the presentation
in Ottawa recently by one of the kernel.org admins, they aren't
concerned about how much space Debian is using, they are concerned about
the obscene amount of space Fedora is using. Debian was pretty
insignificant compared to some other distributions.
> It's not a foregone conclusion that Debian should drop alpha for lenny+1;
> but even http://wiki.debian.org/alphaLennyReleaseRecertification doesn't
> list anyone other than me willing to do the work today, and I'm definitely
> not willing to be on the front line for lenny+1. So if lenny+1 for alpha is
> really something people want, someone will have to step up to do the work.
> Some alternatives to consider would be a minimal port of lenny+1 providing
> only the server packages; or else getting a team together to provide
> extended security support for lenny (preferably for /all/ archs, to share
> the benefits/work) beyond the normal 1-year oldstable cut-off. But these
> are again both solutions that require a commitment from the interested
> Can you quantify how long is "a long time" for you? I'm happy that Debian
> has helped you get 10 years (13, by the time lenny ends) out of this
> hardware! But beyond that point, is continuing to use that hardware really
> the most effective solution for you? (Not a rhetorical question - I'm
> interested to know under what circumstances it makes sense to continue
> running alpha hardware, instead of consolidating on current-generation amd64
Sometimes it isn't about what is most efficient. Besides if you have a
working machine why buy a new one (unless electricity starts to cost too
much to justify the old one running). Besides some people love being
able to keep old hardware running. It's bad enough that Microsoft wants
to make anything 4 or 5 years old obsolete and unable to run current
software for no good reason, but does Debian have to?
> So, it's partly with m68k in mind that I've started this thread when I did.
> I do not think that m68k has set a very good example; I have a lot of
> respect for many of the folks who have been m68k porters over the years, but
> the m68k port had become a burden for the Debian project as a whole long
> before the Vancouver meeting brought the issue to the forefront. I don't
> want alpha to go down that same road; I would like to see the port retired
> with dignity, and not become a source of resentment for the rest of Debian.
The m68k does have an issue of being rather slow I guess and there are
so many varieties of them too. I haven't run Debian on a 68k myself
although I have always wanted to try it, just to see it work.
> I think we're at that point where we need to start planning its retirement
> in order for that to happen - while users still have 3 years to plan what
> they're going to do when support runs out, rather than having it come as a
> slap in the face and have us desperately trying to hang on to doing full
> Debian releases because users are caught unprepared.
> > Of course, running Linux on Alpha today means running Debian.
> Has Jay Estabrook's Red Hat Alpha build fallen by the wayside? Not that I'm
> seriously suggesting that anyone run Red Hat instead of Debian on their
> Alpha ;), just wondering what the status there is since I haven't heard from
> Jay in about a year.
> Also, there do appear to be some folks running Gentoo on Alpha.
And who wants to run that?
> In practice, my current role is in the area of minor updates to keep the
> kernel and installer in shape for release. There is code hacking that
> *needs* to be done to keep alpha as a full-fledged port, but neither I nor
> anyone else is doing this work.
Is there anywhere that has a list of what is in need of being done?
Looking through the BTS is not exactly the most efficient way to find
the things that need doing.
> Lenny will already ship without Java on alpha because no one was willing to
> fix the toolchain; and atlas has also been dropped recently. I'm not sure
> if X in lenny or sid currently works on alpha, but sid had problems last
> time I tried to get it working on the Matrox card in my alpha; and the
> Matrox framebuffer has been broken on alpha since before etch's release,
> with the result that console-based d-i installs on anything except English
> are kinda messy, IIRC.
Hmm, I won't touch java, and I don't know much about atlas (although
that doesn't mean it couldn't be fixed, except I think it might use
assembly). Fixing X ought to be doable as should be the framebuffer.
> To keep the alpha port alive would not require a committment to fix *all* of
> these issues, but these are really a taste of things to come as alpha
> support continues to atrophy upstream due to lack of use and testing. As
> the alpha community continues to shrink, the work will become increasingly
> difficult for the porters who remain.
> The builds themselves take almost no effort on my part, they just require an
> alpha to be running with a copy of the debian-installer svn tree and an
> up-to-date sid install (chrooted is ok). If there's demand for it, I would
> even be happy to continue running the builds themselves on someone /else's/
> alpha that already has to be powered on; but I have ethical objections to
> having an alpha powered on 24/7 just for this purpose :), and I won't do it
> if there aren't going to also be porters taking responsibility for package
> This would not be releasable as a Debian port, no; it's a requirement for
> Debian releases that the port be self-installable, and not require some
> other OS (such as a previous version of Debian) to bootstrap it.
One of my alphas requires milo, so going back a while to install is
required. Of course I haven't succeeded at getting that to work yet
either. The other alphas are much simpler to deal with.
> In what sense do you mean? Lenny as oldstable would still have security
> support on alpha, the same as all other architectures (assuming that we can
> still find sponsorship for the buildds - and many thanks to Tim Cutts and
> the Sanger Institute for providing this service for lenny to date!). But it
> would no longer be present in the 'stable' or 'testing' suites at that
> point, which among other things means that there would be no guaranteed
> upgrade path at all from lenny to sid, and therefore I would argue that we
> should not continue to take up space with this port in sid either.
> Debian Alpha doesn't work very well on SMP systems any more, either. Since
> etch, we've had problems with modules not being loadable due to toolchain
> changes, so you typically have to build a custom static kernel; and the very
> Alphas that have been used as the Debian buildds for the past year have also
> had problems when running under SMP.
> Again, I'm certainly not encouraging anyone to switch away from Debian; I
> would much rather see a trimmed-down version of Debian/Alpha distributed
> from debian-ports.org than that. :) But if there aren't enough folks to
> keep Debian running well on alpha, it may be inevitable.
> In English, we have an expression: "throwing good money after bad". Yes,
> there's an environmental cost associated with the initial production of the
> machine (not just in terms of energy but also in pollution), but that's
> already done and can't be undone. Computers can be had today that are more
> powerful *and* more energy efficient, for relatively little money - how long
> would a more energy-efficient machine have to run in place of your alpha, in
> order to pay for itself in electricity savings?
> For me, I know the answer is "not long".
Certainly true, but there are a few silly people around (like me) that
just loves weird old hardware and keeping it working (even if that takes
a soldering iron once in a while to fix things). If nothing else than
to show it can be done.