Schily schrieb am 27. Dezember 2006 15:17
> Meine Software wird nirgendwo verschwinden, es werden aber viele
> Nutzer gezwungen defekt gemachte, veraltete Varianten davon zu
> verwenden.
Sie ist bereits verschwunden - aus openSUSE 10.2 zum Beispiel.
> Du bist ein uninformierter Troll.
Beleidigungen ersetzen in üblicher Schilling-Manier eine sachliche
Argumentation.
> Ich kann nichts dafür, daß die Linux Kernel Entwickler
> ständig neue Hürden gegen die Verwendung von ATAPI
> einbauen
Die Behauptung ist falsch. Stattdessen kann seit Linux 2.6.4 auch der
ATA-Treiber mit dem von SCSI-Geräten jahrelang erprobten
SG_IO-Interface (ioctl) angesprochen werden, mit DMA und was sonst
dazugehört - in den Augen der meisten Entwickler ist das eine
Erleichterung. Herr Schilling benutzt aber diese Schnittstelle nur
unter lautem Protest und Beleidigungen bei jeder Gelegenheit, weil
der Name der Geräte nun mit /dev/hd statt mit /dev/sg beginnt...
Beleg: Patch in [1] beseitigt diese Hürde, Schilling weigert sich
aber, den Patch anzusehen [2] und beleidigt stattdessen alle
möglichen Personen[3], die seiner Software zu größerer
Verträglichkeit verhelfen wollen.
[1] http://lkml.org/lkml/2006/2/3/195
[2] http://lkml.org/lkml/2006/2/3/204
[3] http://lkml.org/lkml/2006/2/9/68
Es gibt weitere Beispiele, in denen Schilling Software auf seinem
bevorzugten System entwickelt (daran ist nichts verwerflich), das
Verhalten seines Betriebssystems beobachtet, und dann versucht, diese
Beobachtungen auch dann auf Linux zu übertragen, wenn kein Standard
solches Verhalten vorschreibt, oder gar es explizit als
implementierungsabhängig definiert.
Dass Herr Schilling dann die eher üblichen Unterschiede der
Betriebssysteme als künstliche Hürden bezeichnet, ist sachlich nicht
begründet und unkorrekt und auf zwischenmenschlicher Ebene eine
Beleidigung.
> und Linux Nutzer sollten dankbar sein, daß
> ich mir immer wieder neue Workarounds ausdenke um
> _trotzt_ der Probleme im Linux Kern, das CD und DVD Brennen
> unter Linux dennoch zu ermöglichen.
Es ist schon recht dreist, Dankbarkeit dafür zu verlangen, dass der
Programmierer, der sich selbst im Weg steht, die Probleme, die er
dadurch selbst geschaffen hat, auch wieder beseitigt. Ein
"Workaround" ist es auch nur deswegen, weil vielfach der genaue
Sachstand gar nicht untersucht wird, mit dem hier unterstellten
Hintergedanken "alle doof außer ich, Linuxer besonders" -
professionelles Verhalten sieht anders aus; Lösungsmöglichkeiten
innerhalb cdrecord, die in der Regel zu einfacherem
cdrecord-Programmcode geführt hätten, wurden in der Mehrzahl der
Fälle von Herrn Schilling ausgeschlagen.
Auch, dass Herr Schilling jetzt die cdrecord-Debatte aufmacht, von
der weder im Original-Statusbericht von Andreas Barth noch im
Newsticker die Rede war, zeigt, dass Herr Schilling Schwierigkeiten
mit der Einschätzung seines Platzes in der Gesellschaft hat.
Die Konsequenz jedenfalls ist, dass es massive Probleme in der
Zusammenarbeit Herrn Schillings mit anderen gibt, die schlagen sich
im günstigsten Fall in erheblicher Mehrarbeit bei der Verträglichkeit
von cdrtools mit Linux nieder und im häufigeren Fall im völligen
Zerwürfnis.
> Meine Software wird nirgendwo verschwinden, es werden aber viele
> Nutzer gezwungen defekt gemachte, veraltete Varianten davon zu
> verwenden.
Sie ist bereits verschwunden - aus openSUSE 10.2 zum Beispiel.
> Du bist ein uninformierter Troll.
Beleidigungen ersetzen in üblicher Schilling-Manier eine sachliche
Argumentation.
> Ich kann nichts dafür, daß die Linux Kernel Entwickler
> ständig neue Hürden gegen die Verwendung von ATAPI
> einbauen
Die Behauptung ist falsch. Stattdessen kann seit Linux 2.6.4 auch der
ATA-Treiber mit dem von SCSI-Geräten jahrelang erprobten
SG_IO-Interface (ioctl) angesprochen werden, mit DMA und was sonst
dazugehört - in den Augen der meisten Entwickler ist das eine
Erleichterung. Herr Schilling benutzt aber diese Schnittstelle nur
unter lautem Protest und Beleidigungen bei jeder Gelegenheit, weil
der Name der Geräte nun mit /dev/hd statt mit /dev/sg beginnt...
Beleg: Patch in [1] beseitigt diese Hürde, Schilling weigert sich
aber, den Patch anzusehen [2] und beleidigt stattdessen alle
möglichen Personen[3], die seiner Software zu größerer
Verträglichkeit verhelfen wollen.
[1] http://lkml.org/lkml/2006/2/3/195
[2] http://lkml.org/lkml/2006/2/3/204
[3] http://lkml.org/lkml/2006/2/9/68
Es gibt weitere Beispiele, in denen Schilling Software auf seinem
bevorzugten System entwickelt (daran ist nichts verwerflich), das
Verhalten seines Betriebssystems beobachtet, und dann versucht, diese
Beobachtungen auch dann auf Linux zu übertragen, wenn kein Standard
solches Verhalten vorschreibt, oder gar es explizit als
implementierungsabhängig definiert.
Dass Herr Schilling dann die eher üblichen Unterschiede der
Betriebssysteme als künstliche Hürden bezeichnet, ist sachlich nicht
begründet und unkorrekt und auf zwischenmenschlicher Ebene eine
Beleidigung.
> und Linux Nutzer sollten dankbar sein, daß
> ich mir immer wieder neue Workarounds ausdenke um
> _trotzt_ der Probleme im Linux Kern, das CD und DVD Brennen
> unter Linux dennoch zu ermöglichen.
Es ist schon recht dreist, Dankbarkeit dafür zu verlangen, dass der
Programmierer, der sich selbst im Weg steht, die Probleme, die er
dadurch selbst geschaffen hat, auch wieder beseitigt. Ein
"Workaround" ist es auch nur deswegen, weil vielfach der genaue
Sachstand gar nicht untersucht wird, mit dem hier unterstellten
Hintergedanken "alle doof außer ich, Linuxer besonders" -
professionelles Verhalten sieht anders aus; Lösungsmöglichkeiten
innerhalb cdrecord, die in der Regel zu einfacherem
cdrecord-Programmcode geführt hätten, wurden in der Mehrzahl der
Fälle von Herrn Schilling ausgeschlagen.
Auch, dass Herr Schilling jetzt die cdrecord-Debatte aufmacht, von
der weder im Original-Statusbericht von Andreas Barth noch im
Newsticker die Rede war, zeigt, dass Herr Schilling Schwierigkeiten
mit der Einschätzung seines Platzes in der Gesellschaft hat.
Die Konsequenz jedenfalls ist, dass es massive Probleme in der
Zusammenarbeit Herrn Schillings mit anderen gibt, die schlagen sich
im günstigsten Fall in erheblicher Mehrarbeit bei der Verträglichkeit
von cdrtools mit Linux nieder und im häufigeren Fall im völligen
Zerwürfnis.