Date: Thu, 01 Aug 2002 14:59:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Zak Johnson <zakj-freebsd-arch@nox.cx> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: OpenSSL vs. -lmd Message-ID: <3D49AF37.C7E1E272@mindspring.com> References: <200207311641.g6VGfRWj099655@freefall.freebsd.org> <20020801143059.GA536@nevermind.kiev.ua> <200208011151.55478.mi%2Bmx@aldan.algebra.com> <3D498FB4.6987B696@mindspring.com> <20020801195640.GQ26797@madman.nectar.cc> <3D4998F9.A736EA85@mindspring.com> <3D499CF3.4030601@ntlworld.com> <3D49A37B.BA3C2982@mindspring.com> <20020801212004.GC6856@opiate.nox.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Zak Johnson wrote: > On Thu, Aug 01, 2002 at 02:09:15PM -0700, Terry Lambert wrote: > > > If I had the time, I would be so sorely tempted to roll my own *BSD > > > distribution based on that idea.... FreeBSD without the fluff. > > > > > > I'd have to roll some kind of binary distribution channel as there is no > > > system compiler ;) > > > > There have been a lot of us who have felt this way. > > I'm inclined to say that an entirely new distribution is a bad idea, > because it will involve a great deal of duplicated effort. I'd agree, if it were duplicating the effort that we all felt so strongly about. But then if that were the case, there would be no need for it, since the code would be there already, and it wouldn't be a problem. So the part people are concerned with is certainly not something which would be duplication. > What was done recently with Perl was a tremendous step in the right > direction, and a good compromise for those of us who want a smaller base > system. I would like to see this sort of packaging extended to other > unnecessary packages in the base system. The largest barrier seems to > be differing definitions of "unnecessary" in this context. No, the largest barrier is that *everything* is not a package, so that *anyone* can make a decision on what "unnecessary" means to them, without shooting anyone else in the foot. In other words, if you are trying to define "unnecessary", then you are addressing a symptom, rather than the problem. The "make installworld" target defines what is and is not in "The Base System". For better or worse, this is an Ultimate Truth. Without tackling the problem at that level, it's unlikely that it will ever be solvable. If you were around when John Dyson decided to start an SMP kernel project, as a drop-in replacement for the FreeBSD kernel, you'll remember that the project flopped. John was also trying to address a symptom, without addressing the base problem. He wanted to create an SMP system, but the major attribute of such a system is kernel reentrancy. This is also the major attribute of an RT system (as one example of problem domain expansion). But John did not want to permit RT (again, an example) in the resulting system. In other words, he did not expand the set of problems that the resulting system would be able to solve. The net effect was that the newly declared project did not attract volunteers, since it wasn't really solving any new problems, other than John's own perception of the messyness of the existing code. Cleaning up the mess is a goal that could have been achieved through simple code refactoring, if people would permit what would be, without argument, "gratuitous changes" (making code readable is *always* a gratuitous change; worse: it's subjective). With three strikes against it starting out, it's no wonder that it went nowhere. The "OpenSSL vs. -lmd" discussion is, similarly, just a symptom of the real problem. The problem in this case is third party mega-packages, where you have to make an all or none choice between a set of components, rather than on an individual component basis. Ask yourself "Why is it an issue in the first place?" The answer is that the "-lmd" library is seperate in the legacy code, but glommed into the OpenSSL library, along with other cruft, making it no longer severable. The issue is one of severability. I think the idea of fundamentally breaking the system into optional and highly granular components has a large amount of "grass roots" support; discussions like the packaging discussion would not attract nearly so much participation, were that not the case. To readdress your idea of "an entirely new distribution": if that's the only way the problem will be permitted to be solved, then it's a likelihood; one way or another, the problem *will* be solved, eventually, likely sonner than later. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D49AF37.C7E1E272>