dpkg remains the primary bottleneck in the setup, and apt calls dpkg
anyway, so the different is not really significant, and apt-get update
is slow too.
Joseph Carter [EMAIL PROTECTED] writes:
[1 text/plain; us-ascii (quoted-printable)]
On Tue, Oct 06, 1998 at 03:50:01PM -0500, John Goerzen
On Thu, Oct 08, 1998 at 06:40:09AM -0500, John Goerzen wrote:
dpkg remains the primary bottleneck in the setup, and apt calls dpkg
anyway, so the different is not really significant, and apt-get update
is slow too.
The update phase seems to be slow because of translating the package files
to
Right now I'm using a 200MMX with 64MB, which used to be a 133MHz with
64MB and I always found the speed of dpkg perfectly acceptable. Are you
using the outdated dselect method that scans every single package every
time you install one little component, and do have like 400 packages
installed with
On 6 Oct 1998, John Goerzen wrote:
This is silly. dpkg/dselect are already insanely slow, even on my
P166 with 128 meg of RAM -- especially when reading database, etc. If
we slow down the installation so much more by using bzip2, then people
will simply stop upgrading, or switch to other
On Tue, Oct 06, 1998 at 03:50:01PM -0500, John Goerzen wrote:
This is silly. dpkg/dselect are already insanely slow, even on my
P166 with 128 meg of RAM -- especially when reading database, etc. If
we slow down the installation so much more by using bzip2, then people
will simply stop
Joseph Carter wrote:
I doubt it would compile on my 4 meg 486.
Nor would it run there.
I've ran X on 2 mb. (shoot me.. please.. ;-)
--
see shy jo
On Tue, 06 Oct, 1998, Joseph Carter wrote:
On Tue, Oct 06, 1998 at 03:50:01PM -0500, John Goerzen wrote:
This is silly. dpkg/dselect are already insanely slow, even on my
P166 with 128 meg of RAM -- especially when reading database, etc. If
we slow down the installation so much more by
On Mon 05 Oct 1998, Paul Slootman wrote:
On Sun 04 Oct 1998, James Troup wrote:
Joseph Carter [EMAIL PROTECTED] writes:
Old/slow/lomem machines can't properly compile X or Mozilla anyway.
Bzzt. I've compiled xfree86 for Debian/m68k on a 386/25 equivalent
with only 14Mb (don't ask)
This is silly. dpkg/dselect are already insanely slow, even on my
P166 with 128 meg of RAM -- especially when reading database, etc. If
we slow down the installation so much more by using bzip2, then people
will simply stop upgrading, or switch to other distributions because
it is so slow.
Christopher Barry [EMAIL PROTECTED] writes:
If your mighty 386/25
^
a) cut out the sarcasm, it's uncalled for.
b) get your facts right, it's not a 386, it's a 386/25 equivalent[1]
as I said already.
with 4MB can make World the entire X distribution and custom kernels
It seems the whole point you are making is that there is nothing old,
slow, lowmem machines can't handle that should be bzip2 compressed, but
my point is that if there is no package that a slow, lomem machine can't
handle, like an X or Emacs source distribution, then the slow, lowmem
machine could
On Sat, Oct 03, 1998 at 08:37:12AM -0500, dsb3 wrote:
I think we already went through this discussion a short while back.
Unless I'm missing something new, it was pretty much decided that the
memory overhead of bzip2 was too great for low-mem or slow PCs to handle.
It'd STILL be nice to
Joseph Carter [EMAIL PROTECTED] writes:
Old/slow/lomem machines can't properly compile X or Mozilla anyway.
Bzzt. I've compiled xfree86 for Debian/m68k on a 386/25 equivalent
with only 14Mb (don't ask) of memory several times. Took 5 days,
like, but it compiled ``properly''.
--
James
On Sun, Oct 04, 1998 at 12:15:40PM +0100, James Troup wrote:
Old/slow/lomem machines can't properly compile X or Mozilla anyway.
Bzzt. I've compiled xfree86 for Debian/m68k on a 386/25 equivalent
with only 14Mb (don't ask) of memory several times. Took 5 days,
like, but it compiled
Joseph Carter [EMAIL PROTECTED] writes in gratuitous QP:
On Sun, Oct 04, 1998 at 12:15:40PM +0100, James Troup wrote:
Old/slow/lomem machines can't properly compile X or Mozilla anyway.
Bzzt. I've compiled xfree86 for Debian/m68k on a 386/25 equivalent
with only 14Mb (don't ask) of
If your mighty 386/25 with 4MB can make World the entire X distribution
and custom kernels then surely it won't sweat a little bit of bzip2
decompressing... and since you spend a lot less time downloading a
bzip2ed *.deb, the extra time bzip2 would take by swapping and thrashing
the disk should
On Fri, Oct 02, 1998 at 10:06:24PM -0500, dsb3 wrote:
I read in an earlier mail that the main distro will no longer fit on one
CD. Since a standardised specialized tool is already required to install
a *.deb and this tool is installed on every Debian box, why not in the
next update of dpkg
On Fri, 2 October 1998 22:25:35 -0700, Joseph Carter wrote:
It'd STILL be nice to be able to use bzip2 for package source on REALLY BIG
packages (Mozilla, X)
I agree. It'd be fine for now if it's supported and then you can
still decide to use it for your own packages. You won't install X
or
18 matches
Mail list logo
