Re: star 1.4a08 comments / questions / suggestions (was: Re: cdrtools RPM)
>X-Envelope-Sender: [EMAIL PROTECTED] >> 4. I noticed the following files are installed when 'make >> install'ing Schilling programs: >> >> /usr/include/align.h >> /usr/include/avoffset.h >> /usr/lib/libdeflt.a >> /usr/lib/libfile.a >> /usr/lib/libhfs.a >> /usr/lib/librscg.a >> /usr/lib/libscg.a >> /usr/lib/libschily.a >> /usr/lib/libunls.a >I don't care what standard you follow, having applications install >includes and libraries in system directories leads to competing and/or >incompatible versions and application breakage. Not to mention the >ability to build a totally non-portable application because you didn't >know that the code used a non-Linux feature. >With a bit of effort you can put this in a non-conflicting place, such >as /opt/shilly/* directories, and not have this problem. You are wrong: makefiles installs everything in /opt/schily/* except when people start to fiddle with the defaults. Of course, when you change INS_BASE from /opt/schily to / things will work as above - but then it is inetended by the person who changed the DEFAULTS file Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: star 1.4a08 comments / questions / suggestions (was: Re: cdrtools RPM)
"Karol Pietrzak" <[EMAIL PROTECTED]> wrote: > 4. I noticed the following files are installed when 'make > install'ing Schilling programs: > > /usr/include/align.h > /usr/include/avoffset.h > /usr/lib/libdeflt.a > /usr/lib/libfile.a > /usr/lib/libhfs.a > /usr/lib/librscg.a > /usr/lib/libscg.a > /usr/lib/libschily.a > /usr/lib/libunls.a I don't care what standard you follow, having applications install includes and libraries in system directories leads to competing and/or incompatible versions and application breakage. Not to mention the ability to build a totally non-portable application because you didn't know that the code used a non-Linux feature. With a bit of effort you can put this in a non-conflicting place, such as /opt/shilly/* directories, and not have this problem. This is not "in theory" as I have another application which uses an align.h file (not the same one!). -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: star 1.4a08 comments / questions / suggestions (was: Re: cdrtools RPM)
>From: "Karol Pietrzak" <[EMAIL PROTECTED]> >> things. You are hit by the way Linux does memory management. If >> Linux (with the old memory concept - I did not yet test the new >> one) has less than 8 MB of free memory, it becomes very very >> slow. If you run star as root there is a second change (made a >> few weeks ago) that is intended to speed up operation: It tries >> to lock the FIFO in memory. >> >> On your specific machine the last two changes seem to hurt you >> but note that this cannot be called typical behaviour. >The tests _were_ run as root, and top reports ~11MB free before >using star. So, what are the problems affecting me? Maybe there havwe not been 11 MB free. From observing Linux behaviour, I would not believe tools that tell you such things. Please run sdd -inull bs=8m count=1 of=/dev/null If you repeat this command and it takes less than .1 seconds, you should be sure that there is at least 8 MB of free memory - in case there are no other programs that "eat" memory (e.g. netscape). Then run your star tests... >> There are plans to add a way to specify the default FIFO size in >> /etc/default/star Note that backup speed with a DLT tape may >> increase by more than 10% if you use 128 MB for the FIFO. >> However, I won't recommend to use more than 1/4 of the total free >> memory of the machine. >Is there a way I can set this _now_ as a compile-time option? I >have no problems with doing that. Can I also test another >version of star? I am using star every day on a lot of different platforms (since 1985) and I never noticed such a behaviour. For this reason, there is no such compile time option. If you believe that you have problems, try the fs= option and if it really was the problem, send me a mail and edit fifo.c >> >2. There are several cool things in GNU tar that don't work in >> >star. Here's a list: >> > options :: star equivalent >> > o -cf :: -c -f >> > o -xf :: -x -f >> > o -C /fubar :: -C=/fubar >> >> It seems that you did not read the man pages well enough... >> Neither GNUtar not star list that you may combine single char >> BOOLEAN flags but both support them. >> >> So what is your problem? >I didn't know whether or not this was a unintended side effect. >I want to be able to use the same options for star as I do for GNU tar (i.e. I wish I >could use "-xf" in star like I do in GNU tar; I wish I could use "-C /tmp" in star >like I do in GNU tar). Well star never allowed -cf because this is a mehod of calling star with a high risk of loosing files. f= must be a separate option to make sure that you did not make a typo that would make one of the file arguments the tar archive by accident. If you use star in POSIX compatibility mode (no '-' signs before the options) then star cf xx is allowed with some restrictions: the argument to the f option must either not exists, be a decive type argument or a zero sized file. >I apologize for being so valuge in my previous message. >> >3. Is there a way to remove files from tar archives using star? >> >> NO, never needeed >So what do I do? [ star -x -f file.tar -C=./dir; rm -f >./dir/fubar; rm -f file.tar; star -c -f file.tar ./dir; rm -rf >./dir ]? Well during the last 16+ years I never had the need to remove files from a tar archive. >> >4. I noticed the following files are installed when 'make ... >> >/usr/lib/libschily.a >> >/usr/lib/libunls.a >> >> Well, you usually don't need them. >So I guess it would be OK to not distribute them period, I >guess. No problem BTW Star use to mean 'schily tar' before 1993, but then is has been renamed to star (standard tar). Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: star 1.4a08 comments / questions / suggestions (was: Re: cdrtools RPM)
On 18 Nov 2001, Joerg Schilling wrote: > First: t makes no sense to do timings with compressed archives > where tar has to call e.g. gzip to decompress the archive while > running. I realized that when I did the test: I just wanted to show that the problem exists also when calling gzip / bzip2. That's all... > Second: From reading further down, it turns out that you did the > test on a "tiny" machine as it has been used about 12-14 years > ago. In former times, star used to use 1 MB for FIFO by default. > A few weeks ago, I decided to increase FIFO size for what I > assume is a "modern machine". Now, star uses 1 MB (as before) on > sun3 machines, 4 MB on Linux (as Linux detected mmap() a few > months before and SYSV shared mem is static and limited) and 8 MB > on all other machines. This usually dramatically speeds up > things. You are hit by the way Linux does memory management. If > Linux (with the old memory concept - I did not yet test the new > one) has less than 8 MB of free memory, it becomes very very > slow. If you run star as root there is a second change (made a > few weeks ago) that is intended to speed up operation: It tries > to lock the FIFO in memory. > > On your specific machine the last two changes seem to hurt you > but note that this cannot be called typical behaviour. The tests _were_ run as root, and top reports ~11MB free before using star. So, what are the problems affecting me? > There are plans to add a way to specify the default FIFO size in > /etc/default/star Note that backup speed with a DLT tape may > increase by more than 10% if you use 128 MB for the FIFO. > However, I won't recommend to use more than 1/4 of the total free > memory of the machine. Is there a way I can set this _now_ as a compile-time option? I have no problems with doing that. Can I also test another version of star? > >2. There are several cool things in GNU tar that don't work in > >star. Here's a list: > > options :: star equivalent > > o -cf :: -c -f > > o -xf :: -x -f > > o -C /fubar :: -C=/fubar > > It seems that you did not read the man pages well enough... > Neither GNUtar not star list that you may combine single char > BOOLEAN flags but both support them. > > So what is your problem? I didn't know whether or not this was a unintended side effect. I want to be able to use the same options for star as I do for GNU tar (i.e. I wish I could use "-xf" in star like I do in GNU tar; I wish I could use "-C /tmp" in star like I do in GNU tar). I apologize for being so valuge in my previous message. > >3. Is there a way to remove files from tar archives using star? > > NO, never needeed So what do I do? [ star -x -f file.tar -C=./dir; rm -f ./dir/fubar; rm -f file.tar; star -c -f file.tar ./dir; rm -rf ./dir ]? > >4. I noticed the following files are installed when 'make > >install'ing Schilling programs: > > >/usr/include/align.h > >/usr/include/avoffset.h > >/usr/lib/libdeflt.a > >/usr/lib/libfile.a > >/usr/lib/libhfs.a > >/usr/lib/librscg.a > >/usr/lib/libscg.a > >/usr/lib/libschily.a > >/usr/lib/libunls.a > > Well, you usually don't need them. So I guess it would be OK to not distribute them period, I guess. -- Karol Pietrzak PGP KeyID: 3A1446A0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: star 1.4a08 comments / questions / suggestions (was: Re: cdrtools RPM)
>From: "Karol Pietrzak" <[EMAIL PROTECTED]> >It's working, but I have some problems / questions (I couldn't >find a star mailing list, so I hope I don't get beaten down for >this post): >1. On my machine, star is SLOW... More than 7x slower on average >than GNU tar... That can't be right. >linux:~ # time star -z -x -f star-1.4a08.tar.gz -C=/tmp/ >star: 234 blocks + 9216 bytes (total of 2405376 bytes = >2349.00k). First: t makes no sense to do timings with compressed archives where tar has to call e.g. gzip to decompress the archive while running. Second: From reading further down, it turns out that you did the test on a "tiny" machine as it has been used about 12-14 years ago. In former times, star used to use 1 MB for FIFO by default. A few weeks ago, I decided to increase FIFO size for what I assume is a "modern machine". Now, star uses 1 MB (as before) on sun3 machines, 4 MB on Linux (as Linux detected mmap() a few months before and SYSV shared mem is static and limited) and 8 MB on all other machines. This usually dramatically speeds up things. You are hit by the way Linux does memory management. If Linux (with the old memory concept - I did not yet test the new one) has less than 8 MB of free memory, it becomes very very slow. If you run star as root there is a second change (made a few weeks ago) that is intended to speed up operation: It tries to lock the FIFO in memory. On your specific machine the last two changes seem to hurt you but note that this cannot be called typical behaviour. There are plans to add a way to specify the default FIFO size in /etc/default/star Note that backup speed with a DLT tape may increase by more than 10% if you use 128 MB for the FIFO. However, I won't recommend to use more than 1/4 of the total free memory of the machine. >In the last operation, star used ~15.7% of my RAM (total :32MB). > GNU tar only ~2.7%. I would have no qualms about using star >over GNU tar if it was faster even if it used more RAM. >2. There are several cool things in GNU tar that don't work in >star. Here's a list: > options :: star equivalent > o -cf :: -c -f > o -xf :: -x -f > o -C /fubar :: -C=/fubar It seems that you did not read the man pages well enough... Neither GNUtar not star list that you may combine single char BOOLEAN flags but both support them. So what is your problem? >IMO, these options should be added if not for user convenience, >then for GNU tar compatibility. ??? Please be precise so I can guess what you like >3. Is there a way to remove files from tar archives using star? NO, never needeed >4. I noticed the following files are installed when 'make >install'ing Schilling programs: >/usr/include/align.h >/usr/include/avoffset.h >/usr/lib/libdeflt.a >/usr/lib/libfile.a >/usr/lib/libhfs.a >/usr/lib/librscg.a >/usr/lib/libscg.a >/usr/lib/libschily.a >/usr/lib/libunls.a Well, you usually don't need them. >What are they used for? Should I include them in my RPMs? If >you take a peek at >http://home.earthlink.net/~noodlez84/rpm_packages.html , I have >a devel RPM for every Schilling package I compile. Is this the >"right" way? Sorry, I cannot check these files as I am usually using Solaris for development. On Linux, I use the SuSE system and - of course- install my tools manually. >5. Joerg Schilling: I read your GNU tar rant in the rather >lengthy README.otherbugs, and I must say, I agree with you. >Even the folks at 'file' know that GNU tar != POSIX tar: >linux:~ # file some_gnu_tar_file.tar >some_gnu_tar_file.tar: GNU tar archive >linux:~ # file some_star_archive.tar >some_star_archive.tar: POSIX tar archive Well so it seems to be cleverer about this topoic than GNU tar which cannot distinguish between both ,-) >BTW, I apologize for the length of this message. The same applies to the answer ;-) Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
>From: "Karol Pietrzak" <[EMAIL PROTECTED]> > >> Well it's a Linux only standard but it is close to that UNIX >> systems do... >> >> How about putting "star" on your list? >Sure... I just downloaded the source. I presume >ftp://ftp.fokus.gmd.de/pub/unix/star/alpha/star-1.4a08- >sspm.tar.gz is the latest version. I am right? This is the source plugin variant and it misses some README's but the basic source isidentical to the latest release. >> It's bad to see, that currently all Linux systems only have the >> non-standard GNU tar while the standard compilant star is >> available for a long time. >Perhaps I am ignorant, but I always assumed GNU tar _was_ >standards complaint. Could you send me a link to the standard >you have in mind? As long as it has been called PD tar or SUG tar, it was standard compliant and implemented a subset of the standard. After it has been adopted by FSF and called GNU tar it became nonstandard because of the changes people from FSF applied to the source. This was around 1989. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
On 17 Nov 2001, Danilo Godec wrote: > How about a src.rpm or a spec fiel? I have an alpha platform and > I'd like to build the new cdrtools... Sure... I've gotten more than enough comments from people (Denis Pelletier is among them) about offering an SRPM, for at least the SPEC file and a diff. Well, I'm working on that. Should be up in the next couple of days... -- Karol Pietrzak PGP KeyID: 3A1446A0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
star 1.4a08 comments / questions / suggestions (was: Re: cdrtools RPM)
On 16 Nov 2001, Joerg Schilling wrote: > How about putting "star" on your list? > > > It's bad to see, that currently all Linux systems only have the > non-standard GNU tar while the standard compilant star is > available for a long time. It's up. Check out http://home.earthlink.net/~noodlez84/rpm_packages.html . It's working, but I have some problems / questions (I couldn't find a star mailing list, so I hope I don't get beaten down for this post): 1. On my machine, star is SLOW... More than 7x slower on average than GNU tar... That can't be right. linux:~ # time star -z -x -f star-1.4a08.tar.gz -C=/tmp/ star: 234 blocks + 9216 bytes (total of 2405376 bytes = 2349.00k). real0m17.925s user0m0.420s sys 0m1.550s linux:~ # rm -rf /tmp/star-1.4/ linux:~ # time tar --gzip -xf star-1.4a08.tar.gz -C /tmp/ real0m1.620s user0m0.460s sys 0m0.650s linux:~ # rm -rf /tmp/star-1.4/ linux:~ # time gzip -dc star-1.4a08.tar.gz | star -x -f - - C=/tmp/ star: 234 blocks + 9216 bytes (total of 2405376 bytes = 2349.00k). real0m15.408s user0m0.420s sys 0m1.570s linux:~ # rm -rf /tmp/star-1.4/ linux:~ # time bzip2 -dc fubar.tar.bz2 | star -x -f - -C=/tmp/ star: 262 blocks + 0 bytes (total of 2682880 bytes = 2620.00k). real0m10.099s user0m2.320s sys 0m0.970s linux:/tmp # time star -x -f fubar.tar star: 262 blocks + 0 bytes (total of 2682880 bytes = 2620.00k). real0m10.515s user0m0.060s sys 0m0.860s linux:/tmp # rm -rf fubar linux:/tmp # time tar -xf fubar.tar real0m0.676s user0m0.040s sys 0m0.440s linux:/tmp # In the last operation, star used ~15.7% of my RAM (total :32MB). GNU tar only ~2.7%. I would have no qualms about using star over GNU tar if it was faster even if it used more RAM. 2. There are several cool things in GNU tar that don't work in star. Here's a list: options :: star equivalent o -cf :: -c -f o -xf :: -x -f o -C /fubar :: -C=/fubar IMO, these options should be added if not for user convenience, then for GNU tar compatibility. 3. Is there a way to remove files from tar archives using star? 4. I noticed the following files are installed when 'make install'ing Schilling programs: /usr/include/align.h /usr/include/avoffset.h /usr/lib/libdeflt.a /usr/lib/libfile.a /usr/lib/libhfs.a /usr/lib/librscg.a /usr/lib/libscg.a /usr/lib/libschily.a /usr/lib/libunls.a What are they used for? Should I include them in my RPMs? If you take a peek at http://home.earthlink.net/~noodlez84/rpm_packages.html , I have a devel RPM for every Schilling package I compile. Is this the "right" way? 5. Joerg Schilling: I read your GNU tar rant in the rather lengthy README.otherbugs, and I must say, I agree with you. Even the folks at 'file' know that GNU tar != POSIX tar: linux:~ # file some_gnu_tar_file.tar some_gnu_tar_file.tar: GNU tar archive linux:~ # file some_star_archive.tar some_star_archive.tar: POSIX tar archive BTW, I apologize for the length of this message. -- Karol Pietrzak PGP KeyID: 3A1446A0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
On Sat, 17 Nov 2001, Joerg Schilling wrote:
{ >From: Danilo Godec <[EMAIL PROTECTED]>
{
{ >On Thu, 15 Nov 2001, Karol Pietrzak wrote:
{
{ >> I have created RPMs for the latest cdrtools (now 1.11a11) and
{ >> posted them on my website at
{ >> http://home.earthlink.net/~noodlez84/rpm_packages.html . I have
{ >> been doing this for the last couple of weeks, actually.
{
{ >How about a src.rpm or a spec fiel? I have an alpha platform and I'd like
{ >to build the new cdrtools...
{
{ Do you have any problem?
{
{ I don't understand your statement: cdrtools compiles out of the box
{ on ~ 30 different platforms. Linux/alpha and True64 included
The only thing available on his web site is a i386 binary rpm. What Danilo
would want is a src.rpm (or the spec file to build the src.rpm) so that he
could recompile the src.rpm on his alpha platform and get an alpha.rpm. I
guees that he is using an rpm based linux distribution on his alpha.
Denis
___
Denis Pelletier
Étudiant au doctorat
sciences économiques, Université de Montréal
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
>From: Danilo Godec <[EMAIL PROTECTED]> >On Thu, 15 Nov 2001, Karol Pietrzak wrote: >> I have created RPMs for the latest cdrtools (now 1.11a11) and >> posted them on my website at >> http://home.earthlink.net/~noodlez84/rpm_packages.html . I have >> been doing this for the last couple of weeks, actually. >How about a src.rpm or a spec fiel? I have an alpha platform and I'd like >to build the new cdrtools... Do you have any problem? I don't understand your statement: cdrtools compiles out of the box on ~ 30 different platforms. Linux/alpha and True64 included Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
On Thu, 15 Nov 2001, Karol Pietrzak wrote: > I have created RPMs for the latest cdrtools (now 1.11a11) and > posted them on my website at > http://home.earthlink.net/~noodlez84/rpm_packages.html . I have > been doing this for the last couple of weeks, actually. How about a src.rpm or a spec fiel? I have an alpha platform and I'd like to build the new cdrtools... Hopefully it'll build on RedHat 6.1 ... Thanks, D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
On 16 Nov 2001, Joerg Schilling wrote: > There should be recent rpm's fron RedHat too, but I don't know > the location. Looking at RPMfind.net, the newest RPM is 1.10. > Thank you for the SuSE work. No problem. :) > Well it's a Linux only standard but it is close to that UNIX > systems do... > > How about putting "star" on your list? Sure... I just downloaded the source. I presume ftp://ftp.fokus.gmd.de/pub/unix/star/alpha/star-1.4a08- sspm.tar.gz is the latest version. I am right? > It's bad to see, that currently all Linux systems only have the > non-standard GNU tar while the standard compilant star is > available for a long time. Perhaps I am ignorant, but I always assumed GNU tar _was_ standards complaint. Could you send me a link to the standard you have in mind? -- Karol Pietrzak PGP KeyID: 3A1446A0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools RPM
>From: "Karol Pietrzak" <[EMAIL PROTECTED]> >Hello. >I have created RPMs for the latest cdrtools (now 1.11a11) and >posted them on my website at >http://home.earthlink.net/~noodlez84/rpm_packages.html . I have >been doing this for the last couple of weeks, actually. >I have sent this message because I feel there are many cdrecord >users that go around the 'net looking for an RPM, but can only >find one for cdrecord 1.9 (the latest stable version which most >distributions ship with). There should be recent rpm's fron RedHat too, but I don't know the location. Thank you for the SuSE work. >Joerg Schilling: If you want to, please make the RPM link on >your Freshmeat.net page point to my RPM. >BTW, the RPM is FHS-complaint, because I love standards. Well it's a Linux only standard but it is close to that UNIX systems do... How about putting "star" on your list? It's bad to see, that currently all Linux systems only have the non-standard GNU tar while the standard compilant star is available for a long time. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
