In the last episode (Nov 19), Richard Coleman said:
I don't really care whether everything is statically or dynamically linked. With the fast machines and huge disks these days, bloat is not much of an issue. But nss and pam need to work correctly. If the folks that are against dynamic linking have an alternate method to make this work, I'm all for it. But it needs to be more than theory. We need code.
To be honest, I've never understood the (seemingly irrational) resistance against this change. Solaris made this change 10 years ago.
Not completely:
$ uname -a SunOS pd1 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-Enterprise $ file /bin/sh /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically linked, stripped $ file /sbin/* | grep statically | cut -d: -f1 | fmt /sbin/autopush /sbin/fdisk /sbin/jsh /sbin/mount /sbin/sh /sbin/soconfig /sbin/sync /sbin/umount /sbin/uname
I have no problem with FreeBSD doing something similar and leaving a few binaries static. I think most of the resistance to that was due to the increased complexity of the build system.
It seems /bin/sh is the real sticking point. But if the compromise is to statically link /bin/sh, that would be cool with me. Other than tilde expansion not working when using nss_ldap, I can't think of any other problems. I consider that a minor blemish I could easily live with. Normal users will not generally have /bin/sh has their shell anyways. And I could always compile a dynamically linked version into /usr/bin if necessary.
To be honest, 98% of the time that someone notices brokeness due to nss_ldap, it comes when using /bin/ls.
Richard Coleman [EMAIL PROTECTED]
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
