consolidations? In-Reply-To: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Approved: F3r4kX X-OpenSolaris-URL: http://www.opensolaris.org/jive/message.jspa?messageID=237998&tstart=0#237998
> I'm wondering, what thought has anyone seriously > given to the notion of > "shrinking" ON? One advantage to having a large what-is-referred-to-as-ON-in-OpenSolaris `consolidation' is that, when built, you receive a system containing pretty much everything you need as a user to get going. The BSDs have a similar thing going -- there's sendmail (or postfix for NetBSD, I think) and BIND, OpenSSL, all the standard command-line utilities (ls, grep, cut, sed, awk, and what-have-you), the kernel, manpages for everything, and some other stuff that I'm leaving out to be at least somewhat brief. It's possible (due to the directory hierarchy and build infrastructure) to check out only specific bits of what you're interested in, and there is some idea of consolidation in building as well (one can disable building of BIND/sendmail/crypto libs, build only the kernel, build only one utility). Certainly as a developer (re-)beginning to become involved in the project, it's a good thing to have all of this at my fingertips. While I'm mostly interested in kernel-specific stuff, having everything there helps me better understand how everything is set up, how builds work, etc. [snip] > And, it seems like a *lot* of ON doesn't have any > natural reason to be > in ON, other than historical reason, or lack of any > better place to put > it. For example, the recent filebench integration. > Or perl 5.6.1. Or > endmail. Or pretty much the entire printing > subsystem. Or even the > libucb compatibility stuff. I'm sure there's a lot > more that could > easily be pared down. Unless you consider that ON is perhaps not the best name for what it actually is. It seems to me to be mostly a legacy name. These days, networking is tied in to the kernel; it's not really a separate module anymore (though I guess you could probably make it one), and when I hear `operating system', I think `kernel'. Base system or operating environment: these are terms that I think describe more aptly what ON actually represents. And since all of these parts work together to some degree, I think that a globally encompassing `consolidation' for them all is not a particularly bad thing. > My point is, maybe we should consider a separate > consolidation, > "utility" or somesuch, for portions of ON that are > not actually required > to build or boot ON. I'd hazard a guess that this > would help out most > folks who work in ON a great deal -- regardless of > whether their project > was in ON or the new consolidation. (I mean come on, > do the folks > working on "vi" really need or a want a copy of the > entire kernel and > all the drivers? Or even a copy of libc?) Well, I certainly don't know a whole lot of the rather large history behind ON, what it was historically. I'll second Keith's comment on people working on vi needing / wanting libc. I don't know how this is set up internally in Sun, but I'd imagine someone working on vi is not limited to working specifically on vi (and if so, I can't imagine them needing to work on it for a period more than a couple months at the most). People who work in userland utilities (in my experience) end up working in several of them. While they may not *need* a copy of the kernel, openssl, sendmail, or perl for what they're doing, having an environment that, when built, represents the entire, hosted base of what they're working on is (in my view) more of a good thing than not. Figuring out what level to break this down is also difficult. You could have a base-system and a kernel consolidation, which I could understand, but not much more than that. Breaking down the base system is kind of hard. You could probably logically separate it into unix-utilities, sendmail, perl, etc., but going deeper (editors, pattern matching tools, file management tools, etc) seems to me to be splitting hairs. You could do a similar thing for the kernel as well, but I don't think that'd be beneficial at all. Whether you're working in VFS, netstacks, drivers, VM, DTrace, whatever, changes (in general) could potentially affect something anywhere else in the system. > I wouldn't be surprised to learn that X11 or JDS or > SFW have similar > concerns. Unbounded growth of consolidations is > probably painful > everywhere. Granted, someday hopefully we'll get > better tools (hg), but > even then, you have to populate an initial tree to > start working, so a > smaller consolidation is still beneficial. For cutting down build times, I think that a better build infrastructure is possible, and that could speed things up significantly (by easily being able to specify which components of the build to leave out, as one of myriad possibilities). As far as the time it takes to populate the initial tree: it took me about 20 minutes to clone the anonymous-accessible mercurial repo from home. That may be more or less time than average, but I didn't find it a frustratingly long amount of time. And figuring out how to navigate through it, where things are declared, what's where -- well, that's what I find grep, cscope, and the online source cross reference useful for :) > -- Garrett This is all certainly just my opinion; I don't have any clue how it affects you at Sun from an engineering or efficiency standpoint. --dho This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
