On 6/16/19 1:14 AM, Jim Wilson wrote: > On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <frank.schei...@web.de> 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 anymore. > 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 now. > 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 emulation support. 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 QEMU backend. > 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. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
