Btw, if this is the direction that illumos is going to go down, then I’ll stop bothering to try to upstream the other improvements I’ve been making. I frankly don’t have the time to keep fighting the battle, and maybe just getting back to coding on illumos-core would be better for my overall sanity.
- Garrett > On Nov 7, 2014, at 4:59 PM, Garrett D'Amore <[email protected]> wrote: > > 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
