Matthew D. Fuller [EMAIL PROTECTED] wrote:
Not just the startup scripts, but ANY script. I dare say there's a long,
long list of scripts that use ~-expansion, to say nothing of the
homegrown ones we all have working quietly and forgotten for years.
It's required for POSIX compliance.
Tony.
--
Robert Watson [EMAIL PROTECTED] wrote:
Someone must be using /bin/sh as a shell, because apparently someone
spent a lot of time adding things like character input editing, filename
completion, etc. We even use sh as the default in adduser(8).
Command-line editing is required for POSIX
Tony Finch wrote:
Matthew D. Fuller [EMAIL PROTECTED] wrote:
Not just the startup scripts, but ANY script. I dare say there's a long,
long list of scripts that use ~-expansion, to say nothing of the
homegrown ones we all have working quietly and forgotten for years.
It's required for POSIX
[ Lots of CC trimming ]
On Sun, Nov 23, 2003 at 06:27:01PM -0500 I heard the voice of
Richard Coleman, and lo! it spake thus:
You would need to make sure that startup scripts never use tilde
expansion. I'm not sure how common that is with RCNG.
Not just the startup scripts, but ANY script.
From: David O'Brien [EMAIL PROTECTED]
I'll seriously argue against the 2nd point above. I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses
Bash, ATT ksh, pdksh, zsh.
I don't know
On Mon, Nov 24, 2003 at 12:14:39AM -, Duncan Barclay wrote:
From: David O'Brien [EMAIL PROTECTED]
I'll seriously argue against the 2nd point above. I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user. Not ONE. Every Bourne shell'ish
On Mon, 24 Nov 2003, Maxim M. Kazachek wrote:
MOST people uses /bin/sh only for rc scripts (to be correct, their
system uses it). David O'Brien just tried to told, that NOBODY he knows
will be REALLY impacted by performance loss, caused due dynamic /bin/sh
linking. You will... So, because
Robert Watson writes:
It strikes me that this whole conversation has gotten a little
confrontational... The middle ground of adding a static /sbin/sh for
scripts soudds like a reasonable choice, and has precedent in other
systems (Solaris). We can set the boot and periodic scripts to
On Mon, Nov 24, 2003 at 10:47:24AM -0500, Robert Watson wrote:
It strikes me that this whole conversation has gotten a little
confrontational... The middle ground of adding a static /sbin/sh for
scripts soudds like a reasonable choice, and has precedent in other
systems (Solaris).
Time for a
Andrew Gallatin wrote:
So I think the best solution (*) would be to keep /bin/sh statically
linked, and build a dynamic version in /usr/bin that people can use as
an interactive shell. Root's shell remains /bin/sh
1) All three (;-) interactive bourne shell users that use nss/ldap get
tilde
Richard Coleman writes:
Are you suggesting that (t)csh also move to /usr/bin to match
/usr/bin/sh? The screams caused by such a change would be deafening.
Of course not. Nobody in their right mind uses csh for scripting.
Drew
___
[EMAIL
Richard Coleman [EMAIL PROTECTED] writes:
Are you suggesting that (t)csh also move to /usr/bin to match
/usr/bin/sh? The screams caused by such a change would be deafening.
Would there be any screams at all?
chsh -s /bin/sh root# prevent lock-out
rm -f /bin/csh /bin/tcsh
At 8:59 PM -0500 2003/11/24, Andrew Gallatin wrote:
Of course not. Nobody in their right mind uses csh for scripting.
To my great horror, csh is used in most of the DNS debugging and
many of the log-processing scripts that I have inherited. One of
these days, I will finally live up to my
As I pointed out earlier, some of the heat here comes
from the fact that /bin/sh is currently overloaded:
* It is the default system script interpreter, used
by the rc scripts and many other things. As such,
it must start quickly.
* It is the default user shell for many users. As
David O'Brien wrote:
We should build /bin/sh static and be done with the argument.
Or rather, lets find a /bin/sh interactive user and have him argue that
/bin/sh needs NSS support. I dare say that will be a thread two orders
of magnitude shorter than this one.
Statically linking /bin/sh wouldn't
From: David O'Brien [EMAIL PROTECTED]
I'll seriously argue against the 2nd point above. I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses
Bash, ATT ksh, pdksh, zsh.
I don't know anyone
So far, I haven't seen anyone in this thread seriously
argue against either of these points.
I'll seriously argue against the 2nd point above. I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user. Not ONE. Every Bourne shell'ish user I've ever
On Mon, Nov 24, 2003 at 12:14:39AM -, Duncan Barclay wrote:
From: David O'Brien [EMAIL PROTECTED]
I'll seriously argue against the 2nd point above. I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user. Not ONE. Every Bourne shell'ish user
On Sun, Nov 23, 2003 at 06:27:01PM -0500, Richard Coleman wrote:
But it would be sorta odd to have statically linked versions of sh in
both /bin and /rescue.
We'd remove it from /rescue if the /bin/sh one was static. :-)
--
-- David ([EMAIL PROTECTED])
On Mon, 24 Nov 2003, Duncan Barclay wrote:
From: David O'Brien [EMAIL PROTECTED]
I'll seriously argue against the 2nd point above. I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses
Bash,
Date: Mon, 24 Nov 2003 09:34:08 +0600 (NOVT)
From: Maxim M. Kazachek [EMAIL PROTECTED]
So, imagine, i'm accidentally deleted /bin with your most wanted
static sh... And, of course, due to static nature of /bin/sh it was
removed from /rescue? Nothing will protect you from shooting in the
On Sun, 23 Nov 2003, David Wolfskill wrote:
Date: Mon, 24 Nov 2003 09:34:08 +0600 (NOVT)
From: Maxim M. Kazachek [EMAIL PROTECTED]
So, imagine, i'm accidentally deleted /bin with your most wanted
static sh... And, of course, due to static nature of /bin/sh it was
removed from /rescue?
On 2003-11-22 at 00:39:45 Tim Kientzle wrote:
Right now, /sbin/init is statically linked.
Not here... I've built everything with WITH_DYNAMICROOT since the time
the option was introduced, and as such:
# file /sbin/init
/sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
Garrett Wollman wrote:
You forgot:
* Allow statically-linked programs to use dynamic NSS modules
by forking a (dynamically-linked) resolver process when
needed.
This leads to a related, but widely disparaged option:
* Have a persistent NSS caching daemon with
* Tim Kientzle [EMAIL PROTECTED] [031121 18:40]:
Leo Bicknell wrote:
To boot a machine into single user mode you need a kernel, init,
and /bin/sh (minimally). It would seem to me that alone is a good
argument for those three things to be static.
* Rewrite dlopen() to not require dynamic
On Thu, Nov 20, 2003 at 09:29:30PM -0500, Richard Coleman wrote:
But I've often wondered how frequently a production system has such
problems. I've been a sysadmin for many years and can't remember this
ever happening. It's much more common to blow a hard drive, or have
flaky memory, etc.
On Thu, Nov 20, 2003 at 09:51:48PM +0100, boyd, rounin wrote:
From: Peter Jeremy [EMAIL PROTECTED]
Shouldn't that be 'chmod +t /bin/sh' ???
Definitely. Why waste a new bit when there's already a perfectly good
one that is (or was) defined for the purpose.
the 't' bit was known as the
From: Peter Jeremy [EMAIL PROTECTED]
As for overloading the 't' bit, I don't believe it's ever been used
for anything else on executable files.
directories
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
I got bit by this just two days ago. I have one machine that tracks
-current. It upgraded to DYNAMICROOT just fine. I nfs mounted /usr/src
and /usr/obj on another 5.0-release machine made the necessary adjustments,
installed the kernel, rebooted, remounted and began make installworld. It
On Thu, Nov 20, 2003 at 09:29:30PM -0500, Richard Coleman wrote:
But I've often wondered how frequently a production system has such
problems. I've been a sysadmin for many years and can't remember this
ever happening. It's much more common to blow a hard drive, or have
flaky memory, etc.
At 8:52 PM +1100 11/20/03, Peter Jeremy wrote:
On Wed, Nov 19, 2003, Lyndon Nerenberg wrote:
--On Wed, Nov 19, 2003, Garance A Drosihn [EMAIL PROTECTED] wrote:
have a: chflags ldcache /bin/sh
Shouldn't that be 'chmod +t /bin/sh' ???
Definitely. Why waste a new bit when there's already a
Leo Bicknell wrote:
To boot a machine into single user mode you need a kernel, init,
and /bin/sh (minimally). It would seem to me that alone is a good
argument for those three things to be static.
You need a static shell, yes. That does not have to be /bin/sh.
init does prompt, and /rescue/sh is
Leo Bicknell wrote:
The more I think about init the more I don't like dynamic linking for
it. init needs to have as few failure modes as possible. I do still
think it's fine for all the other /bin and /sbin things.
Right now, /sbin/init is statically linked.
Tim Kientzle
On Fri, 21 Nov 2003 15:38:49 -0800, Tim Kientzle [EMAIL PROTECTED] said:
There have been a lot of proposed solutions:
* Rewrite NSS to not require dlopen().
* Rewrite dlopen() to not require dynamic linking.
* Don't support NSS in /bin/sh.
* Change the default script interpreter
Bruce Evans wrote:
It obviously uses NSS. How else could it be so bloated? :
$ ls -l /sbin/init
-r-x-- 1 root wheel 453348 Nov 18 10:30 /sbin/init
I believe it's actually DNS, not NSS.
Pre-5.0, the resolver ballooned significantly.
A lot of the bloat in /bin and /sbin came
from the NIS
Garrett Wollman wrote:
On Fri, 21 Nov 2003 15:38:49 -0800, Tim Kientzle [EMAIL PROTECTED] said:
There have been a lot of proposed solutions:
* Rewrite NSS to not require dlopen().
* Rewrite dlopen() to not require dynamic linking.
* Don't support NSS in /bin/sh.
* Change the default script
On Fri, 21 Nov 2003, Tim Kientzle wrote:
Bruce Evans wrote:
It obviously uses NSS. How else could it be so bloated? :
$ ls -l /sbin/init
-r-x-- 1 root wheel 453348 Nov 18 10:30 /sbin/init
I believe it's actually DNS, not NSS.
Pre-5.0, the resolver ballooned significantly.
A
From: William Josephson [EMAIL PROTECTED]
People at Berkeley (and elsewhere) have done user studies to try to
quantify this sort of thing. It is pretty clear that with modern
hardware, most failures are due to human error. That's not to say
that hardware and software faults aren't real
On Fri, Nov 21, 2003 at 04:52:00PM -0500, Garance A Drosihn wrote:
Shouldn't that be 'chmod +t /bin/sh' ???
b) I thought that you might want to have this an admin-only
command, so nefarious users couldn't abuse it on a shared
system.
I would make one change to your proposal: Instead of
On Wed, Nov 19, 2003 at 09:27:55PM -0800, Tim Kientzle wrote:
Richard Coleman wrote:
It seems /bin/sh is the real sticking point.
There is a problem here: Unix systems have historically used
/bin/sh for two somewhat contradictory purposes:
* the system script interpreter
* as a user
On Wed, Nov 19, 2003 at 11:18:47AM -0700, Lyndon Nerenberg wrote:
--On Wednesday, November 19, 2003 12:30 AM -0500 Garance A Drosihn
[EMAIL PROTECTED] wrote:
have a: chflags ldcache /bin/sh
Shouldn't that be 'chmod +t /bin/sh' ???
Definitely. Why waste a new bit when there's already a
Jacques A. Vidrine [EMAIL PROTECTED] wrote:
Finally, if we could call `dlopen' from statically-linked binaries,
this wouldn't be an issue.
One of the performance problems that John Dyson mentioned (the sparse
dirtying of libc's data section) would still remain, because the whole
of libc has to
Stijn Hoop wrote:
On Wed, Nov 19, 2003 at 09:27:55PM -0800, Tim Kientzle wrote:
Maybe it's time to separate these two functions?
I would be content to have a static /sbin/sh
that is used as the system script interpreter for
rc scripts, etc.
And /usr/bin/sh as a user shell?
I was thinking /bin/sh
On 2003-11-20 at 21:51:48 boyd, rounin wrote:
think about a dynamically linked init(8) ...
% sudo ldd /sbin/init
/sbin/init:
libutil.so.3 = /lib/libutil.so.3 (0x28074000)
libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000)
libc.so.5 = /lib/libc.so.5 (0x28097000)
Yes,
From: Dimitry Andric [EMAIL PROTECTED]
% sudo ldd /sbin/init
/sbin/init:
libutil.so.3 = /lib/libutil.so.3 (0x28074000)
libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000)
libc.so.5 = /lib/libc.so.5 (0x28097000)
Yes, working fine here. What should the problem be?
On Fri, Nov 21, 2003 at 12:23:16AM +0100, boyd, rounin wrote:
you're building a house of cards. once, if /etc/init and
/bin/sh and some other pieces where in place a smashed
file-system could be easily fixed. now you have to have
3 shared libs and a viable /lib.
do you want systems that work?
From: Christopher Vance [EMAIL PROTECTED]
Personally, I think init should be static, and can't think of any way
it would benefit from shared libraries.
plan 9 has everything static. the kernel compiles in about 20 seconds
or less -- no compression -- and you can boot it off a floppy.
if i can
On Fri, Nov 21, 2003 at 12:23:16AM +0100, boyd, rounin wrote:
From: Dimitry Andric [EMAIL PROTECTED]
% sudo ldd /sbin/init
/sbin/init:
libutil.so.3 = /lib/libutil.so.3 (0x28074000)
libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000)
libc.so.5 = /lib/libc.so.5
From: Steve Kargl [EMAIL PROTECTED]
This is only marginally different than /sbin/init
getting smashed. If the root partition develops
problems, you need to restore for tape.
tape? who uses tape? optical, my son.
brother, can you spare a TU-16?
In message: [EMAIL PROTECTED]
boyd, rounin [EMAIL PROTECTED] writes:
: Yes, working fine here. What should the problem be?
:
: the day /lib gets smashed.
/rescue/sh
Warner
___
[EMAIL PROTECTED] mailing list
boyd, rounin wrote:
From: Dimitry Andric [EMAIL PROTECTED]
% sudo ldd /sbin/init
/sbin/init:
libutil.so.3 = /lib/libutil.so.3 (0x28074000)
libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000)
libc.so.5 = /lib/libc.so.5 (0x28097000)
Yes, working fine here. What
boyd, rounin wrote:
From: Christopher Vance [EMAIL PROTECTED]
Personally, I think init should be static, and can't think of any way
it would benefit from shared libraries.
plan 9 has everything static. the kernel compiles in about 20 seconds
or less -- no compression -- and you can boot it
plan9 doesn't count. It's so minimalistic, it's useless.
well, try to think about non-minimalism when you're trying to track
down a kernel bug in a zillion SLOC ...
___
[EMAIL PROTECTED] mailing list
On Fri, 21 Nov 2003 03:37:20 +0100, boyd, rounin [EMAIL PROTECTED] said:
well, try to think about non-minimalism when you're trying to track
down a kernel bug in a zillion SLOC ...
How about trying to think about FreeBSD when posting on the FreeBSD
mailing-lists.
-GAWollman
From: Bruce M Simpson [EMAIL PROTECTED]
During my time in an investment bank, installations were usually hosed
in this way by human error (systems administrators removing a file by
accident, etc) ...
yup, it's rare i've seen flakey h/w. but i do remember one sysadmin
(when i was a contract
In message [EMAIL PROTECTED], boyd, rounin
write
s:
From: Bruce M Simpson [EMAIL PROTECTED]
During my time in an investment bank, installations were usually hosed
in this way by human error (systems administrators removing a file by
accident, etc) ...
yup, it's rare i've seen flakey
On Tue, Nov 18, 2003 at 06:26:21PM -0800, Matthew Dillon wrote:
: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
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
Garrett Wollman said:
On Tue, 18 Nov 2003 18:07:32 -0500 (EST), [EMAIL PROTECTED] said:
If the object is to maximally 'share',
The object, AIUI, is for ~username expansion to work in the shells
when the user stored somewhere defined by an
[cc: dropped]
I suppose I should comment on this thread, since I'm closely related
to at least two of the rationales mentioned for moving towards an
all-dynamically-linked system. (I would prefer to stay out of this
thread. In my mind we've had all these arguments in various
forums months ago
In a message written on Wed, Nov 19, 2003 at 08:10:59AM -0600, Jacques A. Vidrine
wrote:
statically. Unless we are talking about /bin/sh, they probably already
have to go through special measures to get a statically linked binary.
Something has been bothering me about the whole /bin/sh
On Wed, Nov 19, 2003 at 09:19:50AM -0500, Leo Bicknell wrote:
To boot a machine into single user mode you need a kernel, init,
and /bin/sh (minimally).
Roughly the same thing was bothering me last night. You get a chance
to specify the shell when init is in the last phase of getting you to
In a message written on Wed, Nov 19, 2003 at 09:25:35AM -0500, Ken Smith wrote:
Roughly the same thing was bothering me last night. You get a chance
to specify the shell when init is in the last phase of getting you to
single-user mode so you can say /rescue/sh at that point. init is
another
: Don't you think that people are able to change defaults if they think
: thats appropriate?
:
: Prior to that Jordan had bumped the root partition size to 100MB
: in 1.98.2.3 in March 2001. It was 50MB before then, which is too
: small even for 4.x.
:
: Hm, then why do I have
On Wed, Nov 19, 2003 at 09:25:35AM -0500, Ken Smith wrote:
On Wed, Nov 19, 2003 at 09:19:50AM -0500, Leo Bicknell wrote:
To boot a machine into single user mode you need a kernel, init,
and /bin/sh (minimally).
Roughly the same thing was bothering me last night. You get a chance
to
--On Wednesday, November 19, 2003 12:30 AM -0500 Garance A Drosihn
[EMAIL PROTECTED] wrote:
have a: chflags ldcache /bin/sh
Shouldn't that be 'chmod +t /bin/sh' ???
--lyndon
___
[EMAIL PROTECTED] mailing list
On Wed, 19 Nov 2003, Marcel Moolenaar wrote:
set init_path=/rescue/init
If dynamic root were ready to be turned on, then /rescue/init would be
in the default init_path.
A dynamicly linked /sbin/init just
makes it harder to get to the rescue bits, so it makes sense to
link init(8) staticly.
On Thu, Nov 20, 2003 at 06:27:31AM +1100, Bruce Evans wrote:
set init_path=/rescue/init
If dynamic root were ready to be turned on, then /rescue/init would be
in the default init_path.
I had that explained to me too. :-)
There is a loop in sys/kern/init_main.c that probes for an init
to
On Thu, 20 Nov 2003, Bruce Evans wrote:
On Wed, 19 Nov 2003, Marcel Moolenaar wrote:
set init_path=/rescue/init
If dynamic root were ready to be turned on, then /rescue/init would be
in the default init_path.
The fallback path only works if the exec() fails cleanly without actually
SL Date: Tue, 18 Nov 2003 17:06:06 -0700 (MST)
SL From: Scott Long
SL 3. Binary security updates: there is a lot of interest in providing a
SL binary update mechanism for doing security updates. Having a dynamic
SL root means that vulnerable libraries can be updated without having to
SL
GAD Date: Tue, 18 Nov 2003 21:54:53 -0500
GAD From: Garance A Drosihn
GAD Many freebsd users (me for one) are still living on a modem,
GAD where even one bump of 1.5 meg is a significant issue...
GAD
GAD Remember that the issue we're talking about is security
GAD updates, not full system
:GAD Many freebsd users (me for one) are still living on a modem,
:GAD where even one bump of 1.5 meg is a significant issue...
:GAD
:GAD Remember that the issue we're talking about is security
:GAD updates, not full system upgrades. Everyone would want
:GAD the security updates, even if they're
On Wed, 19 Nov 2003, Ken Smith wrote:
On Thu, Nov 20, 2003 at 06:27:31AM +1100, Bruce Evans wrote:
set init_path=/rescue/init
If dynamic root were ready to be turned on, then /rescue/init would be
in the default init_path.
I had that explained to me too. :-)
There is a loop in
Gordon Tetlow wrote:
On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote:
However, PAM and NSS 'tricks' really seem to be exactly that,
and certainly worthy of special builds. However, that isn't
necessary, yet still not building everything with a shared
libc.
Things like
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
Dan Nelson wrote:
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
On Wed, 19 Nov 2003, Dan Nelson wrote:
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
Richard Coleman wrote:
It seems /bin/sh is the real sticking point.
There is a problem here: Unix systems have historically used
/bin/sh for two somewhat contradictory purposes:
* the system script interpreter
* as a user shell
The user shell must be dynamically linked in order
to support
Tim Kientzle said:
Richard Coleman wrote:
It seems /bin/sh is the real sticking point.
There is a problem here: Unix systems have historically used
/bin/sh for two somewhat contradictory purposes:
* the system script interpreter
* as a user shell
The user shell must be
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] 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
In the last episode (Nov 18), M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] 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
On Tue, 18 Nov 2003, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] 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
M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] 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.
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] 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
Scott Long said:
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: It really doesn't make sense to arbitrarily cut-off a
: discussion especially when a decision might be incorrect.
At 17:06 18/11/2003 -0700, Scott Long wrote:
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
[EMAIL PROTECTED] wrote:
Scott Long said:
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: It really doesn't make sense to arbitrarily cut-off a
: discussion especially when a decision might be
masta said:
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.
I guess that I have to remember that my own goals of 'performance'
and handling 'highest
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
Scott Long said:
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: It really doesn't make sense to arbitrarily cut-off a
: discussion
At 8:07 AM -0500 11/18/03, [EMAIL PROTECTED] wrote:
It really doesn't make sense to arbitrarily cut-off a
discussion especially when a decision might be incorrect.
All I wanted to cut off was the claim that this decision had
not been discussed publicly before. It was also annoying
At 6:42 PM -0600 11/18/03, masta wrote:
Besides, I see nothing preventing anybody from building
their system with static worlds,
true...
and there is nothing stopping anybody from putting /rescue
in the PATH before /bin or /sbin.
Note that this will not have the same performance as the
older
On Wed, 19 Nov 2003, Colin Percival wrote:
At 17:06 18/11/2003 -0700, Scott Long wrote:
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
Scott Long said:
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
The cool thing about properly implemented shared libs is that not everything
has to be shared. Even the kernel supports runtime loading/addition
of modules, and the NSS sounds like a good candidate for a library
feature.
On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote:
However, PAM and NSS 'tricks' really seem to be exactly that,
and certainly worthy of special builds. However, that isn't
necessary, yet still not building everything with a shared
libc.
Things like nss_ldap (which is used
Gordon Tetlow said:
On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote:
However, PAM and NSS 'tricks' really seem to be exactly that,
and certainly worthy of special builds. However, that isn't
necessary, yet still not building everything with a shared
libc.
Things
: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
:
:As far as I'm concerned, this is a non-issue. Identifying which static
: binaries need to be replaced is now a solved problem, replacing them is
: easy, and if binary patches are used, there is effectively no impact on
: bandwidth usage either.
:
:Bandwidth is still a concern for a lot of
:/boot has grown quite large too and threatens to be unbounded in size as
:times go on. Shaving off the 30-40MB of size in /bin and /sbin can
:help alleviate this, even on system formatted in 5.x partition sized.
:...
:This argument wasn't the most compelling one by itself, but it played a
:part
Gang,
I suspect that my position has been expressed
adequately.
Further discussion might become divisive, but
a decision that incurs the overhead of performance
or a rebuild on the default user base seems
wrong (JUST MY OPINION.) It took ALOT of
At 6:38 PM -0800 11/18/03, Matthew Dillon wrote:
So you are talking about 1.5 MBytes less bandwidth,
which is nothing compared to the cost of doing a full
install over the net. Yah, yah, /sbin too... but you
get the idea.
Many freebsd users (me for one) are still living on a
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
There might be a certain 'coolness' WRT dynamically linking everything,
but the overhead is certainly measurable. If the object is to maximally
'share', then for shells the FreeBSD VM shares maximally without using
shared libs (perhaps there is a
1 - 100 of 113 matches
Mail list logo
