[illumos-Developer] ON is bloated and a bunch of stuff that doesn't need to be there should be ripped out (was Re: Heads up: perl 5.8.4 removal)

[Erik Trimble]

On 11/11/2010 10:56 AM, Peter Tribble wrote:
> On Tue, Nov 9, 2010 at 7:44 PM, Garrett D'Amore<garrett at nexenta.com>  wrote:
>> On Tue, 2010-11-09 at 19:02 +0000, Peter Tribble wrote:
>>>> Its not a formal list... I'd have to go looking.  One thing that I do
>>>> think we can probably clean up is the support for legacy SunOS 4.1 a.out
>>>> executables.  Its been a few decades now, and I think the need to
>>>> support executing such programs has long since passed.
>>> That's one place I disagree. I regard SunOS4.x binary compatibility as a
>>> massive advantage - and I run a *lot* of stuff that way. Most of it simply
>>> can't be rebuilt (no source, even if the company that made it was still in
>>> existence) or replaced. Sun hardware and software has lifetimes
>>> measured in decades; many companies rely on this (often unknowingly).
>> Right, but can't these be run in an S10C zone or in a VM?
> How does that help? We are talking sparc only here, so the VM options
> are limited. (And one thing you need is to be able to run old software on
> current hardware, so you might not have much choice on the OS
> version.)
>
> As for an S10C zone, does that actually take the code away, or just move it?
>

Peter's right - if we're abandoning it, we're abandoning it. There's no 
looking back.

That said, Oracle doesn't appear to be abandoning SunOS 4 
compatibility.  So, if someone is completely desperate to keep running 
that old app, and won't migrate, well, they at least have an option.  
And, frankly, it's a great way to put a price tag on the cost that 
keeping compatibility for *your* ancient app places on developers.

(frankly, if people have to pay $3k/year or more to keep support for an 
old app, maybe they'll think about paying the costs to upgrade the app 
instead, relieving all of us of a headache)


>> At some point continuing to provide first class support for some this
>> ancient stuff approaches insanity.
> But has huge benefits.
>
> I don't see it as too insane. It's not as if anything is changing. There's
> no new stuff - we're not talking about a moving target here, so it's not
> something that has to be continually updated.
>
Let me say this, as someone who sees what it costs to keep maintaining 
old code (Java versions 5 revs out of date, in my case).

At some point, keeping support for old code in new systems actively 
discourages progress.  People continually want new features, but aren't 
willing to pay the costs it requires to update their stuff - rather, 
they'd prefer to push off the maintenance costs onto the developers 
(and, yes, it does have a non-trivial cost to maintain old code 
compatibility, even if your aren't backporting stuff).   The truth is, 
if you're wedded to old software, and won't pay the cost to update it, 
you shouldn't expect to keep being able to update your hardware and OS 
indefinitely.  Particularly in a Free OS, where you aren't even paying 
for support, it's unrealistic.

There was a similar discussion at Sun awhile ago about abandoning the 
Sun4m platform and Sparc v8plus spec.  That is, a platform that hasn't 
had a piece of hardware made for it in over 15 years.

The sticky question is always *at what point* do you break backward 
compatibility, and, *how* you manage the transition.

I recently had this discussion with the Ubuntu folks, who suddenly (and 
silently) abandoned libc5/gcc2  in Ubuntu 9 and later.

Overall, 20+ years of compatibility for SunOS 4 is damned good.  I do 
think it's time that it be phased out, but the key there is *phased 
out*.   If we want to remove it, there need to be a transition period, 
where we keep the userbase informed about the ongoing plans to remove 
this *at a fixed date in the future*.

> One question is whether this support is impacting other code paths. In
> which case I can see it being shoved off to the side.
>
Frankly, leaving it included but to rot from neglect is worse that 
actively abandoning it.  At least people understand that it won't work, 
rather than bumping into weird problems and then being told "Oh, we 
don't really support that anymore. Go away."

>> I'd like to know what stuff it is that still needs to be run this way.
>> We are talking *really* old software here... much of it would probably
>> have been written before some of our participants were even *born*.
> Hey, I'm not *that* old!
>
yes, you are. So am I, now.  Remember, kids are now entering college 
that were born *after* the Sun4u architecture started being produced. 
Even worse, the likelihood that a 20-something had even seen (or used) a 
SunOS 4 system until they got into the workforce is very low (that is, 
about the only place they're still around is gathering dust in the 
corner of some research lab or running something weird at a business).

> And one thing here is that once you get this problem, you're talking about
> really old applications. So old that they can't be updated or fixed. Sometimes
> you have data in a format that can only be read by an old application.
>
Then, you either:

(1) SHOULDN'T BE UPGRADING YOUR OS.

or

(2) Lay in a stock of older hardware and keeping media around so you can 
re-install the current OS.

or

(3)  Pay the cost it requires to transition your (at this point) 
25-year-old app to something new. Doing a data and code migration every 
3 decades is quite a reasonably thing to ask of your customer base.






Sorry. I have very strong opinions about people who want to continue to 
run old apps on newer platforms indefinitely.  Continuing to support an 
old platform is one thing, but unlimited backward compatibility is 
unrealistic and harmful.


(I still see what it costs our org to keep JDK 1.3.1 compatibility, let 
alone keep maintaining the 1.3.1 codebase...)

-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA