Re: IA-64 GCC deprecation?
On 6/16/19 1:14 AM, Jim Wilson wrote:
> On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <firstname.lastname@example.org> wrote:
>> Because as long as there's software for a specific hardware, that
>> hardware **is** useful IMHO. Devaluation of hardware in my eyes does not
>> come through so-called product obsolescence - hardware never has any
>> practical value without software - but by "trashing" key software which
>> originally was created with a lot of effort.
> There is no proposal to "trash" any gcc release that contains IA-64
> support. There is only a proposal to drop it from future releases.
As I have already mentioned in a previous mail, we cannot unfortunately
use older gcc versions in Debian. We are using the default gcc version
from Debian unstable which is - sometimes with a little delay - always
the current release version.
This is one of the main reasons why I am against rapid release models
for something big as gcc or OpenJDK as it doesn't bring huge advantages
to regular users, but means a considerable extra workload for distribution
maintainers for constantly having to fix regressions of the new versions.
> It is important to keep in mind that software does not magically keep
> working after being written. Someone has to maintain it. That takes
> time and energy.
I fully understand that. In fact, I think most people here know how
software maintenance works.
> It isn't fair to force that burden onto the GCC
> global maintainers when there is no one that cares enough about IA-64
> to maintain it themselves.
But it's also not fair when GCC maintainers think they're the only project
in the open source world that deserves attention. A Linux distribution
isn't just GCC but a lot of other projects.
GCC maintainers should therefore also consider the needs and interests
of the maintainers of other projects, in particular with the power that
GCC has to destroy complete ports.
In Debian, we just had to kill of the PowerPCSPE port because GCC decided
to get rid of the backend despite Andrew Jenner working on fixing up the
backend. Eric Botcazou said that he didn't think the backend had to be
removed as it was separate from the other PowerPC backends. But that comment
was ignored and the backend removed and the Debian port killed off leaving
multiple users in frustration not being able to update their machines
> Maintenance is a significant long term
> cost, and GCC does not have infinite time and people to do this work.
Yes, and this applies to all other open source maintainers as well. I have
done a huge amount of work on various architectures, including some work
on RISC-V, despite neither having RISC-V hardware nor being particularly
interested in the port nor being paid by someone. Yet I helped with the port
because I'm a nice person. In fact, a lot of the work we did in Debian Ports
for the old architectures helped to bring up RISC-V in Debian rather quickly,
much quicker than in the past.
> We have to focus most our time and energy on the targets that have the
> most users. And when there is a target with few users that falls into
> disrepair and remains broken for a long time, we have to deprecate it.
If it was about users, no one would be working on RISC-V. RISC-V boards
are still absurdly expensive and every cheap arm64 board is still faster
and more powerful. By this very argument, RISC-V would have to be dropped
> Also, it is important to note that IA-64 has a higher than normal
> maintenance burden, because there are so very many things it does that
> are different from other targets.
Yes, that's known.
> If you want the port to survive, then someone who cares about it will
> have to maintain it. We have pdp11, vax, and m68k ports for instance
> because each one has a volunteer that is keeping it alive, so that the
> global maintainers don't have to fix it themselves.
Yep, and that's what's GCC's huge value over LLVM. GCC should by all
means not try to be another LLVM because what makes GCC so useful
is the vast amount of supported targets.
> Another issue here, if gcc maintainers can't get access to IA-64
> hardware or simulators, how are they supposed to maintain the IA-64
> gcc port? Most of the lesser gcc targets have freely available
> simulators that make it easy for anyone to test gcc without access to
> hardware. That is a serious problem for IA-64. QEMU dropped the
> IA-64 support Nov 2017.
No, QEMU dropped support for KVM on IA-64. QEMU never had real ia64
And HPPA didn't have emulation support in QEMU for a long time either
but the backend was eventually added because Helge Deller and David
Anglin with the help of Debian Ports brought Debian's hppa port into
such a good shape that there was a very good basis to work on the
> I don't think that ski is maintained anymore
> either. IA-64 hardware is expensive, and soon won't be manufactured
> anymore. This is going to make continued maintenance even harder.
RISC-V hardware is expensive, too, and very hard to come by. The same
applies to VAX and PDP-11. So, I don't think this is a valid argument.
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - email@example.com
`. `' Freie Universitaet Berlin - firstname.lastname@example.org
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913