Paul Wise wrote:
On Sun, Jan 4, 2015 at 6:51 PM, Mark Morgan Lloyd wrote:I was specifically talking about older *systems*, not chips.Do you have any examples of particular systems that are no longer supported? I suppose our RAM usage has increased beyond the capabilities of some systems. The i386 architecture also had it's CPU requirements upgraded, dropping some systems.
Examples from memory. First there's the comparatively minor issue that all architectures need something like 300Mb to accommodate the installation initrd, this is distinct from the requirement of actually using the distro. Second, older PPC Macs stopped at Lenny- I can't remember the detail, it was some sort of booting issue inherent in the firmware. Third, there've been multiple bugs in SPARC listed for several years which haven't been addressed: things like KDE's Konsole crashing when it scrolls (which also affects XFCE); I'd add that some sensitivities based on alignment were common between SPARC and ARM. There's obviously routine bitrot, e.g. some of the classic SGI/MIPS systems quite simply got no work later than "Lenny", and since graphics etc. were only part-understood this was obviously a killer.
For newer systems, in particular anything where the internal hardware can be fully-enumerated in some well-understood way, it's time to move on.
Not a hope in Hell. Well, maybe 1%. Over the last year or so Oracle has succeeded in changing SPARC from a commodity architecture to something very similar to IBM's mainframes, and if Debian can't boot problems upstream for 32-bit SPARC there's no reason to assume that 64-bit will be any better. Even if unavoidable, the loss of SPARC (and/or SPARC64) is unfortunate since for about 10 years it was possible to pick up nice big SMP systems on eBay, which could exercise aspects of threading etc. that other architectures could not reach.As long as the upstream GCC and Linux communities support SPARC, it should be reasonably easy to re-bootstrap a port if anyone cares.
If anybody cares, if anybody remembers the details of the architecture that were never documented, and if Oracle doesn't threaten to sue them. In common with the other workstation manufacturers there was far too much that was never adequately documented, and Sun's assertion at http://wikis.sun.com/display/FOSSdocs/Home that they couldn't locate stuff really isn't credible for /the/ company which underpinned drawing offices and technical libraries for decades.
I'm definitely not blaming Debian for anything, but there are still occasional rumblings in areas like the Free pascal Compiler due to residual library path issues.IIRC those were bugs in fpc that were exposed by multiarch existing; they were hard-coding paths instead of asking GCC. Do you know of any other multiarch related issues?
Mainly path issues I think. I don't remember whether there were distinct issues on end-user systems which didn't have build-essential installed.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]