ubuntu 10.10rc-desktop-i386 zu groß für 700MB-Rohling
Andreas Leitgeb
zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft, merkt zwar
eh, dass es nicht gepasst hat - nur halt eben erst danach.
Der cdrecord(wodim) hat mich jedenfalls *nicht* davor gewarnt, dass
das image zu groß für den rohling ist, und selbst danach keine Meldung
dazu geschrieben.
Was mich aber viel mehr überrascht hat ist, dass das feature
"CD/DVD prüfen" im Bootmenu diesen Brennfehler ebenfalls nicht erkannt hat!
Die Installation ist dann allerdings nach ca 80% (augenmass am progressbar)
mit einem I/O-Error abgebrochen, also kommt es offenbar auch auf die letzten
100kb noch an.
Clemens Schueller
> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
> zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft, merkt zwar
> eh, dass es nicht gepasst hat - nur halt eben erst danach.
Irnkwas läuft da schief, denn ich kann mir nicht vorstellen, das
canonical ein ISO rausbläst, welches nicht auf einen Rohling passt.
> Der cdrecord(wodim) hat mich jedenfalls *nicht* davor gewarnt, dass
> das image zu groß für den rohling ist, und selbst danach keine Meldung
> dazu geschrieben.
Hast Du es schon mal mit dem Original cdrecord
(ftp://ftp.berlios.de/pub/cdrecord/cdrtools-3.00.tar.bz2) versucht?
Version 3.00 hat viele neue Features eingebaut, während wodim auf einer
uralten Version der cdrtools basiert
GreetinX, Clemens Schueller
Andreas Leitgeb
> Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
> Irnkwas läuft da schief, denn ich kann mir nicht vorstellen, das
> canonical ein ISO rausbläst, welches nicht auf einen Rohling passt.
Hast recht, es lag nicht an der iso-Größe.
Hab's dann noch mit einem 800MB-Rohling probiert, und auf dem ist
es jetzt auch abgeschnitten drauf :-(
Neuer Verdächtiger: das Laufwerk (naja, LG halt), obwohl ich damit
schon viel gebrannt habe, und es bisher eigentlich immer ganz gut
funktionierte, aber vl waren die bisherigen images ja stets um das
Äutzerl kleiner...
Werd's demnächst noch mit einem anderen Laufwerk probieren...
PS: das originale cdrtools-cdrecord ist bei Ubuntu nicht dabei
(iirc, weil J.Sch.'s Interpretation der GPL nicht mit anderen
Interpretationen kompatibel war, oder so ähnlich)
Ich denke mir, eine Ubuntu-x CD sollte sich zumindest mit den bord-
mitteln von Ubuntu-(x-1) brennen lassen. - ausser, natürlich, wenn
die HW hinnig ist.
Clemens Schueller
> Clemens Schueller <cs.usene...@aon.at> wrote:
>> Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
>>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
>>> zu groß für einen 700MB-Rohling. ...
>> Irnkwas läuft da schief, denn ich kann mir nicht vorstellen, das
>> canonical ein ISO rausbläst, welches nicht auf einen Rohling passt.
>
> Hast recht, es lag nicht an der iso-Größe.
>
> Hab's dann noch mit einem 800MB-Rohling probiert, und auf dem ist
> es jetzt auch abgeschnitten drauf :-(
>
> Neuer Verdächtiger: das Laufwerk (naja, LG halt), obwohl ich damit
> schon viel gebrannt habe, und es bisher eigentlich immer ganz gut
> funktionierte, aber vl waren die bisherigen images ja stets um das
> Äutzerl kleiner...
Es muss nicht zwangsläufig am LW liegen - siehe unten.
> Werd's demnächst noch mit einem anderen Laufwerk probieren...
oder mit einem anderen 700MB Rohling (die 800er sind IIRC nicht
standardkonform).
> PS: das originale cdrtools-cdrecord ist bei Ubuntu nicht dabei
> (iirc, weil J.Sch.'s Interpretation der GPL nicht mit anderen
> Interpretationen kompatibel war, oder so ähnlich)
> Ich denke mir, eine Ubuntu-x CD sollte sich zumindest mit den bord-
> mitteln von Ubuntu-(x-1) brennen lassen. - ausser, natürlich, wenn
> die HW hinnig ist.
Das ist mir durchaus bekannt, dass das Original _NICHT_ bei ubuntu
mitgeliefet wird. Sollte aber kein Problem sein, es aus den Sourcen zu
compilen. Die Binaries liegen dann іn /opt/schily/bin.
Alte Brennprogramme neigen IIRC dazu, sich an neueren Brennern zu
"verhackeln", da sie die Optimierungen auf den gerade verwendeten
Rohling nicht kennen (woher auch?)
GreetinX, Clemens Schueller
Andreas Leitgeb
>>>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
>>>> zu groß für einen 700MB-Rohling. ...
>>> Irnkwas läuft da schief, denn ich kann mir nicht vorstellen, das
>>> canonical ein ISO rausbläst, welches nicht auf einen Rohling passt.
>> Hast recht, es lag nicht an der iso-Größe.
>> Hab's dann noch mit einem 800MB-Rohling probiert, und auf dem ist
>> es jetzt auch abgeschnitten drauf :-(
>> Neuer Verdächtiger: das Laufwerk (naja, LG halt), obwohl ich damit
>> schon viel gebrannt habe, und es bisher eigentlich immer ganz gut
>> funktionierte, aber vl waren die bisherigen images ja stets um das
>> Äutzerl kleiner...
> Es muss nicht zwangsläufig am LW liegen - siehe unten.
Anderer PC (mit ubuntu 9.10 drauf), anderes Laufwerk, gleicher Fehler.
Und das, obwohl die images z.B. von 8.10 und 9.04 sogar noch größer
waren.
Ich möcht schwören, dass ich mit derselben Brenn-software seit ihrem
ctime-datum: (2010-01-14 12:19 /usr/bin/wodim) auf diesem System schon
erfolgreich größere images gebrannt habe.
Bin gerade etwas ratlos.
Ob es mit cdrtools-3.0 geht habe ich noch nicht probiert, da mich zum
jetzigen Zeitpunkt noch mehr interessiert, warum es mit wodim auf
unveränderter HW plötzlich *nicht mehr* geht, als irgendwie-anders
eine korrekte CD zu bekommen.
Clemens Schueller
Wie schon erwähnt: Hast einen anderen Rohling probiert (evtl. zuerst mal
mit einer Simulation)?
GreetinX, Clemens Schueller
Gerhard Reithofer
On Mon, 4 Oct 2010, Andreas Leitgeb wrote:
> Clemens Schueller <cs.usene...@aon.at> wrote:
> >>>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
...
> Anderer PC (mit ubuntu 9.10 drauf), anderes Laufwerk, gleicher Fehler.
> Und das, obwohl die images z.B. von 8.10 und 9.04 sogar noch größer
> waren.
>
> Ich möcht schwören, dass ich mit derselben Brenn-software seit ihrem
> ctime-datum: (2010-01-14 12:19 /usr/bin/wodim) auf diesem System schon
> erfolgreich größere images gebrannt habe.
>
> Bin gerade etwas ratlos.
>
> Ob es mit cdrtools-3.0 geht habe ich noch nicht probiert, da mich zum
> jetzigen Zeitpunkt noch mehr interessiert, warum es mit wodim auf
> unveränderter HW plötzlich *nicht mehr* geht, als irgendwie-anders
> eine korrekte CD zu bekommen.
Evtl. Image kaputt?
Mounts mal als loop-dev und versuch die Dateien zu kopieren.
--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
David Wührer
> PS: das originale cdrtools-cdrecord ist bei Ubuntu nicht dabei
> (iirc, weil J.Sch.'s Interpretation der GPL nicht mit anderen
> Interpretationen kompatibel war, oder so ähnlich)
Schilling hat Debian explizit verboten, seine Software zu verwenden, weil
die ohne seine Zustimmung gepatcht haben, deshalb können die nur ältere
Versionen verwenden, und Ubuntu verwendet ja für das meiste die Quellen von
Debian.
> Ich denke mir, eine Ubuntu-x CD sollte sich zumindest mit den bord-
> mitteln von Ubuntu-(x-1) brennen lassen. - ausser, natürlich, wenn
> die HW hinnig ist.
Sollte man erwarten.
Wäre ein USB-Stick eine mögliche Alternative?
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
>zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft, merkt zwar
>eh, dass es nicht gepasst hat - nur halt eben erst danach.
>
>Der cdrecord(wodim) hat mich jedenfalls *nicht* davor gewarnt, dass
>dazu geschrieben.
Hättest Du wirklich cdrecord verwendet, dann wärst Du gewarnt worden, zumindest
wenn die mangelnde Kapazität des Rohlings und nicht ein Schreibfehler durch
mangelnde Rohlingskapazität die wirkliche Ursache ist.
wodim basiert auf einer cdrecord Version vom September 2004, in die dann
zusätzliche Fehler eingebaut wurden, z.B. wurden diverse Warnungen ausgebaut
und der seit Februar 1998 gut funktionierende Original DVD Supportcode entfernt
und durch einen halbfertigen Eigenbau der Verantwortlichen ersetzt.
Seit dem 5. Mai 2006 passiert gar nichts mehr bei wodim, abgesehen von
gelegentlichen kleinen Tippfehlerkorrektueren und dem Austausch eines Bugs
durch einen anderen.
Sieh Dir doch mal das aktuelle Original an: ftp://ftp.berlios.de/pub/cdrecord/
Version 3.00 kam im Sommer heraus.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling
Clemens Schueller <cs.usene...@aon.at> wrote:
>Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
>
>
>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
>> zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft, merkt zwar
>> eh, dass es nicht gepasst hat - nur halt eben erst danach.
>
>Irnkwas läuft da schief, denn ich kann mir nicht vorstellen, das
>canonical ein ISO rausbläst, welches nicht auf einen Rohling passt.
Auf einen 80 Minuten Rohling passen 737280000 Bytes.
Was die wirkliche Ursache ist, kann man ohne Kenntnis des Rohlingherstellers
(cdrecord -atip) und des Fehlers nicht entscheiden.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Clemens Schueller <cs.usene...@aon.at> wrote:
>> Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
>>> zu groĂź fĂĽr einen 700MB-Rohling. ...
>> Irnkwas läuft da schief, denn ich kann mir nicht vorstellen, das
>> canonical ein ISO rausbläst, welches nicht auf einen Rohling passt.
>
>Hast recht, es lag nicht an der iso-Größe.
>
>Hab's dann noch mit einem 800MB-Rohling probiert, und auf dem ist
>es jetzt auch abgeschnitten drauf :-(
Ohne Fehlermeldung keine Hilfsmöglichkeit.
>PS: das originale cdrtools-cdrecord ist bei Ubuntu nicht dabei
> (iirc, weil J.Sch.'s Interpretation der GPL nicht mit anderen
> Interpretationen kompatibel war, oder so ähnlich)
Das ist deshalb so, weil Mark Shuttleworth lieber einen ungewarteten
illegalen Fork verteilt, als legale Originalsoftware. Sun verhält sich da
anders als Ubuntu und befragt Fachanwälte, die zur Verwendung der
Originalsoftware raten. Meine Interpretation der GPL stimmt übrigens mit
der Interpretation aller Juristen überein, die sich bislang zu dem Thema im
Netzt mit belegten Aussagen geäußert haben.
Siehe z.B. auch: www.osscc.net
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Ob es mit cdrtools-3.0 geht habe ich noch nicht probiert, da mich zum
>jetzigen Zeitpunkt noch mehr interessiert, warum es mit wodim auf
>unveränderter HW plötzlich *nicht mehr* geht, als irgendwie-anders
>eine korrekte CD zu bekommen.
Durch den Ausbau diverser Sicherheitsabfragen wurde wodim auch unzuverlässiger.
Joerg Schilling
David =?UTF-8?B?V8O8aHJlcg==?= <d...@gmx.at> wrote:
>Andreas Leitgeb wrote:
>> PS: das originale cdrtools-cdrecord ist bei Ubuntu nicht dabei
>> (iirc, weil J.Sch.'s Interpretation der GPL nicht mit anderen
>
>Schilling hat Debian explizit verboten, seine Software zu verwenden, weil
>Versionen verwenden, und Ubuntu verwendet ja für das meiste die Quellen von
>Debian.
Das ist Unsinn!
Debian ist ein feindlicher Distributor, der OSS Autoren und Programme angreift
und darüberhinaus darauf besteht defekte Versionen verbreiten zu wollen.
Debian hat im Mai 2004 zuerst einen völlig defekten UTF-8 Patch für mkisofs
eingebaut und mich und meine Projekte danach massiv und ohne Grund angegriffen.
Später wurden dann durch Debian Lügen über angebliche Lizenzverstöße durch
mich verbreitet.
Jede größere Institution hat schwarze Schafe, so auch Debian. Das Problem bei
Debian ist, daß sie keine Kraft haben sich von ihren schwarzen Schafen zu
reinigen.
Wolfgang Zweimueller
> H\344ttest Du wirklich cdrecord verwendet, dann w\344rst Du gewarnt
> worden, zumindest
[...]
Und würdest du endlich mal deinem Newsreader beibringen Encodings
richtig zu deklarieren, dann könnte man deine Absonderungen auch
lesen. Und spar dir deswegen bitte an anderer Stelle über UTF-8 und
Debian herzuziehen.
Wolfgang
Josef M. Werner
Bei dem Querulanten ist Hopfen und Malz verloren.
--
Jo
Andreas Leitgeb
>> Hab's dann noch mit einem 800MB-Rohling probiert, und auf dem ist
>> es jetzt auch abgeschnitten drauf :-(
So ging's mir auch: Die Brennsoftware - sowohl wodim als auch cdrskin -
haben eben *keine* Fehlermeldungien geschrieben. Deren Output zufolge ist
alles perfekt gelaufen.
Nur, wenn ich dann die CD auswerfe, neu einlege und
dd if=/dev/cdrom bs=2k | md5sum
mache, sagt mir dd am ende einen I/O-Error und eine (gegenueber einer
korrekten CD) zu kleine Anzahl gelesener Bytes. (klarerweise ist die
md5sum dann auch eine andere)
Ich habe mir heute neue Rohlinge (CD-R und CD-RW) gekauft, und
experimentiere wieder weiter...
Auf einem anderen Rechner habe ich zuletzt auch das original
cdrtools-3.0 vom berlios server heruntergeladen&compiliert, was dann
aber noch weniger funktionierte - der Brennvorgang brach gleich ganz
am Anfang ab, mit u.a. dieser Zeile:
Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
(derselbe typ von Rohling am selben Laufwerk wurde von wodim zu 99%
bebrannt, es fehlten dann eben nur die letzten ca 100 kilobyte - das
Problem, weswegen ich diesen Thread startete)
Das war ein Platinum 800MB CD-R Rohling, von dem ich jetzt nur noch
wenige uebrig habe, die aber frueher tadellos (unter linux mit cdrecord)
funktionierten. Die komplette Ausgabe von cdrtools-3.0 cdrecord hatte
ich noch im terminal und habe sie nun in eine Datei kopiert, falls es
ueber den "Sense Code" hinaus noch von Interesse sein sollte - zum hier
Posten ist es aber etwas zu lang (knapp 100 Zeilen).
Und weil grad wieder ein Versuch (wodim auf 700MB CD-RW) fertiggeworden
ist:
...
Performing OPC...
Starting new track at sector: 0
Track 01: 695 of 695 MB written (fifo 100%) [buf 99%] 4.2x.
Track 01: Total bytes read/written: 729747456/729747456 (356322 sectors).
Writing time: 1196.499s
Average write speed 4.0x.
Min drive buffer fill was 99%
Fixating...
Fixating time: 63.689s
wodim: fifo had 11495 puts and 11495 gets.
wodim: fifo was 0 times empty and 11291 times full, min fill was 97%.
$
$ dd if=/dev/cdrom bs=2k | md5sum
dd: reading `/dev/cdrom': Input/output error
356280+0 records in
356280+0 records out
729661440 bytes (730 MB) copied, 267,898 s, 2,7 MB/s
6eab7a4fe53fc72181e75a5814fca24f -
$
die richtige Groesse waere 729747456 (was ja wodim behauptet hat
geschrieben zu haben)
Die kompletten logs (einmal mit cdrtools-3.0 auf 800MB CD-R,
und wodim auf 700MB CD-RW) schicke ich auf Anfrage gerne per
Email. (zusammen knapp 7kb)
Andreas Leitgeb
Die md5summe stimmt jedenfalls für die .iso datei.
Andreas Leitgeb
>>Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
>>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein Äutzerl
>>> zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft, merkt zwar
>>> eh, dass es nicht gepasst hat - nur halt eben erst danach.
Meine Erst-Diagnose hatte ich bereits zurueckgezogen... :-}
> Was die wirkliche Ursache ist, kann man ohne Kenntnis des Rohlingherstellers
> (cdrecord -atip) und des Fehlers nicht entscheiden.
der 800MB CD-R Rohling (Platinum)
ATIP info from disk:
Indicated writing power: 4
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, low Beta category (A-) (2)
ATIP start of lead in: -14888 (96:43/37)
ATIP start of lead out: 359849 (79:59/74)
Disk type: unknown dye (reserved id code)
Manuf. index: -1
Manufacturer: unknown (not in table)
der 700MB CD-RW Rohling (Verbatim)
ATIP info from disk:
Indicated writing power: 6
Reference speed: 2
Is not unrestricted
Is erasable
ATIP start of lead in: -11078 (97:34/22)
ATIP start of lead out: 359849 (79:59/74)
1T speed low: 0 (reserved val 0) 1T speed high: 4
2T speed low: 0 (reserved val 5) 2T speed high: 0 (reserved val 12)
power mult factor: 3 5
recommended erase/write power: 3
A1 values: 02 3A B0
A2 values: 5C C6 26
Disk type: Phase change
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
und noch ein 700MB CD-R (Verbatim "Vinyl"):
ATIP info from disk:
Indicated writing power: 4
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, high Beta category (A+) (3)
ATIP start of lead in: -11077 (97:34/23)
ATIP start of lead out: 359848 (79:59/73)
Disk type: Long strategy type (Cyanine, AZO or similar)
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
Fehler gab es mit deinem cdrecord mit dem 800MB Rohling:
(Was mich ein bisschen wundert, ist, dass cdrecord trotz Fehler dann
noch fixiert... Ich weiss aber nicht, ob der Rohling zu dem Zeitpunkt
nicht ohnehin schon "verbrannt" gewesen wäre.)
Performing OPC...
Sending CUE sheet...
/opt/schily/bin/cdrecord: WARNING: Drive returns wrong startsec (0) using -150
Writing pregap for track 1 at -150
/opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB: 2A 00 FF FF FF 6A 00 00 10 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 2A 00 00 80 30 05 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.002s timeout 200s
write track pad data: error after 0 bytes
BFree: 1029 K BSize: 1029 K
Starting new track at sector: 0
Track 01: 0 of 695 MB written./opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB: 2A 00 00 00 00 00 00 00 10 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 2A 00 00 80 30 05 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.002s timeout 200s
write track data: error after 0 bytes
/opt/schily/bin/cdrecord: A write error occured.
/opt/schily/bin/cdrecord: Please properly read the error message above.
Writing time: 47.223s
Average write speed 100.7x.
Fixating...
Fixating time: 0.004s
/opt/schily/bin/cdrecord: fifo had 128 puts and 1 gets.
/opt/schily/bin/cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%.
Wolfgang Zweimueller
Ich weiß. Aber ich war gestern wegen einem anderen Problem in der
Firma grad "in Fahrt" ;-)
lg,
Wolfgang
Matthias Feichtinger
[Netaran Schmoan]
Kaunstdi endli schleichn mitdein Kaas!
Lesamoi wosndes hoaßt: at, Preiß!
--
Usenet und nur usenet
Hic Rhodos - hic salta!
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>> Was die wirkliche Ursache ist, kann man ohne Kenntnis des Rohlingherstellers
>> (cdrecord -atip) und des Fehlers nicht entscheiden.
>
>der 800MB CD-R Rohling (Platinum)
>
>ATIP info from disk:
> Indicated writing power: 4
> Is not unrestricted
> Is not erasable
> Disk sub type: Medium Type A, low Beta category (A-) (2)
> ATIP start of lead in: -14888 (96:43/37)
> ATIP start of lead out: 359849 (79:59/74)
>Disk type: unknown dye (reserved id code)
>Manuf. index: -1
>Manufacturer: unknown (not in table)
Da ist unklar wo der herkommt. Vermutlich ist das keine gute Qualität
>der 700MB CD-RW Rohling (Verbatim)
>
>ATIP info from disk:
> Indicated writing power: 6
> Reference speed: 2
> Is not unrestricted
> Is erasable
> ATIP start of lead in: -11078 (97:34/22)
> ATIP start of lead out: 359849 (79:59/74)
> 1T speed low: 0 (reserved val 0) 1T speed high: 4
> 2T speed low: 0 (reserved val 5) 2T speed high: 0 (reserved val 12)
> power mult factor: 3 5
> recommended erase/write power: 3
> A1 values: 02 3A B0
> A2 values: 5C C6 26
>Disk type: Phase change
>Manuf. index: 11
>Manufacturer: Mitsubishi Chemical Corporation
Das ist gute Qualität
>und noch ein 700MB CD-R (Verbatim "Vinyl"):
>
>ATIP info from disk:
> Indicated writing power: 4
> Is not unrestricted
> Is not erasable
> Disk sub type: Medium Type A, high Beta category (A+) (3)
> ATIP start of lead in: -11077 (97:34/23)
> ATIP start of lead out: 359848 (79:59/73)
>Disk type: Long strategy type (Cyanine, AZO or similar)
>Manuf. index: 11
>Manufacturer: Mitsubishi Chemical Corporation
Auch der dürfte gut sein.
>Fehler gab es mit deinem cdrecord mit dem 800MB Rohling:
>(Was mich ein bisschen wundert, ist, dass cdrecord trotz Fehler dann
>noch fixiert... Ich weiss aber nicht, ob der Rohling zu dem Zeitpunkt
>nicht ohnehin schon "verbrannt" gewesen wäre.)
>
>Performing OPC...
>Sending CUE sheet...
>/opt/schily/bin/cdrecord: WARNING: Drive returns wrong startsec (0) using -150
>Writing pregap for track 1 at -150
>/opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
>CDB: 2A 00 FF FF FF 6A 00 00 10 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 05 00 00 00 00 0A 2A 00 00 80 30 05 00 00
>Sense Key: 0x5 Illegal Request, Segment 0
>Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
>Sense flags: Blk 0 (not valid)
>cmd finished after 0.002s timeout 200s
>write track pad data: error after 0 bytes
>BFree: 1029 K BSize: 1029 K
>Starting new track at sector: 0
>Track 01: 0 of 695 MB written./opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
>CDB: 2A 00 00 00 00 00 00 00 10 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 05 00 00 00 00 0A 2A 00 00 80 30 05 00 00
>Sense Key: 0x5 Illegal Request, Segment 0
>Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
>Sense flags: Blk 0 (not valid)
>cmd finished after 0.002s timeout 200s
Solche Probleme sind häufig berichtet worden als Wirkung der feindlichen
Aktionen von "hald" unter Linux (auf Solaris tut er sowas nicht).
Hier würde es sich lohnen im RAW Modus (-raw96r) zu brennen, weil dann selbst
das Laufwerk nicht weis in welchem Zustand es gerade ist, oder hald schlafen
zu schicken:
kill -STOP `pgrep hald`
Den aktuellen Zustand des Rohlings bekommst Du übrigens mit "cdrecord -minfo"
David Wührer
> Das ist Unsinn!
Hallo,
> Debian hat im Mai 2004 zuerst einen v�llig defekten UTF-8 Patch f�r
> mkisofs eingebaut
Es war damals Ziel, endlich einmal alles UTF-8-konform zu bekommen.
Es war ja schon damals längst überfällig.
Inzwischen kann und will ja niemand mehr auf UTF-8 verzichten.
> Sp�ter wurden dann durch Debian L�gen �ber angebliche
> Lizenzverst��e durch mich verbreitet.
Das müssen die gewesen sein, die irrig annahmen, Deine Software stünde nach
wie vor unter der GPL.
> Debian ist ein feindlicher Distributor, der OSS Autoren und Programme
> angreift und dar�berhinaus darauf besteht defekte Versionen verbreiten zu
> wollen.
aber
> Jede gr��ere Institution hat schwarze Schafe, so auch Debian.
> Das Problem bei Debian ist, da� sie keine Kraft haben sich von ihren
> schwarzen Schafen zu reinigen.
Debian ist nicht gerade Oracle, das stimmt.
Aber ich sehe jetzt nicht, wo Deine Darstellung dem, was ich gesagt habe,
widerspricht.
Andreas Leitgeb
> Wie schon erwähnt: Hast einen anderen Rohling probiert (evtl. zuerst mal
> mit einer Simulation)?
Mittlerweile ja.
von der simulation versprech ich mir nicht allzuviel, da der
wodim mir ja selbst ohne simulation keinen Fehler meldet...
dafür aber welche macht.
Ich experimentiere derweil weiter mit verschiedenen programmen
(wodim versus cdrtools-3.0 versus ...), verschiedenen Rohlingen
und auch verschiedenen optionen...
Eventuell fische ich auch noch meinen alten scsi-brenner irgendwo
aus dem Archiv ...
Falls es Erfolge gibt, werde ich mich melden.
Und wenn es "neue" Fehler gibt, eh auch. ;-/
Joerg Schilling
>> mkisofs eingebaut
>Es war damals Ziel, endlich einmal alles UTF-8-konform zu bekommen.
>Inzwischen kann und will ja niemand mehr auf UTF-8 verzichten.
Wenn man soetwas angeht, dann muß man es auch richtig machen und nicht, wie es
bei Debian passiert ist, nichtmal die Hälfte der notwendigen Stellen UTF-8
fähig zu machen und die auch noch voller Bugs.
Von den Code den Debiab da im Mai 2004 abgeliefert hat war nichts zu gebrauchen
und zu diesem Zeitpunkt war UTF-8 Support auch noch nicht wirklich wichtig. Da
ich den Code ja nachher warten muß, kann ich nichts annehmen, daß unwartbar und
unbrauchbar ist. Da ist das UTF-8 Projekt dann halt bis Mai 2007
liegengeblieben - bis ich Zeit dafür hatte.
>> Sp�ter wurden dann durch Debian L�gen �ber angebliche
>> Lizenzverst��e durch mich verbreitet.
>Das müssen die gewesen sein, die irrig annahmen, Deine Software stünde nach
>wie vor unter der GPL.
Die Software stand zu diesem Zeitpunkt auch noch unter GPL. Die Lizenzänderung
kam erst _nachdem_ Debian die Lügen über angebliche Lizenzverstöße verbreitet
hatte.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Ich experimentiere derweil weiter mit verschiedenen programmen
>(wodim versus cdrtools-3.0 versus ...), verschiedenen Rohlingen
>und auch verschiedenen optionen...
Hast Du es denn schon ohne hald probiert?
>Eventuell fische ich auch noch meinen alten scsi-brenner irgendwo
>aus dem Archiv ...
Wenn es hald ist, dann nützt Dir das nicht. Hald ist es egal was für Geräte er
stört.
Andreas Leitgeb
> In article <slrniat09...@gamma.logic.tuwien.ac.at>,
> Andreas Leitgeb <a...@logic.at> wrote:
>> der 700MB CD-RW Rohling (Verbatim)
> Das ist gute Qualität
>> [...Probs beim Brennen mit /opt/schily/bin/cdrecord...]
> Solche Probleme sind häufig berichtet worden als Wirkung der feindlichen
> Aktionen von "hald" unter Linux (auf Solaris tut er sowas nicht).
> Hier würde es sich lohnen im RAW Modus (-raw96r) zu brennen, weil dann selbst
> das Laufwerk nicht weis in welchem Zustand es gerade ist, oder hald schlafen
> zu schicken:
> kill -STOP `pgrep hald`
> Den aktuellen Zustand des Rohlings bekommst Du übrigens mit "cdrecord -minfo"
Habe mal wieder einen Versuch mit cdrtools-3.0 cdrecord, dem schon erwähnten
700MB CD-RW und gestopptem "hald". Gleich vorweg das Ergebnis auf der CD:
das anschließende "dd" konnte grad mal 38 records einlesen, also 77824 bytes :-(
Ist ja schon mehr als auf dem 800er ;-/ aber immernoch deutlich weniger als
wodim... (den ich jetzt gerade auf die mittlerweile wieder geblankte CD-RW
diesmal mit -raw96r brennen lasse)
Hier diesmal das komplette log:
avl@fpc:/opt/data/iso-images$ sudo /opt/schily/bin/cdrecord -v -raw96r ubuntu-10.10-rc-desktop-i386.iso
[sudo] password for avl:
Cdrecord-ProDVD-ProBD-Clone 3.00 (i686-pc-linux-gnu) Copyright (C) 1995-2010 J�rg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
SCSI buffer size: 32768
No target specified, trying to find one...
Using dev=1,0,0.
atapi: 1
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'HL-DT-ST'
Identifikation : 'DVDRAM GSA-4120B'
Revision : 'A117'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: CD-RW
Profile: DVD-RAM
Profile: DVD-R sequential recording
Profile: DVD-RW sequential recording
Profile: DVD-RW restricted overwrite
Profile: DVD+RW
Profile: DVD+R
Profile: DVD+R/DL
Profile: DVD-ROM
Profile: CD-R
Profile: CD-RW (current)
Profile: CD-ROM
Profile: Removable Disk
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1053696 = 1029 KB
Drive pbuf size: 1966080 = 1920 KB
Drive DMA Speed: 8274 kB/s 47x CD 5x DVD 1x BD
FIFO size : 4194304 = 4096 KB
Encoding speed : 451x (33783 sectors/s) for libedc from Heiko Ei�feldt
Track 01: data 695 MB
Total size: 799 MB (79:10.96) = 356322 sectors
Lout start: 799 MB (79:12/72) = 356322 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 6
Reference speed: 2
Disk Is not unrestricted
Disk Is erasable
ATIP start of lead in: -11078 (97:34/22)
ATIP start of lead out: 359849 (79:59/74)
1T speed low: 0 (reserved val 0) 1T speed high: 4
2T speed low: 0 (reserved val 5) 2T speed high: 0 (reserved val 12)
power mult factor: 3 5
recommended erase/write power: 3
A1 values: 02 3A B0
A2 values: 5C C6 26
Disk type: Phase change
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
Capacity Blklen/Sparesz. Format-type Type
0 2048 0x00 No Media Present or Unknown Capacity
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 3527
Starting to write CD/DVD/BD at speed 4 in real RAW/RAW96R mode for single session.
Last chance to quit, starting real write 0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is ON.
Turning BURN-Free off
Performing OPC...
/opt/schily/bin/cdrecord: WARNING: Drive returns wrong startsec (0) using -11078 from ATIP
Writing lead-in at sector -11078
Lead-in write time: 71.855s
Writing pregap for track 1 at -150
Starting new track at sector: 0
Track 01: 831 of 831 MB written (fifo 100%) [buf 52%] 1.3x.
Track 01: Total bytes read/written: 872276256/872276256 (356322 sectors).
Writing time: 2223.518s
Average write speed 2.2x.
Min drive buffer fill was 2%
Total of 46 possible drive buffer underruns predicted.
Writing Leadout...
Fixating...
Fixating time: 42.123s
/opt/schily/bin/cdrecord: Drive needs to reload the media to return to proper status.
/opt/schily/bin/cdrecord: fifo had 27410 puts and 27410 gets.
/opt/schily/bin/cdrecord: fifo was 0 times empty and 7749 times full, min fill was 82%.
avl@fpc:/opt/data/iso-images$
avl@fpc:/opt/data/iso-images$ dd if=/dev/cdrom of=ubu-back1.iso bs=2k
dd: reading `/dev/cdrom': Input/output error
38+0 records in
38+0 records out
77824 bytes (78 kB) copied, 3.46627 s, 22.5 kB/s
avl@fpc:/opt/data/iso-images$
Andreas Leitgeb
> Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> Solche Probleme sind häufig berichtet worden als Wirkung der feindlichen
>> Aktionen von "hald" unter Linux (auf Solaris tut er sowas nicht).
>> Hier würde es sich lohnen im RAW Modus (-raw96r) zu brennen, weil dann selbst
>> das Laufwerk nicht weis in welchem Zustand es gerade ist, oder hald schlafen
>> zu schicken:
>> kill -STOP `pgrep hald`
> 700MB CD-RW und gestopptem "hald". Gleich vorweg das Ergebnis auf der CD:
> das anschließende "dd" konnte grad mal 38 records einlesen, also 77824 bytes :-(
> Ist ja schon mehr als auf dem 800er ;-/ aber immernoch deutlich weniger als
> wodim... (den ich jetzt gerade auf die mittlerweile wieder geblankte CD-RW
> diesmal mit -raw96r brennen lasse)
wodim hat es nun mit -raw96r geschafft, die CD richtig zu brennen. (dabei ist
der hald wieder weitergelaufen (die prozesse haben davor ein kill -CONT bekommen).
Jetzt steht es mal 1:0 für wodim versus cdrtools. irgendwas scheint an den
so "kaputten" patches also gar nicht so schlecht gewesen zu sein.
PS:
warum meckert der compiler beim kompilieren der cdrtools eigentlich so oft?
z.B. über ungültige 'r' Konvertierung? (eine solche Konvertierung hab ich
auch in der printf(3C)-manpage auf einer sun mit SunOS 5.10 nicht gefunden)
Nur eine von unzähligen solchen Zeilen:
" io.c:204: warning: unknown conversion type character 'r' in format
Weiters gibt's noch solche warnings:
" cue.c:1681: warning: format '%d' expects type 'int', but argument 3 has type 'const char *'
" cue.c:1681: warning: format '%d' expects type 'int', but argument 4 has type 'va_list'
und solche:
" cdrecord.c:4772: warning: ignoring return value of 'write', declared with attribute warn_unused_result
Einige der Warnings sind wohl insofern Linux(oder gcc)-eigen, als dass
ich bei den SUN-compilern noch nicht gesehen habe, dass die einen direkt
angegebenen format-string überhaupt gegen die Argumente prüfen.
Bernd Petrovitsch
[....]
> Von den Code den Debiab da im Mai 2004 abgeliefert hat war nichts zu
> gebrauchen und zu diesem Zeitpunkt war UTF-8 Support auch noch nicht
> wirklich wichtig. Da ich den Code ja nachher warten muß, kann ich nichts
Naja, zumindest Redhat-9 ist "damals" (im Frühjahr 2003 hatte ich das
erstmals installiert BTW. K.A. mehr, wann das rausgekommnen ist) per
default "UTF-8 enabled" dahergekommen (und von Redhat-7 und -8 vorher
weiß ich es nicht - die hatte ich nie benutzt).
Bei anderen Distributionen von damals müssen andere berichten.
Insofern ist das "nicht wirklich wichtig" oben so wohl - ähemm - etwas
übertrieben.
> annehmen, daß unwartbar und unbrauchbar ist. Da ist das UTF-8 Projekt
> dann halt bis Mai 2007 liegengeblieben - bis ich Zeit dafür hatte.
Das ist die schwere Frage: Besser buggy implementiert oder gar nicht?
Bernd
--
- Wie erkennt man IYO die offensichtlich ungeeigneten, hinter denen sich
nicht das Genie verbirgt?
- Wie erkennt man das Offensichtliche?
Martina Diel und Volker Birk
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Habe mal wieder einen Versuch mit cdrtools-3.0 cdrecord, dem schon erwähnten
>700MB CD-RW und gestopptem "hald". Gleich vorweg das Ergebnis auf der CD:
>das anschließende "dd" konnte grad mal 38 records einlesen, also 77824 bytes :-(
>Ist ja schon mehr als auf dem 800er ;-/ aber immernoch deutlich weniger als
>wodim... (den ich jetzt gerade auf die mittlerweile wieder geblankte CD-RW
>diesmal mit -raw96r brennen lasse)
>
>Hier diesmal das komplette log:
Aber ohne Beleg für die Leseprobleme...
Wenn cdrecord keine Fehlermeldungen ausgibt, dann ist das Laufwerk der Meinung,
daß es ordnungsgemäß gebrannt hat.
Cdrecord hat Dir also geholfen....
Joerg Schilling
>> 700MB CD-RW und gestopptem "hald". Gleich vorweg das Ergebnis auf der CD:
>> Ist ja schon mehr als auf dem 800er ;-/ aber immernoch deutlich weniger als
>> wodim... (den ich jetzt gerade auf die mittlerweile wieder geblankte CD-RW
>> diesmal mit -raw96r brennen lasse)
>
>wodim hat es nun mit -raw96r geschafft, die CD richtig zu brennen. (dabei ist
>der hald wieder weitergelaufen (die prozesse haben davor ein kill -CONT bekommen).
>
>so "kaputten" patches also gar nicht so schlecht gewesen zu sein.
Das ist eindeutig eine Fehlinterpretation.
wodim ist nachweislich in keinem Punkt besser als cdrecord. Was Du siehst muß
daher ein Zufalls effekt sein (Du hast ja bislang auch nicht belegt was mit
cdrecord schiefgegangen sein soll...obwohl das LW keine Probleme gemeldet hat).
An dem was an wodim gegenüber cdrecord geändert worden ist, ist nichts daß
irgendeine Verbesserung bringt.
In den Code für CDs wurden aber weniger Probleme eingebaut als in dem für DVDs.
Wodim gibt bei CDs auf jeden Fall weniger Fehlermeldungen und Warnungen aus (daher
kann man wodim nicht vertrauen) und wodim kennt nicht die Firmwarebugs neuerer
Brenner, daher funktioniert alles was auf neueren (< 2 Jahre) Pioneer
Entwicklungen basiert nicht mehr mit wodim.
Wie ich bereits früher geschrieben habe: die "cdrkit" "Entwicklung" ist seit
dem 5. Mai 2007 eingestellt und Fehlermeldungen an die Verantwortlichen werden
ignoriert.
>PS:
>warum meckert der compiler beim kompilieren der cdrtools eigentlich so oft?
>z.B. über ungültige 'r' Konvertierung? (eine solche Konvertierung hab ich
>auch in der printf(3C)-manpage auf einer sun mit SunOS 5.10 nicht gefunden)
>Nur eine von unzähligen solchen Zeilen:
>" io.c:204: warning: unknown conversion type character 'r' in format
>Weiters gibt's noch solche warnings:
>" cue.c:1681: warning: format '%d' expects type 'int', but argument 3 has type 'const char *'
>" cue.c:1681: warning: format '%d' expects type 'int', but argument 4 has type 'va_list'
>und solche:
>" cdrecord.c:4772: warning: ignoring return value of 'write', declared with attribute warn_unused_result
Du meinst nicht "den Kompiler", sondern der GCC..,. Frag doch mal die gcc
Leute, warum 28 Jahre nachdem das %r Printf Format eingeführt wurde, gcc immer
noch nicht versteht was dieses Format bedeutet.
>Einige der Warnings sind wohl insofern Linux(oder gcc)-eigen, als dass
>ich bei den SUN-compilern noch nicht gesehen habe, dass die einen direkt
>angegebenen format-string überhaupt gegen die Argumente prüfen.
Das Problem mit gcc ist, daß es viele unsinnige Warnungen gibt und sogar
Warnungen für wichtige Dinge fehlen. Ich verwende den gcc nur um einige
zusätzliche Warnungen zu sehen, die ich sonst nur von lint(1) bekommen würde
und um sicherzustellen, daß es auch mit gcc funktioniert.
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>On Fri, 08 Oct 2010 19:19:19 +0000, Joerg Schilling wrote:
>[....]
>> Von den Code den Debiab da im Mai 2004 abgeliefert hat war nichts zu
>> gebrauchen und zu diesem Zeitpunkt war UTF-8 Support auch noch nicht
>> wirklich wichtig. Da ich den Code ja nachher warten muß, kann ich nichts
>
>Naja, zumindest Redhat-9 ist "damals" (im Frühjahr 2003 hatte ich das
>erstmals installiert BTW. K.A. mehr, wann das rausgekommnen ist) per
>default "UTF-8 enabled" dahergekommen (und von Redhat-7 und -8 vorher
>weiß ich es nicht - die hatte ich nie benutzt).
>Bei anderen Distributionen von damals müssen andere berichten.
>
>Insofern ist das "nicht wirklich wichtig" oben so wohl - ähemm - etwas
>übertrieben.
Wenn die Leute anscheinend mit einer nicht funktionierenden Implementierung
zufrieden sind, dann scheint kein Bedarf daran zu existieren.
>> annehmen, daß unwartbar und unbrauchbar ist. Da ist das UTF-8 Projekt
>> dann halt bis Mai 2007 liegengeblieben - bis ich Zeit dafür hatte.
>
>Das ist die schwere Frage: Besser buggy implementiert oder gar nicht?
Mit nicht funktionierenden Code kann man nichts anfangen, er erzeugt nur
Probleme. Für die Leute von Debian zählt das wohl nicht, weil sie den Code
nicht warten müssen....
Andreas Leitgeb
>> das anschließende "dd" konnte grad mal 38 records einlesen, also 77824 bytes :-(
Wiebitte? Meinst du also, ich hätte mir den I/O-Error und die gelesenen
Bytes aus den Fingern gesogen?
> Wenn cdrecord keine Fehlermeldungen ausgibt, dann ist das Laufwerk der Meinung,
> daß es ordnungsgemäß gebrannt hat.
Ob eine CD richtig gebrannt wurde, entscheidet sich ohnehin erst, wenn man
versucht, sie wieder einzulesen. - alles andere waere naiv gegenueber der
Hardware. (die mit wodim gebrannte CD funktioniere dann übrigens auch bei
der installation auf einem anderen Rechner - war also nicht nur am selben
Laufwerk komplett lesbar)
> Cdrecord hat Dir also geholfen....
Insofern, als du mir die option -raw96r empfohlen hast, die zwar nicht mit
cdrecord, dafür aber mit wodim zu einer komplett lesbaren CD führte.
Danke dafür - und natürlich auch für das Fundament, ohne das es
wodim wohl nicht gaebe.
Andreas Leitgeb
>>z.B. über ungültige 'r' Konvertierung? (eine solche Konvertierung hab ich
>> auch in der printf(3C)-manpage auf einer sun mit SunOS 5.10 nicht gefunden)
Scheinbar hat sich Sun auch nicht gerade darum geschert, "%r" in der
manpage von printf, sprintf etc zu dokumentieren. (Stand: Solaris 10,
definitiv jünger als 28 Jahre alt)
Zum Rest antworte ich ein anderes mal... muss weg.
Bernd Petrovitsch
> In article <i8pilh$idp$1...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>>On Fri, 08 Oct 2010 19:19:19 +0000, Joerg Schilling wrote: [....]
>>> Von den Code den Debiab da im Mai 2004 abgeliefert hat war nichts zu
>>> gebrauchen und zu diesem Zeitpunkt war UTF-8 Support auch noch nicht
>>> wirklich wichtig. Da ich den Code ja nachher warten muß, kann ich
>>> nichts
>>
>>Naja, zumindest Redhat-9 ist "damals" (im Frühjahr 2003 hatte ich das
>>erstmals installiert BTW. K.A. mehr, wann das rausgekommnen ist) per
>>default "UTF-8 enabled" dahergekommen (und von Redhat-7 und -8 vorher
>>weiß ich es nicht - die hatte ich nie benutzt). Bei anderen
>>Distributionen von damals müssen andere berichten.
>>
>>Insofern ist das "nicht wirklich wichtig" oben so wohl - ähemm - etwas
>>übertrieben.
>
> Wenn die Leute anscheinend mit einer nicht funktionierenden
> Implementierung zufrieden sind, dann scheint kein Bedarf daran zu
> existieren.
Ich seh hier keinen Zusammenhang zum letzten Absatz.
Falls es nicht klar genug herausgekommen ist: im Jahr 2004 UTF-8
Unterstützung (zumindest in der Linux-Welt) als "nicht wirklich wichtig"
zu bezeichnen zeugt von einer gewissen Ignoranz bzw. Realitätsverweigerung.
Klar, wenn Du keine Zeit/Lust dazu hast, dann bau es nicht (oder erst
später) ein. Ändert aber nichts dran, daß es Zeit dafür war ....
>>> annehmen, daß unwartbar und unbrauchbar ist. Da ist das UTF-8 Projekt
>>> dann halt bis Mai 2007 liegengeblieben - bis ich Zeit dafür hatte.
>>
>>Das ist die schwere Frage: Besser buggy implementiert oder gar nicht?
>
> Mit nicht funktionierenden Code kann man nichts anfangen, er erzeugt nur
> Probleme. Für die Leute von Debian zählt das wohl nicht, weil sie den
> Code nicht warten müssen....
Nicht daß ich für Debian (oder derne Paketmaintainer) sprechen wollte/könnte,
aber solange Du deren Patch nicht bei Dir im Upstream "einwirfst", wird
Debian gar nichts anderes übrig bleiben, den als "out of tree" Patch
mitzuziehen.
Klarerweise werden die Bug-Reporter dann natürlich ggf. auch an "Debian"
(bzw. den zuständigen Paket-Maintainer) - freundlich, aber bestimmt -
verwiesen.
Bernd Petrovitsch
[...]
> Du meinst nicht "den Kompiler", sondern der GCC..,. Frag doch mal die
> gcc Leute, warum 28 Jahre nachdem das %r Printf Format eingeführt wurde,
> gcc immer noch nicht versteht was dieses Format bedeutet.
Hat hier irgendjemand einen URL, wo man nachlesen kann, was "%r" kann/soll?
Googlen nach "printf %r" bringt nix.
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>On Sat, 09 Oct 2010 12:21:45 +0000, Joerg Schilling wrote:
>[...]
>> Du meinst nicht "den Kompiler", sondern der GCC..,. Frag doch mal die
>> gcc immer noch nicht versteht was dieses Format bedeutet.
>
>Hat hier irgendjemand einen URL, wo man nachlesen kann, was "%r" kann/soll?
>Googlen nach "printf %r" bringt nix.
Das ist ein rekursives printf(). Damit kann man völlig problemlos strukturierte
Ausgabefunktionen schreiben:
%r hat als Argument einen Formatstring und eine Varargliste. Beispiel:
EXPORT int
error(const char *fmt, ...)
{
va_list args;
int ret;
va_start(args, fmt);
ret = js_fprintf(stderr, "%r", fmt, args);
va_end(args);
return (ret);
}
Vorteil gegenüber anderen Lösungen: es kann beliebig geschachtelt
verwendet werden, was bei struktutierten Fehlerausgaben sehr hilfreich ist.
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>> Wenn die Leute anscheinend mit einer nicht funktionierenden
>> Implementierung zufrieden sind, dann scheint kein Bedarf daran zu
>> existieren.
>
>Ich seh hier keinen Zusammenhang zum letzten Absatz.
>Falls es nicht klar genug herausgekommen ist: im Jahr 2004 UTF-8
>UnterstĆ¼tzung (zumindest in der Linux-Welt) als "nicht wirklich wichtig"
>zu bezeichnen zeugt von einer gewissen Ignoranz bzw. RealitƤtsverweigerung.
>Klar, wenn Du keine Zeit/Lust dazu hast, dann bau es nicht (oder erst
>spƤter) ein. Ć„ndert aber nichts dran, daĆ es Zeit dafĆ¼r war ....
Debian hat eine nicht benutzbare UTF-8 "Erweiterung" in mkisofs eingebaut.
Das zeugt in der Tat von Ignoranz und Realitätsverweigerung. Soetwas tun nur
Leute, denen es um Prospektdaten und nicht um Funktionalität geht.
Die Originalsoftware hat seit 3,5 Jahren eine funtionierende UTF-8
Unterstützung, der Debian fork ist immer noch nicht zu gebrauchen. Debian zeigt
also fortgesetzte Ignoranz seit über 6 Jahren. ... und das obwohl es seit Jahren
im Debian Bugtracking-System Einträge dazu gibt.
Joerg Schilling
>>> auch in der printf(3C)-manpage auf einer sun mit SunOS 5.10 nicht gefunden)
>> Du meinst nicht "den Kompiler", sondern der GCC..,. Frag doch mal die gcc
>> Leute, warum 28 Jahre nachdem das %r Printf Format eingeführt wurde, ...
>
>Scheinbar hat sich Sun auch nicht gerade darum geschert, "%r" in der
>manpage von printf, sprintf etc zu dokumentieren. (Stand: Solaris 10,
>definitiv jünger als 28 Jahre alt)
Nicht alle Ideen dieser Welt stammen von Sun. Du kannst Dir aber z.B. gerne mal
eine UNOS printf() Manpage von 1982 ansehen ,-)
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> das anschließende "dd" konnte grad mal 38 records einlesen, also 77824 bytes :-(
>> Aber ohne Beleg für die Leseprobleme...
>
>Wiebitte? Meinst du also, ich hätte mir den I/O-Error und die gelesenen
>Bytes aus den Fingern gesogen?
Du hast ihn nicht belegt und stattdessen behauptet es würde mit wodim "besser"
funktionieren als mit cdrecord, was natürlich Unsinn ist weil Du einen
Zufallserfolg erlebt hast. Wenige Brenner können z.B. im RAW Modus "Burn-Free"
und wenn Du mit einem System arbeitest, daß die Daten viel zu langsam an den
Brenner liefert, dann ist jedes Ergebnis ein Zufall. Mit aktuellen Rohlingen
kann kein Brenner heutzutage langsamer als 4-8x schreiben.
Du hast übrigens mit Deiner angezeigten Brenngeschwindgkeit gezeigt, daß Dein
System kein DMA macht und ____viel____ zu langsam arbeitet. Dein Problem ist
entweder ein defekter Brenner oder ein defektes System. Da kann es natürlich
auch mal passieren, daß wodim zufällig mal funktioniert. Vertrauen kann man
wodim dennoch nicht und vor den immer defekten Filesystemen die genisoimage
produziert kann ich nur warnen.
Es gibt jedenfalls keinen Grund ein Programm zu verwenden daß um die
Jahreswende 2006/2007 aus einer damals 2 Jahre Alten Originalquelle durch
Hinzufügen von Bugs entstanden ist und zu dem der "Herausgeber" seit dem
faktisch alle Bugreports ignoriert.
Bei der Originalsoftware hingegen hat sich viel seit dem September 2004 getan
(das ist der Stand auf dem Debian aufbaut). Seit dem ist nahezu 50% des Codes
neu. Viele alte Bugs sind beseitigt worden, viele Workarounds für Firmwarebugs
diverwer Hersteller wurden implementiert und viele neue Features wurden
entwickelt.
Cdrecord hat z.B. innerhalb weniger Wochen einen Workaround für einen
Firmwarebug implementiert, den Pioneer im August 2008 präsentiert hat und damit
(dank OEM Produkten) viele "Marken" betrifft. Wodim kann mit diesen Brennern
heute noch nicht umgehen.
Mkisofs hat seit Sommer 2006 ein eingebautes find(1) dank libfind. Das ist
etwas, daß die Benutzbarkeit deutlich verbessert.
Andreas Leitgeb
> In article <slrnib0r2...@gamma.logic.tuwien.ac.at>,
> Andreas Leitgeb <a...@logic.at> wrote:
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> Aber ohne Beleg für die Leseprobleme...
>> Wiebitte? Meinst du also, ich hätte mir den I/O-Error und die gelesenen
>> Bytes aus den Fingern gesogen?
> Du hast ihn nicht belegt
Wie könnte ein "Beleg" dafür aussehen, wenn cdrecord mir keinen ausgibt, und die
CD dennoch anschließend nicht lesbar war? Soll ich mal schnell nach berlin fahren,
um den Fehler persönlich vorzuführen?
> und stattdessen behauptet es würde mit wodim "besser" funktionieren als mit cdrecord,
> was natürlich Unsinn ist weil Du einen Zufallserfolg erlebt hast.
Das werde ich in den nächsten Tagen durch test-wiederholungen herausfinden.
> Wenige Brenner können z.B. im RAW Modus "Burn-Free"
> und wenn Du mit einem System arbeitest, daß die Daten viel zu langsam an den
> Brenner liefert, dann ist jedes Ergebnis ein Zufall. Mit aktuellen Rohlingen
> kann kein Brenner heutzutage langsamer als 4-8x schreiben.
> Du hast übrigens mit Deiner angezeigten Brenngeschwindgkeit gezeigt, daß Dein
> System kein DMA macht und ____viel____ zu langsam arbeitet.
die 4er geschwindigkeit liegt nicht am system, sondern an den rohlingen.
Zumindest steht bei denen auf der oberseite explizit drauf, dass sie mit
"4x" zu bebrennen sind.
Davon abgesehen hab ich in der vergangenheit z.b. Audio-CDs doch deutlich
schneller und erfolgreich (also ohne buffer-underrun) gebrannt.
> Vertrauen kann man
> wodim dennoch nicht und vor den immer defekten Filesystemen die genisoimage
> produziert kann ich nur warnen.
Ich würde meine warnung generell gegen CDs aussprechen. Ich vertraue weder
wodim noch cdrecord, noch cdrdao, noch... Wenn aber mal eine cd rauskommt,
die beim neu-einlesen die richtige größe und md5sum liefert, dann bin ich
zuversichtlich.
Wenn es nicht immernoch systeme gäbe, die nicht richtig von USB-flashdisks booten
können, hätte ich seit jahren gar keine daten-CD mehr gebrannt.
Andreas Leitgeb
> Nicht alle Ideen dieser Welt stammen von Sun. Du kannst Dir aber z.B. gerne mal
> eine UNOS printf() Manpage von 1982 ansehen ,-)
Würde ich gerne! Dann wüßte ich zumindest, was %r überhaupt tun soll.
René Schuster
> Wenn es nicht immernoch systeme gäbe, die nicht richtig von USB-flashdisks booten
> können, hätte ich seit jahren gar keine daten-CD mehr gebrannt.
Hmm, also gerade ubuntu läuft wunderbar von USB, wie auch zahlreiche
Andere, sogar bug&pray: http://unetbootin.sourceforge.net/
--
If you want to mail me directly:
- Use ROT13 on my reply-to-address
- Enter "abfcnz" after the "@"
- Use ROT13 again and delete the "nospam"
Andreas Leitgeb
> On 2010-10-10 00:55, Andreas Leitgeb wrote:
>> Wenn es nicht immernoch systeme gäbe, die nicht richtig von USB-flashdisks booten
>> können, hätte ich seit jahren gar keine daten-CD mehr gebrannt.
> Hmm, also gerade ubuntu läuft wunderbar von USB, wie auch zahlreiche
> Andere, sogar bug&pray: http://unetbootin.sourceforge.net/
Sorry, hab mich unklar ausgedrückt.
Ich meinte Rechner, nicht Betriebssysteme.
Es gibt leider immernoch Rechner, die (bzw. deren BIOS) nicht richtig
von USB-flashdisks booten können.
Andreas Leitgeb
> Andreas Leitgeb <a...@logic.at> wrote:
>> Jetzt steht es mal 1:0 für wodim versus cdrtools. irgendwas scheint
>> an den so "kaputten" patches also gar nicht so schlecht gewesen zu sein.
> Das ist eindeutig eine Fehlinterpretation.
> wodim ist nachweislich in keinem Punkt besser als cdrecord.
Habe es nun auch mit cdrtools hinbekommen, das image korrekt auf
eine CD-RW zu bekommen. Hiezu habe ich während des Brennens einfach
mal nichts parallel gemacht, und dann war auch der buffer immer
zu mindestens 99% gefüllt. Sollte burnfree nicht vor underrruns
schützen? Warum wird das von cdrecord per default abgedreht?
Clemens Schueller
Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
Kann es sein, dass DMA - warum auch immer - aus ist?
GreetinX, Clemens Schueller
Andreas Leitgeb
> Thus spake Andreas Leitgeb (a...@gamma.logic.tuwien.ac.at):
>> eine CD-RW zu bekommen. Hiezu habe ich während des Brennens einfach
>> mal nichts parallel gemacht, und dann war auch der buffer immer
>> zu mindestens 99% gefüllt. Sollte burnfree nicht vor underrruns
>> schützen? Warum wird das von cdrecord per default abgedreht?
>
> Kann es sein, dass DMA - warum auch immer - aus ist?
Nach der Ausgabe von hdparm -I auf /dev/sda und /dev/cdrom habe
ich auf beiden sogar udma2. (das ist jeweils das mit dem
sternderl davor)
hdparm -d schreibt jeweils:
HDIO_GET_DMA failed: Inappropriate ioctl for device
Ansonsten ist noch zu sagen, dass der Rechner schon etwas betagt ist.
(Athlon 1800)
Christof Meerwald
> Du meinst nicht "den Kompiler", sondern der GCC..,. Frag doch mal die gcc
Moeglicherweise, weil sich gcc an Standards orientiert und %r weder in
ISO/IEC 9899:1999 noch in IEEE Std 1003.1 spezifiziert ist.
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
Bernd Petrovitsch
> In article <i8psjv$jn4$2...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>>On Sat, 09 Oct 2010 12:21:45 +0000, Joerg Schilling wrote: [...]
>>> Du meinst nicht "den Kompiler", sondern der GCC..,. Frag doch mal die
>>> wurde, gcc immer noch nicht versteht was dieses Format bedeutet.
>>
>>Hat hier irgendjemand einen URL, wo man nachlesen kann, was "%r"
>>kann/soll? Googlen nach "printf %r" bringt nix.
>
> Das ist ein rekursives printf(). Damit kann man völlig problemlos
> strukturierte Ausgabefunktionen schreiben:
Nett.
> %r hat als Argument einen Formatstring und eine Varargliste. Beispiel:
>
> EXPORT int
> error(const char *fmt, ...)
> {
> va_list args;
> int ret;
>
> va_start(args, fmt);
> ret = js_fprintf(stderr, "%r", fmt, args); va_end(args);
> return (ret);
> }
Danke. Jetzt ist es klar.
> Vorteil gegenüber anderen Lösungen: es kann beliebig geschachtelt
> verwendet werden, was bei struktutierten Fehlerausgaben sehr hilfreich
> ist.
Hmm, das wird wohl eher nicht durch POSIX u.ä. vorkommen?
Bernd Petrovitsch
> In article <i8pse3$jn4$1...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>
>>> Wenn die Leute anscheinend mit einer nicht funktionierenden
>>> Implementierung zufrieden sind, dann scheint kein Bedarf daran zu
>>> existieren.
>>
>>Ich seh hier keinen Zusammenhang zum letzten Absatz. Falls es nicht klar
Gut, daß du den Absatz rausgelöscht hast, sonst würden alle gleich sehen,
daß untiges immer noch noch nicht auf den Inhalt eingeht.
[ Da ging es darum, daß zumindest seit 2003 UTF-8 in zumindest einer großen
Distribution per default aktiv war und erst 2007 'cdrecord' UTF-8-Support
"gut genug" bekommen hatte). ]
>>genug herausgekommen ist: im Jahr 2004 UTF-8 UnterstÃŒtzung (zumindest
>>in der Linux-Welt) als "nicht wirklich wichtig" zu bezeichnen zeugt von
>>einer gewissen Ignoranz bzw. RealitÀtsverweigerung. Klar, wenn Du keine
>>Zeit/Lust dazu hast, dann bau es nicht (oder erst spÀter) ein. Ändert
>>aber nichts dran, daß es Zeit dafÌr war ....
>
> Debian hat eine nicht benutzbare UTF-8 "Erweiterung" in mkisofs
So what?
> eingebaut. Das zeugt in der Tat von Ignoranz und Realitätsverweigerung.
Oh nein, das zeugt von "mir geht ein Feature ab und ich bau mal was ein".
> Soetwas tun nur Leute, denen es um Prospektdaten und nicht um
> Funktionalität geht.
Es war wohl mehr Funktionalität als im Original drin. Wenn es jemanden
stört, kann er es ja den "schlechten Patch" konstruktiv verbessern .....
> Die Originalsoftware hat seit 3,5 Jahren eine funtionierende UTF-8
> Unterstützung, der Debian fork ist immer noch nicht zu gebrauchen.
Beschwer' Dich bei dem Paketmaintainer und überzeuge ihn. Mach selber
ein besseres Paket. Finde jemanden, der ein Paket aus Deinem Original
macht.
Das würde mbMn mehr helfen als hier nur mit Dreck rumzuwerfen, die Beiträge
anderer zu ignorieren und den Rest der Welt Realitätsverweigerung zu
unterstellen.
Ignorier' den Debian-Patch und schicke alle Leute mit Problemen mit dem
Debian-Paket zu "Debian". Fertig.
Detto für andere "Forks" a la "wodim" u.ä. (wenn ich es richtig verstanden
hab).
So allgemein: Ich weiß ja nicht, wie in Deiner Welt "Fork" definiert ist,
aber ein paar Patches, die der/die Paketmaintainer mitziehen, ergeben noch
(lange) keine "Fork" (und ich etwas forken würde, dann würde ich pronto
den Namen/Label ändern).
Ich persönlich halte mich dazu eher an ESR - ist in "the cathedral and the
bazaar" u.U. nachzulesen.
> Debian zeigt also fortgesetzte Ignoranz seit über 6 Jahren. ... und das
> obwohl es seit Jahren im Debian Bugtracking-System Einträge dazu gibt.
Auch das n+1. Mal wiederholen ändert nichts: Ja, ich hab verstanden, daß
2004(!) kein UTF-8-Support vorhanden war. "Irgendwer" hat damals sowas
gemacht, meinetwegen auch nicht sonderlich perfekt (oder meinetwegen
sogar katastrophal).
Ja, das war ohne Dein Zutun und mag gegen Deinen Widerstand passiert sein.
Nur: Weil wenn ich etwas verschlimmbessere und mir jemand schlüssig erklärt,
wo ich was wie nicht so gut gemacht hab, wo ich was vergessen/übersehen hab,
dann kann ich draus lernen und es v.a. besser machen.
Wenn natürlich nur Vorwürfe kommen, kein "warum" oder gar Rückfragen im
wesentlichen ignoriert bzw. nicht beantwortet werden, dann kann ich auch
nichts machen/verbessern.
Das einzige was dann bei mir ankommt ist, daß der Upstream *längst*
*notwendiges* nicht drin hatte, ich mir die Arbeit angetan hab, dieses zu
beheben und der Upstream nur lästert und überhaupt nicht konstruktiv ist,
weil er keine brauchbaren Hints abwirft, wo ich noch was verbessern
könnte.
Think about it ....
Ich suche oder gar lese jetzt auch nicht nach, ob und wie sehr oder wenig
konstruktiv das damals abgelaufen ist. Alleine der letzte Thread läßt
wenig hoffen ...
David Wührer
> Wenn man soetwas angeht, dann mu� man es auch richtig machen und nicht,
> wie es bei Debian passiert ist, nichtmal die H�lfte der notwendigen
> Stellen UTF-8 f�hig zu machen und die auch noch voller Bugs.
Es hat danach auch noch 5 Jahre gedauert, bis es quasi fertig war, aber es
ändert nichts daran, dass es bereits damals längst überfällig war.
Wenn Upstream es nicht machen will, müssen die DDs es selber machen,
die den Code natürlich nicht so gut kennen wie Upstream.
> Da ich den Code ja nachher warten mu�,
Wieso?
> Die Software stand zu diesem Zeitpunkt auch noch unter GPL. Die
> Lizenz�nderung kam erst _nachdem_ Debian die L�gen �ber angebliche
> Lizenzverst��e verbreitet hatte.
Ach so.
Da ging es darum, dass die CDDL nicht mit der GPL kompatibel ist.
Soweit ich das nachvollziehen kann, hat niemand behauptet, dass Du gegen
eine Lizenz verstößt, sondern Debian wollte vermeiden, dass sie gegen
Lizenzen zu verstoßen.
David Wührer
> Die Originalsoftware hat seit 3,5 Jahren eine funtionierende UTF-8
> zeigt also fortgesetzte Ignoranz seit �ber 6 Jahren. ... und das obwohl es
> seit Jahren im Debian Bugtracking-System Eintr�ge dazu gibt.
Ich bin sicher, sie würden mit Freude Code verwenden, der diese Bugs
ausbessert, soweit es ihnen legal möglich ist.
René Schuster
> René Schuster <rene+...@schuster.priv.at> wrote:
>> On 2010-10-10 00:55, Andreas Leitgeb wrote:
>>> Wenn es nicht immernoch systeme gäbe, die nicht richtig von USB-flashdisks booten
>>> können, hätte ich seit jahren gar keine daten-CD mehr gebrannt.
>> Hmm, also gerade ubuntu läuft wunderbar von USB, wie auch zahlreiche
>> Andere, sogar bug&pray: http://unetbootin.sourceforge.net/
>
> Sorry, hab mich unklar ausgedrückt.
> Ich meinte Rechner, nicht Betriebssysteme.
Achso, alles klar, das stimmt natürlich.
Joerg Schilling
David =?UTF-8?B?V8O8aHJlcg==?= <d...@gmx.at> wrote:
>Joerg Schilling wrote:
>> Die Originalsoftware hat seit 3,5 Jahren eine funtionierende UTF-8
>> zeigt also fortgesetzte Ignoranz seit �ber 6 Jahren. ... und das obwohl es
>> seit Jahren im Debian Bugtracking-System Eintr�ge dazu gibt.
>
>Ich bin sicher, sie wĂźrden mit Freude Code verwenden, der diese Bugs
>ausbessert, soweit es ihnen legal mĂśglich ist.
Du gehst von der falschen Annahme aus, Debian würde sich logisch verhalten.
Leider ist dem nicht so....
Debian behauptet, die Originalsoftware hätte Lizenzpropbleme. Es gibt aber
keinen einzigen Juristen, der diese Behauptung mit zitierfähigen Belegen
stützt. Alle im Netz verfügbaren Äußerungen von Juristen bestätigen meine
Auslegung der GPL.
Debian hat andererseits keinerlei Probleme ihren Fork, der im klaren
Widerspruch zu geltendem Recht entstanden ist, zu verteilen.
Debian behauptet, sie wollen keinerlei Software von mir mehr in ihrer
Distro haben.
Debian hat andererseits keinerlei Problem ihren Fork, der zu weit über 95%
von mir stammt, in ihrer Distro zu haben.
Mit ihrem Verhalten schaden sie letzlich nur ihren Anwendern und ihrer eigenen
Glaubwürdigkeit.
Joerg Schilling
David =?UTF-8?B?V8O8aHJlcg==?= <d...@gmx.at> wrote:
>Joerg Schilling wrote:
>> Wenn man soetwas angeht, dann mu� man es auch richtig machen und nicht,
>> wie es bei Debian passiert ist, nichtmal die H�lfte der notwendigen
>> Stellen UTF-8 f�hig zu machen und die auch noch voller Bugs.
>
>Es hat danach auch noch 5 Jahre gedauert, bis es quasi fertig war, aber es
>ändert nichts daran, dass es bereits damals längst überfällig war.
???? wie kommst Du auf 5 Jahre?
Debian hat keinen funktionierenden UTF-8 Support in ihrem mkisofs Fork.
Das Originalprogramm mkisofs hat funktionierenden UTF-8 Support seit
Mai 2007.
Fazit: Debian verbreitet seit 6 Jahren falsche Behauptungen zu den Fähigkeiten
der von ihnen verbreiteten Brennsoftware.
Wenn man bedenkt, daß die Bug-Einträge zu dem nicht funktionierenden UTF-8
Support bei Debian erst gegen Ende 2008 auftauchten, sollte klar werden daß
der funktionierende UTF-8 Support in der Originalsoftware verfügbar war bevor
Anwender ihn benötigten ;-)
>> Die Software stand zu diesem Zeitpunkt auch noch unter GPL. Die
>> Lizenz�nderung kam erst _nachdem_ Debian die L�gen �ber angebliche
>> Lizenzverst��e verbreitet hatte.
>
>Ach so.
>Da ging es darum, dass die CDDL nicht mit der GPL kompatibel ist.
>Soweit ich das nachvollziehen kann, hat niemand behauptet, dass Du gegen
>eine Lizenz verstößt, sondern Debian wollte vermeiden, dass sie gegen
>Lizenzen zu verstoßen.
Dann hast Du es also verstanden: Debian ging es darum FUD zu verbreiten...
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>> Die Originalsoftware hat seit 3,5 Jahren eine funtionierende UTF-8
>> Unterstützung, der Debian fork ist immer noch nicht zu gebrauchen.
>
>Beschwer' Dich bei dem Paketmaintainer und überzeuge ihn. Mach selber
>ein besseres Paket. Finde jemanden, der ein Paket aus Deinem Original
>macht.
Das ist nicht nötig. Es gibt inzwischen diverse etnervte Anwender, die frei
verfügbare Pakete mit der Originalsoftware bauen.
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>> Das ist ein rekursives printf(). Damit kann man völlig problemlos
>> strukturierte Ausgabefunktionen schreiben:
>
>Nett.
>
>> %r hat als Argument einen Formatstring und eine Varargliste. Beispiel:
>Danke. Jetzt ist es klar.
>
>> Vorteil gegenüber anderen Lösungen: es kann beliebig geschachtelt
>> verwendet werden, was bei struktutierten Fehlerausgaben sehr hilfreich
>> ist.
>
>Hmm, das wird wohl eher nicht durch POSIX u.ä. vorkommen?
Vergleichebare Implementierungen gab es zu Hauf um 1980.
Dann kam "varargs" auf und weil die damaligen varargs Implementierungen
soetwas nicht unterstützten, entstand der Irrglaube, daß bestimmte Dinge mit
varargs (also portabel) nicht zu implementieren sind. In Wirklichkeit gibt es
aber in C nur eine einzie nicht-Orthognalität in der Sprache (Arrays), die
bewirkt daß ein Abstrakter Typ von dem man nicht wissen kann ob er durch
erin Array implementiert wurde, bestimme Operationen nicht unterstützt.
Dann kam 1988 der erste POSIX Standard.....
1990 kam Sun dann mit der printf()-Erweiterung %n$ die für die
Internationalisierung einen Zugriff auf Vararg Parameter außerhalb der
offiziellen Reihenfolge benötigt. Das geht schon nicht mehr mit dem was damals
in POSIX standardisiert war.
Sun führte zur Implementierung dieses Features das neue vararg Marko "va_copy()"
ein, daß mittlerweile standardisiert ist.
Ich benötige für %r ein weiteres Makro: va_arg_list() welches aber keine
weitergehenden maschinenspezifischen Annahmen macht als "va_copy()". Es könnte
also jederzeit standardisiert werden. Um eine dazugehörige Eingabe machen zu
dürfen, muß man leider zahlendes Mitglied sein.......
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> Andreas Leitgeb <a...@logic.at> wrote:
>>> an den so "kaputten" patches also gar nicht so schlecht gewesen zu sein.
>> Das ist eindeutig eine Fehlinterpretation.
>> wodim ist nachweislich in keinem Punkt besser als cdrecord.
>
>Habe es nun auch mit cdrtools hinbekommen, das image korrekt auf
>mal nichts parallel gemacht, und dann war auch der buffer immer
>schützen? Warum wird das von cdrecord per default abgedreht?
Weil es ein Feature ist, daß prinzipiell die Brennqualität nachteilig
beeinflußt.
An jeder Ansatz-Stelle gibt es "mit" einen Defekt der nur durch die
Fahlerkorrektur behoben werden kann. Ältere Audio-Player können diese
Stellen nicht korrigieren.......
Ansonsten: vor > 3 Jahren waren Plextor Brenner die einzigen, die auch im RAW
Modus Burn-free überhaupt unterstützt haben, denn der Standard sagt das geht
nicht.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>> Wenige Brenner können z.B. im RAW Modus "Burn-Free"
>> und wenn Du mit einem System arbeitest, daß die Daten viel zu langsam an den
>> Brenner liefert, dann ist jedes Ergebnis ein Zufall. Mit aktuellen Rohlingen
>> kann kein Brenner heutzutage langsamer als 4-8x schreiben.
>> Du hast übrigens mit Deiner angezeigten Brenngeschwindgkeit gezeigt, daß Dein
>> System kein DMA macht und ____viel____ zu langsam arbeitet.
>
>die 4er geschwindigkeit liegt nicht am system, sondern an den rohlingen.
>Zumindest steht bei denen auf der oberseite explizit drauf, dass sie mit
>"4x" zu bebrennen sind.
Wenn ich mich recht entsinne, hat Deine Ausgabe eine Geschwindigkeit von 1,3x
angezeigt.
David Wührer
> Du gehst von der falschen Annahme aus, Debian w�rde sich logisch
> verhalten.
>
> Leider ist dem nicht so....
>
> keinen einzigen Juristen, der diese Behauptung mit zitierf�higen Belegen
> st�tzt. Alle im Netz verf�gbaren �u�erungen von Juristen best�tigen meine
> Auslegung der GPL.
http://www.gnu.org/licenses/license-list.html#CDDL
> Debian hat andererseits keinerlei Probleme ihren Fork, der im klaren
> Widerspruch zu geltendem Recht entstanden ist, zu verteilen.
Die GPL erlaubt doch Forks?
Wie also widerspricht das geltendem Recht?
> Debian behauptet, sie wollen keinerlei Software von mir mehr in ihrer
> Distro haben.
Das wusste ich nicht, und das überrascht mich.
> Debian hat andererseits keinerlei Problem ihren Fork, der zu weit �ber 95%
> von mir stammt, in ihrer Distro zu haben.
Das ist dann allerdings ziemlich widersprüchlich.
David Wührer
> In article <i8s8r9$fnb$1...@news.eternal-september.org>,
> David =?UTF-8?B?V8O8aHJlcg==?= <d...@gmx.at> wrote:
>>Es hat danach auch noch 5 Jahre gedauert, bis es quasi fertig war, aber es
>>ändert nichts daran, dass es bereits damals längst überfällig war.
>
> ???? wie kommst Du auf 5 Jahre?
Weil zwar bereits für sarge UTF-8 Release-Goal war, aber erst in etch 2009
der Installer das als Standard angeboten hat.
Andreas Leitgeb
>>> Wenige Brenner können z.B. im RAW Modus "Burn-Free"
>>> und wenn Du mit einem System arbeitest, daß die Daten viel zu langsam an den
>> die 4er geschwindigkeit liegt nicht am system, sondern an den rohlingen.
>> Zumindest steht bei denen auf der oberseite explizit drauf, dass sie mit
>> "4x" zu bebrennen sind.
> Wenn ich mich recht entsinne, hat Deine Ausgabe eine Geschwindigkeit von 1,3x
> angezeigt.
Oh, tatsächlich. Hab ich wohl beim cut&paste selber überlesen...
Wegen dma hab ich schon irgendwo geschrieben, dass hdparm wegen der
scsi-emu nicht anzeigt, ob dma oder nicht. Ich habe aber durchaus
schon "Erfahrung" gemacht mit Systemen, die wegen irgendeines Fehlers
auf pio mode schalteten, und sooo zuckelnd wie jene ist mein aktueller
Rechner bei weitem nicht.
Jedenfalls werde ich künftig mehr darauf achten, (mit oder ohne burnfree),
dass ich während dem Brennen sonst nichts tu. Dass "burnfree" einfach
bei leerem Buffer kaputte Sektoren einfügt, war mir nicht bewusst.
Danke für die Hintergrund-info.
Bernd Petrovitsch
> In article <i8s7rm$umh$2...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>
>>> Die Originalsoftware hat seit 3,5 Jahren eine funtionierende UTF-8
>>
>>Beschwer' Dich bei dem Paketmaintainer und ÃŒberzeuge ihn. Mach selber
>>ein besseres Paket. Finde jemanden, der ein Paket aus Deinem Original
>>macht.
>
> Das ist nicht nötig. Es gibt inzwischen diverse etnervte Anwender, die
> frei verfügbare Pakete mit der Originalsoftware bauen.
Wenn Dir das reicht, soll es mir (auch) Recht sein.
Aber dann brauchst/darfst Du nicht nur auf "Debian" rumbashen (und schon
gar nicht so pauschal. Hau' konkret wo hin.) und selber genau nichts dazu
zu tun, daß sich die Situation in deinem Sinne verbessert.
Einfach nur "die sind mbMn im Unrecht" und "aber ich will das so nicht" zu
rufen und sonst nichts zu tun, ist jedenfalls nicht konstruktiv. Und es
verhindert auch nichts ....
Bernd Petrovitsch
> In article <i8s7rf$umh$1...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>
>>> Das ist ein rekursives printf(). Damit kann man völlig problemlos
>>> strukturierte Ausgabefunktionen schreiben:
>>
>>Nett.
>>
>>> %r hat als Argument einen Formatstring und eine Varargliste. Beispiel:
>
>>Danke. Jetzt ist es klar.
>>
>>> verwendet werden, was bei struktutierten Fehlerausgaben sehr hilfreich
>>> ist.
>>
>>Hmm, das wird wohl eher nicht durch POSIX u.À. vorkommen?
>
> Vergleichebare Implementierungen gab es zu Hauf um 1980.
Uuuh, für Unix-Geschichten aus 1980 bin ich nicht alt genug.
> Dann kam "varargs" auf und weil die damaligen varargs Implementierungen
> soetwas nicht unterstützten, entstand der Irrglaube, daß bestimmte Dinge
> mit varargs (also portabel) nicht zu implementieren sind. In
> Wirklichkeit gibt es aber in C nur eine einzie nicht-Orthognalität in
> der Sprache (Arrays), die bewirkt daß ein Abstrakter Typ von dem man
> nicht wissen kann ob er durch erin Array implementiert wurde, bestimme
> Operationen nicht unterstützt.
>
> Dann kam 1988 der erste POSIX Standard.....
>
> 1990 kam Sun dann mit der printf()-Erweiterung %n$ die für die
> Internationalisierung einen Zugriff auf Vararg Parameter außerhalb der
> offiziellen Reihenfolge benötigt. Das geht schon nicht mehr mit dem was
> damals in POSIX standardisiert war.
Rein inhaltlich: Das ABI legt mWn die Art fest, wie Parameter am Stack
abgelegt werden (und das das ist damit ziemlich in steingemeißelt).
Mit va_copy() u.ä. ist "nur" das definiert, was ich im Source reinschreib',
damit es (magisch;-) portabel funktioniert.
Damit seh ich technisch kein Problem, "%n$" so einzubauen, daß es (trotzdem)
portabel funktioniert (auch wenn es nicht explizit durch Text gedeckt ist).
> Sun führte zur Implementierung dieses Features das neue vararg Marko
> "va_copy()" ein, daß mittlerweile standardisiert ist.
>
> Ich benötige für %r ein weiteres Makro: va_arg_list() welches aber keine
> weitergehenden maschinenspezifischen Annahmen macht als "va_copy()". Es
> könnte also jederzeit standardisiert werden. Um eine dazugehörige
> Eingabe machen zu dürfen, muß man leider zahlendes Mitglied sein.......
Tja, offenbar war "%r" keinem zahlenden Mitglied wichtig genug, daß es in
POSIX, SuSv* o.ä. reingekommen ist. Zumal es auch einfach zu verstehen ist
und nicht sonderlich schwierig zu implementieren.
Bernd
--
- Wie erkennt manf IYO die offensichtlich ungeeigneten, hinter denen sich
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>> 1990 kam Sun dann mit der printf()-Erweiterung %n$ die für die
>> Internationalisierung einen Zugriff auf Vararg Parameter außerhalb der
>> offiziellen Reihenfolge benötigt. Das geht schon nicht mehr mit dem was
>> damals in POSIX standardisiert war.
>
>Rein inhaltlich: Das ABI legt mWn die Art fest, wie Parameter am Stack
>abgelegt werden (und das das ist damit ziemlich in steingemeißelt).
>Mit va_copy() u.ä. ist "nur" das definiert, was ich im Source reinschreib',
>damit es (magisch;-) portabel funktioniert.
>Damit seh ich technisch kein Problem, "%n$" so einzubauen, daß es (trotzdem)
>portabel funktioniert (auch wenn es nicht explizit durch Text gedeckt ist).
Es ist f�r den Anwender unerheblich _wie_ die Dinge an die Funktion �bergeben
werden. F�r den Anwender ist es wichtig wie die _Datenstrukturen_ dazu aussehen.
Auch das w�re kein Problem, wenn die Sprache C nicht arrays anders als alle
anderen Typen behandeln w�rde. Da der varargs Standard nicht spezifiziert
welche Typen zu verwenden sind, gibt es ein Problem...
>> Sun führte zur Implementierung dieses Features das neue vararg Marko
>> "va_copy()" ein, daß mittlerweile standardisiert ist.
Das Problem ist wohl, da� auch bei der Einf�hrung von va_copy() niemand
hinterfragt hat ob alle umherirrenden Behauptungen dar�ber was angeblich mit
varargs alles nicht geht noch korrekt sind.
>> Ich benötige für %r ein weiteres Makro: va_arg_list() welches aber keine
>> weitergehenden maschinenspezifischen Annahmen macht als "va_copy()". Es
>> könnte also jederzeit standardisiert werden. Um eine dazugehörige
>> Eingabe machen zu dürfen, muß man leider zahlendes Mitglied sein.......
>
>Tja, offenbar war "%r" keinem zahlenden Mitglied wichtig genug, daß es in
>POSIX, SuSv* o.ä. reingekommen ist. Zumal es auch einfach zu verstehen ist
>und nicht sonderlich schwierig zu implementieren.
Wenn Sun soetwas vorgeschlagen hat, dann wurde es gemacht wenn es geht.
Dank Oracle ist Sun nicht mehr mit bei dser Standardisierung dabei, denn sie
haben Ihren Vertreter in dem Gremium sogar entlassen.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>> Das ist nicht nötig. Es gibt inzwischen diverse etnervte Anwender, die
>> frei verfügbare Pakete mit der Originalsoftware bauen.
>
>Wenn Dir das reicht, soll es mir (auch) Recht sein.
>Aber dann brauchst/darfst Du nicht nur auf "Debian" rumbashen (und schon
>gar nicht so pauschal. Hau' konkret wo hin.) und selber genau nichts dazu
>zu tun, daß sich die Situation in deinem Sinne verbessert.
>
>Einfach nur "die sind mbMn im Unrecht" und "aber ich will das so nicht" zu
>rufen und sonst nichts zu tun, ist jedenfalls nicht konstruktiv. Und es
>verhindert auch nichts ....
Ich habe eigentlich immer konkrete Aussagen gemacht. Das Problem sind eher die
Leute, die Debian meinen besch�tzen zu m�ssen ohne sich vorher um Fakten zu
k�mmern.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>> Wenn ich mich recht entsinne, hat Deine Ausgabe eine Geschwindigkeit von 1,3x
>> angezeigt.
>
>Oh, tatsächlich. Hab ich wohl beim cut&paste selber überlesen...
>
>Wegen dma hab ich schon irgendwo geschrieben, dass hdparm wegen der
>scsi-emu nicht anzeigt, ob dma oder nicht. Ich habe aber durchaus
>schon "Erfahrung" gemacht mit Systemen, die wegen irgendeines Fehlers
>auf pio mode schalteten, und sooo zuckelnd wie jene ist mein aktueller
>Rechner bei weitem nicht.
>
>Jedenfalls werde ich künftig mehr darauf achten, (mit oder ohne burnfree),
>dass ich während dem Brennen sonst nichts tu. Dass "burnfree" einfach
>bei leerem Buffer kaputte Sektoren einfügt, war mir nicht bewusst.
>Danke für die Hintergrund-info.
Wenn Dein Rechner in Ordnung ist und DMA verwendet, dann kannst Du
(vorrausgesetzt Du verwendest cdrecord und nicht wodim) nebenher fast machen
was Du willst. Cdrecord wird ja immer suid Root installiert und arbeitet in der
h�sten Realzeitpriorit�t und mit gegen Ausswwappen gelocktem Speicher.
Wenn das nicht funktioniert, dann hast Du noch ein anderes bisher nicht
erkanntes Problem.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
Andreas Leitgeb
> In article <slrnib86j...@gamma.logic.tuwien.ac.at>,
> Andreas Leitgeb <a...@logic.at> wrote:
>>> Wenn ich mich recht entsinne, hat Deine Ausgabe eine Geschwindigkeit von 1,3x
>>> angezeigt.
>> Oh, tatsächlich. Hab ich wohl beim cut&paste selber überlesen...
>> ... sooo zuckelnd wie jene ist mein aktueller Rechner bei weitem nicht.
>> Jedenfalls werde ich künftig mehr darauf achten, (mit oder ohne burnfree),
>
> Wenn Dein Rechner in Ordnung ist und DMA verwendet, dann kannst Du
> (vorrausgesetzt Du verwendest cdrecord und nicht wodim) nebenher fast machen
> was Du willst. Cdrecord wird ja immer suid Root installiert und arbeitet in der
Offenbar ist bei meinen Rechnern doch nicht alles in ordnung.
Mittlerweile ist die ubuntu-10.10 final heraussen, und "wollte" auch wieder
gebrannt werden. Diesmal hab ich es mal wieder mit CD-R's probiert, mit
seltsamen Effekten: Und mal wieder gleich vorweg:
Die Quote wodim:cdrtools steht nun grad 3:1 (korrekt gebrannte CDs)
wodim und cdrtools gemeinsam hatten, dass obwohl ich explizit speed=4 angegeben
habe, beide speed 10.0 ankündigten.
Bei wodim war es dann auch tatsächlich speed=10 (während des Brennens zeigte
er mir so zw. 9.8x und 10.7x auch eine recht konstante Brenn-geschwindigkeit
an, die auch mit den Geräuschen konsistent war. Der Buffer ging nie unter 90%
und die CDs waren anschließend korrekt lesbar.
cdrtools hingegen hatte (trotz ebenso konstanter, wenn auch hörbar nieder-
tourigerer Laufwerks-Geräusche) eine deutlich höhere Varianz bei der
angezeigten Geschwindigkeit: Sie variierte zwischen 1.2 und über 90(!).
" Average write speed 3.7x.
" Min drive buffer fill was 2%
" Total of 41 possible drive buffer underruns predicted.
jedoch ganz am ende:
" /opt/schily/bin/cdrecord: fifo was 0 times empty and 9152 times full, min fill was 85%.
An der Datenquelle kann's ja dann wohl doch nicht gelegen haben.
Das war diesmal übrigens nicht auf meiner alten lahmen Ente daheim,
sondern auf einem core 2 duo notebook.
cdrecord -atip auf den verwendeten Rohlingen (TDK):
ATIP info from disk:
Indicated writing power: 5
Disk Is not unrestricted
Disk Is not erasable
Disk sub type: Medium Type B, low Beta category (B-) (4)
ATIP start of lead in: -12369 (97:17/06)
ATIP start of lead out: 359849 (79:59/74)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 69
Manufacturer: Moser Baer India Limited
Manufacturer is guessed because of the orange forum embargo.
The orange forum likes to get money for recent information.
The information for this media may not be correct.
Ja, war wohl ein Fehlkauf, aber wodim kam damit ja trotzdem gut zurecht.
Um Zufälle unwahrscheinlicher zu machen, habe ich die TDK 10er Spindel
nun komplett nur diesem Thema gewidmet. Derzeit läuft grad ein zweiter
wodim-test diesmal in "script", sodass ich anschliessend alle momentan-
geschwindigkeiten nachvollziehen kann. (* Nachsatz, weil rechtzeitig vor
dem Abschicken dieses Posts fertig: auch die zweite wodim-CD war OK*)
Die verbleibenden 2 Rohlinge werden dann wieder mit den cdrtools
ge(oder ver)brannt. (* Und da ich mit dem Abschicken nun doch gleich auf's
Endergebnis wartete: Die beiden abschließenden cdrtools-versuche zeigten
(wie schon die zuvorigen) hohe Varianz bei der angezeigten Brenngeschwindig-
keit, sowie beim buffer-Füllstand. Anschließend prophezeite er eben wieder
mögliche buffer-underruns und letztlich hatte ich zwei weitere verbrannte
Rohlinge. *)
> Wenn das nicht funktioniert, dann hast Du noch ein anderes bisher nicht
> erkanntes Problem.
Das ist's dann wohl. Ich stehe für gezielte Diagnostik im Rahmen meiner
Möglichkeiten zur Verfügung. Für Versuche mit CD-R's müsste ich mir zwar
erst wieder eine neue Spindel kaufen. Das wäre es mir auch wert, sofern
die weiteren Versuche neue Aspekte (neue Optionen/Patches) einbringen.
Ad wodim vs cdrtools:
Auf bestimmten Straßen fährt man wohl mit viereckigen Rädern besser.
Bernd Petrovitsch
> In article <i91c09$n49$1...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>
>>> die frei verfÃŒgbare Pakete mit der Originalsoftware bauen.
>>
>>Wenn Dir das reicht, soll es mir (auch) Recht sein. Aber dann
>>brauchst/darfst Du nicht nur auf "Debian" rumbashen (und schon gar nicht
>>so pauschal. Hau' konkret wo hin.) und selber genau nichts dazu zu tun,
>>
>>Einfach nur "die sind mbMn im Unrecht" und "aber ich will das so nicht"
>>zu rufen und sonst nichts zu tun, ist jedenfalls nicht konstruktiv. Und
>>es verhindert auch nichts ....
>
> Ich habe eigentlich immer konkrete Aussagen gemacht. Das Problem sind
Ich beschütze Debian (wer oder was ist das konkret? Die "Projektleitung"?
Der "Debian-Projekt-Leader"? Die Menge aller Paketmaintainer? Irgendwas
dazwischen? ganz was anderes?) nicht.
Oder hast Du eh nur den/die Paketmaintainer des "cdrecord.deb" Pakets
gemeint (die sich erfrecht haben, einen (eigenen?) Patch mitzunehmen)?
Schau Dir mal die gcc und Kernel-Pakete von RedHat an, wenn Du Paket
mit wirklich vielen Distri-Patches sehen willst. Pakete ohne Distri-Patch
(for whatever reason) sind mbMn eher die Ausnahme wie die Regel.
> um Fakten zu kümmern.
Fakten wie
- längst überfälliges war im Upstream nicht eingebaut
- jemand (anderer) macht das
- jemand (wieder anderer?) shipped das in einem Paket einer großen
Linux-Distribution
- der Patch/das gepatchte Paket wird vom Upstream als "illegal", "Fork"
und/oder Kombination davon bezeichnet (ohne Erklärung, wie "Fork"
hier[0] definiert ist und "illegal" suggeriert juristische Deckung -
die wohl kaum da ist. Oder ist die CDDL so restriktiv?) und außer
Bashing läßt sich nicht konstruktives finden wie z.B. ein eigenes,
sauberes, besseres Paket.
Bernd
[0]: Ein Patch macht noch keinen Fork.
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>Ich beschütze Debian (wer oder was ist das konkret? Die "Projektleitung"?
>Der "Debian-Projekt-Leader"? Die Menge aller Paketmaintainer? Irgendwas
>dazwischen? ganz was anderes?) nicht.
>Oder hast Du eh nur den/die Paketmaintainer des "cdrecord.deb" Pakets
>gemeint (die sich erfrecht haben, einen (eigenen?) Patch mitzunehmen)?
Hast Du die anderen Artikel dazu nicht gelesen?
Ein Schwarzes Schaf kann es �berall geben. Wichtig f�r ein Projekt ist es
soein Problem im Sinne des Projektes l�sen zu k�nnen. Dabei hat Debian leider
versagt.
>Schau Dir mal die gcc und Kernel-Pakete von RedHat an, wenn Du Paket
>mit wirklich vielen Distri-Patches sehen willst. Pakete ohne Distri-Patch
>(for whatever reason) sind mbMn eher die Ausnahme wie die Regel.
Das Dr. Oetker Syndrom
Das ist das eigentliche Problem der Debian Paketierer.
Man k�nnte in eine Fertigkuchenmischung auch Eipulver tun. Das w�rde
aber frustrierte Hausfrauen produzieren, die sich in Folge f�r
�berfl�ssig hielten.
Die L�sung des Dr. Oetker Marketings war das Eipulver (bzw.
Milchpulver) wegzulassen und die Hausfrau aufzufordern selbst
besorgte frische Ware dazuzutun. Damit hatte die Hausfrau den
Eindruck selbst etwas wesentliches zum Kuchen beigetragen zu haben
und war zufrieden.
Gute Software die ohne manuelle Eingriffe einfach kompiliert scheint
wie eine 100%-komplett Backmischung zu sein. Sie erzeugt Frust bei
den Paketierern.
Leute die neben ihrer Arbeit als Paketierer auch noch eigenst�ndige
Arbeit machen sind eher nicht von diesem Problem betroffen, weil sie
sich ihre Best�tigung an anderer Stelle holen k�nnen.
Gerade Debian ist aber daf�r bekannt, da� es an _vielen_ Paketen
unsinnige �nderungen gibt. Auch Herr Bloch hatte ab Anfang 2004 statt
neue Cdrtools Versionen zu paketieren lieber alte Versionen mit
eigenen Bugs versch�nert und damit fast 100 Eintr�ge im Debian
Bugtrackingsystem erzeugt.
>> um Fakten zu kümmern.
>
>Fakten wie
>- längst überfälliges war im Upstream nicht eingebaut
>- jemand (anderer) macht das
>- jemand (wieder anderer?) shipped das in einem Paket einer großen
> Linux-Distribution
Nun, es gab ja wohl kein Problem, sonst h�tte jemand anderes wohl etwas
funktionierendes zur L�sung dieses angeblichen Problems gebaut.
> und/oder Kombination davon bezeichnet (ohne Erklärung, wie "Fork"
> hier[0] definiert ist und "illegal" suggeriert juristische Deckung -
> die wohl kaum da ist. Oder ist die CDDL so restriktiv?) und außer
> Bashing läßt sich nicht konstruktives finden wie z.B. ein eigenes,
> sauberes, besseres Paket.
??? Ich bin mir nicht sicher ob Du das Problem verstanden hast.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Ad wodim vs cdrtools:
>Auf bestimmten Straßen fährt man wohl mit viereckigen Rädern besser.
Wenn es um Zuf�lle geht, dann mu�t Du erheblich mehr Ergebnisse kennen.
Ich habe bislang noch niemanden kennengelernt, der mit wodim besser leben
konnte als mit dem Original.
Andreas Leitgeb
> Andreas Leitgeb <a...@logic.at> wrote:
>> Ad wodim vs cdrtools:
>> Auf bestimmten Straßen fährt man wohl mit viereckigen Rädern besser.
> Ich habe bislang noch niemanden kennengelernt, der mit wodim besser leben
> konnte als mit dem Original.
Ich weiß ja nicht, ob du da jetzt nur Leute zählst, die du zusätzlich auch
persönlich kennengelernt hast, aber wenn du von dir zur Kenntnis gebrachten
Vorfällen redest, dann musst du ab nun wohl "erst einen" sagen.
PS: ich nehme zur Kenntnis, dass du am eigentlichen Fehlersymptom und seiner
Diagnose offenbar auch nicht mehr interessiert bist, als die debianpaket-
bauer an deinen bugreports.
David Wührer
> Auch Herr Bloch hatte ab Anfang 2004 statt
> neue Cdrtools Versionen zu paketieren lieber alte Versionen mit
> eigenen Bugs versch�nert und damit fast 100 Eintr�ge im Debian
> Bugtrackingsystem erzeugt.
>
> funktionierendes zur L�sung dieses angeblichen Problems gebaut.
Wie hat das RedHat eigentlich gelöst, Dateien mit UTF8-Dateinamen zu
brennen, bevor cdrtools das unterstützte?
Bernd Petrovitsch
> In article <i94jjm$5rm$2...@cherenkov.luga.at>, Bernd Petrovitsch
> <be...@bofh.at> wrote:
>
>>"Projektleitung"? Der "Debian-Projekt-Leader"? Die Menge aller
>>Paketmaintainer? Irgendwas dazwischen? ganz was anderes?) nicht. Oder
Du bist hier eine *konkrete* Antwort schuldig.
>>hast Du eh nur den/die Paketmaintainer des "cdrecord.deb" Pakets gemeint
>>(die sich erfrecht haben, einen (eigenen?) Patch mitzunehmen)?
>
> Hast Du die anderen Artikel dazu nicht gelesen? Ein Schwarzes Schaf kann
> es überall geben. Wichtig für ein Projekt ist es soein Problem im Sinne
Die gibt es überall. So what?
> des Projektes lösen zu können. Dabei hat Debian leider versagt.
Und wieder kommt nur pauschales und nichts konkretes.
>>Schau Dir mal die gcc und Kernel-Pakete von RedHat an, wenn Du Paket mit
>>wirklich vielen Distri-Patches sehen willst. Pakete ohne Distri-Patch
>>(for whatever reason) sind mbMn eher die Ausnahme wie die Regel.
>
> Das Dr. Oetker Syndrom
>
> Das ist das eigentliche Problem der Debian Paketierer.
Das ist das Problem *aller* Paketierer - egal, ob Debian, SuSE, RedHat,
Fedora, NetBSD, OpenBSD, FreeBSD oder Solaris.
Der Upstream liefert etwas, daß ich mit (z.B.) `configure; make; make
install` bauen und installieren kann.
Aber das ist nur der halbe Spaß - eine Distribution/System/OS bringt
mehr mit als ein volles /usr/local/bin:
- zum einen gehören die Files nach /usr/bin /oder /usr/sbin oder /bin
oder /sbin oder ...
- dann braucht es Konfigfiles - die will die eine Distri in /etc/$PAKET
haben, die nächste in /etc/$PAKET.conf und manchen ist es egal.
- dann will man ein Default-Konfigfile mitschicken
- dann braucht es Menüeinträge für KDE, GNOME, ...
u.v.m.
> Man könnte in eine Fertigkuchenmischung auch Eipulver tun. Das würde
> aber frustrierte Hausfrauen produzieren, die sich in Folge für
> Überflüssig hielten.
>
> Die Lösung des Dr. Oetker Marketings war das Eipulver (bzw. Milchpulver)
> wegzulassen und die Hausfrau aufzufordern selbst besorgte frische Ware
> dazuzutun. Damit hatte die Hausfrau den Eindruck selbst etwas
> wesentliches zum Kuchen beigetragen zu haben und war zufrieden.
Und wenn sie ein bißchen was anders macht wie das übliche Rezept, dann
wird es "besser" oder "schlechter". So what - ist ihre Entscheidung und
sie bekommt die Auswirkungen zu spüren?
Hat der Rezept-Autor das Recht, lokale Anpassungen zu verbieten oder gar
zu verhindern oder im nachhinein drüber zu ranten (so a la "das waren
illegale Rezeptänderungen" oder "die Hausfrau hat ja alles dort nur
schlechter gemacht")?
q.e.d.
> Gute Software die ohne manuelle Eingriffe einfach kompiliert scheint wie
> eine 100%-komplett Backmischung zu sein. Sie erzeugt Frust bei den
> Paketierern.
Du hast offensichltlich nie Paketierer für eine Distribution gemacht.
Oder bestenfalls für genau ein System/Distribution - warauf der Upstream
natürlich die Regeln dieses eine implementiert/einhält.
Ich bin über jede Software froh, die sich ohne Patches und großes
Rumbasteln paketieren läßt. Das macht initial Aufwand und laufend
Aufwand.
Klar, ich habe sowas auch schon Richtung Upstream geschickt - manche
nehmen es freudig so wie es ist, manche nehmen das, was ihnen sinnvoll
erscheint und andere ignorieren einen im wesentlichen.
Dann überlegt man sich, ob man das Paket überhaupt weiterpflegen will
(oder es halt nur für sich selber macht).
> Leute die neben ihrer Arbeit als Paketierer auch noch eigenständige
> Arbeit machen sind eher nicht von diesem Problem betroffen, weil sie
> sich ihre Bestätigung an anderer Stelle holen können.
>
> Gerade Debian ist aber dafür bekannt, daß es an _vielen_ Paketen
> unsinnige Änderungen gibt. Auch Herr Bloch hatte ab Anfang 2004 statt
Alle Pauschalurteile sind falsch. SCNRA ...
> neue Cdrtools Versionen zu paketieren lieber alte Versionen mit eigenen
> Bugs verschönert und damit fast 100 Einträge im Debian Bugtrackingsystem
> erzeugt.
Tja, er wird seine Gründe gehabt haben - nachvollziehbar oder nicht, gut
oder nicht gut.
Hättest halt eine besseres Debian-Paket als bessere Alternative gemacht
- mit oder ohne offiziellem Segen von "Debian".
Wenn seines Schrott ist und deines funktioniert, werden es die Leute
verwenden - auch wenn es nicht offiziell von "Debian" abgesegnet ist.
Nur mit Dreck werfen ist jedenfalls (viel) zu wenig .....
>>> um Fakten zu kÃŒmmern.
>>
>>Fakten wie
>>- lÀngst ÌberfÀlliges war im Upstream nicht eingebaut - jemand
>>(anderer) macht das
>>- jemand (wieder anderer?) shipped das in einem Paket einer großen
>> Linux-Distribution
>
> Nun, es gab ja wohl kein Problem, sonst hätte jemand anderes wohl etwas
> funktionierendes zur Lösung dieses angeblichen Problems gebaut.
Oder es war zumindest "gut genug". Und/oder einer/viele/alle waren zu
faul, die - kleinen oder nicht so kleinen - Probleme/Bugs zu fixen bzw.
an einer Lösung mitzuhelfen.
Nur Ranten, Basdhen, schimpfen (egal auf wen) bringt praktisch niemandem
etwas.
BTW der Trick mit dem "jetzt treiben wir es ins andere Extrem, um eine
Negation zu erreichen, die wir dann ganz woanders anwenden" zieht
nicht.
>> und/oder Kombination davon bezeichnet (ohne ErklÀrung, wie "Fork"
>> hier[0] definiert ist und "illegal" suggeriert juristische Deckung -
>> die wohl kaum da ist. Oder ist die CDDL so restriktiv?) und außer
>> Bashing lÀßt sich nicht konstruktives finden wie z.B. ein eigenes,
>> sauberes, besseres Paket.
>
> ??? Ich bin mir nicht sicher ob Du das Problem verstanden hast.
Zum einen ist das eine Bestätigung der Fakten oben.
Zum anderen: Warum fühlst Du Dich ursächlich zuständig und verantwortlich,
wenn $MENSCH eine schlechtes Paket (bzw. Patches) macht (selbst wenn
sie für deine Software sind)?
Schick' die Leute zum Paket/Patch-"Verursacher" oder rate ihnen, dein
Original zu verwenden. Problem für Dich gelöst und alle Probleme, die
der Paketmaintainer verursacht hat, bekommt er diekt ab und wird draus
lernen und die beheben.
Der Upstream kann ja nichts für einen Paketierer, der es nicht gut (genug)
macht. Oder mach ein besseres Paket (oder finde jemanden, der es tut). Oder
Review die Patches und hilf dem ach-so-schlechten Patchschreiber ein wenig.
Aber die einzige Reaktion, die ich im Laufe der Jahre mitbekommen hast,
ist nur Ranting und Bashing mit zumindest unpassenden Worten wie "illegal"
oder offensichtlich anders definierten wie "Fork".
Bernd
Joerg Schilling
Bernd Petrovitsch <be...@bofh.at> wrote:
>Nur mit Dreck werfen ist jedenfalls (viel) zu wenig .....
Danke da� Du best�tigst, das sich Debian nicht korrekt verhalten hat.
Debian hat (seit dem Bloch der Paketierer wurde) niemals versucht
zusammenzuarbeiten sondern immer nur mit Dreck geworfen. Das zeigt da�
Debian ein soziales Problem hat. Und nun sollten wir diese Diskusion, die seit
Langem keine neuen Ideen mehr von Dir bringt beenden.
Joerg Schilling
Sie konnten es nicht und sie k�nnen es noch heute nicht weil sie den defekten
Fork statt der Originalsoftware vertreiben.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>PS: ich nehme zur Kenntnis, dass du am eigentlichen Fehlersymptom und seiner
> Diagnose offenbar auch nicht mehr interessiert bist, als die debianpaket-
> bauer an deinen bugreports.
Ich bin im Gegensatz zu den Debian-Leuten sehr wohl an Fehlersymptomen
interessiert, nur lieferst Du nichts das es erlauben w�rde Dir zu helfen.
Deine Behauptung, es w�rde mit wodim weniger Probleme geben ist jedenfalls
absolut nicht hilfreich, denn niemand kann auf Basis von Zufallserfolgen
Aussagen treffen.
Zudem habe ich Dir die vermutliche Ursache Deines Problems schon vor Tagen
erkl�rt. Sorge doch erstmal daf�r, da� Dein System DMA macht und teste dann mit
aktueller Originalsoftware (suid root installiert oder als root aufgerufen)
nocheinmal. Ich bin mir zu 99,9% sicher, da� Deine Probleme dann nicht mehr
existieren. Solange Du jedenfalls ein System mit einem bekannten Problem
betreibst kann Dir niemand helfen.
Dein System schreibt in 1,3-facher Geschwindigkeit, cdrecord k�nnte aber selbst
in dem rechenaufwendigen RAW-Modus auf einem halbwegs aktuellen 2,4 GHz System
(nicht �lter als 5-6 Jahre) CDs in 500-700-facher Geschwindigkeit schreiben
falls es Rohlinge f�r diese Geschwindigkeit g�be und die DMA Deines Rechners
das herg�be.
Hast Du Dir �berhaupt mal die M�he gemacht die cdrecord Man Page zu lesen?
Hast Du vielleicht unsinnigerweise Brenner und Festplatte am selben PATA Kabel?
W��test Du (siehe Man page) welchen Workaround cdrecord f�r so ein
fehlkonfiguriertes System anbietet?
Ist Dein PATA Kabel vielleicht defekt?
Hast Du nur ein 40-poliges Kabel zum Brenner, statt des f�r DMA notwendigen
80-poligen Kabels?
Statt Dich um das Problem Deines Rechners zu k�mmern, hast Du leider in den
letzen Tagen nur statistisch irrelevante Zufallsergebnisse von wodim erw�hnt.
Andreas Leitgeb
> Ich bin im Gegensatz zu den Debian-Leuten sehr wohl an Fehlersymptomen
Ich liefere alles, was mir an Information zur Verfuegung steht.
Und ich warte geduldig auf weitere Vorschlaege (optionen, etc), die
es mir ermoeglichen wuerden, nuetzlichere Informationen zurueckliefern
zu koennen. Eine Testreihe mit -V habe ich auch gemacht: Ergebnis siehe
unten.
Ich hatte ja anfangs auch mit wodim Probleme, sonst haette ich diesen
Thread gar nicht erst angefangen. Jedoch hat die von dir vorgeschlagene
Option -raw96r bei wodim nun zu einer seither 100% success-rate gefuehrt,
egal ob CD-R oder CD-RW, waehrend cdrecord mit CD-RW 1 mal gut ging, und
mit CD-Rs seither noch *kein einziges mal*(!) gut ging.
Ich gehe davon aus, dass cdrecord aus irgendeiner System-antwort eine
Annahme ueber meine Hardware trifft, die letztlich kontraproduktiv ist.
Wodim kommt vielleicht gar nicht erst auf die Idee, die entsprechende
Abfrage zu machen, oder ignoriert Teile des Ergebnisses, was fuer dieses
Modell von Laufwerk (und vl auch andere) aber offenbar *gut* ist.
An reinen Zufall kann ich nach meinen bisherigen Tests jedenfalls bei
bestem Willen nicht mehr glauben. Immerhin waren bis dato zwei Rechner
(und somit 2 laufwerke) und ca 10 ver/ge-brannte Rohlinge alleine fuer
die tests mit -raw96r involviert, und das Ergebnis kein "eher...",
sondern ein "100% vs 0%".
Weitere Diagnose (mit -V):
Ich habe hier nun zwei log-files von jeweils einem cdrecord und einem
wodim Brenn-lauf, jeweils mit optionen -v -V -raw96r speed=52 ubu*.iso
Was mir auffaellt ist, dass cdrecord (im gegensatz zu wodim) anfangs
mal alle scsi-busse und targets abklappert, obwohl das CD-Laufwerk
bereits als 0,0,0 aufscheint. (die Festplatte taucht dann als 2,0,0
auf, was zumindest mal die "haengen am gleichen bus"-theorie hier
am laptop entkraeften duerfte)
Irgendwo spaeter schreiben beide ihre Vermutungen ueber mein LW:
cdrecord:
Drive DMA Speed: 8070 kB/s 45x CD 5x DVD 1x BD
FIFO size : 4194304 = 4096 KB
Encoding speed : 346x (25932 sectors/s) for libedc from Heiko Eißfeldt
wodim:
Drive DMA Speed: 13112 kB/s 74x CD 9x DVD
FIFO size : 12582912 = 12288 KB
Encoding speed : 349x (26138 sectors/s) for libedc from Heiko Eißfeldt
(das iso8859-1 kodierte scharfe s fuer's posting utf-8-isiert.)
cdrecord meldet dann noch, dass es burnfree abschaltet.
Ab dem Zeitpunkt, wo dann gleich das eigentliche Brennen beginnt, kriegt
cdrecord auf gleiche Anfragen ("test unit ready" und "mode sense g1") leicht
unterschiedliche Antworten als wodim zurueck, und ab dem ersten "write_g1"
sind die Daten auch verschieden (aber jeweils erfolgreich):
cdrecord: CDB: 2A 00 FF FF D2 8E 00 00 0D 00
wodim: CDB: 2A 00 FF FF D2 8E 00 00 1A 00
einige solche Bloecke spaeter kriegt cdrecord einen Fehler zurueck:
Executing 'write_g1' command on Bus 0 Target 0, Lun 0 timeout 40s
CDB: 2A 00 FF FF D2 E9 00 00 0D 00
/opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB: 2A 00 FF FF D2 E9 00 00 0D 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 0A FF FF D2 80 04 08 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after ##s timeout 40s
(das ##s war ein ":%s/after [0-9.]*s/after ##s/" um nicht fuer jede
hundertstel sekunden Abweichung eine eigene diff-zeile zu kriegen)
Bei wodim ging dieser write_g1, so wie auch alle weiteren erfolgreich ab.
Die weitere Beschreibung des diffs wuerde den Rahmen des Postings
sprengen, aber ich sende, wenn es dir sinnvoll scheint, gerne die
zwei logfiles (zusammen ca. 10MB), oder auch jeweils nur die
relevanten Anfangsteile per email zu.
Johann Mayerwieser
> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein
> Äutzerl zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft,
> merkt zwar eh, dass es nicht gepasst hat - nur halt eben erst danach.
>
>
ich lade mir gerade von <http://cdimage.ubuntu.com/releases/10.10/release/
> das Image herunter, das heruntergeladene ISO hat folgenden Namen:
ubuntu-10.10-dvd-i386.iso
Fällt dir was auf? Zum ersten Mal scheint Canonical von der CD abgegangen
zu sein, in der URL hätte man aber auch statt cdimage das richtige Wort
dvdimage einsetzen sollen.
Liebe Grüße
Hannes
--
Für persönliche Nachricht Reply-Adresse verwenden und "usenet" im Betreff
einfügen.
Johann Mayerwieser
> Andreas Leitgeb schrieb:
>
>> Eine kleine "Warnung": Das iso-image für desktop-i386 ist um ein
>> Äutzerl zu groß für einen 700MB-Rohling. Wer immer brav mdsum prüft,
>> merkt zwar eh, dass es nicht gepasst hat - nur halt eben erst danach.
>>
>>
>>
> ich lade mir gerade von
> <http://cdimage.ubuntu.com/releases/10.10/release/
>> das Image herunter, das heruntergeladene ISO hat folgenden Namen:
> ubuntu-10.10-dvd-i386.iso
> Fällt dir was auf? Zum ersten Mal scheint Canonical von der CD
> abgegangen zu sein, in der URL hätte man aber auch statt cdimage das
> richtige Wort dvdimage einsetzen sollen.
>
Tja - da scheinen alle Ubuntu-Versionen drinnen zu sein (auch Kubuntu,
Edubuntu...) - werden 4 GByte, habe abgebrochen.
Andreas Leitgeb
>> ich lade mir gerade von
>> <http://cdimage.ubuntu.com/releases/10.10/release/
>>> das Image herunter, das heruntergeladene ISO hat folgenden Namen:
>> ubuntu-10.10-dvd-i386.iso
Das Problem war letztlich ein anderes. wodim schaffte es nicht,
das cd (nicht dvd!) image auf einen Rohling zu brennen.
Für den Rest, wenn er dich noch interessiert, lies (oder überflieg)
einfach die aktuellen threads. (abseits davon ist sonst eh grad nix los)
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> Ich bin im Gegensatz zu den Debian-Leuten sehr wohl an Fehlersymptomen
>> interessiert, nur lieferst Du nichts das es erlauben wuerde Dir zu helfen.
>
>Ich liefere alles, was mir an Information zur Verfuegung steht.
>Und ich warte geduldig auf weitere Vorschlaege (optionen, etc), die
>es mir ermoeglichen wuerden, nuetzlichere Informationen zurueckliefern
>zu koennen. Eine Testreihe mit -V habe ich auch gemacht: Ergebnis siehe
>unten.
Nur das Du leider nicht auf die Hinweise reagierst die man Dir gibt.
>Ich hatte ja anfangs auch mit wodim Probleme, sonst haette ich diesen
>Thread gar nicht erst angefangen. Jedoch hat die von dir vorgeschlagene
>Option -raw96r bei wodim nun zu einer seither 100% success-rate gefuehrt,
>egal ob CD-R oder CD-RW, waehrend cdrecord mit CD-RW 1 mal gut ging, und
>mit CD-Rs seither noch *kein einziges mal*(!) gut ging.
Inzwischen hast Du ja wenigstens einen Hinweis darauf gegeben was Du mit
cdrecord falsch machst....
>Ich gehe davon aus, dass cdrecord aus irgendeiner System-antwort eine
>Annahme ueber meine Hardware trifft, die letztlich kontraproduktiv ist.
>Wodim kommt vielleicht gar nicht erst auf die Idee, die entsprechende
>Abfrage zu machen, oder ignoriert Teile des Ergebnisses, was fuer dieses
>Modell von Laufwerk (und vl auch andere) aber offenbar *gut* ist.
>
>An reinen Zufall kann ich nach meinen bisherigen Tests jedenfalls bei
>bestem Willen nicht mehr glauben. Immerhin waren bis dato zwei Rechner
>(und somit 2 laufwerke) und ca 10 ver/ge-brannte Rohlinge alleine fuer
>die tests mit -raw96r involviert, und das Ergebnis kein "eher...",
>sondern ein "100% vs 0%".
Kein Wunder wenn Du die Ratschl�ge nicht umsetzt....
>Weitere Diagnose (mit -V):
>
>Ich habe hier nun zwei log-files von jeweils einem cdrecord und einem
>wodim Brenn-lauf, jeweils mit optionen -v -V -raw96r speed=52 ubu*.iso
>
>Was mir auffaellt ist, dass cdrecord (im gegensatz zu wodim) anfangs
>mal alle scsi-busse und targets abklappert, obwohl das CD-Laufwerk
>bereits als 0,0,0 aufscheint. (die Festplatte taucht dann als 2,0,0
>auf, was zumindest mal die "haengen am gleichen bus"-theorie hier
>am laptop entkraeften duerfte)
Cdrecord ist halt im Gegensatz zu wodim automatisiert und pr�ft ob Du genau
einen Brenner hast.
>Irgendwo spaeter schreiben beide ihre Vermutungen ueber mein LW:
>cdrecord:
> Drive DMA Speed: 8070 kB/s 45x CD 5x DVD 1x BD
> FIFO size : 4194304 = 4096 KB
> Encoding speed : 346x (25932 sectors/s) for libedc from Heiko Eißfeldt
Was f�r einen lahmen Rechner hast Du denn da?
Ich habe seit 5 Jahren keinen aktuellen PC mehr gesehen, der weniger als 500x
bei der Reed-Solomon Kodierung schafft.
Auch die Transfergeschwindigkeit ist zuwenig f�r funktionierende DMA, wenn auch
eigentlich zu schnell f�r PIO.
>cdrecord meldet dann noch, dass es burnfree abschaltet.
Und warum hast Du meine Hinweise es einzuschalten ignoriert?
Da Dein System ja, wie bereits bekannt, so extrem langsam ist, da� es nur
1,3fache Geschwindigkeit schafft, sollte wohl klar sein das ohne Burnfree ein
Brennen unm�glich ist. Da cdrecord konfektionierbar ist, kann man es sogar
einstellen, da� burnfree per default an ist.
>Ab dem Zeitpunkt, wo dann gleich das eigentliche Brennen beginnt, kriegt
>cdrecord auf gleiche Anfragen ("test unit ready" und "mode sense g1") leicht
>unterschiedliche Antworten als wodim zurueck, und ab dem ersten "write_g1"
>sind die Daten auch verschieden (aber jeweils erfolgreich):
> cdrecord: CDB: 2A 00 FF FF D2 8E 00 00 0D 00
> wodim: CDB: 2A 00 FF FF D2 8E 00 00 1A 00
wodim scheint die R�ckmeldung des Kerns �ber die maximale Transfergr��e zu
ignorieren....
>einige solche Bloecke spaeter kriegt cdrecord einen Fehler zurueck:
> Executing 'write_g1' command on Bus 0 Target 0, Lun 0 timeout 40s
> CDB: 2A 00 FF FF D2 E9 00 00 0D 00
> /opt/schily/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
> CDB: 2A 00 FF FF D2 E9 00 00 0D 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 02 00 00 00 00 0A FF FF D2 80 04 08 00 00
> Sense Key: 0x2 Not Ready, Segment 0
> Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) Fru 0x0
> Sense flags: Blk 0 (not valid)
> cmd finished after ##s timeout 40s
>(das ##s war ein ":%s/after [0-9.]*s/after ##s/" um nicht fuer jede
> hundertstel sekunden Abweichung eine eigene diff-zeile zu kriegen)
>Bei wodim ging dieser write_g1, so wie auch alle weiteren erfolgreich ab.
Das ist doch nur eine hinweis-Meldung des LW an cdrecord auf die cdrecord auch
korrekt reagiert.
Wenn Du bei wodim keine solche Meldungen siehst spricht das eher f�r ein
Problem bei wodim.....bzw. daf�r da� Du mit wodim nicht im RAW Modus
geschrieben hast.
Fazit: wenn Du cdrecord und wodim mit unterschiedlichen Randbedingungen
betreibst, solltest Du Dich auch nicht �ber unterschiedliche Ergebnisse
wundern. Du hast letztlich bewiesen, da� wodim keinesfalls irgendwelche
Vorteile gegen cdrecord bietet.
Andreas Leitgeb
>> cdrecord meldet dann noch, dass es burnfree abschaltet.
> Und warum hast Du meine Hinweise es einzuschalten ignoriert?
Da muss es wohl ein Missverstaendnis gegeben haben... Ich hatte deine
Kommentare so verstanden, dass "burnfree" letztlich per design "kaputte"
CDs erzeugt, und sich mit "raw96r" sowieso nur bei ganz wenigen Brennern
ueberhaupt kombinieren laesst und deswegen prinzipiell schlecht ist und
deswegen per default off.
Habe nun die Gegentests gemacht:
wodim -driveropts=noburnfree -v -V -raw96r speed=24 ubu*.iso
Die brenngeschwindigkeit war anfangs 16 und schaltete
zwischendrin auf 24
Muss ich's dazusagen, dass die CD fehlerfrei lesbar war? Ja? Na gut:
Sie war auch ohne burnfree fehlerfrei gebrannt und wiedereinlesbar.
im Gegenzug blieb cdrecord mit gleichen optionen, ausser
-driveropts=burnfree (also ohne "no")
irgendwann einfach stecken:
" Executing 'write_g1' command on Bus 1 Target 0, Lun 0 timeout 40s
" CDB: 2A 00 FF FF D5 11 00 00 0D 00
" /opt/schily/bin/cdrecord: faio_wait_on_buffer for writer timed out.
"
" Executing 'flush cache' command on Bus 1 Target 0, Lun 0 timeout 120s
" CDB: 35 00 00 00 00 00 00 00 00 00
Und da haengt er grad und zwar schon laenger als 120s.
(nur der cdrecord - das restl. System rennt fluessig)
Klar, es ist's das Laufwerk, das da blockiert, aber von wodim
gestreichelt blieb es eben nicht haengen - reproduzierbar.
> Da Dein System ja, wie bereits bekannt, so extrem langsam ist, dass es nur
> 1,3fache Geschwindigkeit schafft,
Das Ignorieren beruht offenbar auf Gegenseitigkeit.
sowohl wodim (mit -raw96r) als auch cdrdao brennen flott und verlaesslich.
Nur cdrecord kennt sich mit meiner HW offenbar nicht aus, und steuert sie
so an, dass sie langsam ist und fehlerhafte Ergebnisse bringt.
Und dann wiederholst du zum x-ten mal den Unsinn, dass mein *System*
nur 1,3x schafft... anstatt korrekt: "*cdrecord* schafft auf dem system
nur 1,3x - und nichteinmal das ohne Fehler".
>> Ab dem Zeitpunkt, wo dann gleich das eigentliche Brennen beginnt, kriegt
>> cdrecord auf gleiche Anfragen ("test unit ready" und "mode sense g1") leicht
>> unterschiedliche Antworten als wodim zurueck, und ab dem ersten "write_g1"
>> sind die Daten auch verschieden (aber jeweils erfolgreich):
>> cdrecord: CDB: 2A 00 FF FF D2 8E 00 00 0D 00
>> wodim: CDB: 2A 00 FF FF D2 8E 00 00 1A 00
> wodim scheint die Rueckmeldung des Kerns ueber die maximale Transfergroesse zu
> ignorieren....
Ist es technisch plausibel, dass *das* der Grund ist, warum's mit wodim geht?
Koennte das Aufzaehlen aller Geraete damit zu tun haben? (immerhin schaut er
dabei ja auch andere scsi-busse, wie den wo der USB-Multi Flash Reader
dranhaengt), an.
Was fuer parameter koennten cdrecord zu einer hoeheren Transfergroesse ueberreden,
als die vom Kernel als maximal angegebene? (ts=# ist ja beschrieben, dass es
eben nicht ueber's kernel-max druebergeht)
Fuer einen Test mit einer solchen Option wuerde ich noch einen Rohling
spendieren - ansonsten mach ich ein "rm -rf /opt/schily" und lass es
damit gut sein.
PS: Fuer's weiter-experimentieren mit dem Brenner werd ich wohl meinen Rechner
neustarten muessen, weil sich das Laufwerk vom Abbruch des cdrecord mit ^C
noch nicht erholt hat, und der aufruf mit -abort nun mit status "D" haengt.
Abseits davon ist das System aber noch ok, sodass ich diese Meldung noch
fertigschreiben und abschicken kann.
Joerg Schilling
Das sieht danach aus, als ob Du ein extremes Performanceproblem auf dem System
hast. Warum beantwortest Du eigentlich meine Fragen? Ich habe Dich schon letzte
Woche danach gefragt, ob Du Brenner und Platte am gleichen Kabel hast....
>
>> Da Dein System ja, wie bereits bekannt, so extrem langsam ist, dass es nur
>> 1,3fache Geschwindigkeit schafft,
>
>Das Ignorieren beruht offenbar auf Gegenseitigkeit.
>sowohl wodim (mit -raw96r) als auch cdrdao brennen flott und verlaesslich.
>Nur cdrecord kennt sich mit meiner HW offenbar nicht aus, und steuert sie
>so an, dass sie langsam ist und fehlerhafte Ergebnisse bringt.
> Und dann wiederholst du zum x-ten mal den Unsinn, dass mein *System*
>nur 1,3x schafft... anstatt korrekt: "*cdrecord* schafft auf dem system
>nur 1,3x - und nichteinmal das ohne Fehler".
>
>>> Ab dem Zeitpunkt, wo dann gleich das eigentliche Brennen beginnt, kriegt
>>> cdrecord auf gleiche Anfragen ("test unit ready" und "mode sense g1") leicht
>>> unterschiedliche Antworten als wodim zurueck, und ab dem ersten "write_g1"
>>> sind die Daten auch verschieden (aber jeweils erfolgreich):
>>> cdrecord: CDB: 2A 00 FF FF D2 8E 00 00 0D 00
>>> wodim: CDB: 2A 00 FF FF D2 8E 00 00 1A 00
>> wodim scheint die Rueckmeldung des Kerns ueber die maximale Transfergroesse zu
>> ignorieren....
>
>Ist es technisch plausibel, dass *das* der Grund ist, warum's mit wodim geht?
Dein System ist ganz offenbar nicht korrekt konfiguriert und da kann dann alles
M�gliche passieren.
>Was fuer parameter koennten cdrecord zu einer hoeheren Transfergroesse ueberreden,
>als die vom Kernel als maximal angegebene? (ts=# ist ja beschrieben, dass es
>eben nicht ueber's kernel-max druebergeht)
>
>Fuer einen Test mit einer solchen Option wuerde ich noch einen Rohling
>spendieren - ansonsten mach ich ein "rm -rf /opt/schily" und lass es
>damit gut sein.
Aha, Du ignorierst also alle Ratschl�ge und brigst Dein System nicht in
Ordnung.
>PS: Fuer's weiter-experimentieren mit dem Brenner werd ich wohl meinen Rechner
> neustarten muessen, weil sich das Laufwerk vom Abbruch des cdrecord mit ^C
> noch nicht erholt hat, und der aufruf mit -abort nun mit status "D" haengt.
> Abseits davon ist das System aber noch ok, sodass ich diese Meldung noch
> fertigschreiben und abschicken kann.
Du hast da zumindest zus�tzlich den Beweis, da� Dein Kern defekt ist, denn so
ein H�nger darf unter keinen Umst�nden vorkommen. Ausl�ser kann (wie bereits
erw�hnt) ein defektes Kabel (aber auch der defekte Kern selbst) sein.
Andreas Leitgeb
Das ist ein wortwoertliches Zitat:
> Warum beantwortest Du eigentlich meine Fragen?
Das frage ich mich mittlerweile auch. Ich dachte, es waere was Gutes,
cdrecord ein wenig stabiler auch gegenueber *un-perfekter* Hardware zu
machen, aber der Autor hat daran offenbar kein Interesse, obwohl es
andere Software gibt, die die Probleme mit derselben Hardware reprodu-
zierbar *nicht* hat.
>>> wodim scheint die Rueckmeldung des Kerns ueber die maximale Transfergroesse zu
>>> ignorieren....
>> Ist es technisch plausibel, dass *das* der Grund ist, warum's mit wodim geht?
> Dein System ist ganz offenbar nicht korrekt konfiguriert und da kann dann alles
> Moegliche passieren.
Nur, dass cdrecord mal korrekt CD-Rs brennt, scheint nicht im Bereich des
Moeglichen zu sein.
> Aha, Du ignorierst also alle Ratschlaege und brigst Dein System nicht in
> Ordnung.
Korrekt. "/opt/schily/bin/cdrecord" alleine ist fuer mich nicht genug Grund,
mir einen neuen Rechner zu kaufen, oder das Linux durch opensolaris zu
ersetzen, solange wodim damit noch hinreichend schnell (sprich: mit 24x)
und verlaesslich(!) funktioniert und auch sonst keine Probleme erkennbar
sind.
Entweder, du hast Interesse daran, cdrecord "besser" zu machen (was eben
auch die Einsetzbarkeit auf aelteren Rechnern einschliesst), oder du hast
es eben nicht. Auf einem Schoenwetter-geraet laeuft bald einmal was.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>Das ist ein wortwoertliches Zitat:
>> Warum beantwortest Du eigentlich meine Fragen?
>
>Das frage ich mich mittlerweile auch. Ich dachte, es waere was Gutes,
>cdrecord ein wenig stabiler auch gegenueber *un-perfekter* Hardware zu
>machen, aber der Autor hat daran offenbar kein Interesse, obwohl es
>andere Software gibt, die die Probleme mit derselben Hardware reprodu-
>zierbar *nicht* hat.
OK, ich mu� also leider davon ausgehen, da� Du nie ein ernsthaftes Interesse an
Hilfe hattest.
Dein System has mehrere offensichtliche Probleme (mindestens DMA Probleme und
einen Kern der sich aufh�ngt). Du hast Fragen zu Deiner Konfiguration auch nach
mehrfachem Wiederholen nicht beantwortet. Du hast bislang anscheinend auch
keine Anstrengungen unternommen die benannten Probleme Deines Rechners zu
beseitigen.
So wie Du Dich verh�lst kann Dir niemand helfen.
Wolfgang Zweimueller
Ach, ist das lieb! Kennt ihr Steinböcke? Die rennen sich auch
gegenseitig die Schädel ein und wissen gar nicht mal warum!
Wie wärs, wenn jeder mal einen Schritt zurück macht und die Sachlage
mit etwas weniger Emotionen betrachtet. Man kann z.B. auch mal von
seiner eingeschlagenen Richtung abweichen und echt was verbessern!
Wobei ich schon auch feststellen muss, dass einer von euch für
Argumente unzugänglich ist. *gg*
Gute Nacht! ;-)
Andreas Leitgeb
> Andreas Leitgeb <a...@logic.at> wrote:
>> Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> Warum beantwortest Du eigentlich meine Fragen?
>> Das frage ich mich mittlerweile auch. Ich dachte, es waere was Gutes,
>> cdrecord ein wenig stabiler auch gegenueber *un-perfekter* Hardware zu
> OK, ich muß also leider davon ausgehen, daß Du nie ein ernsthaftes Interesse an
> Hilfe hattest.
Wobei dahingestellt ist, ob "Dein System has mehrere offensichtliche Probleme"
und das Dahinstellen von wodim's 100%iger Erfolgsrate als Zufall überhaupt als
Hilfe zu bezeichnen ist.
Der Tip mit -raw96r war hingegen echte Hilfe, und dafür hab ich mich
ja eh schon ein paarmal bedankt.
> einen Kern der sich aufhängt...
Wer lesen kann wäre klar im Vorteil.
Andreas Leitgeb
> OK, ich muß also leider davon ausgehen, daß Du nie ein
> ernsthaftes Interesse an Hilfe hattest.
Zuerst brauchte ich selber Hilfe, die ich dann von dir als Tip "-raw96r"
bekam.
Dann stellte ich fest, dass dieser Tip auf 2 verschiedenen Rechnern jeweils
nur mit wodim für alle getesteten Medien funktionierte, bei cdrecord nur mit
einer (auf 4x beschränkten) CD-RW, nicht aber mit CD-Rs.
Ab dann war es meine Meinung, dass wenn von zwei Produkten unter den gleichen
(wenn auch ungünstigen) Umständen eines funktioniert, und das andere nicht,
dass dann das zweite Produkt einen "Hilfsbedarf" hätte.
PS: habe vorhin eine andere Antwort verfasst, und mittlerweile gecancelt,
da sie einen Jargon-ausdruck enthielt, der, wortwörtlich genommen, als
eher unguter persönlicher Angriff missverstanden werden konnte ("wer
lesen kann..."). Gemeint war dabei jedoch nur die Kritik, dass aus meinen
Texten Aussagen herausgelesen wurden, deren Gegenteil eigentlich drinstand.
Andreas Leitgeb
> Wobei ich schon auch feststellen muss, dass einer von euch für
> Argumente unzugänglich ist. *gg*
Die Unzugänglichkeit ist wohl auf beiden Seiten und jeweils gegen
(subjektiv bewertet) schlechte Argumente. Der Unterschied liegt wohl
eher in den Argumenten selbst, bzw. in der subjektiven Bewertung
derselben.
Die Argumente welcher Seite sind für Aussenstehende nachvollziehbarer?
A) Wenn Prog A mit System B funktioniert, dann sollte das auch für
Prog C möglich sein.
J) Wenn System B mit Prog C nicht funktioniert, dann ist System B
fehlkonfiguriert und somit irrelevant.
Wobei Prog A und C die gleiche Aufgabe erfüllen (sollten) und keines
davon spezifisch für das konkrete System B angepasst wurde.
Joerg Schilling
>> Argumente unzugänglich ist. *gg*
>
>Die Unzugänglichkeit ist wohl auf beiden Seiten und jeweils gegen
>(subjektiv bewertet) schlechte Argumente. Der Unterschied liegt wohl
>eher in den Argumenten selbst, bzw. in der subjektiven Bewertung
>derselben.
>
>
>A) Wenn Prog A mit System B funktioniert, dann sollte das auch für
> Prog C möglich sein.
>
>J) Wenn System B mit Prog C nicht funktioniert, dann ist System B
> fehlkonfiguriert und somit irrelevant.
Ich hatte schon mehrfach erklärt, daß man solche Aussagen nur machen kann, wenn
das Basissystem korrekt funktioniert. Das ist aber bei Dir nicht der Fall.
Kombinierte Zufallseffekte können hochkomplex sein.
Solange Du Dich weigerst zusammenzuarbeiten und wichtige Informationen
bewußt zurückhälst, solltest Du nicht erwarten, daß man Dir helfen kann.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
Arno Lutz
>Solange Du Dich weigerst zusammenzuarbeiten und wichtige Informationen
und wieso weigerst du dich beharrlich dein "Content-Type: text/plain;
charset=UTF-8" zu setzen?
Gruß
Arno
--
Windows ist nicht die Antwort sondern die Frage. Die Antwort ist "Nein!"
Andreas Leitgeb
> Ich hatte schon mehrfach erklärt, daß man solche Aussagen nur machen kann, wenn
> das Basissystem korrekt funktioniert. Das ist aber bei Dir nicht der Fall.
> Kombinierte Zufallseffekte können hochkomplex sein.
> Solange Du Dich weigerst zusammenzuarbeiten und wichtige Informationen
> bewußt zurückhälst, solltest Du nicht erwarten, daß man Dir helfen kann.
Wie ich schon sagte: eigentlich brauche ich zumindest für's brennen keine weitere
Hilfe mehr, da es mit wodim, aus welchen hochkomplexen "Zufalls"-Gründen auch
immer, mit -raw96r simpel und einfach funktioniert, ebenso cdrdao.
Ich gebe die Hoffnung aber noch nicht auf, dass dieser Thread am Ende auf die
Erkenntnis, welcher Hardware- oder eventuell auch Linux-bug (vl aber eben
doch auch cdrecord-bug) für's nicht-funktionieren von cdrecord auf meinen
beiden (und möglicherweise auch anderen) Rechnern konkret verantwortlich
ist, hinauslaufen könnte.
Bist du an einer Hintergrund-Analyse interessiert?
Wenn nicht, können wir den Thread hiermit beenden.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Bist du an einer Hintergrund-Analyse interessiert?
Nun, da Du keine meiner Fragen, die ich zur Analyse des Problems gestellt habe,
bislang beantwortest hast und da Du diese Verweigerungshaltung auch nach
mehrfachem Nachfragen beigehalten hast, gehe ich davon aus, da� Du noch nie an
einer L�sung Deines Problems interessiert warst und dies vermutlich auch in
Zukunft nicht sein wirst.
Es ist ja nicht so, da� Du ein Signal von mir ben�tigen w�rdest. Du mu�t
lediglich die Fragen beantworten, die ich bereits vor knapp einer Woche
gestellt habe.
Solange Du jedenfalls bei Deiner Verweigerungshaltung bleibst und keine der
notwendigen Informationen lieferst, ist eine Fortf�hrung der "Diskusion"
alleine aus technischen Gr�nden unm�glich.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
Andreas Leitgeb
> Nun, da Du keine meiner Fragen, die ich zur Analyse des Problems gestellt habe,
> bislang beantwortest hast
Welche Fragen habe ich eigentlich nicht beantwortet?
Die Fragen an die ich mich noch erinnern kann, waren nach der Verkabelung
von Platte und Brenner, und die habe ich beantwortet. Hier nocheinmal die
Kurzfassung:
Beim Rechner daheim sind die Kabeln separat und 80polig.
beim Laptop kann ich nicht reinschauen; ein scsi-scan zeigt sie
jedenfalls auf verschiedenen Bussen der pata-scsi-emulation, falls
das was aussagt.
Dann war da noch die Frage nach aktiviertem DMA, die ich folgendermaßen
beantwortete:
hdparm -d funktioniert wegen der scsi-emu nicht
hdparm -I zeigt einen "*" bei udma2, falls das was aussagt.
Das System verhält sich insgesamt gänzlich pio-UNtypisch.
Weiters habe ich angeboten, die jeweiligen "-V" logs (eventuell gekürzt)
zu senden, was aber bis dato nicht gewünscht wurde. Da ist es eben bei
den kurzen Ausschnitten geblieben, die ich gepostet habe.
Für weitere Infos braeuchte ich eine Anleitung, wie ich dazu komm.
> gehe ich davon aus, daß Du noch nie an einer Lösung Deines Problems
> interessiert warst und dies vermutlich auch in Zukunft nicht sein wirst.
Nocheinmal: "Mein" Problem ist bereits mit wodim und -raw96r gelöst.
Ist es. Punkt. Lösen wir nun auch das Problem, warum cdrecord auf einem
(damals nicht grad billigen) core2duo-Notebook nicht funktioniert?
Matthias Feichtinger
> Nun, da Du keine meiner Fragen, die ich zur Analyse des Problems gestellt
Geh weg, geh einfach weg, geh ganz weit weg.
Sülz in Geranien herum, Preiß.
Hat jemand vielleicht A******ch gerufen?
--
Usenet und nur usenet
Hic Rhodos - hic salta!
Franz Sauerzopf
> Joerg Schilling gab zum Besten:
>> Nun, da Du keine meiner Fragen, die ich zur Analyse des Problems
>> gestellt
>
> Geh weg, geh einfach weg, geh ganz weit weg. Sülz in Geranien herum,
> Preiß.
> Hat jemand vielleicht A******ch gerufen?
Schäm Dich, bitte. Ich schäme mich schon für Dich.
Franz
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> Nun, da Du keine meiner Fragen, die ich zur Analyse des Problems gestellt habe,
>> bislang beantwortest hast
>
>Welche Fragen habe ich eigentlich nicht beantwortet?
>
>Die Fragen an die ich mich noch erinnern kann, waren nach der Verkabelung
>von Platte und Brenner, und die habe ich beantwortet. Hier nocheinmal die
>Kurzfassung:
> Beim Rechner daheim sind die Kabeln separat und 80polig.
> beim Laptop kann ich nicht reinschauen; ein scsi-scan zeigt sie
> jedenfalls auf verschiedenen Bussen der pata-scsi-emulation, falls
> das was aussagt.
Das ist ja gut, diese Info hatte ich bislang nicht und wenn die am gleichen
Kabel h�ngen, dann verklemmt es sich normalerweise, bzw. es gibt einen
Buffer-Underrun.
>Dann war da noch die Frage nach aktiviertem DMA, die ich folgendermaßen
>beantwortete:
> hdparm -d funktioniert wegen der scsi-emu nicht
> hdparm -I zeigt einen "*" bei udma2, falls das was aussagt.
> Das System verhält sich insgesamt gänzlich pio-UNtypisch.
Es verh�lt sich aber auch nicht so wie man es mit DMA erwartet. Es ist zu
langsam.
>Weiters habe ich angeboten, die jeweiligen "-V" logs (eventuell gekürzt)
>zu senden, was aber bis dato nicht gewünscht wurde. Da ist es eben bei
>den kurzen Ausschnitten geblieben, die ich gepostet habe.
In meinen Anleitungen steht, da� ich mich schon melde wenn ich sowas ben�tige.
Das was ich aber wirklich benn�tige hast Du meines Wissens nie geschickt:
cdrecord -v sagt viel was ich ben�tige und es sagt halt auch welche
Transfergr��e der Kern cdrecord gestattet hat, bzw. welche Gr��e in
/etc/default/cdrecord eingestellt wurde. Hast Du denn mal probiert mit
ts=irgendwas eine gr��ere Transfersize einzustellen?
Cdrecord mu� da (gerade bei Linux) sehr vorsichtig sein, denn der Linux
Kern l�gt das sich die Balken biegen. W�rde ich dem alles glauben, dann
w�rde cdrecord unter Linux mit bestimmten USB Adaptern zur Blockade des
Rechners f�hren.
>Nocheinmal: "Mein" Problem ist bereits mit wodim und -raw96r gelöst.
> Ist es. Punkt. Lösen wir nun auch das Problem, warum cdrecord auf einem
> (damals nicht grad billigen) core2duo-Notebook nicht funktioniert?
Nocheinmal: Solange cdrecord nicht zuverl�ssig bei Dir l�uft sind die
Ergebnisse mit wodim purer Zufall, der schon morgen nicht mehr da sein kann.
Cdrecord verwendet eine geringere Transfersize als wodim und entweder Du hast
das selbst verkonfiguriert, oder jemand der Deine Distro baut hat
b�sartigerweise eine st�rende Konfigdatei f�r cdrecord erzeugt oder dein Kern
meldet Parameter die cdrecord nicht akzeptieren kann. F�r ein PATA Laufwerk
sollte jedenfalls ts=128k oder ts=256k unter Linux gehen wenn nicht dem Linux
Kern gerade der Speicher ausgeht.
Andreas Leitgeb
Das "Problem" mit cdrecord ist, dass es das Gerät bevorzugt mit dem
(zumindest unter Linux und/oder für -raw96r) schlechteren Treiber
ansprechen will.
Wenn ich cdrecord, so wie es sich wodim aus seiner /etc/wodim.conf holt,
mit dem Parameter dev=/dev/cdrom (symlink auf /dev/sr0 (11,0) -> "sr")
starte, dann motzt cdrecord:
" Warning: Open by 'devname' is unintentional and not supported.
arbeitet in weiterer Folge aber genauso brav, wie wodim es (eben wegen
der conf) auch schon bisher tat.
Das folgende habe ich (teilweise) schon vorher geschrieben, und lasse es
nun stehen, da es eventuell für die Frage nach dem bevorzugten Interface
relevant ist. Immerhin warnt cdrecord gegen die Verwendung des besser
funktionierenden, während wodim es wegen der von den packagern beigelegten
default-config verwendet (und diese warnung wohl weggepatcht bekommen hat).
Joerg Schilling <j...@cs.tu-berlin.de> wrote:
> Das was ich aber wirklich bennötige hast Du meines Wissens nie geschickt:
> cdrecord -v sagt viel was ich benötige und es sagt halt auch welche
> Transfergröße der Kern cdrecord gestattet hat, bzw. welche Größe in
> /etc/default/cdrecord eingestellt wurde. Hast Du denn mal probiert mit
> ts=irgendwas eine größere Transfersize einzustellen?
Wenn du die Zeile mit "SCSI buffer size:" meinst, hier meldet wodim
64512 (also 63k) während cdrecord 32768 meldet.
Bei der "Drive buf size" sagen beide: 1053696 = 1029 KB
cdrecord zusätzlich: Drive pbuf size: 1966080 = 1920 KB
Bei der Geschwindigkeit schaut's dann so aus:
wodim:
Drive DMA Speed: 13356 kB/s 75x CD 9x DVD
Encoding speed : 357x (26708 sectors/s) for libedc from Heiko Ei�feldt
cdrecord:
Drive DMA Speed: 8832 kB/s 50x CD 6x DVD 1x BD
Encoding speed : 364x (27280 sectors/s) for libedc from Heiko Ei�feldt
Nachtrag:
cdrecord dev=/dev/cdrom ts=256k ... (syslimit ist nun wohl 128k)
SCSI buffer size: 131072
Drive DMA Speed: 13265 kB/s 75x CD 9x DVD 2x BD
Encoding speed : 346x (25902 sectors/s) for libedc from Heiko Ei�feldt
Hier wurde (glaub ich) scsi-linux-sg.c verwendet, bei
der x,y,z-form oben hingegen (weiss ich) scsi-linux-pg.c
> Cdrecord verwendet eine geringere Transfersize als wodim und entweder Du hast
> das selbst verkonfiguriert, oder jemand der Deine Distro baut hat
> bösartigerweise eine störende Konfigdatei für cdrecord erzeugt
Es existiert kein /etc/default/cdrecord, aber dafür ein /etc/wodim.conf
mit den folgenden nicht-ge#ten Zeilen:
CDR_DEVICE=cdrom
CDR_FIFOSIZE=12m
cdrom= -1 -1 -1 burnfree
Auf diese Datei hatte ich leider bis dato selber nicht geachtet.
Das hätte die Diskussion bis dato wohl deutlich abgekürzt.
Joerg Schilling
Andreas Leitgeb <a...@logic.at> wrote:
>Mir ist grad was klar geworden.
>
>Das "Problem" mit cdrecord ist, dass es das Gerät bevorzugt mit dem
>(zumindest unter Linux und/oder für -raw96r) schlechteren Treiber
>ansprechen will.
Eigentlich sollte es nur einen Treiber geben. Das ist leider ein Linux
Problem.
Um welche beiden Treiber geht es denn?
>Wenn ich cdrecord, so wie es sich wodim aus seiner /etc/wodim.conf holt,
>mit dem Parameter dev=/dev/cdrom (symlink auf /dev/sr0 (11,0) -> "sr")
>starte, dann motzt cdrecord:
> " Warning: Open by 'devname' is unintentional and not supported.
>arbeitet in weiterer Folge aber genauso brav, wie wodim es (eben wegen
>der conf) auch schon bisher tat.
Das sollte eigentlich ein Treiber sein, der in das SCSI System eingeordnet ist.
Das sollt eeigenlich keine Probleme geben ud das sollte cdrecord (mit Hilfe der
libscg) auch automatisch zuerst finden - es sei denn der Kern ist
fehlkonfiguriert und enth�lt keinen "sg" Treiber.
>Das folgende habe ich (teilweise) schon vorher geschrieben, und lasse es
>nun stehen, da es eventuell für die Frage nach dem bevorzugten Interface
>relevant ist. Immerhin warnt cdrecord gegen die Verwendung des besser
>funktionierenden, während wodim es wegen der von den packagern beigelegten
>default-config verwendet (und diese warnung wohl weggepatcht bekommen hat).
Cdrecord warnt vor dem das potentiell Probleme birgt - in der Annahme der Kern
ist ansonsten OK.
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> Das was ich aber wirklich bennötige hast Du meines Wissens nie geschickt:
>> cdrecord -v sagt viel was ich benötige und es sagt halt auch welche
>> Transfergröße der Kern cdrecord gestattet hat, bzw. welche Größe in
>> /etc/default/cdrecord eingestellt wurde. Hast Du denn mal probiert mit
>> ts=irgendwas eine größere Transfersize einzustellen?
>
>Wenn du die Zeile mit "SCSI buffer size:" meinst, hier meldet wodim
>64512 (also 63k) während cdrecord 32768 meldet.
Ein f�r Linux seit 10 Jahren ungew�hnlich kleiner Wert.
>Bei der "Drive buf size" sagen beide: 1053696 = 1029 KB
>cdrecord zusätzlich: Drive pbuf size: 1966080 = 1920 KB
Das letzte ist das Physische RAM im Brenner. wodim basiert halt auf einer
6 Jahre alten und seit dem ungewarteten Version.....
>Bei der Geschwindigkeit schaut's dann so aus:
> wodim:
> Drive DMA Speed: 13356 kB/s 75x CD 9x DVD
> Encoding speed : 357x (26708 sectors/s) for libedc from Heiko Ei�feldt
> cdrecord:
> Drive DMA Speed: 8832 kB/s 50x CD 6x DVD 1x BD
> Encoding speed : 364x (27280 sectors/s) for libedc from Heiko Ei�feldt
Fehlendes DMA kann durch einen andern Treiber kommen - aber durch welchen?
>Nachtrag:
> cdrecord dev=/dev/cdrom ts=256k ... (syslimit ist nun wohl 128k)
> SCSI buffer size: 131072
> Drive DMA Speed: 13265 kB/s 75x CD 9x DVD 2x BD
> Encoding speed : 346x (25902 sectors/s) for libedc from Heiko Ei�feldt
> Hier wurde (glaub ich) scsi-linux-sg.c verwendet, bei
> der x,y,z-form oben hingegen (weiss ich) scsi-linux-pg.c
Das letzte Mal als ich einen Parallelport Brenner gesehen habe war 2001.
Welches Treiberinetrface verwendet cdrecord?
Vor der Verwendung des alten ATA Interfaces in Linux (welches kein DMA
unterst�tzt) warnt cdrecord �brigens. Nun w��te ich gerne, welchen Treiber
cdrecord bei Dir verwendet wenn es langsam ist.
>> Cdrecord verwendet eine geringere Transfersize als wodim und entweder Du hast
>> das selbst verkonfiguriert, oder jemand der Deine Distro baut hat
>> bösartigerweise eine störende Konfigdatei für cdrecord erzeugt
>
>Es existiert kein /etc/default/cdrecord, aber dafür ein /etc/wodim.conf
>mit den folgenden nicht-ge#ten Zeilen:
> CDR_DEVICE=cdrom
> CDR_FIFOSIZE=12m
> cdrom= -1 -1 -1 burnfree
>
>Auf diese Datei hatte ich leider bis dato selber nicht geachtet.
>Das hätte die Diskussion bis dato wohl deutlich abgekürzt.
Ich hatte Dich ja darauf bereits hingewiesen, da� man cdrecord problemlos so
konfigurieren kann, da� es per Default BurnFree anschaltet.
Clemens Schueller
> Dann war da noch die Frage nach aktiviertem DMA, die ich folgendermaßen
> beantwortete:
> hdparm -d funktioniert wegen der scsi-emu nicht
^^^^^^^^
Das erinnert mich an ide-scsi.o im 2.4er Zweig.
Was sagt denn uname -a zu Deiner Kiste.
GreetinX, Clemens Schueller