[EMAIL PROTECTED] writes:
My DVD needs get served well by original growisofs and
cdrecord-ProDVD.
So i have not much reason to try any DVD-patched cdrecords yet.
I actually wonder why they live forth.
Some people appear to prefer one tool for one burning needs, without
locking themselves in
Hi,
So i have not much reason to try any DVD-patched cdrecords yet.
I actually wonder why they live forth.
I wondered too and questioned that, and got my head bitten off on the
dvdrtools list
Only good we are virtual entities here.
The blood spill would be immense if we met in real
On Tue, 2006-01-17 at 20:09 +0100, [EMAIL PROTECTED] wrote:
as you
still have to pull a lot of data from disk, you still put quite a
pressure on VM subsystem, so direct I/O can still help,
But how to talk afio, star or mkisofs into that ?
I was thinking that a simple wrapper to open()
[EMAIL PROTECTED] wrote:
Hi,
i nearly gave up the hope to see more growisofs releases.
The release of version 6.0 is good news.
dvd+rw-tools 6.0 are available for download at usual location,
http://fy.chalmers.se/~appro/linux/DVD+RW/. In addition to bug fixes
[most notably for Pioneer
[EMAIL PROTECTED] wrote:
Hi,
How come that the time granularity of the backup processing chain
does not get finer as the systems get faster ?
What do you understand by time granularity?
I see a fifo as a method to smoothen out peaks and gaps in a
input function and to bring
Patrick Ohly wrote:
On Tue, 2006-01-17 at 20:09 +0100, [EMAIL PROTECTED] wrote:
as you
still have to pull a lot of data from disk, you still put quite a
pressure on VM subsystem, so direct I/O can still help,
But how to talk afio, star or mkisofs into that ?
I was thinking
Joerg Schilling wrote:
Thaddeus H. Black [EMAIL PROTECTED] wrote:
This post regards Debian cdrtools cdrecord/cdrecord.c.
It may be old news to you. If so, ignore it; no reply
is needed. If it does interest you, however, please
copy replies to me.
Be careful: Debian publishes a
Because growisofs doesn't do CD, cdrecord doesn't do DVD, and -ProDVD
isn't open source. I find it very nice to have a single tool to burn ISO
images, because then I can write the media type fitted to the data size
without needing multiple tools.
That's why I have used my writecd script
Hi,
Bill Davidsen wrote:
Because growisofs doesn't do CD, cdrecord doesn't do DVD, and -ProDVD
isn't open source. I find it very nice to have a single tool to burn ISO
images, because then I can write the media type fitted to the data size
without needing multiple tools.
Volker
Hi,
I recently introduced a fifo into my growisofs script.
Now it is already obsolete. What a carreer. :))
For a talk I gave on introduction to pthreads I wrote a ring buffer
program with most of the options one could want.
Isn't there anybody in the world who did not make his own fifo
Bill Davidsen [EMAIL PROTECTED] wrote:
Be careful: Debian publishes a bastardized version of cdrtools.
Most problems go away once you convert to the official programs.
There seems to be no open source official program.
Looks like you missunderstood OpenSource and forks.
Even for Open
Bill Davidsen [EMAIL PROTECTED] wrote:
I was thinking that a simple wrapper to open() which adds
O_DIRECT might be sufficient, but it turned out that this
alone is not sufficient: the buffers used by the programs
must have a certain alignment. This is not guaranteed
without modifying the way
Bill Davidsen [EMAIL PROTECTED] wrote:
isn't open source. I find it very nice to have a single tool to burn ISO
images, because then I can write the media type fitted to the data size
without needing multiple tools.
This is why I use cdrecord wherever possible.
And just a note: growisofs
[EMAIL PROTECTED] wrote:
Would there be volunteer testers for a united cdrecord
compatibility wrapper based on libburn for CD and
growisofs for DVD ? (With the funny property to have
TAO-like behavior for DVD and only SAO for CD. Libburn
is only available for x86 Linux 2.4 and 2.6 afaik.)
[EMAIL PROTECTED] wrote:
Hi,
I recently introduced a fifo into my growisofs script.
Now it is already obsolete. What a carreer. :))
For a talk I gave on introduction to pthreads I wrote a ring buffer
program with most of the options one could want.
Isn't there anybody in the
On Sat, Jan 21, 2006 at 11:35:25PM +0100, Joerg Schilling wrote:
Bill Davidsen [EMAIL PROTECTED] wrote:
There seems to be no open source official program.
Looks like you missunderstood OpenSource and forks.
Even for Open Source, there is an Author or a group of authors.
The version that comes
Steve McIntyre [EMAIL PROTECTED] wrote:
And in case you also missunderstood forks: A fork is a _working_ and
_maintained_ modified version of a program. What you see with the
bastardized
cdrtools versions on Linux is neither working nor maintained, it is just
a result of the religion of
On Sun, Jan 22, 2006 at 12:14:55AM +0100, Joerg Schilling wrote:
Steve McIntyre [EMAIL PROTECTED] wrote:
And in case you also missunderstood forks: A fork is a _working_ and
_maintained_ modified version of a program. What you see with the
bastardized
cdrtools versions on Linux is neither
Hi Joerg,
Would there be volunteer testers for a united cdrecord
compatibility wrapper based on libburn for CD and
growisofs for DVD ?
The last time I checked libburn, it was a complete desater.
The first time where a project turned unmaintainable short
after it's creation.
It's not
On Saturday 21 January 2006 19:06, Steve McIntyre wrote:
[...]
--
Steve McIntyre, Cambridge, UK.
[EMAIL PROTECTED] Getting a SCSI chain working is perfectly simple if
you remember that there must be exactly three terminations: one on
one end of the cable, one on
Steve McIntyre [EMAIL PROTECTED] wrote:
Oh, FFS. Give it a rest, Joerg. Most of the work that the various
Linux distro people have done on cdrtools is to fix real bugs that you
won't acknowledge. Sometimes users simply want things to work on their
systems, rather than random Solaris
[EMAIL PROTECTED] wrote:
Let me take the occasion to show to you the due politeness and
respect by informing you in advance about my upcoming cdrecord
compatibility wrapper around libburn: cdrskin .
What kind of advantage should this have?
Cdrecord is opensource and portable to 30
On Sun, Jan 22, 2006 at 01:38:19AM +0100, Joerg Schilling wrote:
Steve McIntyre [EMAIL PROTECTED] wrote:
Please tell me why an unmodified cdrecord runs best on Linux and
why 90% of all bugs on the Debian bug tracking system for cdrtools
are caused by the modifications done by Debian.
Joerg Schilling wrote:
Bill Davidsen [EMAIL PROTECTED] wrote:
I was thinking that a simple wrapper to open() which adds
O_DIRECT might be sufficient, but it turned out that this
alone is not sufficient: the buffers used by the programs
must have a certain alignment. This is not guaranteed
Joerg Schilling wrote:
Bill Davidsen [EMAIL PROTECTED] wrote:
Be careful: Debian publishes a bastardized version of cdrtools.
Most problems go away once you convert to the official programs.
There seems to be no open source official program.
Looks like you missunderstood
Joerg Schilling wrote:
Steve McIntyre [EMAIL PROTECTED] wrote:
And in case you also missunderstood forks: A fork is a _working_ and
_maintained_ modified version of a program. What you see with the bastardized
cdrtools versions on Linux is neither working nor maintained, it is just
a
Joerg Schilling wrote:
[EMAIL PROTECTED] wrote:
Let me take the occasion to show to you the due politeness and
respect by informing you in advance about my upcoming cdrecord
compatibility wrapper around libburn: cdrskin .
What kind of advantage should this have?
Cdrecord is
27 matches
Mail list logo
