Hi Luke, There are others that are far better at walking through this than I am, but as someone who has experienced source based Unixes and Solaris alike...
Luke wrote: >Any system based on binary package management cannot be as flexible as a >system which works with source-based packages. At least in the world of >open-source software, there are often important configuration options which >must be chosen at the start of the build process of a certain piece of >software. > Sometimes these build options are entirely valid things to be configuring before building a binary. Sometimes it's just a method of admitting you don't want to do the hard work of handling different binary execution environments in your program. As you're probably also familiar with, just because you have the source does not mean it will work with your systems particular 'genome'. With some "source based" linux distributions, upgrade of one particular package will cause a cascade of upgrades. In some cases, this will break a number of other things unintentionally (and without any way to go back). > Additionally, the target CPU for a particular binary must be selected before > the build - the performance penalty of using binaries targetted to a > different CPU vary, but in some cases it is quite significant (such as on the > Pentium 4). > Ah, but there are other solutions for that problem. Some of which OpenSolaris already handles. Admittedly, it's more complex in the mixed 32/64 bit area, but one can still get the capabilities one desires without having to resort to everyone needing a compiler and the skills to operate it. http://cvs.opensolaris.org/source/xref/usr/src/cmd/sgs/rtld/common/cap.c http://blogs.sun.com/roller/page/rie?entry=shared_object_filters http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl19?a=view#chapter2-19 OpenSolaris even uses this for libc, meaning applications can benefit from different hardware capabilities without needing to be recompiled. And the application developer didn't even need to know about it or "configure" it. It also means even old binaries created before the existence of the new hardware capabilities can benefit from said capabilities. >Distributing packages as binaries may be necessary for closed source software, >but there's no need for such a limitation with open source software. > True, but you can, in some cases, run into other limitations. Just because you have source, does not mean interdependencies do not exist. Does the end user know how to handle this source package? Does the end user know the right flags to throw at the config/makefile (GNU autoconf doesn't get this right for me on most distros). Also, it's arguable that for some things (i.e. apps from ISVs that won't provide source, device drivers source is not available for, etc.) you will inhibit your own flexibility by expecting to be able to rebuild dependencies from new source every time you upgrade one component. Take a look at this article, I think it's an excellent read: http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=305&page=1 Just a few thoughts, - Matt -- Matt Ingenthron - Technical Specialist, Web Services Sun Microsystems, Inc. - Client Solutions http://blogs.sun.com/mingenthron/ email: [EMAIL PROTECTED] Phone: 310-242-6439 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
