On Thu, Dec 04, 2003 at 07:54:03AM -0800, Karsten M. Self wrote: > on Wed, Dec 03, 2003 at 04:57:29PM +0100, Adam ENDRODI ([EMAIL PROTECTED]) wrote: > > > > I tend to disagree. The kernel is a versatile program, it can be > > patched, configured and compiled in too many ways. > > ...including many of which are wrong, broken, or suboptimal. [...] > I already count seven builds of the 2.4.20 kernel on x86 architecture, > fitting specific needs of different specific kernel types as well as > uni- and multi-processor systems.
I can't accept that the seven builds could come ahywhere close to satisfy adequately the needs of 75% of the user base at least. Perhaps there are actually more people who rely on the prebuilt kernel packages but I'm sure a great deal of the installations are a result of the lack of time, skills or motivation. To illustrate my point, let us suppose you want a module-less system. This case all of the prebuilt binary packages suddenly become useless. What if you need a driver for thrid-party NIC which conflicts with another in the vanilla tree? What about PaX + UML which you cannot apply to the same tree without tinkering the source? No doubt, many people, for they don't know any better, can survive without the features I've outlined above, but it appears to me the solution (of staying with dpkg -i kernel*) leads them to a situation you've described in you reply: suboptimal. > > To sum up, it's always great to have a chance to learn from > > the more experienced, but I don't expect them to do my homework. > > They are not supposed to. > > You're missing the point of collaborative development. > > For the individual, or group, which puts the effort into building a > secure architecture, Debian offers distribution, bugtracking, QC, and > release mechanisms which can prove highly useful. In the specific case > of kernel hardening, there's the question of how to package and > structure things in a way that's useful across other axes of variance > (arches, SMP/UP, server/workstation/desktop, etc.), but the task isn't > impossible. You've misunderstood what I tried to explain, I'm afraid. I was talking specially about the kernel, not the general consciousness of the project. I really appreciate the effort the Debian Developers make to produce well-thought, accountable and cooperating packages that cover the common expectations. On the other hand, it's impossible for them to prepare for the less common ones. How come I've never been able to deploy any web service (phpmyadmin, mailman, bugzilla, ...) via a simple dpkg -i? The packages place files under /var/www when I need a different destination directory in a different layout and with different owner/group/permissions; the packages put symlinks and suid binaries here and there which I don't allow; the php scripts are assumed to be interpreted by the mod_php module that I refuse to load... Little details of a system are subject to change and my observation is that the more you customize the more likely you'll end up in trouble. Clearly, in my case with my little changes I diverge from the Debian (and likely other) standards more than the automatic install scripts could tolerate. In a nutshell, I can hardly imagine a well-maintained system without a fistful of customizations, and in my opinion, it's easy to reach the point after which the standard Debian packages cannot support your strategies. And certainly, the Debian developers are not to be blamed for the natural limitations of their packages. > Peace. PaX. bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever? | 82DD 54C2 843D 37B8 D989 Renegade? | http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
