Re: Squeeze can't fit on 512MiB
On 12/15/2010 07:02 PM, Joey Hess wrote: Samuel Thibault wrote: - Gnome grew from 1830MiB to 2409MiB, still can't fit on just CD1. This should fix itself once both tasksel 2.88 and gnome-core 1:2.30+7 reach testing. Should happen by monday, would appreciate any testing you can do. Both migrated during yesterday's britney run, fwiw. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d09d911.9080...@dogguy.org
Re: Squeeze can't fit on 512MiB
Mehdi Dogguy, le Thu 16 Dec 2010 10:17:05 +0100, a écrit : On 12/15/2010 07:02 PM, Joey Hess wrote: Samuel Thibault wrote: - Gnome grew from 1830MiB to 2409MiB, still can't fit on just CD1. This should fix itself once both tasksel 2.88 and gnome-core 1:2.30+7 reach testing. Should happen by monday, would appreciate any testing you can do. Both migrated during yesterday's britney run, fwiw. tasksel 2.88 with gnome-core 1:2.30+7 still wants to install ~2.5GiB packages. But maybe that includes things that tasksel would be happy not to install if it wasn't available on CD1? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101216195137.gc6...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
Samuel Thibault wrote: - Gnome grew from 1830MiB to 2409MiB, still can't fit on just CD1. This should fix itself once both tasksel 2.88 and gnome-core 1:2.30+7 reach testing. Should happen by monday, would appreciate any testing you can do. -- see shy jo signature.asc Description: Digital signature
Re: Squeeze can't fit on 512MiB
Joey Hess, le Wed 15 Dec 2010 14:02:38 -0400, a écrit : Samuel Thibault wrote: - Gnome grew from 1830MiB to 2409MiB, still can't fit on just CD1. This should fix itself once both tasksel 2.88 and gnome-core 1:2.30+7 reach testing. Should happen by monday, would appreciate any testing you can do. Sure I will. Thanks, Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101215190908.gb22...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
Hello,
Here is an updated report on task size:
Samuel Thibault, le Wed 27 Oct 2010 18:00:16 +0200, a écrit :
- Base+Standard grew from 397MiB to 491MiB
(we install libdb4.{5,6,7,8} !?, and since openssh-client recommends
xauth, x11 stuff gets installed)
Still 492MiB. One nice thing is we now only have libdb4.8!
- Gnome grew from 1830MiB to 2409MiB,
still can't fit on just CD1.
- KDE grew from 1592MiB to 1969MiB.
- Xfce grew from 1056MiB to 1502MiB.
- LXDE grew from 963MiB to 1282MiB.
- Web grew from 42MiB to 54MiB.
- Print shrunk from 215MiB to 186MiB:
gutenprint and such grew quite a bit, but all kinds of X11 stuff
previously pulled because pnm2ppa depends on gs provided by
ghostscript-x is not pulled any more.
- DNS grew from3MiB to4MiB.
- File grew from 74MiB to 118MiB.
(Samba grew quite a bit)
- Mail grew from 14MiB to 94MiB.
(spamassasin recommends libc6-dev/gcc/make, and thus all their
recommends such for sa-compile)
- SQL shrunk from 50MiB to 44MiB.
- Laptopgrew from 26MiB to 171MiB.
(bluez-cups (and thus cups) recommended by bluetooth)
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101215013359.gi5...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
And here are the values for amd64:
Samuel Thibault, le Wed 15 Dec 2010 02:34:00 +0100, a écrit :
Samuel Thibault, le Wed 27 Oct 2010 18:00:16 +0200, a écrit :
- Base+Standard grew from 397MiB to 491MiB
(we install libdb4.{5,6,7,8} !?, and since openssh-client recommends
xauth, x11 stuff gets installed)
Still 492MiB. One nice thing is we now only have libdb4.8!
532MiB.
- Gnome grew from 1830MiB to 2409MiB,
still can't fit on just CD1.
2588MiB.
- KDE grew from 1592MiB to 1969MiB.
2162MiB.
- Xfce grew from 1056MiB to 1502MiB.
1671MiB.
- LXDE grew from 963MiB to 1282MiB.
1452MiB.
- Web grew from 42MiB to 54MiB.
55MiB.
- Print shrunk from 215MiB to 186MiB:
gutenprint and such grew quite a bit, but all kinds of X11 stuff
previously pulled because pnm2ppa depends on gs provided by
ghostscript-x is not pulled any more.
196MiB.
- DNS grew from3MiB to4MiB.
4MiB.
- File grew from 74MiB to 118MiB.
(Samba grew quite a bit)
127MiB.
- Mail grew from 14MiB to 94MiB.
(spamassasin recommends libc6-dev/gcc/make, and thus all their
recommends such for sa-compile)
64MiB (I guess there must be some i386-specific package above)
- SQL shrunk from 50MiB to 44MiB.
49MiB.
- Laptopgrew from 26MiB to 171MiB.
(bluez-cups (and thus cups) recommended by bluetooth)
182MiB.
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101215023157.gk5...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
severity 528914 serious thanks Quoting Samuel Thibault (sthiba...@debian.org): Hello, Actually, partman will even just refuse to setup partitions. Additionnall, a test today with beta1, on a 1GiB disk (virtual machine) and the separate home partman-auto recipe lead to failure because of disk full The minimum size for / needs to be increased (it is currently 500MiB and is not enough). This is roughly what #528914 says (though it really says that the minimum for / should allow two kernel flavours to be installedwhich I kinda agree upon as there are chances that, during tha machine's life, this will happen). Anyway, this bug is a blocker, imho. signature.asc Description: Digital signature
Re: Squeeze can't fit on 512MiB
Christian PERRIER, le Mon 01 Nov 2010 12:03:51 +0100, a écrit : Quoting Samuel Thibault (sthiba...@debian.org): Hello, Actually, partman will even just refuse to setup partitions. Additionnall, a test today with beta1, on a 1GiB disk (virtual machine) and the separate home partman-auto recipe lead to failure because of disk full I guess you were installing the standard system task via network? The minimum size for / needs to be increased (it is currently 500MiB and is not enough). The default should be changed indeed. To what the standard task needs? This is roughly what #528914 says (though it really says that the minimum for / should allow two kernel flavours to be installedwhich I kinda agree upon as there are chances that, during tha machine's life, this will happen). Remember however that d-i now cleans .debs away, which most probably frees room for future kernels in the case of network installs (and for CD installs you haven't used it anyway). Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101101162101.gc5...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
Quoting Samuel Thibault (sthiba...@debian.org): Christian PERRIER, le Mon 01 Nov 2010 12:03:51 +0100, a écrit : Quoting Samuel Thibault (sthiba...@debian.org): Hello, Actually, partman will even just refuse to setup partitions. Additionnall, a test today with beta1, on a 1GiB disk (virtual machine) and the separate home partman-auto recipe lead to failure because of disk full I guess you were installing the standard system task via network? Yes. (install with netinst CD and mirror configured) The minimum size for / needs to be increased (it is currently 500MiB and is not enough). The default should be changed indeed. To what the standard task needs? 900MiB seems to be the right size. This is roughly what #528914 says (though it really says that the minimum for / should allow two kernel flavours to be installedwhich I kinda agree upon as there are chances that, during tha machine's life, this will happen). Remember however that d-i now cleans .debs away, which most probably frees room for future kernels in the case of network installs (and for CD installs you haven't used it anyway). Yes. With 900MiB, the partition is temporarily nearly full, then gets 140MiB free after cleaning, which is enough for another kernel. signature.asc Description: Digital signature
Re: Squeeze can't fit on 512MiB
Ben Armstrong, le Sat 30 Oct 2010 06:54:16 -0300, a écrit : On 30/10/10 05:11 AM, Stefan Fritsch wrote: Is there an easy way to see what is in the tasks without reinstalling? From /usr/share/tasksel/debian-tasks.desc it would seem that web- server only pulls apache2-mpm-prefork, and I have no idea how that could account for this increase $ tasksel --task-packages web-server libapache2-mod-python apache2-doc libapache2-mod-php5 libapache2-mod-perl2 apache2-mpm-prefork analog This however doesn't provide the installed dependencies. To get a proper list, you have to install from start, e.g. in a VM. It's not very long as you just need to install the base system. Then you can run tasksel --new-install from the installed system and check out in the spawned aptitude. Actually, checking again FJP's previous figures, it seems like contrary to what he documented, he would install the standard system task first, and then try to install other tasks. With that in mind, the increase is only from 43MiB to 57MiB, i.e. not really surprising. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101102002926.gp5...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
On Wednesday 27 October 2010, Lennart Sorensen wrote: On Wed, Oct 27, 2010 at 06:36:35PM +0200, Mike Hommey wrote: FWIW, it's what worked best when I set up Time Machine over the network. Well I must admit that I consider the file server task totally useless. Who really wants IPX, netatalk, samba, nfs, and who knows what else on the same server? Never mind the garbage the web server task installs that I sure wouldn't want on any web server I run. Is there an easy way to see what is in the tasks without reinstalling? From /usr/share/tasksel/debian-tasks.desc it would seem that web- server only pulls apache2-mpm-prefork, and I have no idea how that could account for this increase - Web grew from 42MiB to 121MiB -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010301011.53712...@sfritsch.de
Re: Squeeze can't fit on 512MiB
On Friday 29 October 2010, Sven Joachim wrote: On 2010-10-29 11:58 +0200, Mike Hommey wrote: On Fri, Oct 29, 2010 at 11:36:59AM +0200, Adam Borowski wrote: Or, for a less drastic solution, use localepurge. Losing the docs is a significant loss, you don't want to suffer that unless your machine is a really small dinky gadget. This is a part of the damage Nokia inflicted on n900 even though it would be a tiny part of that 32GB disk. Or, we could finally get dpkg to not install files matching some patterns. That would also help those who don't need the 1GB+ from linux-image-$(uname -r)-dbg to use systemtap. For the record, this feature has already been implemented in dpkg 1.15.8. Awesome. Maybe d-i could offer an option to add something like path-exclude /usr/share/locale/[a-z][a-z] path-exclude /usr/share/locale/[a-z][a-z][a-z] path-exclude /usr/share/locale/[a-z][a-z...@]* path-include /usr/share/locale/en* to /etc/dpkg/dpkg.cfg? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010301004.58011...@sfritsch.de
Re: Squeeze can't fit on 512MiB
On 30/10/10 05:11 AM, Stefan Fritsch wrote: Is there an easy way to see what is in the tasks without reinstalling? From /usr/share/tasksel/debian-tasks.desc it would seem that web- server only pulls apache2-mpm-prefork, and I have no idea how that could account for this increase $ tasksel --task-packages web-server libapache2-mod-python apache2-doc libapache2-mod-php5 libapache2-mod-perl2 apache2-mpm-prefork analog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ccbeb48.7040...@sanctuary.nslug.ns.ca
Re: Squeeze can't fit on 512MiB
On Wed, 27 Oct 2010 17:20:56 +0200 Samuel Thibault sthiba...@debian.org wrote: Indeed, installling Squeeze (without any task) via the network needs 460MiB free on /, so you don't really have room for swap. Once the .debs cleaned, you're still with 340MiB, while Lenny needed only 268MiB for the same base system. You can't install Debian on a.g. a 512MiB sheeva-plug unless disabling swap. Try Emdebian Grip and consider using multistrap to install so that the packages can be cleaned out before creating a tarball which is then unpacked onto the final system. Emdebian Grip packages are smaller than Debian ones but still binary compatible. http://www.emdebian.org/grip http://www.emdebian.org/multistrap Wherever storage space is the principle limitation, please look at using Embedded Debian rather than full sized Debian. Another interesting view of all this increase is through the filesystem: Lenny Squeeze Squeeze-Lenny /lib/modules 57640 75428 17788 /usr/share81584 98344 16760 (notably +6M locales, +2M doc, If you want to trim that down, you should *definitely* use Emdebian where the packages themselves have this content already trimmed out. The apt cache increase (~20MiB) is merely due to more packages available (28000) Emdebian Grip also reduces the apt cache size because we simply have fewer packages - concentrating on the base system and things you're likely to want on devices like this. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpjLWZgBfuSI.pgp Description: PGP signature
Re: Squeeze can't fit on 512MiB
Neil Williams, le Fri 29 Oct 2010 09:57:23 +0100, a écrit : Samuel Thibault sthiba...@debian.org wrote: Indeed, installling Squeeze (without any task) via the network needs 460MiB free on /, so you don't really have room for swap. Once the .debs cleaned, you're still with 340MiB, while Lenny needed only 268MiB for the same base system. You can't install Debian on a.g. a 512MiB sheeva-plug unless disabling swap. Try Emdebian Grip Well, it's a shame that 512MiB now has to be called embedded. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101029091922.gi4...@const.famille.thibault.fr
Re: Squeeze can't fit on 512MiB
On Wed, Oct 27, 2010 at 18:29:19 +0200, Samuel Thibault wrote: Sven Joachim, le Wed 27 Oct 2010 18:16:43 +0200, a écrit : On 2010-10-27 17:20 +0200, Samuel Thibault wrote: /lib (except modules) 9276 14096 4820 (notably 3.6M discover) Why does discover get installed? It is not particularly useful these days, and I don't see anything in your list that would pull it in. The hw-detect udeb installs it, see #577451. So instead of detecting the hw and installing needed packages based on that, hw-detect bloats the system with another package to detect hw? This sounds suboptimal (by which I mean, wrong). Cheers, Julien signature.asc Description: Digital signature
Re: Squeeze can't fit on 512MiB
On Wed, Oct 27, 2010 at 18:00:16 +0200, Samuel Thibault wrote:
I forgot to mention other tasks as well:
- Base+Standard grew from 397MiB to 491MiB
(we install libdb4.{5,6,7,8} !?, and since openssh-client recommends
xauth, x11 stuff gets installed)
fwiw db4.5 is (finally) out of squeeze. That still leaves the other
three, but...
Cheers,
Julien
signature.asc
Description: Digital signature
Re: Squeeze can't fit on 512MiB
On Fri, Oct 29, 2010 at 09:57:23AM +0100, Neil Williams wrote: On Wed, 27 Oct 2010 17:20:56 +0200 Samuel Thibault sthiba...@debian.org wrote: Indeed, installling Squeeze (without any task) needs 460MiB If you want to trim that down, you should *definitely* use Emdebian where the packages themselves have this content already trimmed out. Or, for a less drastic solution, use localepurge. Losing the docs is a significant loss, you don't want to suffer that unless your machine is a really small dinky gadget. This is a part of the damage Nokia inflicted on n900 even though it would be a tiny part of that 32GB disk. I really wonder why you still need to install locales to get UTF-8. Even in current glibc, it's a second class citizen. Several years ago, I benchmarked a mockup of hard-coding UTF-8 the way ISO-8859-1 and KOI8-R were done in the past, and it shaved 20% of the whole fork-exec-ld-setlocale-getopt-...-exit sequence almost every program does. The character classification tables are needlessly duplicated for every locale as well -- try an ISO-8859-1 and look at iswfoo() for chars 0xFF, even though there's a separate copy per locale, for all but C and POSIX it's identical. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101029093659.ga10...@angband.pl
Re: Squeeze can't fit on 512MiB
On Fri, Oct 29, 2010 at 11:36:59AM +0200, Adam Borowski wrote: On Fri, Oct 29, 2010 at 09:57:23AM +0100, Neil Williams wrote: On Wed, 27 Oct 2010 17:20:56 +0200 Samuel Thibault sthiba...@debian.org wrote: Indeed, installling Squeeze (without any task) needs 460MiB If you want to trim that down, you should *definitely* use Emdebian where the packages themselves have this content already trimmed out. Or, for a less drastic solution, use localepurge. Losing the docs is a significant loss, you don't want to suffer that unless your machine is a really small dinky gadget. This is a part of the damage Nokia inflicted on n900 even though it would be a tiny part of that 32GB disk. Or, we could finally get dpkg to not install files matching some patterns. That would also help those who don't need the 1GB+ from linux-image-$(uname -r)-dbg to use systemtap. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101029095832.ga11...@glandium.org
Re: Squeeze can't fit on 512MiB
On 2010-10-29 11:58 +0200, Mike Hommey wrote: On Fri, Oct 29, 2010 at 11:36:59AM +0200, Adam Borowski wrote: Or, for a less drastic solution, use localepurge. Losing the docs is a significant loss, you don't want to suffer that unless your machine is a really small dinky gadget. This is a part of the damage Nokia inflicted on n900 even though it would be a tiny part of that 32GB disk. Or, we could finally get dpkg to not install files matching some patterns. That would also help those who don't need the 1GB+ from linux-image-$(uname -r)-dbg to use systemtap. For the record, this feature has already been implemented in dpkg 1.15.8. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874oc548nw@turtle.gmx.de
Re: Squeeze can't fit on 512MiB
On Fri, Oct 29, 2010 at 11:36:59AM +0200, Adam Borowski wrote: I really wonder why you still need to install locales to get UTF-8. Even in current glibc, it's a second class citizen. Several years ago, I benchmarked a mockup of hard-coding UTF-8 the way ISO-8859-1 and KOI8-R were done in the past, and it shaved 20% of the whole fork-exec-ld-setlocale-getopt-...-exit sequence almost every program does. The character classification tables are needlessly duplicated for every locale as well -- try an ISO-8859-1 and look at iswfoo() for chars 0xFF, even though there's a separate copy per locale, for all but C and POSIX it's identical. #522776 has quite a bit of information about basic UTF-8 support without locales (creation of C.UTF-8). From the end of the report, there was talk of getting C.UTF-8 into squeeze, but I'm not sure what the status of that work is at present (it's a trivial glibc tweak to generate and package the additional locale). Do you still have your patch for hard-coding UTF-8? I did start doing this, but didn't get as far as having a working locale. It might be a good starting point if it still works with current glibc. I agree the duplication of character tables in glibc is totally insane; a single copy of each character set is more than plenty, and having both ASCII and UTF-8 hard-coded into glibc would be a major performance improvement, though it would require eliminating the duplication on locale loading. Having the entire UTF-8 table duplicated for each different locale you use is just mad. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Squeeze can't fit on 512MiB
On Fri, Oct 29, 2010 at 02:09:32PM +0100, Roger Leigh wrote: On Fri, Oct 29, 2010 at 11:36:59AM +0200, Adam Borowski wrote: I really wonder why you still need to install locales to get UTF-8. Even in current glibc, it's a second class citizen. Several years ago, I benchmarked a mockup of hard-coding UTF-8 the way ISO-8859-1 and KOI8-R were done in the past, and it shaved 20% of the whole fork-exec-ld-setlocale-getopt-...-exit sequence almost every program does. The character classification tables are needlessly duplicated for every locale as well -- try an ISO-8859-1 and look at iswfoo() for chars 0xFF, even though there's a separate copy per locale, for all but C and POSIX it's identical. #522776 has quite a bit of information about basic UTF-8 support without locales (creation of C.UTF-8). C.UTF-8 would carry another copy of that big table and provide no performance benefits, but indeed, having a guaranteed UTF-8 locale would be really, really useful. I've read #522776 and it provides compelling reasons to add C.UTF-8 right now, for squeeze -- we can discuss better implementations later. From the end of the report, there was talk of getting C.UTF-8 into squeeze, but I'm not sure what the status of that work is at present (it's a trivial glibc tweak to generate and package the additional locale). Especially that it's already done for an udeb. Do you still have your patch for hard-coding UTF-8? I did start doing this, but didn't get as far as having a working locale. It might be a good starting point if it still works with current glibc. 1. It was several major versions of glibc before. 2. It was merely a mockup, not the proper code. These were stubs like: if (ch 128) return value_for_C(ch); else return 0; I assumed that having the library bigger by a large table in its data segment should not make a noticeable difference in speed, as it's merely mmapping a bigger chunk without even a single additional syscall. 3. I did not investigate anything but character classification. I suspect uppercasing would work, but I didn't test that. 4. It broke legacy locales. 5. I don't seem to have that anymore, just some test programs for character classes. I agree the duplication of character tables in glibc is totally insane; a single copy of each character set is more than plenty, and having both ASCII and UTF-8 hard-coded into glibc would be a major performance improvement, though it would require eliminating the duplication on locale loading. Having the entire UTF-8 table duplicated for each different locale you use is just mad. At least in that version (unstable in July 2006), all wctype() functions returned the same value for all loadable locales. The two hardcoded ones, C and POSIX, had the data for characters 0..127 only, being the only ones that differ. The only function I found that was actually locale dependent was wcwidth(). For 8 bit classification routines, legacy locales would need to iconv at most 128 characters -- the API can't support multiple byte CJK encodings anyway. That's still a lot faster than opening a file. Meow? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101029222356.ga27...@angband.pl
Re: Squeeze can't fit on 512MiB
Indeed, installling Squeeze (without any task) needs 460MiB If you want to trim that down, you should *definitely* use Emdebian where the packages themselves have this content already trimmed out. Or, for a less drastic solution, use localepurge. Losing the docs is a significant loss, you don't want to suffer that unless your machine is a really small dinky gadget. This is a part of the damage Nokia inflicted on n900 even though it would be a tiny part of that 32GB disk. ... I've had good luck installing into larger storage, like a 2GB CF, and then making a squashfs and loopmount of /usr, getting it down to a reasonable installed size 512MB, and then cloning that (with rsync or tar) into the target 512MB CF. Haven't tried that in squeeze though. Tony -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=n4wfn9_ulydxcmpqug6vpd2htwlcgikah-...@mail.gmail.com
Re: Squeeze can't fit on 512MiB
* Samuel Thibault:
- Base+Standard grew from 397MiB to 491MiB
(we install libdb4.{5,6,7,8} !?,
I suspect that this is caused primarily by API and ABI
incompatibility, and in part by the lack of response to bug reports
from upstream. Everybody who uses Berkeley DB extensively has once
been bitten by a regression. Often, people outside Sleepycat and
Oracle couldn't fix those bugs in a timely fashion, so the affected
people stay on the version which works for them. Even upon request,
Oracle does not provide individual patches for bug fixes which have
been applied to subsequent major version. Their source repository is
totally private, too (if they use version control at all).
On top of that, while there is an environment migration strategy, it
requires a lot of boilerplate code that is hard to get completely
right. Few applications provide it, so you end up with risky manual
migration procedures and user-visible disk format incompatible. The
actual data format is extremely stable, except for the DB_HASH format,
which was inferior to DB_BTREE in pre-4.5 (I think) release. However,
for reasons I don't completely understand, almost all scripting
language bindings for Berkeley DB defaulted to DB_HASH, so we end up
with plenty of pointless disk-format incompatibility, in potentially
large files containing user data where it really, really hurts.
I guess that for most users of Berkeley DB, SQLite would be a better
fit: thread-safe and NFS-safe by default, automatic crash recovery, a
simple API with a stable API and ABI, a commitment to disk format
compatibility, no predetermined limits on transaction size, and the
ability to browse the database using third-party tools. In the
multiple writers case, SQLite cannot compete with Berkeley DB running
in the Transactional Data Store mode, and it lacks built-in
replication, but how many libdb4.x reverse dependencies set *that* up
correctly?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjzr8nko@mid.deneb.enyo.de
Re: Squeeze can't fit on 512MiB
On 10/27/2010 06:11 PM, Lennart Sorensen wrote: Is netatalk STILL included in the file server task? Who uses that anymore? The thing takes almost 2 minutes to start at boot (or at least if feels like it) and probably no Mac made in a decade has any need for it. It needs two minutes to start only if you don't configure it properly. But yes, it should go imho. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cc8a709.3040...@bzed.de
Re: Squeeze can't fit on 512MiB
On 10/27/2010 06:36 PM, Mike Hommey wrote: FWIW, it's what worked best when I set up Time Machine over the network. That sounds like they're using CNIDs then... Indeed netatalk is the only way to get such things done properly. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cc8a7b6.1070...@bzed.de
