I think you and I disagree because you presume that keeping ancient stuff is zero cost.
That’s not true. We even have a term for some of this — “technical debt”. Old code presents challenges along several fronts. 1. Build times and cost of effort to use and modify the code base. This individual piece doesn’t add much — maybe only a minute or so to build times. But we suffer the death of a 1000 cuts. 2. People mistakenly using the code. The fact that tools for emulex software may still be using libucb is a case in point . This is just plain evil. 3. Indexing (code searches) add confusion. Go search sometime for symbols that are duplicated in libbc, libucb, and libc. That’s evil. I’ve personally found myself confused by looking at the wrong implementation of a function because of the duplication in libbc. (Note that libc and libbc differ by exactly one character!) 4. Focus on on retaining compatibility with stuff we don’t test, can’t test, and that nobody uses winds up making life harder. I don’t know if this is the specific case here, but I know that for example when I wanted to make other changes to improve the DDI I ran into problems because of ancient DMA interfaces that were long ago obsoleted, but are only still used by 16-bit PCMCIA. (That’s a specific case of ancient legacy crap holding us back.) I’m thoroughly committed to making illumos easier to build, easier to integrate into other products, and generally a nicer place to work. I believe that elimination of ancient crap Furthermore, I believe its time to take a stand — to put a stake in the ground so to speak. illumos must have a goal that is more than just the continuation of Solaris from the mid-90’s. Frankly, divorcing ourselves from some of the ancient and irrelevant heritage is a good thing here. Btw, there are other places compatibiity with our “legacy” base actually *hurts*. That’s the readdir_r and other nonsense. I know you don’t agree.. and are probably not alone here. I thought I’d try starting with some less contentious stuff first. Maybe I’m alone here - I want to make changes that increase market share, that make us modern and relevant, rather than some nostalgic holdover from that company we used to work for but which no longer exists. - Garrett > On Nov 7, 2014, at 4:44 PM, Keith Wesolowski <[email protected]> > wrote: > > On Thu, Nov 06, 2014 at 11:48:02PM -0800, Garrett D'Amore via > illumos-developer wrote: > >> Well gee… that’s helpful…. if I actually wanted to test this. The reality >> is, I don’t. Running an internet browsers from the mid ’90’s (or is it >> early 90’s?) is so… pointless. >> >> I should have known someone would dredge up some old archives somewhere… >> >> The point is, nobody uses or needs any of this ancient stuff anymore; >> outside of a museum it has no real interest today. > > Even if that's true, what harm is it doing? If you want to make the > case that new code linking with things like libucb is bad, that's fair, > but we already don't ship a symlink for it. Likewise, I doubt there's > any way for someone to create a binary in one of these old formats > either, short of hand-assembling it or maybe some hack like GNU objcopy. > We all seem to agree that no one is creating new stuff that uses these > things, which is good; we also agree they shouldn't. > > The fact that this is SPARC-only is even more of a reason it can't > possibly be hurting anything: there are no SPARC users and there is zero > new development happening on SPARC. If I'm wrong about this, I want to > hear the person who is actively developing SPARC tell us why this is > obstructing progress. > > We purchase reward with the coin of risk. Even if it seems like the > risk is low, unless there's clear reward to removing something I really > do not see the point. If one person out there wants to run a copy of > Mosaic Netscape from 1992, why should we break that? It needs to buy us > something, and it just doesn't. I wish I understood your obsession with > this. Breaking the past simply does not equate to improving the future. ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
