Mit meinem DVD-Recorder (;DR 4912S von LG) habe ich auf eine DVD-RW einen Film gebrannt. Nun wollte ich den Film auf eine DVD-R kopieren. In meinem Rechner befindet sich der DVD-Brenner GSA-4040B von LG.
Ich habe zwar zusätzlich noch ein DVD-Laufwerk in meinem Rechner, aber nur dieser Brenner kann DVD-RWs lesen. Also muß ich den Film erst von der DVD-RW auf Festplatte speichern, um ihn dann auf DVD-R brennen zu können. Doch genau das ist mein Problem.
Zunächst noch folgende Informationen: Mit PowerDVD Version 4 kann ich den Film ohne Probleme abspielen; wenn ich jedoch im Explorer auf den Laufwerksbuchstaben des DVD-Brenners klicke, kommt die Meldung "Auf G: kann nicht zugegriffen werden. Unzulässige Funktion."
Zum Zwischenspeichern des Films auf Festplatte wollte ich nun mit WinOnCD DVD Edition 6 ein Image erzeugen. Dazu wählte ich beim Start von WinOnCD "Copy Projekt öffnen". Nun habe ich Image schreiben gewählt und auf den Knopf zum Schreiben geklickt. Dann kommt jedoch nur kurz die Meldung Untersuche CD/Lese Inhaltsverzeichnis ansonsten passiert nichts. Außerdem besitze ich noch Nero 5.Dort habe ich CD kopieren und dann Brennen gewählt, aber dann kommt die Meldung ungültige Trackinfo.
Kann es sein, daß WinOnCD die DVD-RW nicht lesen kann (;denn über den Explorer konnte ich sie ja auch nicht lesen)? Aber wenn die DVD-RW vom Explorer und von WinOnCD nicht gelesen werden kann, warum kann PowerDVD sie dann abspielen? Wie kann ich ein Image der DVD-RW erzeugen?
Danke für alle Antworten.
Ernst Schmidt
Antwort von Jan Peter Stotz:
Ein ISO-Image von einer Film-DVD dürfte schwierig werden, denn die sind normalerweise in UDF beschrieben.
Ernst Schmidt schrieb: > Zum Zwischenspeichern des Films auf Festplatte wollte ich nun mit > WinOnCD DVD Edition 6 ein Image erzeugen. > Dazu wählte ich beim Start von WinOnCD "Copy Projekt öffnen". > Nun habe ich Image schreiben gewählt und auf den Knopf zum Schreiben geklickt. > Dann kommt jedoch nur kurz die Meldung Untersuche CD/Lese Inhaltsverzeichnis > ansonsten passiert nichts.
Eventuell kennt WinOnCD die verwendete UDF-Version nicht. Es gibt mittlerweile einige Varianten mit denen auch nicht alle Windows-Versionen etwas anfangen können.
> Außerdem besitze ich noch Nero 5.Dort habe ich CD kopieren und dann Brennen > gewählt, aber dann kommt die Meldung ungültige Trackinfo.
Mit "CD kopieren" bei eine DVD kann man auch nicht weit kommen...
Jan
Antwort von Andre Beck:
Jan Peter Stotz writes: > > Ein ISO-Image von einer Film-DVD dürfte schwierig werden, denn die sind > normalerweise in UDF beschrieben.
Deswegen sagt man besser Image. Auch vor UDF und DVD habe ich schon Images von CD-ROMs gemacht, egal ob da ein ISO9660, ein ext2 oder ein ufs drauf war. Bei CD-ROM ist das trivial - ein Image ist schlicht der blockweise Abzug des einzigen Datentracks, dessen Inhalt ist dabei vollkommen schnurz. Nur irgendwelche Windows-Clickware verwirrt mal wieder Anwender, indem sie irgend ein ISO hinzuerfindet (;oder gar völlig überflüssige eigene Imageformate¹).
Eine DVD-V ist nun nix weiter als eine spezielle Anwendung einer DVD-ROM, also ist es hier exakt so trivial wie bei CD-ROM. Essenziell reicht zum Erzeugen eines Image auf mitdenkenden Plattformen also der simpelste Befehl aller Zeiten, nämlich cat(;1):
# cat /dev/dvd > my-dvd.img
Und brennen würde man das dann z.B. mit
# growisofs -Z /dev/dvd%my-dvd.img
Aber klar, man kann sich das Leben natürlich auch schwer machen mit Monstrositäten á la WinOnCD oder Nero ;)
¹) Nichts gegen spezialisierte Imageformate für die CD-Anwendungsfälle, die über CD-ROM hinausgehen. Aber da existierte CUE/BIN auch lange vor dem ganzen Quark, den EWMS-Programme später noch erfinden mussten. Und für DVD ist das irrelevant, da dort alle bisher existenten Applikationen auf DVD-ROM aufbauen.
-- The S anta C laus O peration or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Udo Wolter:
On 2004/10/09 19:02 you (;beck@ibh.de) transmitted structured data: > Eine DVD-V ist nun nix weiter als eine spezielle Anwendung einer DVD-ROM, > also ist es hier exakt so trivial wie bei CD-ROM. Essenziell reicht zum > Erzeugen eines Image auf mitdenkenden Plattformen also der simpelste > Befehl aller Zeiten, nämlich cat(;1): > # cat /dev/dvd > my-dvd.img
Hm, es kommt ja selten vor, aber eigentlich nehme ich dafür lieber dd. cat kann auch mal so abbrechen, da hatte ich schon komische Effekte.
> Und brennen würde man das dann z.B. mit > > # growisofs -Z /dev/dvd%my-dvd.img
Wenn es vorher eine CSS-geschützte DVD war (;böse, sowas darf man natürlich überhaupt nicht, weil CSS ja ein "wirksamer Kopierschutz" ist, haha), dann geht das aber nur mit R/ RWs. Denn bei -R/-RW ist die CSS-Spur nicht beschreibbar. Insofern also: nicht machen !
> Aber klar, man kann sich das Leben natürlich auch schwer machen mit > Monstrositäten á la WinOnCD oder Nero ;)
Das braucht jemand ? :) Hey, das ist unfair, Windows-User haben genug Probleme, man muß nicht noch auf ihnen rumtreten. Sei doch froh, daß Du's einfacher hast.
Mermgfurt, Udo
-- Udo Wolter | /" email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN www: www.dicke-aersche.de | X AGAINST HTML MAIL dark: heaven@lutz-ziffer.de | /
Antwort von Andre Beck:
Udo Wolter writes: > On 2004/10/09 19:02 you (;beck@ibh.de) transmitted structured data: >> Eine DVD-V ist nun nix weiter als eine spezielle Anwendung einer DVD-ROM, >> also ist es hier exakt so trivial wie bei CD-ROM. Essenziell reicht zum >> Erzeugen eines Image auf mitdenkenden Plattformen also der simpelste >> Befehl aller Zeiten, nämlich cat(;1): >> # cat /dev/dvd > my-dvd.img > > Hm, es kommt ja selten vor, aber eigentlich nehme ich dafür lieber dd.
Das ist unter anderen Unixoiden u.U. relevant, nicht aber unter Linux. Der wesentliche Vorteil von dd ist, dass es geblockt zugreifen kann, also auch zum Lesen und Schreiben von echten block devices taugt. Man hat es daher früher gern mit Platten, Bändern und sowas verwendet. Bei Linux sind aber block devices praktisch immer gleichzeitig frei zugreif- bar, ahmen also diesen Aspekt von character devices nach, ohne dass der Userspace sich darum kümmern muss. Das macht den Zugriff über STDIO völlig gleichwertig.
> cat kann auch mal so abbrechen, da hatte ich schon komische > Effekte.
Wo cat abbräche, bricht dd genau so ab. Es gibt zwar ein dd rescue, aber das ist wieder eine andere Geschichte. Glaub mir, ich kopiere unter Linux seit *Jahren* Disketten, Platten, Partitionen, CD/DVD und Bänder mit STDIO, also cat, netcat oder direkter E/A-Umlenkung, und hatte *nie* ein Problem damit. Man muss nur wissen, dass das nicht 1:1 auf klassische Unixe zu übertragen ist, Rumgemache mit Bandgeräten unter Solaris etwa sollte tunlichst mit dd erfolgen.
Der große Vorteil von dd ist natürlich, dass man mehr Parameter hat. So erschauere ich immer, wenn ich irgendwo etwas wie
dd if=/dev/zero of%disk.img bs%1m count24
lese, was ein Disk-Image für Loopmounts/UML werden soll. Das kann man sehr viel einfacher haben:
Das geht Größenordnungen schneller und ganz nebenbei ist das Resultat auch noch sparse. Sowas geht wirklich nicht mit cat.
>> Und brennen würde man das dann z.B. mit >> >> # growisofs -Z /dev/dvd%my-dvd.img > > Wenn es vorher eine CSS-geschützte DVD war (;böse, sowas darf man natürlich > überhaupt nicht, weil CSS ja ein "wirksamer Kopierschutz" ist, haha), > dann geht das aber nur mit R/ RWs. Denn bei -R/-RW ist die CSS-Spur nicht > beschreibbar. Insofern also: nicht machen !
Die CSS-Information ist überhaupt nicht Bestandteil des ROM-Parts¹, daher ist das vollkommen irrelevant. Wäre der Ausgangspunkt eine CSS-DVD-V, dann würde das nach Aktivierung des CSS-Decrypt im Laufwerk immer noch exakt so funktionieren, ohne diese Entschlüsselung wäre das Image hinterher einfach nur unbrauchbar. Da der Urposter aber explizit von DVD-RW als Quelle sprach, ist das auch egal.
>> Aber klar, man kann sich das Leben natürlich auch schwer machen mit >> Monstrositäten á la WinOnCD oder Nero ;) > > Das braucht jemand ? :) Hey, das ist unfair, Windows-User haben genug > Probleme, man muß nicht noch auf ihnen rumtreten. Sei doch froh, daß Du's > einfacher hast.
Och, die Arroganz, mit der einige Win-User ihren goldenen Käfig zu übersehen pflegen, fordert schon hin und wieder ein paar Spitzen heraus. Etwa, wenn wieder jemand Dateinamen mit Dateiinhalten ver- wechselt. Man trifft zwar gewöhnlich die Falschen, aber Usenet hat eh was von Schrotschießen an sich ;)
¹) Meines Wissens ist das Zeug auf spezielle Weise im Lead-In codiert, so dass es ausschließlich dem Laufwerk zugänglich ist. Dieses wiederum tätigt diese Zugriffe nur, wenn sich die Applikation ihm gegenüber mittels einer kryptografischen Anmeldeprozedur authentisiert hat. Der Zugriff auf die verschlüsselten ROM-Daten wird also über spezielle SCSI²-Kommandos autorisiert. Ob man mittels gepatchter Firmware prinzipiell in der Lage wäre, die CSS-Daten im Lead-In einer R(;W) zu setzen, so dass das undekodierte Image anschließend funktioniert, ist eine sehr interessante Frage, die sicher früher oder später von jemandem (;wahrscheinlich nicht in DE) rein wissenschaftlich untersucht wird. Ich glaube es erst, wenn ich es gesehen^Wdavon verlässlich gelesen habe.
²) Ja, SCSI. ATAPI ist im wesentlichen auch nur SCSI-over-IDE. -- The S anta C laus O peration or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Udo Wolter:
On 2004/10/09 22:25 you (;beck@ibh.de) transmitted structured data: >> cat kann auch mal so abbrechen, da hatte ich schon komische >> Effekte. > Wo cat abbräche, bricht dd genau so ab. Es gibt zwar ein dd rescue, aber
Das war bei mir schon oft genug anders. Zumindest was Plattenkopieren betrifft, geht's mit cat schief. Aber dd kann man eh viel besser zur Optimierung nutzen.
> Das geht Größenordnungen schneller und ganz nebenbei ist das Resultat > auch noch sparse. Sowas geht wirklich nicht mit cat.
Kein Widerspruch. Letztlich ist cat aber auch nicht für sowas gemacht worden. Aber wir werden Off-Topic hier...
>> Das braucht jemand ? :) Hey, das ist unfair, Windows-User haben genug >> Probleme, man muß nicht noch auf ihnen rumtreten. Sei doch froh, daß Du's >> einfacher hast. > Och, die Arroganz, mit der einige Win-User ihren goldenen Käfig zu > übersehen pflegen, fordert schon hin und wieder ein paar Spitzen
Naja, mittlerweile kann man sich ja nur müde lächelnd zurücklehnen, wenn die nächste Viren-/Trojaner-/Sonstwas-Welle läuft. Eigentlich überwiegt in letzter Zeit eher Mitlight.
> heraus. Etwa, wenn wieder jemand Dateinamen mit Dateiinhalten ver- > wechselt. Man trifft zwar gewöhnlich die Falschen, aber Usenet hat > eh was von Schrotschießen an sich ;)
Ich sage mir immer: hier ballern schon genug, zu dem Wahnsinn muß ich nicht beitragen. Letztlich poste ich hier nicht, um andere anzuscheißen, sondern weil ich das Thema Video interessant finde, gerne Hilfe in Anspruch nehme und deshalb auch Hilfen gebe (;ich doofer Moralist, ich). Wo es zu hirnrissig wird, muß man ja nicht antworten, Trolle bleiben so immer unter sich.
> ¹) Meines Wissens ist das Zeug auf spezielle Weise im Lead-In codiert, > so dass es ausschließlich dem Laufwerk zugänglich ist. Dieses
Also wenn ich mir DVD-Rs genau betrachte, dann findet sich knapp ein halber Zentimeter vom ersten Spurrand (;ausgehend von der Mitte natürlich) eine gut sichtbare Spur. Die läßt sich auch nicht beschreiben. Bei DVD Rs fehlt diese, also muß es doch einen Zusammenhang zwischen CSS und dieser Spur geben, schließlich hat das DVD-Forum nicht umsonst auf 2 Sorten beschreibbarer Minus-DVDs bestanden, den A- und den G-Rohlingen. G-Rohlinge haben alle diese ausgegraute Spur. Ich habe übrigens noch nie einen A-Rohling in der Hand gehabt. Gibt's die überhaupt ?
> authentisiert hat. Der Zugriff auf die verschlüsselten ROM-Daten > wird also über spezielle SCSI²-Kommandos autorisiert. Ob man mittels > gepatchter Firmware prinzipiell in der Lage wäre, die CSS-Daten > im Lead-In einer R(;W) zu setzen, so dass das undekodierte > Image anschließend funktioniert, ist eine sehr interessante > Frage, die sicher früher oder später von jemandem (;wahrscheinlich > nicht in DE) rein wissenschaftlich untersucht wird. Ich glaube > es erst, wenn ich es gesehen^Wdavon verlässlich gelesen habe.
Ich muß zugeben, daß ich es nicht weiß, weil ich es nie ausprobiert habe (;das wäre eh Blödsinn, wer will schon diesen riesigen Overkill an Qualität mitnehmen, wenn er mal was kopiert, das macht doch keiner), nichtsdestotrotz muß es ja irgendwie um diese komische "sinnfreie" Spur gehen.
> ²) Ja, SCSI. ATAPI ist im wesentlichen auch nur SCSI-over-IDE.
Im neuen kernel (;2.6.9-rc3) ist ATAPI Standard und nervt mich dadurch, daß die dvd rw-tools (;also Dein besagtes growisofs, was ich für wesentlich geschmeidiger halte als dvdrecord) nicht damit umgehen können, jedenfalls nicht mit meinem NEC-Drive. Also bleibe ich bei reinem SCSI-over-IDE. Alleine der Umstand, daß sie das mittlerweile sauber trennen, deutet darauf hin, daß ATAPI nicht nur sowas wie SCSI-over-IDE ist, sondern durchaus eine eigene, ernst zu nehmende Schiene ist.
Mermgfurt, Udo -- Udo Wolter | /" email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN www: www.dicke-aersche.de | X AGAINST HTML MAIL dark: heaven@lutz-ziffer.de | /
Antwort von Andre Beck:
Udo Wolter writes: > On 2004/10/09 22:25 you (;beck@ibh.de) transmitted structured data: >>> cat kann auch mal so abbrechen, da hatte ich schon komische >>> Effekte. >> Wo cat abbräche, bricht dd genau so ab. Es gibt zwar ein dd rescue, aber > > Das war bei mir schon oft genug anders. Zumindest was Plattenkopieren > betrifft, geht's mit cat schief.
Kann ich wie gesagt nicht nachvollziehen. Ich image Platten öfter mal mit netcat, das ist noch nie schief gegangen. Bei einem I/O-Error fliegt Dir dd genau so weg wie cat/netcat/gzip/whatever. Dort beginnt die Domäne von dd rescue, das unlesbare Blöcke als Nullen kopiert und dann beim nächsten Block weitermacht. Da ich an der Sicherheit meiner Daten sehr interessiert bin, wüsste ich gern mehr über Szenarien, in denen dd funktioniert, während cat (;also STDIO) schiefgeht. Gern auch in einer anderen Gruppe. Ich würde es nur gern Linux-spezifisch halten, da wie gesagt auf anderen Unixoiden objektive Gründe dafür sprechen, dass es schiefgehen kann, nicht aber (;meines Wissens) unter Linux (;1.2 bis 2.6).
> Aber dd kann man eh viel besser zur Optimierung nutzen.
Yep, speziell was Blockgrößen angeht. Ein dd mit laufendem Feedback wäre noch besser ;)
>> Das geht Größenordnungen schneller und ganz nebenbei ist das Resultat >> auch noch sparse. Sowas geht wirklich nicht mit cat. > > Kein Widerspruch. Letztlich ist cat aber auch nicht für sowas gemacht > worden. Aber wir werden Off-Topic hier...
Kein Widerspruch ;)
> Ich sage mir immer: hier ballern schon genug, zu dem Wahnsinn muß > ich nicht beitragen. Letztlich poste ich hier nicht, um andere anzuscheißen,
Na komm, eine Spitze ist kein Anschiss. Ich hatte mein Posting IMO mit genug sinnvoller Information gefüllt, die auch dem Win-User bei der Lösung seines Problems helfen würde, weil sie das grundlegende Ver- ständnis, wie eine DVD-V aufgebaut ist und wie simpel sie zu imagen und kopieren wäre, fördert. Er steht höchstens vor dem Problem, für seine Plattform passende Software zu finden, die genau das und nicht mehr macht. Und vielleicht noch frei ist. Nun, er hat diese Plattform gewählt, also ist das sein Problem. Oder er bootet dafür Knoppix ;)
>> ¹) Meines Wissens ist das Zeug auf spezielle Weise im Lead-In codiert, >> so dass es ausschließlich dem Laufwerk zugänglich ist. Dieses > > Also wenn ich mir DVD-Rs genau betrachte, dann findet sich knapp ein > halber Zentimeter vom ersten Spurrand (;ausgehend von der Mitte natürlich) > eine gut sichtbare Spur. Die läßt sich auch nicht beschreiben.
Die ist vorbeschrieben. Allerdings ist die wie gesagt im Lead-In-Bereich und ließe sich auch nicht direkt beschreiben, wenn sie nicht bereits zerbröselt wäre. Du kommst da mit dem Kommandosatz Deines G-Brenners nicht mal in die Nähe (;anders als lesend im Sinne der Authentisierungs- prozedur).
> Bei DVD Rs fehlt diese, also muß es doch einen Zusammenhang zwischen > CSS und dieser Spur geben,
Natürlich, sagte ich doch: Das ist der Bereich im Lead-In, wo die für CSS relevanten Informationen (;zulässige Playerkeys etc) stehen. Nur ist der eben nicht Teil einer eventuellen ROM-Session, er ist komplett out of band und kann nur mit speziellen Kommandos erreicht werden und nur zu dem Zweck, das dekodierte Lesen von kodierten Scheiben durch das Lufwerk zu aktivieren.
> schließlich hat das DVD-Forum nicht umsonst auf 2 Sorten > beschreibbarer Minus-DVDs bestanden, den A- und den G-Rohlingen. G-Rohlinge > haben alle diese ausgegraute Spur. Ich habe übrigens noch nie einen > A-Rohling in der Hand gehabt. Gibt's die überhaupt ?
Ja, klar, für größere zweistellige Euro-Beträge pro Exemplar. Zusammen mit dem entsprechenden A-wie-Authoring-Brenner (;heute schon sehr günstig im vierstelligen Bereich erhältlich, jedenfalls AFAIK) hat man dann auch die Chance, diese Daten zu setzen, was wieder über spezielle Steuer- kommandos gehen wird, die der Brenner dann beim Schreiben des Lead-In umsetzt. Preislich ist das alles wohl sogar noch unter einem ordentlichen DLT-Drive und Cartridge, aber ehrlich gesagt wäre mir letzteres trotzdem lieber, wenn ich professionell authorn müsste. Nur *testen* kann man nur mit dem A-Medium und -Brenner.
>> authentisiert hat. Der Zugriff auf die verschlüsselten ROM-Daten >> wird also über spezielle SCSI²-Kommandos autorisiert. Ob man mittels >> gepatchter Firmware prinzipiell in der Lage wäre, die CSS-Daten >> im Lead-In einer R(;W) zu setzen, so dass das undekodierte >> Image anschließend funktioniert, ist eine sehr interessante >> Frage, die sicher früher oder später von jemandem (;wahrscheinlich >> nicht in DE) rein wissenschaftlich untersucht wird. Ich glaube >> es erst, wenn ich es gesehen^Wdavon verlässlich gelesen habe. > > Ich muß zugeben, daß ich es nicht weiß, weil ich es nie ausprobiert habe > (;das wäre eh Blödsinn, wer will schon diesen riesigen Overkill an Qualität > mitnehmen, wenn er mal was kopiert, das macht doch keiner), nichtsdestotrotz > muß es ja irgendwie um diese komische "sinnfreie" Spur gehen.
Nun, das DVD-Forum hat offenbar erkannt, dass es fatal wäre, wenn der gewöhnliche Joe User diese CSS-Parameter auf DVD-R schreiben könnte. Das würde nämlich jegliche der unrühmlichen Regelungen, wie wir sie hier inzwischen auch haben, die also das *knacken* eines Kopierschutz (;und sei es noch so trivial) unzulässig machen, zu Makulatur erklären. Man kann dann nämlich DVD kopieren, ohne dabei irgendwas zu knacken, das übernimmt weiterhin der (;erstaunlicherweise legale) DVD-Player.
Also erfand man zwei getrennte Medien: General Use und Authoring Use. Um die Sache für Firmwarehacker etwas zu erschweren, nutzen die auch unterschiedliche Laser-Wellenlängen.
Dann kam das subversive -Panel um Philips und meinte, dass es reicht, wenn der Brenner (;also seine Firmware) das manipulieren des Lead-In wirkungsvoll verhindert. Lassen wir uns einfach überraschen, wann der erste Firmwarehacker das umgedreht hat.
>> ²) Ja, SCSI. ATAPI ist im wesentlichen auch nur SCSI-over-IDE. > > Im neuen kernel (;2.6.9-rc3) ist ATAPI Standard und nervt mich dadurch, > daß die dvd rw-tools (;also Dein besagtes growisofs, was ich für wesentlich > geschmeidiger halte als dvdrecord) nicht damit umgehen können, jedenfalls > nicht mit meinem NEC-Drive.
Ich umgehe dieses Problem dadurch, dass mein DVD-Brenner in einer externen Box sitzt, die per Firewire oder USB2 an den Rechner gehängt wird. Das hat nur Vorteile, u.a. auch, dass es für Linux nach wie vor SCSI ist, so wie sich das gehört. Und da ich nicht zu den Leuten gehöre, die zwanghaft DVDs brennen, ist das Ding meistens aus und verheizt weder Strom noch altert es sinnlos.
> Also bleibe ich bei reinem SCSI-over-IDE. Alleine > der Umstand, daß sie das mittlerweile sauber trennen, deutet darauf hin, > daß ATAPI nicht nur sowas wie SCSI-over-IDE ist, sondern durchaus > eine eigene, ernst zu nehmende Schiene ist.
Ich schrieb "im wesentlichen", was Abweichungen im Detail zulässt. Sicher divergiert da einiges, aber ATAPI ist aus SCSI hervorgegangen (;damals, als es CD-Laufwerke anfangs nur mit SCSI gab und dann die ersten für IDE gestrickt wurden - man hat einfach den bewährten Steuerkommandosatz irgendwie auf ATA gepfropft) und momentan ist es sogar teilweise wieder am konvergieren (;SATA/SAS). Das Gerangel um die IDE-SCSI-Emu im Kernel hat weniger technische Gründe als vielmehr soziologische, aber das wäre nun hier tatsächlich OT ;)
-- The S anta C laus O peration or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-