At 21:54 18/11/2003 -0500, Garance A Drosihn wrote:
Many freebsd users (me for one) are still living on a modem,
where even one bump of 1.5 meg is a significant issue...
Remember that the issue we're talking about is security
updates, not full system upgrades. Everyone would want
the security
:Many freebsd users (me for one) are still living on a modem,
:where even one bump of 1.5 meg is a significant issue...
:
:Remember that the issue we're talking about is security
:updates, not full system upgrades. Everyone would want
:the security updates, even if they're on a slow link.
:
:--
I just thought I would chime in on this heated debate and maybe add a little
gasoline or at least a few oily rags. :-)
For what it's worth, I've been running FreeBSD literally since before its
inception, when it was merely a collection of patches to 386BSD 0.1. I'm
also a longtime kernel guy so
On Tue, Nov 18, 2003, Robert Watson wrote:
(2) Shells again, because they will be fork()d and exec()d frequently
during heavily scripted activities, such as system boot, periodic
events, large make jobs, etc. And presumably the only shell of
interest is sh, although some of the
On Tue, Nov 18, 2003, Scott Long wrote:
The additional hole of exploiting the system through the shared libs
is a negative tradeoff.
Exploits in libraries happen though. The LD_LIBRARY_PATH attack is an old
one that most Unixes are hopefully hardened against.
FreeBSD had a lingering
At 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] wrote:
Of course, there was a development resource limitation,
but the decision (discussion) was made approx 6months ago?
(Enough time to solve the problem without a GLOBAL
performance hit.)
Well, yes, perhaps. But there is that issue of development
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: At 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] wrote:
: Of course, there was a development resource limitation,
: but the decision (discussion) was made approx 6months ago?
: (Enough time to solve the problem
On Tue, 18 Nov 2003, David Schultz wrote:
On Tue, Nov 18, 2003, Robert Watson wrote:
(2) Shells again, because they will be fork()d and exec()d frequently
during heavily scripted activities, such as system boot, periodic
events, large make jobs, etc. And presumably the only shell
At 2003-11-19T04:43:23Z, M. Warner Losh [EMAIL PROTECTED] writes:
The main reason we went with dynamic / was to be able to get dynamic
libary/loading support for newer authentication and user technologies.
Just a quick interjection:
As one who recently migrated a FreeBSD server from NIS to
On Tue, Nov 18, 2003, Robert Watson wrote:
On systems like Mac OS X, use of a shared
region permits not only use of prebinding, but assumptions of common load
addresses for common libraries. In addition, the shared region approach
allows the reuse of page table and VM meta-data across many
At 11:45 PM -0500 11/18/03, Robert Watson wrote:
My feeling is we should all go away for a day or two, and run
our favorite macro-benchmark on our favorite sensitive dynamic
linking-sensitive application.
I wish I had the time and background to implement one solution
that I'd like to benchmark.
On 18 Nov, Garance A Drosihn wrote:
At 8:07 AM -0500 11/18/03, [EMAIL PROTECTED] wrote:
If there hadn't been a noticed increase in cost by using
all-shared-libs, then the measurements were done
incorrectly. If the decision is made based upon allowing
for 1.5X (at least)
On 18 Nov, Robert Watson wrote:
(2) Shells again, because they will be fork()d and exec()d frequently
during heavily scripted activities, such as system boot, periodic
events, large make jobs, etc. And presumably the only shell of
interest is sh, although some of the supporting
101 - 113 of 113 matches
Mail list logo
