dyson_at_iquest.net wrote: > Scott Long said: > >>On Tue, 18 Nov 2003 dyson_at_iquest.net wrote: >> >>>M. Warner Losh said: >>> >>>>In message: <200311181307.hAID7uHa032514_at_dyson.jdyson.com> >>>> dyson_at_iquest.net writes: >>>>: It really doesn't make sense to arbitrarily cut-off a >>>>: discussion especially when a decision might be incorrect. >>>> >>>>I'd say that good technical discussion about why this is wrong would >>>>be good. However, emotional ones should be left behind. Except for >>>>John's message, most of the earlier messages have been more emotional >>>>than technical. >>>> >>>>John, do you have any good set of benchmarks that people can run to >>>>illustrate your point? >>>> >>> >>>I'll see if I can find some of my old benchmarks (from memory, >>>not disk -- lots of stuff has rotted away.). I had hoped >>>to avoid doing much in the way of proof. Pointing to the >>>much more complex process map along with the implication >>>for significantly higher overhead :-). (The VM code generally >>>gets slower with more complex process maps and more memory used. >>>For smallish programs -- including those with a few shared libs, >>>changing the VM code won't help much, because the cost is built >>>in to the complexity of the process image.) >> >>I'm glad that real arguments are finally starting to surface =-) >> >>Our rationale for encouraging Gordon is as follows: >> >>1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want >> to upgrade from 4-STABLE. Historically in 4.x, the / partition has >> been very modest in size. One just simply cannot cram the bloat that >> has grown in 5.x into a 4.x partition scheme. Of course there is the >> venerable 'dump - clean install - restore' scheme, but we were looking >> for something a little more user-friendly. >> > [snip] > >>2. NSS support out-of-the-box: Again, this is a user-experience issue >> in that forcing NSS users to recompile world was seen as a potential >> roadblock to them. >> > [snip] > >>3. Binary security updates: there is a lot of interest in providing a >> binary update mechanism for doing security updates. Having a dynamic >> root means that vulnerable libraries can be updated without having to >> update all of the static binaries that might use them. >> > [snip] > > >>4. I've probably forgotten the other factors... >> >>As for performance, we felt that the typical use of FreeBSD did not fall >>into the category of doing forkbomb performance tests. >> > One of ther things he might have "forgot" to mention is dynamic tricks releated to PAM, which sorta falls in the same league as NSS working out of the box. It was worth mentioning IMHO. Besides, I see nothing preventing anybody from building their system with static worlds, and there is nothing stopping anybody from putting /rescue in the PATH before /bin or /sbin. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep masta_at_wifibsd.org http://wifibsd.orgReceived on Tue Nov 18 2003 - 15:43:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:29 UTC