On Wed, Dec 03, 2003 at 07:44:16AM -0600, Bob Willcox wrote:
Nothing specific. I suppose it's just a space-time tradeoff from my
point of view. With disk sizes what they are today (most of my systems
have a system disk size of 40 GB or more), in my environment reducing
the root filesystem
In a message written on Tue, Dec 02, 2003 at 06:05:40PM -0200, Daniel C. Sobral wrote:
And if you are using FreeBSD on desktop you should use bash or some
other ports-shell, instead of slowing down _the_ shell for shell
scripts. But that's IMHO, so I didn't pipe this in until now. But it's
Daniel C. Sobral wrote:
Now, my machines usually get by themselves, but all *I* do on them is
sh(1) intensive, so I'll probably be using the static root option when
it comes time to upgrade them to 5.x.
The static root option exists for people with special requirements:
* Use a lot of shell
On Tue, Dec 02, 2003 at 01:43:16PM -0800, Tim Kientzle wrote:
Daniel C. Sobral wrote:
Now, my machines usually get by themselves, but all *I* do on them is
sh(1) intensive, so I'll probably be using the static root option when
it comes time to upgrade them to 5.x.
The static root option
Bob Willcox wrote:
What impact, if any, will this have on those of us that use NIS and
still want a statically linked root? I have been using NIS for years ...
First, let me clarify that I'm advocating moving NIS out of libc in
the 6.0 timeframe. Also, I'm not suggesting anyone replace NIS
with
In the last episode (Dec 02), Tim Kientzle said:
Does that rule out NIS with a static root?
Yes, with the current NSS/PAM implementation, although a variety of
suggestions have been floated around that would make NSS/PAM
compatible with static binaries. My personal favorite is to
implement
I have found that the cost of printing the spew often
slows down compiles measurably, especially when spewing
to an xterm running on a local XFree86 process. Even
with syscons, this is noticeable.
I generally tend to run my builds behind the screen
port these days, which helps (screen implements
Jonathan Mini wrote:
I have found that the cost of printing the spew often
slows down compiles measurably, especially when spewing
to an xterm running on a local XFree86 process. Even
with syscons, this is noticeable.
I generally tend to run my builds behind the screen
port these days, which
On Dec 1, 2003, at 10:15 PM, Scott Long wrote:
Jonathan Mini wrote:
I have found that the cost of printing the spew often
slows down compiles measurably, especially when spewing
to an xterm running on a local XFree86 process. Even
with syscons, this is noticeable.
I generally tend to run my
At 6:27 PM +1100 11/27/03, Bruce Evans wrote:
On Wed, 26 Nov 2003, Garance A Drosihn wrote:
I have reformatted the numbers that Michael reported,
into the following table:
Static /bin/sh: Dynamic /bin/sh:
real385m29.977s real455m44.852s = 18.22%
user
On Wed, 26 Nov 2003, Garance A Drosihn wrote:
At 12:23 AM -0500 11/26/03, Michael Edenfield wrote:
Just to provide some real-world numbers, here's what I got
out of a buildworld:
I have reformatted the numbers that Michael reported,
into the following table:
Static /bin/sh:
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: What are people doing to make buildworld so slow?
using gcc 3 :-)
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
Brad Knowles wrote:
At 2:48 PM -0800 2003/11/25, Matthew Dillon wrote:
What I am advocating is that FreeBSD-5 not marginalize and
restrict (make less flexible) basic infrastructure in order to get other
infrastructure working.
If you've got working,
At 12:23 AM -0500 11/26/03, Michael Edenfield wrote:
Just to provide some real-world numbers, here's what I got
out of a buildworld:
I have reformatted the numbers that Michael reported,
into the following table:
Static /bin/sh: Dynamic /bin/sh:
real385m29.977s real
obrien wrote @ Tue, 25 Nov 2003 18:55:05 -0800:
On Tue, Nov 25, 2003 at 03:07:55PM +1030, Daniel O'Connor wrote:
What about the newer version of gcc? That is considerably slower than
previous versions, but I don't see people screaming to have it removed.
Uh... you must not know what you
* M. Warner Losh [EMAIL PROTECTED] [031126 00:43]:
In message: [EMAIL PROTECTED]
Michael Edenfield [EMAIL PROTECTED] writes:
: * M. Warner Losh [EMAIL PROTECTED] [031125 12:07]:
: In message: [EMAIL PROTECTED]
: boyd, rounin [EMAIL PROTECTED] writes:
: : i see that
* Garance A Drosihn [EMAIL PROTECTED] [031126 06:56]:
At 12:23 AM -0500 11/26/03, Michael Edenfield wrote:
Just to provide some real-world numbers, here's what I got
out of a buildworld:
I have reformatted the numbers that Michael reported,
into the following table:
Static /bin/sh:
:At 00:23 26/11/2003 -0500, Michael Edenfield wrote:
:Static /bin/sh:
: real385m29.977s
: user111m58.508s
: sys 93m14.450s
:
:Dynamic /bin/sh:
: real455m44.852s
: user113m17.807s
: sys 103m16.509s
:
: Given that user+sys real in both cases, it looks like
In message: [EMAIL PROTECTED]
Michael Edenfield [EMAIL PROTECTED] writes:
: time make -j 4 buildworld
Hmmm, more jobs.
: They were on a single CPU Athlon 500 with 320MB of RAM.
320MB is not enough RAM not to swap.
I did some preliminary testing last night (which I lost due to a
: That seems to have the most impact. We can also expend our efforts
: to improve dynamic linking performance, since that will improve the
: performance of the other 99.9% of the universe.
:
:
:What happened to mdodd's prebinding efforts?
:
:Drew
Prebinding was put into DFly but the
* M. Warner Losh [EMAIL PROTECTED] [031126 14:51]:
In message: [EMAIL PROTECTED]
Michael Edenfield [EMAIL PROTECTED] writes:
: They were on a single CPU Athlon 500 with 320MB of RAM.
320MB is not enough RAM not to swap.
However, having said that, I think everybody realizes the
On Wed, 26 Nov 2003, Terry Lambert wrote:
I don't know what Matt is planning on delivering, but...
http://developer.apple.com/darwin/projects/opendirectory/
[...]
lookupd is included with the Darwin project and is
documented online in Apple's Support database and
as
MD Date: Tue, 25 Nov 2003 11:50:25 -0800 (PST)
MD From: Matthew Dillon
MD (B) the authentication code access an IPC service which *ONLY* allows
MD challenge/response, does *NOT* give you direct access to the
MD encrypted contents of the password file, and which limits the challenge
MD
On Mon, 24 Nov 2003, Andrew Gallatin wrote:
Daniel O'Connor writes:
It is _trivial_ to buildworld with a static root.
Then its equally trivial to build with a dynamic root. Please do so,
and don't wreck the performance of the OS I've used since 1994.
Then just use OS from 1994 and
./Scott Long wrote:
Please, read : http://www.netmeister.org/news/learn2quote.html
Also, I'm really starting to resent you using the FreeBSD mailing
lists as an advocacy channel for DragonFly. I fail to see how FreeBSD
4.x and DFBSD relate to FreeBSD 5-current, which is the overall topic
of
On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote:
H, It looks like the hit is less than 10% in the fork intensive
test I just wrote:
#!/bin/sh
for i in 0 1 2 3 4 5 6 7 8 9; do
for j in 0 1 2 3 4 5 6 7 8 9; do
for k in 0 1 2 3 4 5 6 7 8 9; do
for l in 0 1
In message: [EMAIL PROTECTED]
Peter Jeremy [EMAIL PROTECTED] writes:
: On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote:
: H, It looks like the hit is less than 10% in the fork intensive
: test I just wrote:
:
: #!/bin/sh
: for i in 0 1 2 3 4 5 6 7 8 9; do
: for
On Tue, Nov 25, 2003 at 04:54:41AM +, E.B. Dreger wrote:
What specific aspects of rtld are required to support NSS in
static binaries? dlopen(), fixups, and dlsym()?
All of the above. The underlying problem is how to handle a
library call from within the NSS/PAM/whatever shared library.
On Tue, Nov 25, 2003 at 01:17:34AM -0700, M. Warner Losh wrote:
True. However, I get very similar numbers of I change it to
/usr/bin/true (12% slower). /bin/sh usually fork+exec things other
/bin/sh.
That's a more interesting result and more comparable to Drew's test.
It doesn't necessarily
On Mon, 24 Nov 2003, Leo Bicknell wrote:
Process accounting can tell the story:
% lastcomm | wc -l
47806
% lastcomm | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head
25281 sendmail
4094 sh
2987 perl
2846 inetd
1704 procmail
1640 httpd
1221 cron
814 date
732 postgres
648
:...
:5.x and propaganda about DFBSD doesn't really mean a whole lot, unless you
:are looking for new recruits to your camp. In any case, you've made your
:point on a nearly daily basis that 5.x is inferior to what DFBSD will be,
:and that you don't have much knowledge or care about 5.x anyways.
On Tuesday 25 November 2003 03:07, Don Lewis wrote:
On 25 Nov, Daniel O'Connor wrote:
On Tuesday 25 November 2003 11:52, Dan Nelson wrote:
I'd greatly prefer that the the dynamic root default be backed out
until a substantial amount of this performance can be recovered.
What
i see that there some doubt about whether running lots of
shell scripts ever happens. what happens when you
use make? lots of shells get run and they run small
(one line?) scripts.
___
[EMAIL PROTECTED] mailing list
That's a more interesting result and more comparable to Drew's test.
It doesn't necessarily invalidate Drew's results - /bin/sh has 3
shared libraries and is locale-aware whereas /usr/bin/test has 1
shared library and doesn't rely on the locale. /usr/bin/true is also
significantly smaller
Matthew Dillon writes:
Hmm. Well, I think there's some confusion here. While I
certainly like my vision for DFly better then I like the vision
for FreeBSD-5, that is simply in the eye of the beholder... of
course I am going to like my own vision better. It's my vision,
On Mon, Nov 24, 2003 at 07:11:29PM -0800, Matthew Dillon wrote:
You don't need dynamic loading to get nsswitch type functionality. You
only need dynamic loading if nobody is willing to write an IPC
model to get the functionality. It's really silly to create such a
fundamental
On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote:
How about Gordon's initial bootstone, which increased by 25%?
http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531
And I just did a make clean run in /usr/ports/archivers (by manually
mv'ing a static and dynamic sh to
On Mon, Nov 24, 2003 at 08:22:52PM -0600, David Leimbach wrote:
Yep :).
I feel like saying set the default to static and make the dynamic bins
the option so
the people who can't be bothered to compile their own system even
though everyone
I know does this for tuning purposes anyway can
Jacques A. Vidrine wrote:
On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote:
How about Gordon's initial bootstone, which increased by 25%?
http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531
And I just did a make clean run in /usr/ports/archivers (by manually
Jacques A. Vidrine writes:
So can we just have a statically linked /bin/sh and get on with life?
That certainly seems like the best compromise. Then we can end this
thread ;)
That seems to have the most impact. We can also expend our efforts
to improve dynamic linking performance,
In message [EMAIL PROTECTED], Jacques A. Vidrine
wri
tes:
So can we just have a statically linked /bin/sh and get on with life?
I was thinking the same thing myself a few days ago.
Cheers,
--
Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/
BC Government .
At 9:19 AM -0600 11/25/03, Jacques A. Vidrine wrote:
On Mon, Nov 24, 2003, Andrew Gallatin wrote:
So can we just have a statically linked /bin/sh and get on
with life?
I still think we would be better off using 5.2-release for
collecting more experience with the *operational* issues of
having a
In message: [EMAIL PROTECTED]
boyd, rounin [EMAIL PROTECTED] writes:
: i see that there some doubt about whether running lots of
: shell scripts ever happens. what happens when you
: use make? lots of shells get run and they run small
: (one line?) scripts.
make buildworld slows
Daniel O'Connor [EMAIL PROTECTED] writes:
What _REAL WORLD_ task does this slow down?
I suspect 'make world' takes a serious hit.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
:IMHO, it makes more sense to write NSS modules that do their own
:proxying than to make things even more complicated in libc. Those
:that are lightweight don't carry extra baggage; those that do can
:implement proxying in the most efficient manner for that particular
:backend, e.g. some calls
On Tue, Nov 25, 2003 at 11:50:25AM -0800, Matthew Dillon wrote:
Just not thinking out of the box, maybe.
Matt, I'm talking about the de facto standard NSS, as found in Solaris
and Linux; and now FreeBSD 5 [*] and soon NetBSD [**]. You are talking
about some better mousetrap. The latter
On Tue, Nov 25, 2003 at 07:36:45PM +0100, Dag-Erling Sm?rgrav wrote:
Daniel O'Connor [EMAIL PROTECTED] writes:
What _REAL WORLD_ task does this slow down?
I suspect 'make world' takes a serious hit.
It does not (Warner has quoted numbers a few times now).
Kris
pgp0.pgp
Description:
:Matt, I'm talking about the de facto standard NSS, as found in Solaris
:and Linux; and now FreeBSD 5 [*] and soon NetBSD [**]. You are talking
:about some better mousetrap. The latter does not have any relevance
:to this thread, which is about dynamic linking in next release of
:FreeBSD.
:
:If
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote:
So, yes, I do think you guys are being lazy in that regard. If this
is the path you've chosen to go then you have an obligation not to
tear out major existing system capabilities, such as the ability to
generate
: is the path you've chosen to go then you have an obligation not to
: tear out major existing system capabilities, such as the ability to
: generate static binaries, in the process.
:
:If this is what you think has happened, you're living in some parallel
:fantasy universe.
I am
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote:
My original opinion
still stands... you guys are using this issue as an excuse to basically
do away with static binaries, rather then fixing the real problem which
is an inability to dynamically load modules in a
On Tue, Nov 25, 2003 at 01:15:58PM -0800, Matthew Dillon wrote:
: is the path you've chosen to go then you have an obligation not to
: tear out major existing system capabilities, such as the ability to
: generate static binaries, in the process.
:
:If this is what you think has
:No, what you said was not to tear out..the ability to generate static
:binaries. That's completely different, and is absolutely not what
:has happened, or what is planned. Static binaries continue to be
:supported, available, and work with the system NSS and PAM modules as
:before.
I
At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote:
... Or you can build an IPC mechanism that implements the PAM
functionality and then have programs which would otherwise use PAM
instead use the IPC mechanism. Which is the whole point of having
the IPC mechanism in the
At 11:27 PM +0100 11/25/03, Brad Knowles wrote:
At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote:
... Or you can build an IPC mechanism that implements
the PAM functionality and then have programs which
would otherwise use PAM instead use the IPC mechanism.
Which is the
At 2:48 PM -0800 2003/11/25, Matthew Dillon wrote:
What I am advocating is that FreeBSD-5 not marginalize and
restrict (make less flexible) basic infrastructure in order to get other
infrastructure working.
If you've got working, debugged code that works in the manner you
On Tue, Nov 25, 2003 at 03:07:55PM +1030, Daniel O'Connor wrote:
What about the newer version of gcc? That is considerably slower than
previous versions, but I don't see people screaming to have it removed.
Uh... you must not know what you are talking about. GCC *COMPILES*
slower as it does a
On Wednesday 26 November 2003 13:25, David O'Brien wrote:
On Tue, Nov 25, 2003 at 03:07:55PM +1030, Daniel O'Connor wrote:
What about the newer version of gcc? That is considerably slower than
previous versions, but I don't see people screaming to have it removed.
Uh... you must not know
* boyd, rounin [EMAIL PROTECTED] [031125 05:16]:
i see that there some doubt about whether running lots of
shell scripts ever happens. what happens when you
use make? lots of shells get run and they run small
(one line?) scripts.
Just to provide some real-world numbers, here's what I got
* M. Warner Losh [EMAIL PROTECTED] [031125 12:07]:
In message: [EMAIL PROTECTED]
boyd, rounin [EMAIL PROTECTED] writes:
: i see that there some doubt about whether running lots of
: shell scripts ever happens. what happens when you
: use make? lots of shells get run and they run
In message: [EMAIL PROTECTED]
Michael Edenfield [EMAIL PROTECTED] writes:
: * M. Warner Losh [EMAIL PROTECTED] [031125 12:07]:
: In message: [EMAIL PROTECTED]
: boyd, rounin [EMAIL PROTECTED] writes:
: : i see that there some doubt about whether running lots of
: :
At 00:23 26/11/2003 -0500, Michael Edenfield wrote:
Static /bin/sh:
real385m29.977s
user111m58.508s
sys 93m14.450s
Dynamic /bin/sh:
real455m44.852s
user113m17.807s
sys 103m16.509s
Given that user+sys real in both cases, it looks like you're running
out of
So.. forking a dynamic sh is roughly 40% more expensive than
forking a static copy of sh. This is embarrassing.
read the original paper carefully:
On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote:
So.. forking a dynamic sh is roughly 40% more expensive than
forking a static copy of sh. This is embarrassing.
I propose that we at least make /bin/sh static. (and not add a
/sbin/sh; if we must have a dynamic sh, import pdksh, or
At 3:15 PM -0500 11/24/03, Andrew Gallatin wrote:
Here is a simple test which times the execution of a null
shell script. It basically times fork/exec of the chosen
shell.
So.. forking a dynamic sh is roughly 40% more expensive
than forking a static copy of sh. This is embarrassing.
To be more
Daniel O'Connor wrote:
What _REAL WORLD_ task does this slow down?
I think the point was that, in this particular worst case, it's a forty
percent performance hit. What's the average case? What's the case for a
real world pipeline with a lot of tiny little static binaries?
I dislike this
In the last episode (Nov 25), Daniel O'Connor said:
On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote:
So.. forking a dynamic sh is roughly 40% more expensive than
forking a static copy of sh. This is embarrassing.
I propose that we at least make /bin/sh static. (and not add a
In message: [EMAIL PROTECTED]
Dan Nelson [EMAIL PROTECTED] writes:
: In the last episode (Nov 25), Daniel O'Connor said:
: On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote:
: So.. forking a dynamic sh is roughly 40% more expensive than
: forking a static copy of sh. This
On Monday 24 November 2003 05:25 pm, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Dan Nelson [EMAIL PROTECTED] writes:
: In the last episode (Nov 25), Daniel O'Connor said:
: On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote:
: So.. forking a dynamic sh is
On Tuesday 25 November 2003 11:36, Frank Mayhar wrote:
Daniel O'Connor wrote:
What _REAL WORLD_ task does this slow down?
I think the point was that, in this particular worst case, it's a forty
percent performance hit. What's the average case? What's the case for a
real world pipeline
On Tuesday 25 November 2003 11:52, Dan Nelson wrote:
I'd greatly prefer that the the dynamic root default be backed out
until a substantial amount of this performance can be recovered.
What _REAL WORLD_ task does this slow down?
Try timing cd /usr/ports/www/mozilla-devel ; make clean
Daniel O'Connor writes:
On Tuesday 25 November 2003 11:52, Dan Nelson wrote:
I'd greatly prefer that the the dynamic root default be backed out
until a substantial amount of this performance can be recovered.
What _REAL WORLD_ task does this slow down?
Try timing cd
Steve Kargl wrote:
On Mon, Nov 24, 2003 at 05:06:52PM -0800, Frank Mayhar wrote:
Kind of defeats the purpose, don't you think?
Let's see. You dislike the dynamic root decision enough that
you are considering the abandonment of FreeBSD. Then when
you're told that you can still build a
Daniel O'Connor writes:
It is _trivial_ to buildworld with a static root.
Then its equally trivial to build with a dynamic root. Please do so,
and don't wreck the performance of the OS I've used since 1994.
Why didn't you pipe up when this was discussed _long_ ago?
In the orginal
I'm not going to add to the heat in the rest of the email, but this is
a very good question:
Daniel O'Connor wrote:
Why didn't you pipe up when this was discussed _long_ ago?
Honestly, I don't remember the discussion. It's certainly possible that I
may have missed it. I just dug around in the
On Tuesday 25 November 2003 12:23, Frank Mayhar wrote:
Let's see. You dislike the dynamic root decision enough that
you are considering the abandonment of FreeBSD. Then when
you're told that you can still build a static root if you
need/want it, you make a sarcastic remark.
It wasn't
On 25 Nov, Daniel O'Connor wrote:
On Tuesday 25 November 2003 11:52, Dan Nelson wrote:
I'd greatly prefer that the the dynamic root default be backed out
until a substantial amount of this performance can be recovered.
What _REAL WORLD_ task does this slow down?
Try timing cd
In a message written on Tue, Nov 25, 2003 at 12:12:59PM +1030, Daniel O'Connor wrote:
If you have a file, web, mail, database, etc server it's predominant
application is already dynamically linked.
It just occured to me what bothers me about this line of thinking,
since several people have
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
: I'll bet a larger percentage of our users build ports than need nss or
: ldap.
I'll bet a larger percentage of the people are ignoring this thread
than reading it since it has been so devoid of concrete numbers.
M. Warner Losh writes:
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
: I'll bet a larger percentage of our users build ports than need nss or
: ldap.
I'll bet a larger percentage of the people are ignoring this thread
than reading it since it
Daniel O'Connor wrote:
You DO know FreeBSD is a cooperative project right?
Of course I do. I was using it when it was just 386BSD 0.1 and a patchkit.
I've watched it through a lot of changes and while I've never been a part
of the team, mostly due to lack of time, I try to throw whatever I can
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
:
: M. Warner Losh writes:
: In message: [EMAIL PROTECTED]
: Andrew Gallatin [EMAIL PROTECTED] writes:
: : I'll bet a larger percentage of our users build ports than need nss or
: : ldap.
:
On Nov 24, 2003, at 8:09 PM, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
: I'll bet a larger percentage of our users build ports than need nss
or
: ldap.
I'll bet a larger percentage of the people are ignoring this thread
than
On Tue, 25 Nov 2003 12:14:23 +1030
Daniel O'Connor [EMAIL PROTECTED] wrote:
Try timing cd /usr/ports/www/mozilla-devel ; make clean with static
and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes.
OK my bad, it will probably slow down the ports building.
you can use put
M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
: I'll bet a larger percentage of our users build ports than need nss or
: ldap.
I'll bet a larger percentage of the people are ignoring this thread
than reading it since it has been so
On Tue, 25 Nov 2003 03:26:14 +0100
Clement Laforet [EMAIL PROTECTED] wrote:
:27 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LUCIFER i386
Forget about it :-)
Next time i should think befor posting ;-)
sorry for the noise
clem
___
[EMAIL
On Mon, 24 Nov 2003, Frank Mayhar wrote:
Daniel O'Connor wrote:
You DO know FreeBSD is a cooperative project right?
Of course I do. I was using it when it was just 386BSD 0.1 and a patchkit.
I've watched it through a lot of changes and while I've never been a part
of the team, mostly due
On Mon, Nov 24, 2003 at 07:19:31PM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
:
: M. Warner Losh writes:
: In message: [EMAIL PROTECTED]
: Andrew Gallatin [EMAIL PROTECTED] writes:
: : I'll bet a larger
In message: [EMAIL PROTECTED]
David O'Brien [EMAIL PROTECTED] writes:
: What qualifies as a concrete, real benchmark? I take it you don't
: think Drew's qualifies.
No. forkbomds are realworld.
Warner
___
[EMAIL PROTECTED] mailing list
On Tuesday 25 November 2003 12:44, Frank Mayhar wrote:
_This_ is the issue. You assert that this change benefits a fair number
of users. I and others assert that it hurts performance and makes
disaster recovery more complex (while the existence of /rescue is a great
idea, it still adds
M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Andrew Gallatin [EMAIL PROTECTED] writes:
:
: M. Warner Losh writes:
: In message: [EMAIL PROTECTED]
: Andrew Gallatin [EMAIL PROTECTED] writes:
: : I'll bet a larger percentage of our users build ports than
On Mon, Nov 24, 2003 at 03:15:57PM -0500, Andrew Gallatin wrote:
% /usr/bin/time ./harness.sh ./sh.dynamic 100
1.60 real 0.21 user 1.18 sys
% ./harness.sh ./sh.static 100
1.12 real 0.08 user 0.87 sys
So.. forking a dynamic sh is roughly
M. Warner Losh writes:
In message: [EMAIL PROTECTED]
I'm just saying that most of the developers I'm talking to on IRC say
this tread is insane, has no content and they are blowing it off
because of that. A concrete, real benchmark will go a long way
towards changing that. Until then,
Newbie developer question
Would it be possible to ship a static /bin/sh and a dynamic
/bin/dynamic-sh, with /bin/sh execing /bin/dynamic-sh if it is invoked
interactively? If I'm understanding the issues correctly, a dynamic
/bin/sh is desired for the benefit of interactive users, while the
:Ding! Oh god, not another one! *plonk*
:
:We need nsswitch type functionality in /bin/sh. To the people who want to
:make it static, lets see some static binary dlopen() support or a nsswitch
:proxy system.
:
:If half as much effort had been spent on implementing such a thing as there
:has been
Peter Wemm writes:
We need nsswitch type functionality in /bin/sh. To the people who want to
make it static, lets see some static binary dlopen() support or a nsswitch
proxy system.
Maybe this is just nieve, but I always thought that it was the
responsibility of the party introducing the
:I supported the decision because:
:
:1. It has been requested for years
:2. It benefits PAM and NSS.
:3. It is easy to revert.
Easy to revert? You are talking about depending on mechanisms for
authentication and other things that WILL NOT WORK with static binaries
as they
On Mon, 24 Nov 2003, Matthew Dillon wrote:
:Ding! Oh god, not another one! *plonk*
:
:We need nsswitch type functionality in /bin/sh. To the people who want to
:make it static, lets see some static binary dlopen() support or a nsswitch
:proxy system.
:
:If half as much effort had been
In the last episode (Nov 24), Scott Long said:
I think that you forgot to attach the patches that demonstrate all of
this.
Also, I'm really starting to resent you using the FreeBSD mailing
lists as an advocacy channel for DragonFly. I fail to see how
FreeBSD 4.x and DFBSD relate to FreeBSD
On Mon, 24 Nov 2003, Matthew Dillon wrote:
:I supported the decision because:
:
:1. It has been requested for years
:2. It benefits PAM and NSS.
:3. It is easy to revert.
Easy to revert? You are talking about depending on mechanisms for
authentication and other things that
1 - 100 of 109 matches
Mail list logo
