Mike Hommey schrieb: > On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote: >> Luk Claes schrieb: >>> Matthias Klose wrote: >>>> Grant Grundler schrieb: >>>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: >>>>>> Grant Grundler wrote: >>>>>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: >>>>>>> http://lists.debian.org/debian-release/2009/04/msg00303.html >>>>>> Note that it's wrong to assume we will come with the answers. >>>>> I was expecting a summary of specific issues from an organization >>>>> that claims to operate transperently. The hand waving is easy. But >>>>> doesn't resolve problems and doesn't meet my expectation of an "open" >>>>> organization that I've donated money, time, and materials to. >>>> +1. dropping hppa as a release architecture was not communicated by the >>>> release >>>> team at all. I did spend some time to get gcj / default-jdk working on >>>> hppa, >>>> and some money (buying a new disk for a hppa machine) to help this port. >>>> The >>>> time and the money could have spent better, if d-r would have better >>>> communicated about their intent. >>> There are issues with the hppa port where the release team considered >>> dropping it since 2005 communicated to the porter list... >>> >>>> hppa is not in a good shape, but there are other architectures which are >>>> not >>>> better (sparc, mips*) from a toolchain point of view. what about these? >>> I'm not aware of current toolchain issues on sparc and the issues on >>> mips* still seem to be manageable, no? >> sparc-biarch defaulting to 32bit isn't supported by upstream; there are >> requests >> to move to v9 optimization by default, which requires some work in the >> compiler. >> I don't plan to update this for upcoming GCC versions, and there's no >> interest >> by upstream to help with this kind of setup. You can't buy v8 software for >> years >> now, but afaik all our machines run 64bit kernels. Maybe it's time to >> acknowledge this, remove sparc from the list of release architectures and go >> on >> with sparc64? > > Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64, > where the pros of the added registers overcome the cons of bigger > pointers. In other words, 64 bits code is slower, fatter and more memory > hungry than 32 bits code on sparc.
which of the previous statements did you check? E.g. speed comparing the current 32bit v8 with 64bit ultrasparc code? and even then I wouldn't care that much if it becomes maintainable. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
