Joerg Sonnenberger wrote: >> One has to be totally unaware of realities to suggest tools from >> obscure Linux distributions, wether they are good or bad, when such >> distribution may collapse at any moment. Already the move to NetBSD >> pkgsrc has cost DFLY division by 3 of the number of available ports with >> respect to FreeBSD for an advantage that i have hard time to even >> discern. > > Package counting like comparing penis length. There are more important > parameters... I've spoken with at least one member of FreeBSD's portmgr > who cursed the current size of the tree, making it very hard to > maintain or move forward. A friend also just reminded me that ports has > over 8700 (!) Perl modules in the list, factoring that out reducing the > divisor a lot.
rose% uname -a FreeBSD rose 6.2-RELEASE FreeBSD 6.2-RELEASE #1: Sat Feb 3 12:51:15 UTC 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROSE i386 rose% find . -depth 2 -maxdepth 2|grep p5|wc -l 2684 and this picks php5 stuff and perhaps other. The reality is that on FreeBSD i find everything i want in the ports, even more easily that in Ubuntu, while on several other BSD and Linux systems i don't, by a very large margin. This is not pissing contest, for me the wide abundance of ports in FreeBSD is by far the most important reason why i am using it. It is certainly not because the kernel is more stable or more performing that on a Linux system, which would not be true, it is because each time i want to use some software i find it. OpenBSD has an excellent packaging system recently revamped by Marc Espie, but it is severely lacking ports coverage. What FreeBSD and NetBSD lack is a good system for management of binary packages. Marc has very well understood that, and has made every effort so that updates work smoothly. To my knowledge OpenBSD is the only BSD which has a working update mechanism, fully integrated. I have written something experimental for FreeBSD: http://www.lpthe.jussieu.fr/~talon/pkgupgrade because i think there is no future for an OS without a binary packages management system,for the reasons that i have mentioned. Sorry, i don't buy Steve's arguments. It is not because One person wants to build sane without gimp support that All users have to endure the pain of building all their ports. The solution is simply that Steve uses an alternative mechanism, involving compilation, when he wants to install sane. If moreover the reason for such desire is to avoid bloat on the hard disk, then i call that an exercise in futility.