On 12/17/07, Florin Iucha <florin at iucha.net> wrote: > > On Mon, 17 Dec 2007, Josh Paetzel wrote: > > > > > A linux distribution is an independantly developed kernel + a bunch of > > > independantly developed 3rd party userland tools + an independantly > > > developed package management system + an independantly developed > > > installer released as an operating system. > > > > > > In FreeBSD (and the other BSD projects follow this model as well) the > > > installer, package management, userland, and kernel are all developed > > > together by the same project. > > And that is an advantage because...? Microsoft follows the same > model. it's an advantage for the end user because he knows that he has consistency and coherence across the kernel and the critical elements of user space. not necessarily from the perspective of making things work, although in my experience it certainly does, but because the end users get a consistent system with a _known_ suite of elements. on a *BSD system i know that i'm going to have a certain well defined set of libraries, utilities and a well honed upgrade path. it doesn't vary from distribution to distribution. things just work. i got a baseline OS and i could layer applications onto it in an entirely separate mode of operation. setting aside the relative merits of the kernel and such, it's simply a matter of operational preference. as a guy who would get paged for something (mercifully no more) i wanted to have a well established baseline with known system elements and commitments to backport features or bugs or security issues. i got that w/freebsd. the community is very good about backports and addressing _system_ bugs and security issues. while in the linux world that responsibility falls upon the distribution to take care of. > > > Take for instance the split in development between gnu libc and the > > > linux kernel. At one point in the past it was a difficult enough > > > situation that the linux kernel crowd forked gnu libc so they could > > > maintain their own, and only their inability to keep up with feature > > > development sent them back to using straight gnu libc. > > References? http://en.wikipedia.org/wiki/GNU_C_Library - see the section called "a temporary fork" having lived through that it wasn't pretty and pushed me to freebsd for production boxes pretty quickly. i simply didn't have time for that. fwiw - i don't care about the politics and such associated with this, i just need to have stuff that works and works with a minimum of fuss. i'm trying to make money. i'm kind of mercenary like that and diversions like this are wasted time for what i'm usually trying to accomplish. clearly this situation has been fixed in linux and we're all moving forward. :) > > > So you end up in > > > a situation where the linux kernel devs criticize gnu libc and vice > > > versa...."You got your chocolate in my peanut butter!" and in the > > > ultimate examples of absurdity the distros provide a fix! (a doesn't > > > worth with b so x provides a patch) > > And in FreeBSD something like this never happen? Or in any reasonably > large group of people that work to deliver a product? Like guys > developing rocket engines and the guys developing the control logic, > using different units of measure. > > There will always be friction at the interfaces. Be it a rock on a > inclined plane or hardware and software or application and database or > Tom & Jerry. > > > > That's what I mean by FreeBSD having a coherent development model. > > Lack of criticism between groups responsible for different layers? Or > everybody changing everything at once, without regard for layers > whatsoever? the freebsd development processes are hardly criticism free. there's just more (IMHO) rigor around what goes into a release. fwiw - i've found ubuntu (especially ubuntu server) to be a release that exhibits an impressive amount release rigor and commitment to backporting and acknowledging that folks have a need to focus on their on their core development/business/scientific problems and not on their linux system maintenance issues and noodling on how they're going to make libthreads+libcfoo+yourmoms_patch work and then push it out to a bunch of machines. which has historically been my frustration. people addressing the _system_ management issues and providing rigorous integration and support deserve a lot of credit/praise. kudos to the ubuntu folks and the shoulders they've stood on. > 'need more data'... 'need more data'... -- steve ulrich (sulrich at botwerks.*)