Date: Sun, 16 Dec 2007 04:35:27 -0700 From: Modulok <modulok@gmail.com> To: "Tino Engel" <elrap@web.de> Cc: FreeBSD-Questions@freebsd.org Subject: Dependencies. (was: "Yikes! FreeBSD samba-3.0.26a_2, 1 is forbidden: "Remote Code Execution...") Message-ID: <64c038660712160335x61bc5965m74aa98e5cc5e21af@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
<snip> >>Code re-use is a good thing. Intricate, far-reaching dependencies are >> not. While package managers attempt to mitigate the underlying issue, >> using code re-use as an excuse for the fragility of a system design, >> is unfortunate. I do not pretend to have all of the answers, but I >> feel that current state of things could be much improved. </snip> On 12/15/07, Tino Engel <elrap@web.de> wrote: <snip> >I think that what you describe as "intricate, far-reaching dependencies" >is determined by adequately designing a complex system in order to keep >it modular (in not over-sized modules) and therefore easy-to-maintain. </snip> We concern ourselves with the size of a given module in light of reducing system resource usage, (namely storage space and arguably memory usage) but we don't blink at burning 300+ megs on the ports collection... the majority of which consists of build skeletons for packages that are not installed. What happens when the ports collection grows to double it's size? Then double again? Not to worry, we'll be saving disk space on installed modules, by sharing modules between packages. (Thus making them intricately dependent upon one another.) Furthermore, we'll install them all in a single directory by default, such that they exist within the same namespace, presenting the opportunity for name conflicts. While things such as name conflicts should not happen. In the real world, they do. Come to find out, trying to maintain all the little pieces was a royal pain and thus we birthed a toolset in an attempt to solve the problem, both keeping track of dependencies and conflicts. Package managers of every shape and size popped up. While they certainly do mitigate the issue to various degrees, they do not solve the underlying problem. Often they introduce new problems. >And this is imho the only effective way to structure a big software project. So between now and eternity it is not possible for anyone to ever come up with a solution that is better? I'd like to hope otherwise. Yes, what we have works...sort of. (Your milage may vary.) Is it better than what we had? Arguably. Could it still be improved? I sincerely hope so. Sorry for the seemingly endless ranting, I'll shut up eventually :p -Modulok-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64c038660712160335x61bc5965m74aa98e5cc5e21af>