[gentoo-user] Re: star

[gentoo-user] Re: star

[Alexander Skwar]

Florian Philipp <f.philipp@addcom.de> wrote:

> What I'd like to know: Is it fully backward compatible to tar? Could I
> safely unmerge tar and make a symlink from tar to star?

star is fully Posix compliant. GNU tar is not. In theory, there could
be problems with GNU tar tar archives if they are unpacked using star.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

Florian Philipp <f.philipp@addcom.de> wrote:

> star supports p7zip which can be much better and especially more
> flexible than bzip2, gzip and zip.

Uhm, what's bad about

        tar cf - | p7zip ....

> If star were a fully qualified replacement for gnu tar, there would not
> have been the need to keep it 

To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
have star: Star is made by Jörg Schilling, one of the biggest morons
on the earth. Guess why some distributions no longer use cdrecord but
switched to cdrkit?

> I used find and grep to search for any implementations of tar
> compressing to stdout - I couldn't find any.

What do you mean?

> I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
> to /bin/tar.
> 
> Let's see if it works.

Command line options aren't identical. I wouldn't wonder if you run
into problems.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:
> On Samstag, 22. September 2007, Florian Philipp wrote:

>> star supports p7zip which can be much better and especially more
>> flexible than bzip2, gzip and zip. Its other features (better
>> funcionality for acl, sparse files, recovery and backups among other
>> things) didn't sound bad, either.
> 
> I don't know - bzip2 is very good at 'recovery' because only the affected
> block is lost.

True - in theory. It doesn't help you much, if you lose a block in a
.tar.bz2 file, as the block sizes of bzip2 and tar won't overlap. Thus,
something like ".bz2.tar" would be better, meaning a tar which contains
pre compressed files. Granted, compression ratio would be worse.

If you want safety, I'd either suggest afio or maybe something like
par.

> and if p7zip supports pipes, you don't need its support in tar. Just pipe
> from/to it.

It does and that's the way it's supposed to be used on unix, according
to its manpage.

> as you can see, you need to play around with pipes anyway when you use
> star. So switching just because of one compression algo and become
> incompatible with the way emerge unpacks packages sounds pretty stupid
> IMHO.

ACK

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Florian Philipp]

Alexander Skwar schrieb:
> Florian Philipp <f.philipp@addcom.de> wrote:
> 
>> star supports p7zip which can be much better and especially more
>> flexible than bzip2, gzip and zip.
> 
> Uhm, what's bad about
> 
>         tar cf - | p7zip ....

It's a bit cumbersome to create a pipe each time I access an archive.
Well, I think I'll create a shell script or an alias for that.

> 
>> If star were a fully qualified replacement for gnu tar, there would not
>> have been the need to keep it 
> 
> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
> have star: Star is made by Jörg Schilling, one of the biggest morons
> on the earth. Guess why some distributions no longer use cdrecord but
> switched to cdrkit?
> 
>> I used find and grep to search for any implementations of tar
>> compressing to stdout - I couldn't find any.
> 
> What do you mean?
> 
Just that I used regular expressions to search for tar writing to
stdout, something that star can't, apparently. It seems it didn't work.
Not all but some emerge actions failed while using star.

>> I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
>> to /bin/tar.
>>
>> Let's see if it works.
> 
> Command line options aren't identical. I wouldn't wonder if you run
> into problems.
> 
Well, most are. I ran into problems anyway (see above). So, I'm back to
gnu tar.



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Stroller]

On 24 Sep 2007, at 09:30, Alexander Skwar wrote:
> ...
>> and if p7zip supports pipes, you don't need its support in tar.  
>> Just pipe
>> from/to it.
>
> It does and that's the way it's supposed to be used on unix, according
> to its manpage.

GNU tar features the -j, -z and -Z options. These are much more  
convenient than piping, and it would be nice to see p7zip supported  
in the same way.

Stroller.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

b.n. <brullonulla@gmail.com> wrote:

> Alexander Skwar ha scritto:
>> Stroller <stroller@stellar.eclipse.co.uk> wrote:
>> 
>>> On 24 Sep 2007, at 09:30, Alexander Skwar wrote:
>>>> ...
>>>>> and if p7zip supports pipes, you don't need its support in tar.
>>>>> Just pipe
>>>>> from/to it.
>>>> It does and that's the way it's supposed to be used on unix, according
>>>> to its manpage.
>>> GNU tar features the -j, -z and -Z options.
>> 
>> Yes, bad, isn't it? These options are not part of the Posix standard.
>> It would be good, if these superflous options wouldn't be present at
>> all. I say "superflous", as pipes work just fine.
> 
> It's not that an option becomes "bad" just because it's not carved into
> the POSIX standard.

To a degree, it is.

> What's important, I guess, is that tar is  
> POSIX-compliant, so that if you want, you can build POSIX-compliant
> scripts etc. ,

Depends. On the hand, you're right. But if non-compliant options
exist, people tend to use them. That's bad in so far, as they get
used to non-standard behaviour. That's especially bad, as standard
compliants solution exist.

> but I can't see how non-POSIX but handy extensions could 
> be bad. 

Let me give you a different example, although it has nothing
to do with POSIX.

Internet Explorer translates a \ in a URL to /. That's a non
standard compliant behaviour. Now, as many people (still *G*)
use IE, many people rely on that mis-behaviour of IE and make
it hard for non-misbehaving browsers (ie. Mozilla) to display
the content.

What does this have to do with GNU tar and it adding superflous
options? Quite a lot. -j et.al. are non-standard options. If a
(badly written) script relies on the presence of -j, this script
won't work with a POSIX compliant tar (like star or any Unix
tar (eg. Sun, HP, ...)). Is that bad? Yes, it is. It is bad, as
there's an easily accessible solution to this problem available:
Use pipes! In this case, the solution would be: 

        tar cf - dir | bzip2 > dir.tar.bz2
        tar cf - dir | 7z a -si dir.tar.7z

Or for decompression:

        bzcat dir.tar.bz2 | tar xf -
        7z x -so dir.tar.7z | tar xf -

> Maybe it's me not seeing the problem.

Yep.

> Maybe the POSIX standard  
> could just be extended as well. :)

Equally fine.

>>> and it would be nice to see p7zip supported
>>> in the same way.
>> 
>> No.
> 
> "No" means nothing. Tell us why.

Pipes exist. The current "integration" of 7-zip is fine. There's
no need to integrate other compression into tar. Actually, there's
no need at all to integrate ANY compression alg. into tar.

Furthermore, especially with 7zip, an integration into tar would
make the use of 7zip somewhat limited, as all of the additional
command line options of 7z would not be accessible anymore.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Tue, 25 Sep 2007 15:34:41 +0200, Alexander Skwar wrote:

> What does this have to do with GNU tar and it adding superflous
> options? Quite a lot. -j et.al. are non-standard options. If a
> (badly written) script relies on the presence of -j, this script
> won't work with a POSIX compliant tar

The script is only badly written if it is supposed to be POSIX
compliant. Additional features can enhance a program and make scripts
using it more readable/efficient/compact, providing the environment does
not require POSIX-compliance. e.g. portage can use tar-specific
enhancements if tar is in system on all profiles. 


-- 
Neil Bothwick

If at first you don't succeed, you'll get a lot of free advice from
folks who didn't succeed either.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: star

[Michael Schreckenbauer]

Am Montag, 24. September 2007 schrieb Alexander Skwar:
> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
> have star: Star is made by Jörg Schilling, one of the biggest morons
> on the earth. Guess why some distributions no longer use cdrecord but
> switched to cdrkit?

Keep your private rants offlist please. Your personal opinions on Jörg 
Schilling are completly irrelevant.

Regards,
Michael

--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[b.n.]

Michael Schreckenbauer ha scritto:
> Am Montag, 24. September 2007 schrieb Alexander Skwar:
>> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
>> have star: Star is made by Jörg Schilling, one of the biggest morons
>> on the earth. Guess why some distributions no longer use cdrecord but
>> switched to cdrkit?
> 
> Keep your private rants offlist please. Your personal opinions on Jörg 
> Schilling are completly irrelevant.

I agree it was not a nice rant, but it's not an irrelevant opinion,
because Schilling -let's say- idiosyncratic personality, has led, as
Alexander pointed out, to the disapperance of cdrecord from most Linux
distros and its substitution with cdrkit, for example.

The problem is that of a tool that for licence etc. problems could be
easily be dropped from a distribution. It's of a relatively unreliable
developer (or, better stated, of unrealiable relationships between the
dev and the community). Given this, I would think twice before
substituting tar with a Schilling tool. The cdrecord scar is still painful.

m.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

Neil Bothwick <neil@digimed.co.uk> wrote:

> Hello Alexander Skwar,
> 
>> Yes, it's very bad that Gentoo scripts don't limit themselves to
>> POSIX. Another windmill to fight against.
> 
> Artificially limiting yourself to the lowest common denominator when
> better options are available is bad, and discourages evolution.

Well, depends.

Making use of non standard options when standard compliant
options are avialable, is no-good evolution. It very much
tastes of the way Microsoft handles standards. Eg. have a
look at how MS treated Java or HTML (granted, Netscape wasn't
much better either).

Back to tar: Why use "tar -j" in scripts, when "bzip2 | tar"
does the same thing? I very much disagree that "tar -j" is
the "better" option here; in fact, I'd say that "bzip2 | tar"
is the better option, as it works on a lot more systems than
"tar -j" does. Heck, "tar -j" even does not work on all GNU
tar implementations, as very old GNU tars don't have bzip2
support at all and -j wasn't always used for bzip2.

> POSIX 
> specifies the minimum set of options and features, not the maximum. As
> long as the standards aren't broken, nothing is wrong, and adding new,
> useful and compatible features is one way that standards get improved.

No, it's not. To improve a standard, you make sure that the standard
gets amended and then you implement something. Not the other way around.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Wed, 26 Sep 2007 10:14:58 +0200, Alexander Skwar wrote:

> Back to tar: Why use "tar -j" in scripts, when "bzip2 | tar"
> does the same thing? I very much disagree that "tar -j" is
> the "better" option here;

Either way requires that you first determine the type of compression used
before you can decide where to pipe tar's output, if at all. Whereas
something like "tar xf somefile" avoids the need to do" file somefile"
and parse the output first.

> in fact, I'd say that "bzip2 | tar"
> is the better option, as it works on a lot more systems than
> "tar -j" does. Heck, "tar -j" even does not work on all GNU
> tar implementations, as very old GNU tars don't have bzip2
> support at all and -j wasn't always used for bzip2.

If you don't know the details of the platform running your script, you
should of course stick to POSIX, which tar can do fine. But if your
script in running in an environment you control, why not make use of more
efficient methods?


> > POSIX 
> > specifies the minimum set of options and features, not the maximum. As
> > long as the standards aren't broken, nothing is wrong, and adding new,
> > useful and compatible features is one way that standards get
> > improved.  
> 
> No, it's not. To improve a standard, you make sure that the standard
> gets amended and then you implement something. Not the other way around.

That's not how evolution works. Things are tried, some (most) fall by the
wayside and others are accepted. As long as you don't break the standard
with your enhancements, where's the harm in improvement? I know car
analogies are tired, but it's like arguing that all cars should be
designed to meet the minimum standards required by law, and if the law
doesn't stipulate air conditioning, we don't need it - that example is
usually true here in the UK :(


-- 
Neil Bothwick

The fact that no one understands you doesn't mean you're an artist.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: star

[Michael Schreckenbauer]

Am Mittwoch, 26. September 2007 00:26:51 schrieb b.n.:
> Michael Schreckenbauer ha scritto:
> > Am Montag, 24. September 2007 schrieb Alexander Skwar:
> >> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
> >> have star: Star is made by Jörg Schilling, one of the biggest morons
> >> on the earth. Guess why some distributions no longer use cdrecord but
> >> switched to cdrkit?
> >
> > Keep your private rants offlist please. Your personal opinions on Jörg
> > Schilling are completly irrelevant.
>
> I agree it was not a nice rant, but it's not an irrelevant opinion,
> because Schilling -let's say- idiosyncratic personality, has led, as
> Alexander pointed out, to the disapperance of cdrecord from most Linux
> distros and its substitution with cdrkit, for example.

and I for myself drop cdrkit in every place I find it and replace it with the 
imo working tool named cdrecord. 

> The problem is that of a tool that for licence etc. problems could be
> easily be dropped from a distribution. It's of a relatively unreliable
> developer (or, better stated, of unrealiable relationships between the
> dev and the community).

I have no problems at all with Jörg, quite the opposite.

> Given this, I would think twice before 
> substituting tar with a Schilling tool. The cdrecord scar is still painful.

Good programmers often have big egos. See Linus for an example. When will 
distributions drop the kernel, because Linus made bad comments about gnome, 
cups or some other random program?
The tool (star, cdrecord) works, is well supported and the programmer reacts 
in time to requests. What else do you expect?

> m.

Greetings,
Michael
--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[b.n.]

Michael Schreckenbauer ha scritto:
> and I for myself drop cdrkit in every place I find it and replace it with the 
> imo working tool named cdrecord. 

Sure, your choice.

>> The problem is that of a tool that for licence etc. problems could be
>> easily be dropped from a distribution. It's of a relatively unreliable
>> developer (or, better stated, of unrealiable relationships between the
>> dev and the community).
> 
> I have no problems at all with Jörg, quite the opposite.

It's not *you* that has to have problems with him. It's distributions.
See below.

>> Given this, I would think twice before 
>> substituting tar with a Schilling tool. The cdrecord scar is still painful.
> 
> Good programmers often have big egos. See Linus for an example. When will 
> distributions drop the kernel, because Linus made bad comments about gnome, 
> cups or some other random program?
> The tool (star, cdrecord) works, is well supported and the programmer reacts 
> in time to requests. What else do you expect?

The problem with cdrecord (and J.S.) is that in a new version of
cdrecord he bundled CDDL and GPL code together, thinking that it's right
to distribute such an hybrid binary.
Debian and a large number of other distros think instead that you cannot
legally distribute a CDDL+GPL hybrid thing. So, to avoid legal concerns,
they had to remove cdrecord from the distribution and fork the last GPL
(or CDDL?)-only version of cdrecord.

In our case: if you use a tool like that in your scripts and suddenly
the Gentoo devs feel that tool has to be removed/replaced (not the case
of cdrtools in Gentoo apparently, but...), you are in trouble. It's not
matter of who is right/who is wrong (I personally have no serious
opinion on that, because I didn't enter into the issue), but J.S.
refused any attempt to settle down the problem with the Linux
distribution, only putting blame on them and telling them "oh who cares,
f**k you". That's why someone has harsh opinions on him and can't trust
relying on his tools.

OTOH, I agree he's a truly skilled developer.

m.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Wed, 26 Sep 2007 19:44:20 +0200, b.n. wrote:

> In our case: if you use a tool like that in your scripts and suddenly
> the Gentoo devs feel that tool has to be removed/replaced (not the case
> of cdrtools in Gentoo apparently, but...), you are in trouble.

In this case, that shouldn't be a problem, because the cdrkit ebuild
installs cdrecord and mkisofs as symlinks to wodim and genisoimage
respectively.


-- 
Neil Bothwick

Top Oxymorons Number 41: Good grief

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: star

[b.n.]

Hi Joerg,

Quite an honour to receive a mail from you. :)

> The reason why Debian started this is the missing will for quality oriented
> cooperation by a single person: "Eduard Bloch".
> 
> The reason why other Linux distributions followed Debian is that they believed
> the lies spread by Eduard Bloch.
>
> I see a good cooperation with 99.99% of the Linux commuinity but there are some
> Trolls who attack me. It seems that once you do a lot of work, some people 
> become jealous and start to attack you. Doing popular things seems to imply 
> that you become the target of attacks.

I didn't follow the whole licence issue, nor I don't care that much
about that (I was just explaining what I know from the Internet). The
problem, as it seemed, is that you and Bloch staunchly refused to settle
down the issue somehow. Please correct me if it's wrong.

But I don't buy the "people that attack me is just jealous/trolling"
argument, sorry. Assuming good faith is always better. To tell "I'm
right and B is lying" is quite trollish too. To tell "I'm right, B
probably hasn't understood that..." is another thing. And trying to do
baby steps each in the direction of the other should always be strived
for. It seems in this case that both failed to do that. Personally I'd
have stepped down on licence issues if that meant more distribution for
my code, but I'm not a serious programmer so I don't know if it holds
for larger projects. However I'll have to review ye old flamewar to
understand the issue.

The problem, however, is that -being it your fault or not- that incident
somehow made hard for some people to rely on your tools. :(

> I am frequently meeting with Linux (and other OSS) people and I get frequent
> invitations as speaker on Linux events. Noone from the people who attack me 
> did ever meet me.....

Well, what does it mean?

m.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Joerg Schilling]

"b.n." <brullonulla@gmail.com> wrote:

> > The reason why Debian started this is the missing will for quality oriented
> > cooperation by a single person: "Eduard Bloch".
> > 
> > The reason why other Linux distributions followed Debian is that they believed
> > the lies spread by Eduard Bloch.
> >
> > I see a good cooperation with 99.99% of the Linux commuinity but there are some
> > Trolls who attack me. It seems that once you do a lot of work, some people 
> > become jealous and start to attack you. Doing popular things seems to imply 
> > that you become the target of attacks.
>
> I didn't follow the whole licence issue, nor I don't care that much
> about that (I was just explaining what I know from the Internet). The
> problem, as it seemed, is that you and Bloch staunchly refused to settle
> down the issue somehow. Please correct me if it's wrong.

Mr. Bloch started several attacks against the cdrtools project and he did this 
in an extremely unfair way. He spread unproven and untrue claims about cdrtools.

> But I don't buy the "people that attack me is just jealous/trolling"
> argument, sorry. Assuming good faith is always better. To tell "I'm
> right and B is lying" is quite trollish too. To tell "I'm right, B

If I was not informed about the background I may have thought in a similar way.

But please tell me what you would do if you have been attacked in an unfair way?

It is usual not to believe unproven claims, but why do so many people believe
the unproven claims from Mr. Bloch? The problem with all the attacks was that 
the people around Mr. Bloch spread vague unproven claims as usual in 
calumniation campaigns. When asked to prove their claims, they either started
with new vague attacks or stopped answering. This would not be a problem if 
people would not believe unproven claims.....

The real reason behind the attacks from Mr. Bloch is missing will for 
cooperation. As he did not like this to be in relation with his name, he started
to spread the fairy tale about "license problems".

Interestingly, Eben Moglen (law professor) says that what cdrtools do is OK in 
general. Lawyers asked by distributors of the original cdrtools say that there
is no problem in special. Some people still believe the "legal opinion" from a 
laymen like Mr. Bloch.


> The problem, however, is that -being it your fault or not- that incident
> somehow made hard for some people to rely on your tools. :(

You cannot rely on the fork because it is full of bugs that never have been 
in the original software and because no bugs are fixed since nearly 6 months.

You cannot rely on it because it has been initiated by people who attack free 
software.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Joerg Schilling]

Let me try to give some information on star

star by default writes to stdout and already supports 7z compression
including auto-format/comression detection. You need to install a working 
"p7zip" in your PATH.

Star is 100% compatible to tar, a big problem is that GNU tar is not 100%
compatible to tar.

Star is not only a TAR archiver but a complete solution.

-	Star is an archiver library supports the most important archive 
	formats: 

	-	OLD UNIXv7 tar
	-	OLD BSD tar
	-	POSIX-1.1988 TAR
	-	POSIX-1.2001 TAR
	-	CPIO
	-	the old star format from 1985 (the first tar with special
		file support)
	-	Star extensions on POSIX-1.1988 TAR
	-	Star extensions on POSIX-1.2001 TAR - this include _working_
		incremental dump/restore

-	Star's upper layer supports several CLI variants depending on av[0]:

	-	Star - the UNIX compatible CLI that star introduced in 1982
		under the name "star", all features of all archiveers are
		available.
	-	TAR - the SUSv2 (UNIX-98) TAR CLI
	-	gtar - all useful features of GNU tar 1.14
	-	pax - the POSIX archiver
	-	cpio - the SUSv2 (UNIX-98) cpio CLI

-	Star has a built in find(1) that works in archive/extract/list/copy
	mode. It helps to make star very powerful as this find includes
	-chown/-chgrp/-ghmod to on-the-fly change incore information during
	archive processing.

-	Star implements highly optimized buffering for optimum I/O thoughput

-	Star typically needs 1/3 of the user CPU time than GNU tar

-	Star supports fully correct archiving of sparse files if the OS
	supports to read the hole list.

-	Star supports ACLs in an OS independent way.

-	Star supports Linux specific features (like file flags and XATTR).
	GNU tar does not implement a single Linux specific feature.

-	Star implementes ~ 2x as many features as GNU tar does.

-	The star archive format extensions are fully documented.

For more information see http://cdrecord.berlios.de/old/private/star.html

The main problem on many Linux distributions is that they do not actively
maintain recent star packages.

If you believe that star called as "tar" does not behave correctly (as decribed
in http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html, send me a report!


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

· Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
> "b.n." <brullonulla@gmail.com> wrote:

>> But I don't buy the "people that attack me is just jealous/trolling"
>> argument, sorry. Assuming good faith is always better. To tell "I'm
>> right and B is lying" is quite trollish too. To tell "I'm right, B
> 
> If I was not informed about the background I may have thought in a similar way.
> 
> But please tell me what you would do if you have been attacked in an unfair way?

If *YOU* are attacked, it's mostly not unfair. There's most certainly
some prior history. Most of the time, you attacked other people first.

> It is usual not to believe unproven claims, but why do so many people believe
> the unproven claims from Mr. Bloch? 

Maybe, just maybe, it's because of how you are?

> The problem with all the attacks was that  
> the people around Mr. Bloch spread vague unproven claims as usual in 
> calumniation campaigns. When asked to prove their claims, they either started
> with new vague attacks or stopped answering.

*LOL*

You've got the nerve to say that? When you, Jörg, post to Usenet and
use Umlauts, your client neglects to add the necessary headers. You've
been asked more than once by numerous people to prove your claim, that
what you're doing is correct.

>> The problem, however, is that -being it your fault or not- that incident
>> somehow made hard for some people to rely on your tools. :(
> 
> You cannot rely on the fork because it is full of bugs 

Works good enough for me.

> that never have been  
> in the original software and because no bugs are fixed since nearly 6 months.

Latest *RELEASE* was at  2007/05/06. Latest *RELEASE* of cdrecord
is dated 09.09.2004.

> You cannot rely on it because it has been initiated by people who attack free 
> software.

You're talking about cdrecord?

Alexander Skwar
-- 
Death is a spirit leaving a body, sort of like a shell leaving the nut behind.
                -- Erma Bombeck


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Joerg Schilling]

> > that never have been  
> > in the original software and because no bugs are fixed since nearly 6 months.
>
> Latest *RELEASE* was at  2007/05/06. Latest *RELEASE* of cdrecord
> is dated 09.09.2004.

There was a typo, it's 5 not 6 months.

Latest release cdrtools: September 3rd. Number of cdrtools releases since
May 6th (the last release for cdrkit): 9.

Age of cdrtools: 12 years
Age of wodim: 12 months

If cdrtools was as "active" as cdrkit, the last release was 5 years ago.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-- 
gentoo-user@gentoo.org mailing list