Re: Size matters. Debian binary package stats
On Thu, 2006-01-19 at 20:49 -0800, Thomas Bushnell BSG wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: [snip] (And really, data about which mirrors would be dropped would help: maybe we can buy *them* a disk. Disks are cheap!) Unless the shelf is full, there's no more plugs left on the PS, there's no more room on the SCSI chain, they only allow purchases in RAID-5 units of SCSI disks, etc, etc. -- - Ron Johnson, Jr. Jefferson, LA USA Not peace at any price! Chains are worse than bayonets. Douglas William Jerrold -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Spare disk space isn't available to add amd64 to mirrors. Spare bandwith isn't available to add amd64 to mirrors. I see. Can we please have the numbers? Exactly how much disk space is needed? Perhaps we can simply go ahead and buy more disks for our machines. I recently posted a mail with mirror sizes for all arch on debian-devel so check lists.debian.org for it. The problem also isn't our machines but some mirror in low-diskspace-land. Mirrors that don't want to carry the additional arch shouldn't have to; this should be easy to arrange. Given the recent mail about the mirror split this seems to finaly get started. So far all primary mirrors HAD to carry all archs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Goswin von Brederlow [EMAIL PROTECTED] writes: The problem also isn't our machines but some mirror in low-diskspace-land. The amount of disk it takes to carry a complete Debian copy is simply going to be increasing. We have to tradeoff dropping a mirror or two against the costs of weakening the distribution by leaving out important things. (And really, data about which mirrors would be dropped would help: maybe we can buy *them* a disk. Disks are cheap!) Mirrors that don't want to carry the additional arch shouldn't have to; this should be easy to arrange. Given the recent mail about the mirror split this seems to finaly get started. So far all primary mirrors HAD to carry all archs. Yes, this has been a long time in coming and I'm glad that it has begun to move. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-28 22:33:10, schrieb Benjamin Seidenberg: Seriously? Where? I live in the states, and we pay approx. $50/month (600 USD/year) for residential DSL (I think, parents pay the bill). That's a 1.5m down/512k up pipe, with horrible reliability (alltel sucks). Where can I get the fiber optic for $10/year? I was talking about a E3, STM-1/4 or something similar. Here in Strasbourg we have ADSL with 8MBit downstream and 0.5 to 1 MBit upstream for 30-55 Euros. Generaly these ADSL lines are ADSL2+ with 16 MBit, but 8 MBit are reserved for TV and Telephone. I use an 1 MBit SDSL (incl. 8 IP fix and free Reverse DNS Service) from http://www.nerim.net/ for 253 Euros. Speed is with warantie. and service 24/7 Benjamin Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-27 16:04:42, schrieb Florian Weimer: * Michelle Konzack: Because we do not get 34 MBit and we have not a netload of 100% 24/7 the price per GByte is around 50 US$/GByte. This means you still have plenty capacity you've already paid for, supporting Steinar's claim that bandwidth is cheap. Just think about it. 8-) If you need to pay 450.000 DHs (42.000 €) for an E3 of 34 MBit which give you maximum 20-24 MBit because the Infrastructure is to bad in Morocco then it IS expensive. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Michelle Konzack [EMAIL PROTECTED] wrote: If you need to pay 450.000 DHs (42.000 ¤) for an E3 of 34 MBit which give you maximum 20-24 MBit because the Infrastructure is to bad in Morocco then it IS expensive. No. Based on what you've said, the price is the same regardless of whether you download 1GB or 20GB in a month. Therefore, as long as the increase in traffic doesn't saturate your line, the cost per GB is 0. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Goswin von Brederlow [EMAIL PROTECTED] writes: Spare disk space isn't available to add amd64 to mirrors. Spare bandwith isn't available to add amd64 to mirrors. I see. Can we please have the numbers? Exactly how much disk space is needed? Perhaps we can simply go ahead and buy more disks for our machines. Mirrors that don't want to carry the additional arch shouldn't have to; this should be easy to arrange. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:31:26PM +0100, Florian Weimer wrote: Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? Memory use during decompression would be interesting, too. For pure lzma it isn't really bad, it's about 100kb + directory_size and this is usually 8 MB (that is a sane value), but smaller directory sizes may be used as well. Some data discussion, also for the speed issue: (user time only) compression of libgcj6 (17612800 uncompressed), the first file i found that is big enough for usefull data gzip- 7.5 sec - 5118403 bzip2 - 16.9 sec - 5039522 lzma 8MB (-a2) - 53.8 sec - 3643734 lzma 2MB (-a2) - 50.3 sec - 3648493 lzma 1MB (-a2) - 48.1 sec - 3675183 lzma 1MB (-a1) - 41.1 sec - 3707349 lzma 1MB (-a0) - 23.5 sec - 3985219 lzma 512k(-a0) - 22.6 sec - 3994574 lzma 2MB (-a0) - 26.5 sec - 3979074 decompression: Memory usage about gzip - 0.2 sec - no idea, but few bzip2- 3.2 sec - 3700 kb lzma 8MB - 0.8 sec - 8200 kb lzma 2MB - 0.8 sec - 2150 kb lzma 1MB - 0.8 sec - 1120 kb lzma 512k- 0.8 sec - 620 kb In the end adding lzma to dpkg can't harm, it's just a small patch and has no external requierements, code size just grows like 12 kb or something. Cheers, Christian -- Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. (Aurelius Augustinus) Translation: http://gnuhh.org/work/fsf-europe/augustinus.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
I demand that Benjamin Seidenberg may or may not have written... [snip] I read 120.000 as 120 dollars, I'm not used to the European '.' as the seperator, but the US ','. Hmm? You'd better file a bug against locales wrt en_GB, then ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk Say NO to UK ID cards | http://www.no2id.net/ They took some of the Van Goghs, most of the jewels, and all of the Chivas! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Michelle Konzack wrote: Please not, that I had berween 12/1999 and 12/2004 a contract with a Parisian ISP for a OC-3 and Hosting of one 19 Rack (210cm, 600kg). I have payed including unlimited traffic 499.998 French Francs (76.000 Euro) per month and my own Class-C Block registered at RIPE. I heared (on debian-isp) that in the USA you can get a BGP4 routed STM4 (622MBit) Fiber Optic for only 120.000 US$ PER YEAR !!! Argh... Do I live in the false country? Greetings Michelle Seriously? Where? I live in the states, and we pay approx. $50/month (600 USD/year) for residential DSL (I think, parents pay the bill). That's a 1.5m down/512k up pipe, with horrible reliability (alltel sucks). Where can I get the fiber optic for $10/year? Benjamin signature.asc Description: OpenPGP digital signature
Re: Size matters. Debian binary package stats
Benjamin Seidenberg wrote: Michelle Konzack wrote: Please not, that I had berween 12/1999 and 12/2004 a contract with a Parisian ISP for a OC-3 and Hosting of one 19 Rack (210cm, 600kg). I have payed including unlimited traffic 499.998 French Francs (76.000 Euro) per month and my own Class-C Block registered at RIPE. I heared (on debian-isp) that in the USA you can get a BGP4 routed STM4 (622MBit) Fiber Optic for only 120.000 US$ PER YEAR !!! Argh... Do I live in the false country? Greetings Michelle Seriously? Where? I live in the states, and we pay approx. $50/month (600 USD/year) for residential DSL (I think, parents pay the bill). That's a 1.5m down/512k up pipe, with horrible reliability (alltel sucks). Where can I get the fiber optic for $10/year? Benjamin Oopps. Strike that. I read 120.000 as 120 dollars, I'm not used to the European '.' as the seperator, but the US ','. I also meant $10/month above, but that's obviously not relevant anymore. signature.asc Description: OpenPGP digital signature
Re: Size matters. Debian binary package stats
Michelle writes: I heared (on debian-isp) that in the USA you can get a BGP4 routed STM4 (622MBit) Fiber Optic for only 120.000 US$ PER YEAR !!! Benjamin writes: Where can I get the fiber optic for $10/year? I think you meant to write $10/month. However, Michelle is European and uses '.' where you would use ',' in numbers. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-22 16:04:45, schrieb Florian Weimer: With traffic included? How's that more than 10$ per gigabyte transferred and month? 8-) IF you can reach 34 Mbit! My old colo E3 at UUnet in Kehl/Germany was 5000 Euro/month plus traffic of as Reseller and End-User - 40 GByte 28 Euro/GByte 42 Euro/GByte 40 - 80 GByte 26 Euro/GByte 39 Euro/GByte 80 - 160 GByte 24 Euro/GByte ... 160 - 320 GByte 22 Euro/GByte ... ... Its not really funny in Europe and Africa. In Germany you can get an E1 für 300-400 Euro/month but if you must pay for traffic... In France at Estel you pay for the E1 2460 Euro/month. Ich you count France-Germany then you can have 78 GByte in Germany for the same prcie in France. Do not tell me, you can make 600 GByte traffic per month on an E1. Such things are stupid and you know it. No one run 100/ Netload 24/7. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-22 16:31:57, schrieb Olaf van der Spek: On 12/21/05, Andrew Suffield [EMAIL PROTECTED] wrote: Are you paying 10 $/gb? Heck yes, you can't get it that cheap unless you have no SLA (or one of those insulting SLAs that come with residential service, claiming that it doesn't have to work at all). And you can't get that at all on a pipe of any significant size (unless you're big enough to work out a peering agreement). We pay per month though, not per byte. That's unlimited traffic then I assume? At 1 mbyte/s (average) you'd be paying 25000 $/month. But do you actually need very high uptime for very large transfers? Please not, that I had berween 12/1999 and 12/2004 a contract with a Parisian ISP for a OC-3 and Hosting of one 19 Rack (210cm, 600kg). I have payed including unlimited traffic 499.998 French Francs (76.000 Euro) per month and my own Class-C Block registered at RIPE. I heared (on debian-isp) that in the USA you can get a BGP4 routed STM4 (622MBit) Fiber Optic for only 120.000 US$ PER YEAR !!! Argh... Do I live in the false country? Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-22 16:04:45, schrieb Florian Weimer: * Michelle Konzack: Am 2005-12-19 09:56:27, schrieb Olaf van der Spek: Are you paying 10 $/gb? Where is it that expensive? I pay 450.000 DHs (around 57.000 US$) in Morocco for an E3 (34 MBit) with traffic included. With traffic included? How's that more than 10$ per gigabyte transferred and month? 8-) 57.000 US$/month / 10 US$/GB = 5700 GB/month 5700 GB/month / 30,4 days / 24 h / 3600 sec = 2,22 MByte/second 2,22 MByte/Second ~ 28 MBit Because we do not get 34 MBit and we have not a netload of 100% 24/7 the price per GByte is around 50 US$/GByte. Please think twice. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/27/05, Michelle Konzack [EMAIL PROTECTED] wrote: 57.000 US$/month / 10 US$/GB = 5700 GB/month 5700 GB/month / 30,4 days / 24 h / 3600 sec = 2,22 MByte/second 2,22 MByte/Second ~ 28 MBit 12.6 bit/byte? Because we do not get 34 MBit and we have not a netload of 100% 24/7 the price per GByte is around 50 US$/GByte. True and I didn't know it was that expensive.
Re: Size matters. Debian binary package stats
* Michelle Konzack: Am 2005-12-22 16:04:45, schrieb Florian Weimer: With traffic included? How's that more than 10$ per gigabyte transferred and month? 8-) IF you can reach 34 Mbit! My old colo E3 at UUnet in Kehl/Germany was 5000 Euro/month plus traffic of as Reseller and End-User - 40 GByte 28 Euro/GByte 42 Euro/GByte 40 - 80 GByte 26 Euro/GByte 39 Euro/GByte 80 - 160 GByte 24 Euro/GByte ... 160 - 320 GByte 22 Euro/GByte ... ... Its not really funny in Europe and Africa. Even in Euope, you can get IP traffic at certain places for around 6 EUR per MBit/s and month, or something like that. In Germany you can get an E1 für 300-400 Euro/month but if you must pay for traffic... This is still rather cheap for real E1. 8- Links between arbitrary places can be quite expensive, unfortunately. Anyway, you are shifting the topic away from costs of bandwidth to renting fibers and colo pricing. They aren't equivalent.
Re: Size matters. Debian binary package stats
* Michelle Konzack: Because we do not get 34 MBit and we have not a netload of 100% 24/7 the price per GByte is around 50 US$/GByte. This means you still have plenty capacity you've already paid for, supporting Steinar's claim that bandwidth is cheap. Just think about it. 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Ron Johnson [EMAIL PROTECTED] writes:
On Tue, 2005-12-27 at 02:17 +0100, Goswin von Brederlow wrote:
Adam Heath [EMAIL PROTECTED] writes:
On Sun, 25 Dec 2005, Goswin von Brederlow wrote:
debs are created by debian/rules. So, only dependencies of dpkg would
have to
be modified.
I was talking about the hypothetical situation of dpkg defaulting to
!gzip compression and adding a Pre-Depends to the dpkg version
required for unpacking. The buildd would have to override that for
core packages.
No, the packages themselves would include such logic in their debian/rules.
There's no way we'd want to keep buildds in sync with what the set of core
packages is.
That would realy defeat the purpose of not having to modify every deb.
Why not just modify them the next time they are scheduled to be
built from source?
It occurs to me, though: while adding a {g|b}zip stage to the i386,
amd64, ppc, ia64, etc build wouldn't be noticed that much by 2GHz
CPUs, it *would* be noticed by 40MHz 68Ks. Is there a way to make
the compression conditional on the CPU?
On that note, we should make amd64 use bzip2 or similar before
anythinng else is added to the archive. :
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Adam Heath [EMAIL PROTECTED] writes: On Sun, 25 Dec 2005, Goswin von Brederlow wrote: debs are created by debian/rules. So, only dependencies of dpkg would have to be modified. I was talking about the hypothetical situation of dpkg defaulting to !gzip compression and adding a Pre-Depends to the dpkg version required for unpacking. The buildd would have to override that for core packages. No, the packages themselves would include such logic in their debian/rules. There's no way we'd want to keep buildds in sync with what the set of core packages is. That would realy defeat the purpose of not having to modify every deb. And, besides, libc6.deb is core, but is libc6-dev? Or it's documentation? Definetly as nearly everyone has it installed and it has a strict versioned depend (not the docs). And that one is the easiest to spot. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Tue, 27 Dec 2005, Goswin von Brederlow wrote: No, the packages themselves would include such logic in their debian/rules. There's no way we'd want to keep buildds in sync with what the set of core packages is. That would realy defeat the purpose of not having to modify every deb. We'd only modify the set of packages that are in base. That's a very small set. Are you thinking the opposite? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Tue, 2005-12-27 at 02:17 +0100, Goswin von Brederlow wrote:
Adam Heath [EMAIL PROTECTED] writes:
On Sun, 25 Dec 2005, Goswin von Brederlow wrote:
debs are created by debian/rules. So, only dependencies of dpkg would
have to
be modified.
I was talking about the hypothetical situation of dpkg defaulting to
!gzip compression and adding a Pre-Depends to the dpkg version
required for unpacking. The buildd would have to override that for
core packages.
No, the packages themselves would include such logic in their debian/rules.
There's no way we'd want to keep buildds in sync with what the set of core
packages is.
That would realy defeat the purpose of not having to modify every deb.
Why not just modify them the next time they are scheduled to be
built from source?
It occurs to me, though: while adding a {g|b}zip stage to the i386,
amd64, ppc, ia64, etc build wouldn't be noticed that much by 2GHz
CPUs, it *would* be noticed by 40MHz 68Ks. Is there a way to make
the compression conditional on the CPU?
--
-
Ron Johnson, Jr.
Jefferson, LA USA
But Gates is a visionary. Very early in the history of the PC,
he evolved a strikingly clear concept of where the industry was
headed, and he has pursued that vision_despite many tactical
setbacks_unwaveringly, relentlessly, and ruthlessly.
www.stanford.edu/group/mmdd/SiliconValley/Ferguson/Chapter.5.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Adam Heath [EMAIL PROTECTED] writes: On Sat, 24 Dec 2005, Goswin von Brederlow wrote: It would require some buildd hacking to get it to use gzip only for those few debs so more human power. debs are created by debian/rules. So, only dependencies of dpkg would have to be modified. I was talking about the hypothetical situation of dpkg defaulting to !gzip compression and adding a Pre-Depends to the dpkg version required for unpacking. The buildd would have to override that for core packages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, 25 Dec 2005, Goswin von Brederlow wrote: debs are created by debian/rules. So, only dependencies of dpkg would have to be modified. I was talking about the hypothetical situation of dpkg defaulting to !gzip compression and adding a Pre-Depends to the dpkg version required for unpacking. The buildd would have to override that for core packages. No, the packages themselves would include such logic in their debian/rules. There's no way we'd want to keep buildds in sync with what the set of core packages is. And, besides, libc6.deb is core, but is libc6-dev? Or it's documentation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sat, 24 Dec 2005, Goswin von Brederlow wrote: It would require some buildd hacking to get it to use gzip only for those few debs so more human power. debs are created by debian/rules. So, only dependencies of dpkg would have to be modified. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Ron Johnson [EMAIL PROTECTED] writes: On Wed, 2005-12-21 at 16:12 +0100, Goswin von Brederlow wrote: Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: [snip] The transition itself would go completly unadministered. Once dpkg is switched to default to a different compression all freshly build packages use it and the archive transitions itself over time. Because a .deb would know whether it is compressed or not, and dpkg would dynamically determine whether it needed to decompress or not? One would use the filename (e.g. data.tar.bz2) or a more elaborate system (add another file to the ar archive stating the compression) or something. The decompression must automaticaly pick whatever is right for a specific deb or the implementation would be inherently flawed. Only building a deb needs to be told or change the default what to use. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Goswin von Brederlow [Wed, Dec 21 2005, 04:19:56PM]: Actual maintainer of dpkg is evaluating the possibility to use 7zip. Even if the decision of using 7zip by default is far from being taken, it looks likely that dpkg will at least start supporting it. Cheers, It can't be the default unless stable dpkg has support for installing such debs. That means not before etch+1 or more likely etch+2. Why not? Use Pre-Depends. Sounds evil but is more reliable than just hoping that all users always upgrade to the latest stable. A Pre-Depends would work for non crucial stuff but would indeed be evil. Users should at least be able to update libc6, dpkg, apt, aptitude, whatever apt frontend so that has to be kept as gzip. It would require some buildd hacking to get it to use gzip only for those few debs so more human power. Of course dpkg and all of its dependencies must not be compressed with 7zip. There might also some depends/conflicts cases that could require updating or removing additional debs normaly unrelated to dpkg. Those usualy creap up on one unexpected which makes Pre-Depends on dpkg risky. Eduard. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Andrew Suffield wrote: As a general rule, UK bandwidth prices are roughly five to ten times those of equivalent service in other EU countries. Not that you can get equivalent service. Ouch. I pay less than that for a T1 to my house, and far far far less for bandwidth at a colo. I suggest that you consider either emigrating or rioting in the streets. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-18 12:36:05, schrieb Ron Johnson: On Sun, 2005-12-18 at 12:59 +0100, Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Spoken like someone who's never had to pay for a server room. ACK. My Internet Connection in Paris/France and Offenburg/Germany went France Germany E1 (colo) 2.460 480 Euro/month E3 (colo)17.600 2100 Euro/month incl. traffic 8 Euro/GByte STM-1 (FO) 32.000 42.000 Euro/month incl. traffic incl. traffic using my own CISCO 7xxx Curently I have in France a singel E3 with E1 Backup and in Germany a Dual E1. Betweex X-mas and new year, I will instal my third Server in Swiss and the price is between Germany and France. I have already read in debian-isp, that in the USA ate STM-4 (622 MBit, FiberOptic) are availlable for 120.000 US$/month. Oops!!! Oh yes, a E1 in Morocco cost around 7000 Euro, an E3 43.00 Euro and a STM-1 is around 130.000 Euro. All prices per Month !!! Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Hi Andrew, Am 2005-12-19 03:02:06, schrieb Andrew Suffield: I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. I feel with you, because I have an E3 in Morocco and must pay 450.000 DHs wich are around around 43.000 Euro per month. Currently I have a Proxim Tsunami MP.11a OutDoor-Router and two Lucent Stinger IP DSLAM with each 24 Ports plus a Debian portslave with 2 Cyclades PC400-Modem (each 60 Ports) Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-19 09:56:27, schrieb Olaf van der Spek: I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. Are you paying 10 $/gb? Where is it that expensive? I pay 450.000 DHs (around 57.000 US$) in Morocco for an E3 (34 MBit) with traffic included. An Internet Access 128/64 KBit is arRound 24 US$ and 1024/128 KBIT 90 US$. SO THINK TWICE! Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com)
Re: Size matters. Debian binary package stats
* Michelle Konzack: Am 2005-12-19 09:56:27, schrieb Olaf van der Spek: Are you paying 10 $/gb? Where is it that expensive? I pay 450.000 DHs (around 57.000 US$) in Morocco for an E3 (34 MBit) with traffic included. With traffic included? How's that more than 10$ per gigabyte transferred and month? 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/21/05, Andrew Suffield [EMAIL PROTECTED] wrote: Are you paying 10 $/gb? Heck yes, you can't get it that cheap unless you have no SLA (or one of those insulting SLAs that come with residential service, claiming that it doesn't have to work at all). And you can't get that at all on a pipe of any significant size (unless you're big enough to work out a peering agreement). We pay per month though, not per byte. That's unlimited traffic then I assume? At 1 mbyte/s (average) you'd be paying 25000 $/month. But do you actually need very high uptime for very large transfers?
Re: Size matters. Debian binary package stats
#include hallo.h * Goswin von Brederlow [Wed, Dec 21 2005, 05:03:41PM]: $ uncompressor -bash: uncompressor: command not found This solution doesn't look usable in scripts and user have to use a more complex syntax. You have to replace uncompressor with whatever tool is the right to uncompress the format. Just like you have to use -z or -j depending on gzip or bzip2 compression. ucat from the unp package. However, for this purpose it is rather a cludge and IIRC it does not work with STDIN well. Eduard. -- Ambassador Londo Mollari: I would remind the Drazi Ambassador that the Centuri have already signed the declaration. Citizen G'Kar: And if the Centuri can sign it, anybody can sign it! Ambassador Londo Mollari: Right! -- Quotes from Babylon 5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
#include hallo.h * Goswin von Brederlow [Wed, Dec 21 2005, 04:19:56PM]: Actual maintainer of dpkg is evaluating the possibility to use 7zip. Even if the decision of using 7zip by default is far from being taken, it looks likely that dpkg will at least start supporting it. Cheers, It can't be the default unless stable dpkg has support for installing such debs. That means not before etch+1 or more likely etch+2. Why not? Use Pre-Depends. Sounds evil but is more reliable than just hoping that all users always upgrade to the latest stable. Of course dpkg and all of its dependencies must not be compressed with 7zip. Eduard. -- Commander Jeffrey David Sinclair: Everyone lies, Michael. The innocent lie because they don't want to be blamed for something they didn't do and the guilty lie because they don't have any other choice. -- Quotes from Babylon 5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Spare disk space isn't available to add amd64 to mirrors. Spare bandwith isn't available to add amd64 to mirrors. Users disk space might be cheap but they have the unpacked binaries anyway. Users bandwith might be cheap but often very limited due to infrastructure. A lot of analog modems are still out there. - CPU doesn't grow nearly as fast as those three. Any arch where cpu speed still grows has plenty of cpu time to spare anyway. Only old archs (and the embedded stuff) have cpu problems. But do they want a 200MB OpenOffice? - Human power grows even slower. - The administrative overhead of transitioning to a new .deb format would be huge. Where do you get this from? Where is this relevant? The overhead to change to a new deb format is small. A very few packages have to change (dpkg, apt, DAK, mini-dinstall). A few man hours of work and compared with the amount of changes in debian every day that is miniscule. The transition itself would go completly unadministered. Once dpkg is switched to default to a different compression all freshly build packages use it and the archive transitions itself over time. All the transition needs, after the initial infrastructure change, is a lot of time. At least one stable release to get stable dpkg to cope with differently compressed unstable packages and then time for every package to get a new upload. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. Don't forget CD/DVD space. With better compression you could probably fit Sarge i386 on a dual layer dvd again. The businesscard and netboot images would also shrink alowing some more debs on them, e.g. a graphical installer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Olaf van der Spek [EMAIL PROTECTED] writes: On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd Why is the knowledge of how to decode a .deb distributed over so many tools? have to make sure it works on all kinds of obscure platforms actually using the thing. (And yes, I have used ar and tar to extract debs, and consider it a quite useful feature.) Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? uncompressor file.tar.whatever | tar -x The .deb format is _fixed_ -- this isn't AVI where you just plug in another codec and hope it works. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Raphael Hertzog [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: Hi I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ FWIW : https://wiki.ubuntu.com/Dpkg7Zip Actual maintainer of dpkg is evaluating the possibility to use 7zip. Even if the decision of using 7zip by default is far from being taken, it looks likely that dpkg will at least start supporting it. Cheers, It can't be the default unless stable dpkg has support for installing such debs. That means not before etch+1 or more likely etch+2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote: uncompressor file.tar.whatever | tar -x $ uncompressor -bash: uncompressor: command not found This solution doesn't look usable in scripts and user have to use a more complex syntax.
Re: Size matters. Debian binary package stats
Olaf van der Spek [EMAIL PROTECTED] writes: On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote: uncompressor file.tar.whatever | tar -x $ uncompressor -bash: uncompressor: command not found This solution doesn't look usable in scripts and user have to use a more complex syntax. You have to replace uncompressor with whatever tool is the right to uncompress the format. Just like you have to use -z or -j depending on gzip or bzip2 compression. For a generic uncompressor the mailcap programs are probably best suited for adopting it. E.g. add an action dump to run-mailcap that outputs the uncompressed data. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Wed, 2005-12-21 at 16:12 +0100, Goswin von Brederlow wrote: Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: [snip] The transition itself would go completly unadministered. Once dpkg is switched to default to a different compression all freshly build packages use it and the archive transitions itself over time. Because a .deb would know whether it is compressed or not, and dpkg would dynamically determine whether it needed to decompress or not? -- - Ron Johnson, Jr. Jefferson, LA USA A man can't be too careful in the choice of his enemies. Oscar Wilde
Re: Size matters. Debian binary package stats
On Mon, Dec 19, 2005 at 09:56:27AM +0100, Olaf van der Spek wrote: On 12/19/05, Andrew Suffield [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote: * Steinar H. Gunderson: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. Are you paying 10 $/gb? Heck yes, you can't get it that cheap unless you have no SLA (or one of those insulting SLAs that come with residential service, claiming that it doesn't have to work at all). And you can't get that at all on a pipe of any significant size (unless you're big enough to work out a peering agreement). We pay per month though, not per byte. Where is it that expensive? UK. As a general rule, UK bandwidth prices are roughly five to ten times those of equivalent service in other EU countries. Not that you can get equivalent service. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
On 12/19/05, Andrew Suffield [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote: * Steinar H. Gunderson: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. Are you paying 10 $/gb? Where is it that expensive?
Size matters. Debian binary package stats
Hi I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Comments are welcome... Yours, Gürkan
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. - CPU doesn't grow nearly as fast as those three. - Human power grows even slower. - The administrative overhead of transitioning to a new .deb format would be huge. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Gürkan Sengün [EMAIL PROTECTED] wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
2005/12/18, Andreas Metzler [EMAIL PROTECTED]: Gürkan Sengün [EMAIL PROTECTED] wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? That page has compression and decompression speeds, putting 7zip at about 40% slower than bzip2 and 90% slower than gzip. The decompression speed of 7zip is better than bzip2 but still nothing to write home about. Anyone know a good heuristic for measuring bang for buck for compression algorithms? Have a nice day, Martijn
Re: Size matters. Debian binary package stats
Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. In many parts of the world. Nos so much in others. - CPU doesn't grow nearly as fast as those three. ??? In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space. - Human power grows even slower. OK. - The administrative overhead of transitioning to a new .deb format would be huge. This is quite true. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. That really depends. I routinely see posts on debian-user asking about how to use a friend's fast DSL or cable connection to download packages to install on a Debian box that has only dial up access to the Internet. I think that the biggest problem is really updates. Packages like XFree86 (no X.org) and Openoffice.org are *huge*. A simple security update to one of those packages causes all subordinate binary packages to get a version bump. That means that if there was a bug in the XFree86 driver for video card foo and I use video card bar, I still get download a many dozens of MB update. IIRC, something similar caused a major strain on security.debian.org shortly after the Sarge release. If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/18/05, Roberto Sanchez [EMAIL PROTECTED] wrote: I think that the biggest problem is really updates. Packages like XFree86 (no X.org) and Openoffice.org are *huge*. A simple security update to one of those packages causes all subordinate binary packages to get a version bump. That means that if there was a bug in the XFree86 driver for video card foo and I use video card bar, I still get download a many dozens of MB update. IIRC, something similar caused a major strain on security.debian.org shortly after the Sarge release. If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach. It would be nice to make it even smarter and grab only the files that actually changed instead of the entire package.
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. - CPU doesn't grow nearly as fast as those three. - Human power grows even slower. - The administrative overhead of transitioning to a new .deb format would be huge. Why would this be huge? Why is it that hard to plugin another codec?
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:41:03AM -0500, Roberto Sanchez wrote: - CPU doesn't grow nearly as fast as those three. In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space. So? We're talking “bandwidth”, not “dial-up modem bandwidth” -- thankfully, the world is progressing, and we're moving away from dial-up at lightning speeds. :-) In 1995 I had a 28.800 modem -- today, I have 6Mbit at about the same price (probably a bit lower). That's a 21300% increase to match your 2200% increase :-) Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach. Splitting packages makes sense for this sort of thing, and X did just that. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd have to make sure it works on all kinds of obscure platforms actually using the thing. (And yes, I have used ar and tar to extract debs, and consider it a quite useful feature.) The .deb format is _fixed_ -- this isn't AVI where you just “plug in another codec” and hope it works. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005, Andreas Metzler wrote: Have you perhaps run some benchmarks? Thanks to Kingsley Morse Jr.: http://adn.diwi.org/debian/p7zip/7za.jpg Even more precise at http://www.linuxjournal.com/article/8051 -- adn Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, 2005-12-18 at 15:02 +0100, Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 08:41:03AM -0500, Roberto Sanchez wrote: - CPU doesn't grow nearly as fast as those three. In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space. So? We're talking “bandwidth”, not “dial-up modem bandwidth” -- thankfully, the world is progressing, and we're moving away from dial-up at lightning speeds. :-) In 1995 I had a 28.800 modem -- today, I have 6Mbit at about the same price (probably a bit lower). That's a 21300% increase to match your 2200% increase :-) But there are still many people stuck on dial-up, because of where they live. -- - Ron Johnson, Jr. Jefferson, LA USA You're a good example of why some animals eat their young. Jim Samuels
Re: Size matters. Debian binary package stats
On Sun, 2005-12-18 at 12:59 +0100, Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Spoken like someone who's never had to pay for a server room. -- - Ron Johnson, Jr. Jefferson, LA USA Man, I'm pretty. Hoo Hah! Johnny Bravo
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd Why is the knowledge of how to decode a .deb distributed over so many tools? have to make sure it works on all kinds of obscure platforms actually using the thing. (And yes, I have used ar and tar to extract debs, and consider it a quite useful feature.) Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? The .deb format is _fixed_ -- this isn't AVI where you just plug in another codec and hope it works.
Re: Size matters. Debian binary package stats
* Steinar H. Gunderson: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. My main concern is that changing the compression algorithm alone optimizes for the wrong case (initial install), which you can do from CD anyway if you are bandwidth-starved. Delta compression for .debs would be far more interesting, I guess, but I have no idea how to implement them in a sane way. 8-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: Hi I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ FWIW : https://wiki.ubuntu.com/Dpkg7Zip Actual maintainer of dpkg is evaluating the possibility to use 7zip. Even if the decision of using 7zip by default is far from being taken, it looks likely that dpkg will at least start supporting it. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
* Andreas Metzler: Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? Memory use during decompression would be interesting, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd Why is the knowledge of how to decode a .deb distributed over so many tools? Probably, it's because there's no [C] library that would allow those tools to deal with .deb files. Hence everybody start writing the tool by creating one more parser for the .deb format. -- Misha signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
On Sun, 18 Dec 2005 15:02:55 +0100 Steinar H. Gunderson [EMAIL PROTECTED] wrote: Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) Anyway, ~ 3 000 times, not ~ 3 000 000 times, sadly! -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 09:08:21PM +0100, Luca Brivio wrote: Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) Anyway, ~ 3 000 times, not ~ 3 000 000 times, sadly! Oops. Oh well, good thing the error consisted of zeros only ;-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? Get real. gzip is probably understood by 99.9% of all installed UNIX systems in the world, and you cannot possibly hope to get anywhere near that for a relatively obscure alternative. (The -j flag to tar is a Debian specific extension, BTW -- I'm not sure if the -z flag is a GNU-specific extension, but it wouldn't surprise me.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? Get real. gzip is probably understood by 99.9% of all installed UNIX systems in the world, and you cannot possibly hope to get anywhere near that for a relatively obscure alternative. (The -j flag to tar is a Debian specific extension, BTW -- I'm not sure if the -z flag is a GNU-specific extension, but it wouldn't surprise me.) I guess what I'm asking is, why are tar and other applications using gzip instead of a generic library that handles all compression/decompression and can be easily extended.
Re: Size matters. Debian binary package stats
Steinar H Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? Well, tar supports --use-compress-program. [...] (The -j flag to tar is a Debian specific extension, BTW No, the Debian extension was -I (and even that was present for a while in upstream). It was changed to -j because that's what upstream did. The -j flag is present upstream as of 1.13.18. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote: I guess what I'm asking is, why are tar and other applications using gzip instead of a generic library that handles all compression/decompression and can be easily extended. General complexity, I'd guess. If you want “easily extended”, you'll have to cope with dynamic, shared libraries -- look to NSS for a case on how evil that can get. (And tar is really something you'd like to stay small and simple.) Also, having to hunt down the right plug-in module for whatever format somebody had the bright idea to use at some point can be a real pain. (Ever had to use one of those “codec packs” for Micosoft Windows?) Besides, UNIX does this a different way, traditionally -- via separate programs. “gzip -d file.tar.gz ; tar xf file.tar” gives you most of the same functionality, with zero extra complexity. (Try --use-compress-program in GNU tar, but that probably doesn't exist in anything else.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote: I guess what I'm asking is, why are tar and other applications using gzip instead of a generic library that handles all compression/decompression and can be easily extended. General complexity, I'd guess. If you want easily extended, you'll have to cope with dynamic, shared libraries -- look to NSS for a case on how evil that can get. (And tar is really something you'd like to stay small and simple.) Also, having to hunt down the right plug-in module for whatever format somebody had the bright idea to use at some point can be a real pain. (Ever had to use one of those codec packs for Micosoft Windows?) Besides, UNIX does this a different way, traditionally -- via separate programs. gzip -d file.tar.gz ; tar xf file.tar gives you most of the same functionality, with zero extra complexity. (Try --use-compress-program in GNU tar, but that probably doesn't exist in anything else.) I guess that's even easier. Just use/write a filter that looks at the header and invoke the right coder/decoder internally.
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote: * Steinar H. Gunderson: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
