[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Erleuchtet mich zu wodim oder wer hat cdrecord geklaut?



#include <hallo.h>
* Joerg Schilling [Fri, Oct 20 2006, 01:39:30AM]:
> Damit verstanden werden kann, warum Leute wie Eduard Bloch OSS Projekte
> "vergiften" und z.B. dem cdrtools Projekt gewaltig schaden versuche ich mal 
> beispielhaft eine der typischen "Bloch" Aussagen zu kommentieren......

"vergiften", "schaden", "gewaltig"... du nimmst den Mund ganz schön voll
für das, was du an "harten" Tatsachen vorlegst. Ich versuche mal,
objektiv zu bleiben.

> Eduard Bloch <edi@gmx.de> wrote:
> 
> > > Kein Wunder, denn beim Original findet um Gegensatz zu dem Debian Scheinprojekt
> > > auch weiterhin eine Entwicklung statt.
> >
> > Wer den Verlauf der Entwicklung sehen will, sollte erstmal einen Blick ins
> > http://svn.debian.org/wsvn/debburn/nonameyet/trunk/Changelog?op=file&rev=0&sc=0
> > werfen und erst dann solchen Sprüchen glauben (vielleicht).
> 
> Eine ziemlich gewagte Aussage des Herrn Bloch, die auf der Hoffnung basiert,
> daß niemand das was er da schreibt auch tut: sich selbst ein Bild machen.....

Fakten:

 - unser Changelog ist öffentlich einsehbar. Das
   Versionsverwaltungssystem ebenfalls.

> Ich rate jedem dieses Angebot zu nutzen und vor Allem mal zu versuchen, sich die 
> alte Bugliste der cdrtools auf Debian zu beschaffen. Dann mal sehen ob einer der 
> selbstverursachten Bugs (denn praktisch alle Bugs in der besagten Liste sind
> nicht in der Originalsoftware zu finden) beseitigt wurde.

Fakten:

 - Alte Bugliste ist irrelevant. Cdrkit wurde geforkt, damit die Arbeit
   wetiergehen kann und der Bughaufen endlich aufgeräumt wird.
 - Jeder, auch Joerg Schilling haette die Bugs schliessen können, wenn
   sie nicht länger den Tatsachen entsprechen.
 - aktuelle Bugliste findet man unter
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cdrkit;dist=unstable
   und dort verlinkt Seiten. Die derzeit "brennenden" Bugs ohne
   anstehender Lösung sind: #390320, #387020, #392342, #393188, #387783
   (hässliche FUD-Meldungen auf stdout verwirren
   verwirren Benutzer und stören die Arbeit von Frontends). Die
   entsprechenden Bereiche sind durch Jörgs Kommentare "geschützt", man
   dürfe sie nicht verändern oder die Ausgabe entfernen. Wie genau
   dieser "Schutz" mit der GPL zu vereinbaren ist, wurde bis heute nicht
   geklärt.

> > > Seit Februar gibt es Workarounds für die Interface-Inkompatibilitäten neuerer 
> >
> > Die als Basis verwendete Version 2.01.01a08 ist aber vom Mai 2006.
> 
> Wieder mal eine typische Falschdarstellung:
> 
> Verwendet wird in "wodim" eine cdrecord Version vom Februar 2006 die dann aber 
> mit einer fast zwei Jahre alten Version der libscg kombiniert wird, so daß kein 
> Support für die Anweichungen von Linux-2.6 vorhanden ist.

Fakten:

 - Releasedatum von dem grundlegenden Cdrtools-Snapshot:
File: cdrtools-2.01.01a08.tar.bz2  	1409 KB  	07.05.2006  	19:27:00

 - letzte von dir vorgenommenen Änderungen in libscg:
 scsihack.c:/* @(#)scsihack.c    1.44 06/01/30 Copyright 1997,2000,2001 J. Schilling */
 scsi-linux-sg.c:/* @(#)scsi-linux-sg.c  1.86 05/11/22 Copyright 1997 J. Schilling */
 scsi-sun.c:/* @(#)scsi-sun.c    1.83 05/11/20 Copyright 1988,1995,2000-2004 J. Schilling */
 scsi-mac-iokit.c:/* @(#)scsi-mac-iokit.c        1.10 05/05/15 Copyright 1997,2001-2004 J. Schilling */

 Dass 05/ und 06/ nicht für das Jahr 2004 stehen ist offensichtlich.

> > > Linux Versionen, die Debian immer noch nicht verwendet. Dank dieser Workarounds
> > > kann cdrecord (falls suid-root installiert) korrekt funktionieren wenn es als
> > > user genutzt wird.
> >
> > Wodim muss nicht mal suid-root installiert werden. Was durch den
> > Verzicht auf den root-Rechte-Zwang "inkorrekt" sein soll, liess sich
> > durch empirische Untersuchungen noch nicht feststellen.
> 
> Herrn Bloch sollten die Probleme eigentlich bekannt sein. Es gibt viele 
> Einträge im Debian Bug Tracking system dazu. Auch habe ich ihm mehrfach erklärt
> weshalb cdrecord root-Rechte benötigt um korrekt zu funktionieren.

Fakten:

 - Leute können mit wodim brennen, auch unter Kernel 2.6
 - an die Erklärung, _warum_ man sie braucht, kann ich mich nicht
   erinnern. An viele Behauptungen, dass man sie bräuchte (gesalzen mit
   FUD) dagegen schon.
 - Probleme mit Kernel-Versionen 2.6.8 <= x < 2.6.11 sind bekannt. Diese
   Kernel-Versionen sind jedoch schon lange nicht mehr aktuell.

> > > Mit dem Original bekommt man funktionierenden DVD Support und auch bei mkisofs 
> > > hat sich einiges in den letzten Wochen getan.
> >
> > Mit Cdrkit bekommt man funktionierenden DVD-Support und auch bei mkisofs
> > hat sich einiges getan.
> 
> Wer die Einträge im Debian Bugtrackingsystem mal gelesen hat, der weis, daß 
> Behauptungen dieser Art nicht ernstgenommen werden können.

Fakten:

 - Jörg Schilling ist kein staatlich geprüfter Hellseher.

> DVD+ Support in Wodim ist faktisch nicht vorhanden, mit Pinoeer Laufwerken
> werden alle Medien durch "Wodim" zerstört.

Fakten:

 - hier liegt eine frisch gebrannte DVD+RW, keinen Meter entfernt
 - es gibt im Debian-BTS keine Bugberichte über "Zerstörung" von Medien
   durch Pioneer- oder Pinoeer-Laufwerke

> Sämtliche Komfortfunktionen die von cdrecord bekannt sind (wie z.B. -atip)

Fakten:

 - -atip ist nicht vollständig implementiert. Dies wurde von mir auf
   dieser Mailingliste auch berichtet.
 - das freie Tool dvd+rw-mediainfo liefert ebenfalls ausführliche
   Informationen.

> fehlen komplett. Mit den meisten LW kann nur mit Minimalgeschwindigkeit 
> gebrannt werden. Mit vielem LW ist auch DVD- nicht benutzbar.

"vielem" und "meisten" sind vollkommen subjektive Bewertungen, ausser du
kannst es irgenwie belegen. Was ich grade sehe (natürlich nicht für
jedes Stück Hardware repräsentativ):

Track 01: 4489 of 4489 MB written (fifo 100%) [buf  81%]  16.5x.

> > > Vor dem nicht sauber eingebauten iconv Support bei der Debian Variante von 
> > > mkisofs muß hingegen weiterhin gewarnt werden. Wenn man den Code mit einem
> > > funktionierenden Kompiler übersetzt bekommt man Warnungen die das Problem
> > > offensichtlich werden lassen.
> >
> > Die aktuelle Version (SVN-Trunk) kann mit GCC auf mehreren Plattformen
> > gebaut werden, und zumindest auch mit IBMs xlc-Compiler. Es sind keine
> > Warnungen zu sehen, die ein Problem offensichtlich machen.
> 
> Hier muß man wohl mal erklären, daß Herr Bloch mit diesem für andere 
> unverständlichem Wirrwar versucht einen Seitenhieb gegen die echten cdrtools
> auszuteilen dabei aber seine eigene Unfähigkeit beweist:

Fakten:

 - bei Verständnisproblemen muss es nicht immer am Schreiber/Sprecher
   liegen

> Vor ca. 2 Wochen bekam ich eine Mail von Herrn Bloch, daß angeblich cdrtools
> nicht mehr auf AIX-5.x kompilieren würden. Da ich die (wenn auch 
> unwahrscheinliche) Möglichkeit daß er erstmals helfen will, in Betracht ziehen 

Fakten:

 - ich habe dir eine ausreichende Problembeschreibung gegeben. Bei
   Cdrkit bin ich diesen Symptomen begegnet und das war die
   offensichtliche Lösung.
 - ich habe es diskrett getan und nicht damit z.B. auf dem
   Heise-Trollforum gepöbelt

> mußte, fragte ich nach und bat um die notwendigen Informationen um das Problem
> untersuchen zu können.

Der Inhalt war eher:

 - Abspeisung mit dem Verweis auf die Standardseite, meine
   Fehlerbeschreibung scheinbar ignorierend
 - Aufforderung, urheberrechtlich geschützte Betriebssystemdateien
   (Headers) an ihn weiterzugeben.

> Was als Antwort kam, war eine seiner typischen Beleidigungen in der er mir erst
> erklärte, ich hätte keine Ahnung und dann stolz erklärte wie er das Problem
> durch Einführung eines weiteren selbstgemachten Bugs "behoben" hätte.

Fakten:

 - "hätte keine Ahnung" sind deine Worte
 - ich produziere nicht gezielt Bugs, um diese zu beheben. Ganz egal,
   was du dir sonst noch alles einbildest.

> Nun, es ist zwar sehr unwahschrinlich, daß AIX-5.x nicht kompatibel zu AIX-4.x 
> ist, aber in den echten cdrtools gibt es nun dennoch einen Workaround für 
> Systeme die _nur_ C-99 kompatbel sind.

Fakten:

 - 2.01.01a16 und jetzt auch 2.01.01a18 wurde von mir auf AIX-5.x
   getestet.
 - Beide bauen nach wie vor nicht, es fehlt .isnan beim Linken und bei
   mkisofs auch noch diverse andere Sachen. Mit LDOPTX=-lm klappt schon
   mal das meiste bis auf mkisofs, siehe [1].

Persönliche Erwartung: Wer mit höchster Portabilität wirbt, sollte auf
den Zielplatformen auch real testen.

> Und auch wenn es Herr Bloch nicht wahrhaben will, das offizielle mkisofs 
> hat seit März 2006 viele wichtige neue Features eingeführt und wurde dazu seit
> dem um 30% modifiziert....

Fakten:

 - nicht jede Modifizikation ist wichtig oder sinnvoll, Menge der
   Änderungen ist kein Maß für diese Eigenschaften
 - die in Changelogs erwähnten "Cstyle fixes" sind
   Refactoring/Umstellung auf dein geliebtes Cstyle, die das Diff
   aufblähen.

> > Zu lizenztechnischen Dingen kann ich erst dann etwas sagen, wenn du die
> > genaue Lizenz von cdrecord.c u.a. in 2.01.01.a08 endlich offenbart hast.
> 
> Angesehen davon, daß ich die Lizenzbedingungen _mehrfach_ ausführlichst

Fakten:

 - in den letzten Wochen kam keine ausführliche ERKLÄRUNG. Gerede um
   den heissen Brei herum erklärt die zentralen Fragen nicht.

Solltest du es anders sehen, so nenn doch mal die Message-Id der
Mail mit den ausführlichen Erklärungen und ich werde sie nach
Möglichkeit veröffentlichen.

> Herrn Bloch erklärt habe, ist 2.01.01a08 so veraltet, das sie schon fast 
> nicht mehr wahr ist.

"fast nicht mehr wahr"... ist das so wie "fast nicht mehr GPL"?

Eduard.

[1]

echo "  ==> LINKING \"OBJ/rs6000-aix-cc/mkisofs\""; cc -o OBJ/rs6000-aix-cc/mkisofs OBJ/rs6000-aix-cc/mkisofs.o OBJ/rs6000-aix-cc/tree.o OBJ/rs6000-aix-cc/write.o OBJ/rs6000-aix-cc/hash.o OBJ/rs6000-aix-cc/rock.o OBJ/rs6000-aix-cc/inode.o OBJ/rs6000-aix-cc/udf.o OBJ/rs6000-aix-cc/multi.o OBJ/rs6000-aix-cc/joliet.o OBJ/rs6000-aix-cc/match.o OBJ/rs6000-aix-cc/name.o OBJ/rs6000-aix-cc/eltorito.o OBJ/rs6000-aix-cc/boot.o OBJ/rs6000-aix-cc/isonum.o OBJ/rs6000-aix-cc/scsi.o OBJ/rs6000-aix-cc/scsi_cdr.o OBJ/rs6000-aix-cc/cd_misc.o OBJ/rs6000-aix-cc/modes.o OBJ/rs6000-aix-cc/apple.o OBJ/rs6000-aix-cc/volume.o OBJ/rs6000-aix-cc/desktop.o OBJ/rs6000-aix-cc/mac_label.o OBJ/rs6000-aix-cc/stream.o OBJ/rs6000-aix-cc/ifo_read.o OBJ/rs6000-aix-cc/dvd_file.o OBJ/rs6000-aix-cc/dvd_reader.o OBJ/rs6000-aix-cc/defaults.o OBJ/rs6000-aix-cc/getnum.o OBJ/rs6000-aix-cc/walk.o  -L../libs/rs6000-aix-cc -L/opt/schily/lib -lm -lhfs -lfile -lunls -lrscg -lscg  -ldeflt -lfind -lschily    -lintl 

Ergebnis:

        ==> LINKING "OBJ/rs6000-aix-cc/mkisofs"
ld: 0711-317 ERROR: Undefined symbol: .d_getw
ld: 0711-317 ERROR: Undefined symbol: .d_getl
ld: 0711-317 ERROR: Undefined symbol: .d_toutime
ld: 0711-317 ERROR: Undefined symbol: .d_dtoutime
ld: 0711-317 ERROR: Undefined symbol: hfs_error
ld: 0711-317 ERROR: Undefined symbol: .f_trunc
ld: 0711-317 ERROR: Undefined symbol: .f_flush
ld: 0711-317 ERROR: Undefined symbol: .v_getvol
ld: 0711-317 ERROR: Undefined symbol: .v_resolve
ld: 0711-317 ERROR: Undefined symbol: .v_catsearch
ld: 0711-317 ERROR: Undefined symbol: .d_relstring
ld: 0711-317 ERROR: Undefined symbol: .v_getthread
ld: 0711-317 ERROR: Undefined symbol: .r_makecatkey
ld: 0711-317 ERROR: Undefined symbol: .r_packcatkey
ld: 0711-317 ERROR: Undefined symbol: .bt_delete
ld: 0711-317 ERROR: Undefined symbol: .r_packcatdata
ld: 0711-317 ERROR: Undefined symbol: .bt_insert
ld: 0711-317 ERROR: Undefined symbol: .v_putcatrec
ld: 0711-317 ERROR: Undefined symbol: .v_adjvalence
ld: 0711-317 ERROR: Undefined symbol: .f_selectfork
ld: 0711-317 ERROR: Undefined symbol: .bt_space
ld: 0711-317 ERROR: Undefined symbol: .d_tomtime
ld: 0711-317 ERROR: Undefined symbol: .v_newfolder
ld: 0711-317 ERROR: Undefined symbol: .r_packdirent
ld: 0711-317 ERROR: Undefined symbol: .r_unpackdirent
ld: 0711-317 ERROR: Undefined symbol: .f_getptrs
ld: 0711-317 ERROR: Undefined symbol: .f_alloc
ld: 0711-317 ERROR: Undefined symbol: b_writeab
ld: 0711-317 ERROR: Undefined symbol: .f_doblock
ld: 0711-317 ERROR: Undefined symbol: b_readab
ld: 0711-317 ERROR: Undefined symbol: hfs_mounts
ld: 0711-317 ERROR: Undefined symbol: .bt_getnode
ld: 0711-317 ERROR: Undefined symbol: .r_unpackcatkey
ld: 0711-317 ERROR: Undefined symbol: .r_unpackcatdata
ld: 0711-317 ERROR: Undefined symbol: .bt_search
ld: 0711-317 ERROR: Undefined symbol: .l_readpm
ld: 0711-317 ERROR: Undefined symbol: .n_init
ld: 0711-317 ERROR: Undefined symbol: r_compareextkeys
ld: 0711-317 ERROR: Undefined symbol: r_comparecatkeys
ld: 0711-317 ERROR: Undefined symbol: .b_writelb
ld: 0711-317 ERROR: Undefined symbol: .v_flush
ld: 0711-317 ERROR: Undefined symbol: hfs_curvol
ld: 0711-317 ERROR: Undefined symbol: .v_destruct
ld: 0711-317 ERROR: Undefined symbol: .l_readblock0
ld: 0711-317 ERROR: Undefined symbol: .l_readmdb
ld: 0711-317 ERROR: Undefined symbol: .l_readvbm
ld: 0711-317 ERROR: Undefined symbol: .bt_readhdr
ld: 0711-317 ERROR: Undefined symbol: .v_scavenge
ld: 0711-317 ERROR: Undefined symbol: .d_putw
ld: 0711-317 ERROR: Undefined symbol: .d_putl
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make[1]: *** [OBJ/rs6000-aix-cc/mkisofs] Error 8


-- 
*** SignOff sbeyer: #debian.de (f**ken und haare waschen)
<Y_Plentyn> hm. warum forkt er vorm haare waschen?



Reply to: