|
osdir.com mailing list archive |
|
Subject: RFC#8 - bzip2 - msg#00298List: os.openbsd.portsRequest to import bzip2 in the official src tree. Reading /policy.html and looking at the src tree layout is clear that GPLed software is used only if there aren't alternative ways. Looking at bzip2 I found out that this software seems to have a full compatible license and it gives better compression than gzip. It is already used by some ports to decompress distfiles and could give a lot of advantages (RFC#9). Look at how many Mbytes you could save downloading 3.3 snapshots: base33 (tgz) 30903567 (bz2) 24120264 comp33 (tgz) 16590617 (bz2) 13837916 etc33 (tgz) 1500604 (bz2) 1232789 man33 (tgz) 6128578 (bz2) 4685742 misc33 (tgz) 1748521 (bz2) 1712209 In this case a patch to pax/tar should be developed, but a pipe can work in the meantime. Obviously also packages could be built using bzip2 saving again a lot of bandwidth and storage space. However, all this ways of using bzip2 are only examples, at the moment I'm only saying that bzip2 seems to have a better license and performance than gzip, so I'm asking to include it in the dafult src tree. Ed # RFC @ hacking.openbsd.it Thread at a glance:
Previous Message by Date: click to view message previewRFC#7 - ports fetchingRequest to define HTTP as preferred way to fetch distfiles. Today every port mantainer choose a way to fetch distfiles among what is possible. Most times this choice is FTP even if HTTP is available. Every FTP download occupy 2 sockets of the server and the client: Active FTP Client A > 1024 and B > 1024 Server C = 21 and D = 20 Passive FTP Client A > 1024 and B = A+1 Server C = 21 and D > 1024 HTTP is stateless, FTP no. But we never use this feature of the FTP protocol, infact if you try to fetch all kde distfiles you'll see a new connection to the server port 21 for every file. This is overhead... HTTP fetch is faster to setup. HTTP needs only one shared socket on the server. I'm asking port coordinators to publically define a preferred order of fetching methods. This is what I'll suggest: 1) HTTP 2) FTP Downloading distfiles from one single mirror is really faster using HTTP than FTP because you don't loose time setting up a FTP control connection for each file. Try to believe... Ed # RFC @ hacking.openbsd.it Next Message by Date: click to view message previewRFC#9 - distfilesRequest to define bzip2 as preferred distfiles format. Today every port mantainer choose a format among what is possible. Most times this choice is gzip even if bzip2 is available. Bzip2 could let OpenBSD mirrors save a lot of Mbytes of disk storage and bandwidth. Also fetching users will need less time. Time is precious for anyone... I'm asking port coordinators to publically define a preferred order of distfiles formats. This is the order I'll suggest: 1) bzip2 2) gzip 3) zip 4) ... Some interesting examples: PHP 4.3.1 (tar.bz2) 3,596Kb (tar.gz) 4,395Kb GTK+ 2.2.1 (tar.bz2) 6.2MB (tar.gz) 8.9MB OpenOffice 1.0.2 (bzip2) 154MB (gzip) 172MB Ed # RFC @ hacking.openbsd.it Previous Message by Thread: click to view message previewRFC#7 - ports fetchingRequest to define HTTP as preferred way to fetch distfiles. Today every port mantainer choose a way to fetch distfiles among what is possible. Most times this choice is FTP even if HTTP is available. Every FTP download occupy 2 sockets of the server and the client: Active FTP Client A > 1024 and B > 1024 Server C = 21 and D = 20 Passive FTP Client A > 1024 and B = A+1 Server C = 21 and D > 1024 HTTP is stateless, FTP no. But we never use this feature of the FTP protocol, infact if you try to fetch all kde distfiles you'll see a new connection to the server port 21 for every file. This is overhead... HTTP fetch is faster to setup. HTTP needs only one shared socket on the server. I'm asking port coordinators to publically define a preferred order of fetching methods. This is what I'll suggest: 1) HTTP 2) FTP Downloading distfiles from one single mirror is really faster using HTTP than FTP because you don't loose time setting up a FTP control connection for each file. Try to believe... Ed # RFC @ hacking.openbsd.it Next Message by Thread: click to view message previewRe: RFC#8 - bzip2On Wed, Feb 26, 2003 at 11:02:52AM +0100, Ed White wrote: > However, all this ways of using bzip2 are only examples, at the moment I'm > only saying that bzip2 seems to have a better license and performance than > gzip, so I'm asking to include it in the dafult src tree. This is not true. bzip2 needs more memory to decompress stuff. It is a hindrance on older machines, or would make it downright impossible to install the base sets without a larger memory footprint (e.g., bump the minimal requirements for a 386 install from 12M to 16M). You might think this is not important, but an older i386 can be quite adequate as a personal firewall box (hint: slow machine, no fans, no noise...) Loading Comments...
|
|
