Michael Stone [EMAIL PROTECTED] writes:
No it's not. Every bash upgrade blows it away without notice or comment.
On Tue, Aug 17, 1999 at 06:20:13PM -0700, Chris Waters wrote:
Yes, but that's considered to be a bug. I agree that it's a bug that
*needs* to be fixed. Ok, it's *supposed* to be
Justin Wells [EMAIL PROTECTED] writes:
Well Chris you obviously only run desktop systems [...]
Sheesh, talk about missing the point *completely*!
No, I've been known to run systems remotely. And I usually try to
install sash on systems where I may *need* to do remote repairs.
That doesn't
Justin Wells [EMAIL PROTECTED] writes:
I am not concerned with full POSIX complience for /bin/sh
Well, I am. Why are your concerns more important than mine?
ash has a long history as a /bin/sh shell, since all the *BSD unixes
use it as /bin/sh.
I don't consider the BSD's to be a good
Michael Stone [EMAIL PROTECTED] writes:
On Tue, Aug 17, 1999 at 01:44:00PM -0700, Chris Waters wrote:
*compliance* is a big issue to me, but I'd be open to allowing the use
of ash as /bin/sh *as an option*. Oh wait, it already is! :-)
No it's not. Every bash upgrade blows it away without
On 17 Aug 1999, Chris Waters wrote:
But I think it's reasonable to change the behavior on new systems as
long as that change is well documented.
I think people will find it confusing if Debian is the only distro
that doesn't have bash as /bin/sh by default, and so I'd *rather* keep
it
On Tue, 17 Aug 1999, Steve Willer wrote:
From a policy point of view, as far as I can tell, the bash failure is due
to a dpkg bug, isn't it? I'm not completely sure if it's readline or bash
that got removed, but my reading of the Essential packages section tells
It's a strange APT feature
You should be able to use a chroot combined with a hard link to get
the static binaries into a subspace of the filesystem. I'll admit
that I am not too familiar with fakeroot.
I am proposing a fairly large change. Perhaps fakeroot would have
to be adapted to compensate. I don't see this as a
On Mon, Aug 16, 1999 at 02:24:20PM -0700, Carl R. Witty wrote:
If the standard system binaries are statically linked, then you can't
use fakeroot to build packages any more.
Only if there are no dynamically linked versions of the important
utilities available. Worst case, fakeroot could
On Mon, Aug 16, 1999 at 12:44:34PM -0400, Justin Wells wrote:
May I summarise your proposal briefly?
* You want statically linked recovery stuff to be standard.
* You mainly want this so you can recover from your own mistakes
(or other less clueful admin's mistakes on
The first question is, is sash enough? It doesn't include dpkg or
apt-get's functionality, in particular. Is that really worthwhile
though? What sort of failure modes are there that a statically
linked dpkg/apt would help with that are actually plausible. I
assume
Anthony Towns aj@azure.humbug.org.au writes:
On Mon, Aug 16, 1999 at 12:44:34PM -0400, Justin Wells wrote:
May I summarise your proposal briefly?
* You want statically linked recovery stuff to be standard.
* You mainly want this so you can recover from your own mistakes
On 17 Aug 1999 [EMAIL PROTECTED] wrote:
* static binaries are bigger (disk and RAM, which is a problem)
Could you explain the RAM part? I don't see how it affects RAM usage,
given my understanding of the way the linker works.
* Dynamic linking gives one point of failure, but
Here's a suggestion: what if we make statically linked versions of
some of these basic tools *available*, but *don't* make them
standard. Let people choose for themselves how to manage their
systems, and which risks are worth what costs.
Personally, I am very much opposed to the idea of making
Michael Stone [EMAIL PROTECTED] writes:
[1 text/plain; us-ascii (quoted-printable)]
On Tue, Aug 17, 1999 at 01:31:03PM +1000, Anthony Towns wrote:
(3) Make ash the default /bin/sh. ash links to libc6 and ld-linux, whereas
bash links to libreadline, ncurses, libdl, as well as libc6 and
I think you'd be surprised to learn how little RAM we're talking
about here. Especially if the statics used old libc rather than
glibc (sh, ls and dd certainly don't need to be multi-threaded,
and don't require any advanced support from the C library).
First, none of the system install,
Justin Wells [EMAIL PROTECTED] writes:
I think you'd be surprised to learn how little RAM we're talking
about here.
I think you'd be surprised at how little RAM I and many other people
have. Especially on some of my systems. My 486 to-be-router has
trouble with the *existing* system, *not*
ash has a long history as a /bin/sh shell, since all the *BSD unixes
use it as /bin/sh.
I am not concerned with full POSIX complience for /bin/sh, providing I
get everything I would normally expect a Bourne shell to have. And ash
does you that.
Obviously I think it should be static as well.
On Tue, Aug 17, 1999 at 01:44:00PM -0700, Chris Waters wrote:
Ash is just as susceptible to mispackaging as bash is.
Ash depends on few libraries, and on libraries that have shown
themselves to be more reliable historically.
*compliance* is a big issue to me, but I'd be open to allowing the
Well Chris you obviously only run desktop systems, and never run
anything from remote. You're one of those people who believe that
having a boot disk solves all reliability problems, and I guess you
have just never been in a situation where that isn't an option.
I wish my life were as simple
(This discussion was originally in the devel list, I am restating my
views here because it is actually a policy issue.)
HOW TO MAKE DEBIAN LESS FRAGILE:
All the core system tools, including the package manager (apt_get
and dpkg) should be available as static binaries rather than dynamic
On Mon, 16 Aug 1999, Justin Wells wrote:
responses. Here are refutations of many of the common counter-arguments:
You forgot:
The smallest GLIBC static binary is 200k and that number seems to double
every release!
I know the BSD's come in with about a 40k overhead for a small static
binary,
On Mon, 16 Aug 1999, Jason Gunthorpe wrote:
The smallest GLIBC static binary is 200k and that number seems to double
every release!
Let's say you would be adding 200K per system binary. Justin had a list of
26 binaries. That would be an extra 5MB of total disk space used up. The
entire
Justin Wells [EMAIL PROTECTED] writes:
HOW TO MAKE DEBIAN LESS FRAGILE:
All the core system tools, including the package manager (apt_get
and dpkg) should be available as static binaries rather than dynamic
executables.
...
I previously raised this issue in the devel list, and met with
23 matches
Mail list logo
