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
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
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
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?
___
From: "Tim Kientzle" <[EMAIL PROTECTED]>
> Many of us here have been hamstrung by systems that didn't
> provide a static fallback. I've personally been bitten by
> unrecoverable Linux and Solaris systems due to hosed shared
> libraries.
bingo. a small set of tools will usually save you. vi(1) i
> 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-
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
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
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
how about no copy of vi, or termcap and one copy of ed?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
From: "Richard Coleman" <[EMAIL PROTECTED]>
> Is this where we start swapping stories about "when I was a young
> sysadmin, we didn't need no stinkin vi. We used ed and liked it!". :-)
the point is that when you really want your valuable data back
(without resorting to backups) a small, simple
From: "Jacques A. Vidrine" <[EMAIL PROTECTED]>
> The application is broken. You must only check errno if you get an
> error indication from the library call.
errno is only meaningful after a syscall error.
it is also well known that stdio uses isatty(3) (or equivelant) that may
set errno to ENOT
> 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:
http://citeseer.nj.nec.com/cache/papers/cs/3066/http:zSzzSzswt-www.informatik.uni-hamburg.dezSz~1friedrizSzsvzSzreferenceszSzShared_Libraries_In
From: "Stefan Farfeleder" <[EMAIL PROTECTED]>
> > errno is meaningful for syscalls after an error (the original
> > message). The fact that other functions also dink with errno is not
> > relevant to that statement.
>
> I read boyd's statement as a contradiction to Jacques' one (only after
> sysc
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
http://lists.freebsd.org/mailman/lis
> 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 smalle
> Wrong, strtol() can set errno in two cases, when the value is outside
> the range of representable values or when no conversion could be
> performed.
well 'natch. it's trying to do math.h style hacks and overloads errno.
iirc those sorts of things stem from V6/V7 on the PDP/11 when you
may hav
17 matches
Mail list logo
