I am totally out of the loop on this discussion - would this affect any of the attempts to run Illumos on current SPARC sun4u hardware? Nothing that uses special hardware beyond the framebuffers. I don't use SANs - I'd implement COMSTAR for that.
I'd much rather put OpenSXCE on my Sun Blade 2500 Red versus Solaris 10, but I'll do so if necessary to get sufficient support for my hobbyist applications. Nothing special, just some game emulators... " 'With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and warning... The first time any man's freedom is trodden on, we’re all damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG episode "The Drumhead" - Alex Smith - Huntsville, Alabama metropolitan area USA On Fri, Nov 7, 2014 at 10:08 PM, Joshua M. Clulow via illumos-discuss < [email protected]> wrote: > On 7 November 2014 16:59, Garrett D'Amore via illumos-discuss > <[email protected]> wrote: > > 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. > > I don't think keeping libucb around, at least until we can reduce it > to some hollow filter library, is a huge burden on the build times. > > If you're really keen to solve a build time problem, it's probably > worth investigating things that might materially affect it: e.g. stub > objects/libraries for increased build parallelism. > > It would be worth doing some kind of GANTT-like chart of the processes > that run during a build, to find where the parallelism is (or isn't), > and where the long time periods are. People have done similar things > with anonymous DTrace and the booting of the system, to find out where > we spend all the time there. > > If the goal is truly to reduce the build time, Amdahl would have us > look for the _big_ problems first, where possible. > > > 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. > > There's no reason to just break their software unless we really get > something amazing from doing so. It is the basic expectation of > empathy for users that is taught (for a reason) in Engineering > programmes at University. > > > 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!) > > I agree this is a legitimate concern, and Robert and I were discussing > this the other day. I would rather we solve this by enhancing the > code search tooling. There will always be duplicate or overlapping > symbols in a code-base as large as ours, and clearly we cannot solve > _every_ overlap by removing code. > > I think it would be neat to adjust the cscope generation targets, or > perhaps cscope itself, to allow searching particular useful subsets of > the code -- e.g., kernel-only, or system headers only, or libraries > only. That would be genuinely helpful work for people developing the > system, and I would think would be basically without contention! > > > 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 > > I think that you left out some words, there. But, I, too, am keen to > make things better. That's why I fix bugs in things, answer > questions, look after infrastructure and upstream work from SmartOS > where I can. This is, as near as I can tell, what basically > _everybody_ is doing -- just not all in the same way. > > > 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. > > I know you don’t agree.. and are probably not alone here. > > I do not understand why you are so keen to paint people that are > reluctant to pull the rug out from existing users as some kind of > villains in a pantomime. It's not "us and them" -- we are all just > trying to get work done, without breaking stuff that _other people_ > are using; stuff that really is not in the way. > > > 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. > > It is not really fair to try to sort all changes into a 1-dimensional > line from "least" to "most" contentious. Removing rtld4.x and > exec/aout seems like attacking something very unlikely to be in use > and is probably fine -- especially if it's in the way of the > maintenance of some part of the kernel that you are trying to get > done. Removing libucb.so will clearly hurt some people, even if only > a few, and unless it's really in the way and there is no other way to > fix the road block, we may as well leave it until we have a solution > that doesn't leave users out in the cold. > > I've tried to outline a few things above that are valuable work to do > -- i.e. enhancing the code search tooling, and examining in detail why > the build takes as long as it does. I think these are tasks that, if > you are serious about improving the life of the illumos developer, you > might consider tackling! They seem like work that is much less likely > to break existing software than just culling old libraries, and I > cannot see how anybody could argue with "better cscope" or "faster > builds". > > > Cheers. > > -- > Joshua M. Clulow > UNIX Admin/Developer > http://blog.sysmgr.org > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: > https://www.listbox.com/member/archive/rss/182180/21175766-b8dde626 > Modify Your Subscription: > https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com > ------------------------------------------- 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
