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
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 co
"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.
To
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 thr
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/tc
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 PROTEC
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 exp
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
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 scri
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, becaus
> 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
> >
> >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, AT&T ksh, pdksh,
[ 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 scrip
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
>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 i
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 u
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, 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 she
> > 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
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, AT&T ksh, pdksh, zsh.
I don't know a
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
> 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 use
On Sat, 22 Nov 2003, Dimitry Andric wrote:
> 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:
* 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 d
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
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), fo
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: Inste
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 rea
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 signif
Garrett Wollman wrote:
< 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 for rc and such.
* Make dynamic linking faster.
You forg
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 fu
< 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 for rc and such.
> * Make dynamic linking faster.
You forgot
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
_
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
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 alre
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, e
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
failed
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-curr
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 know
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.
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
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 contr
< 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
___
[EMAIL PROTECTED] mailing list
ht
> 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
http://lists.freebsd.org/mailman/listinfo/freebsd-
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
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. Wha
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
http://lists.freebsd.or
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?
___
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
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
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? or
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
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, wor
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 'sticky' bit to keep frequently used,
sharable (judged by a
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
"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 ha
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
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
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
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 cent
M. Warner Losh said:
> 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?
>
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 co
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 ag
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 dynami
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 nss_ldap
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
: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 t
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 u
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 t
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 actua
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 ini
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) staticl
--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
http://lists.freebsd.org/mailman/listinf
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
: 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 s
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
> anot
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
s
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 funct
[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 an
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote:
> Garrett Wollman 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 external NSS module. I
> > don't believe that there
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 mode
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 supportin
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 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.
hav
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
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
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
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 pro
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
r
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 lingerin
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
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 I
: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.
:
:--
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
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
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 modem,
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 WOR
:/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 i
:>
:>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
: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.
1 - 100 of 119 matches
Mail list logo
