[rescue] SS10SX Value

[silcreval]

Mouse

Compilers have got pretty mad over the past decades - but a lot of this is chasing optimisation and modern language complexity.

Package managers also dont help. You pull in a library to do some small task and a it brings with it a ton of dependencies. Before you know it you're dragging around 200M of dependencies and barely used junk.

- Ian

> On 16 Jun 2026, at 21:39, Mouse via rescue <rescue at sunhelp.org> wrote:
> 
>>> NetBSD has supported the SS10 for a very long time (decades, at
>>> least).  In recent years, they have to some extent desupported
>>> everything not "industrially relevant", I think the phrase was,
>>> which includes 32-bit SPARCs.
>> FTR: NetBSD/sparc [...] is 'tier 2' / 'evolving at its own pace', it
>> shares the status with most of the ports.
> 
> Yes.  They spun it very skilfully.  But it *is* spin; it is hard to
> hide that they have desupported them significantly.  If someone wants
> something for an "industrially relevant" port that happens to break a
> "tier 2" port, well, that's just too bad.  It leads to sloppiness.
> 
> An example is their heat-seeking gcc: I've seen mail on the list which
> makes me think that you have to max out RAM on a machine like an SS10
> or SS20 (an SS20 maxes out at half a gig) in order to get it to not
> thrash itself to death trying to build the world.  If they actually
> _supported_ those machines, they'd've found some way to address that
> issue.
> 
>> It is included in current releases, you get to run an up to date,
>> supported release on your sparc.
> 
> *If* you have a machine that can handle a system that bloated.
> 
> At one of my jobs, I'm working with a transpiler which, to my mind,
> exhibits the kind of problem I'm talking about.  Its executable is
> 618173528 bytes - significantly over half a gig.  Much of that is debug
> symbol table, but even stripped it's 84760408 bytes, over six times one
> of my (unstripped!) amd64 kernels.
> 
> What I've heard doesn't make me think gcc is that bad yet.  But, for
> example, NetBSD also claims to support the VAX, but I've seen VAXen
> that physically cannot have more than 16M of RAM (only 24 address
> lines) - back in the '80s I supported a real research on such a
> machine.  On a 9.1 machine at work, I checked /usr/libexec/cc1, and
> it's over 19.5 megs counting just the text segment.  That's an amd64
> cc1, not a VAX cc1, but I have trouble imagining that it would do
> anything but page itself to death trying to compile even hello-world.
> 
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
> X  Against HTML		mouse at rodents-montreal.org
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> 
> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org