As proof of my statement about not wanting to disrupt people unduly, I offer up my github illumos-bsd-compat repo:
https://github.com/gdamore/illumos-bsd-compat <https://github.com/gdamore/illumos-bsd-compat> (theres also a slightly older one on bitbucket, but it has the same contents). This repo builds exactly like illumos-gate, but contains only the ucblib and those parts of ucbcmd that I didn’t think really belong in /usr/bin (and it contains symlinks for those). (I.e. the users, whoami, and printenv commands.) The whole point here is to minimize disruption to users, and even mitigate the disruption to distributions, while allowing us to prune out some of those rotting bits so that the entire community doesn’t have to continue to carry them. Btw, I did this for other things as well. For example, audioplay & audiorecord. They work perfectly fine, and I suspect some people rely upon them. But they aren’t intrinsic to the system, and moving them out of the gate simplifies things. (The fact that they are a nasty bit of C++ didn’t make my decision to move them out of -gate any harder.) But I *did* create a miniconsolidation for them, and I sorted out the bits that *are* intrinsic to illumos (audioctl and audiotest) as they represent critical support for the base system. illumos-core’s goal is to minimize to a self contained fully POSIX compliant, portable, self-hosting, and ideally cross-compilable, and self-testing base environment. This is an ambitious piece of work. Unlike illumos-gate, it represents a clear vision, beyond just being a place for corporate contributors to dump code and for people who just want Solaris nostalgia^Wcompatibility. These goals will ultimately, I believe, make illumos-core a far far better shared base for all the people who are building interesting and innovative things like SmartOS, NexentaStor, etc. etc. It probably isn’t quite as nice for people who just want to be like Solaris, but I suspect that even most of them will like the results better than illumos-gate, if I am ultimately successful. Its unclear if I will be, or if I’m merely tilting at windmills. As far as I can tell, I’m in the tiny minority in this drive. But yes, when I do dozens and dozens of builds, and have to touch every goddamn Makefile to make it support cross compilation, minimizing the system makes my job lots *lots* easier. I’m far more inclined to punt out the useless dead weight than expend effort making it work. And there is tons more crap like this. Like the entire support for the Enterprise 10000 systems, which will almost never ever run illumos. Yet we carry that technical debt with us. (The debt is particularly high where SPARC is concerned, as many kernel modules have to be recompiled dozens of times to accommodate the differences in platforms. (This is mostly unix and the platmods, but not exclusively them.) Other technical debt hurts us hard. wanboot is a case in point. We carry openssl almost entirely just for this one feature, that nobody actually uses. I gutted it from illumos-core — it wasn’t easy, but it means that someday I’ll be able to yank out openssl as well. (I have to make ssh use uEF first, and fix a tiny certificate thing in ipsec userland utilities.) As far as I know, I’m the only one really pushing hard to clean this kind of crap up. After all, its more fun to just make new things. I’m trying to find a balance where I clean *and* I add new things. I think my commit history shows I do a fair bit of both. - Garrett > On Nov 8, 2014, at 12:16 AM, Garrett D'Amore <[email protected]> wrote: > > I think you may misunderstand me. I have heard the objections to removing > libucb. Indeed I believe a few people made good points and I even had > already went so far as to create a separate consolidation containing just > those bits for distros that believe that they need to provide them for their > users. > > This is quite separate from the sparc support for executing sunos 4.x > binaries which I think has no legitimate use on illumos. I do object to > arguments about keeping that around as pointless FUD and nostalgia. > > Sent from my iPhone > >> On Nov 7, 2014, at 8:08 PM, Joshua M. Clulow <[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/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
