Ford+VW: Argo AI - Robotaxi-Startup eingestellt...

On 12/23/2022 10:42, Carla Schneider wrote:
Helmut Schellong wrote:

On 12/22/2022 19:11, Carla Schneider wrote:
Rupert Haselbeck wrote:

Helmut Schellong schrieb:
[...]

Die Allianz entwickelt/konzipiert bereits Versicherungen für die Autonomen.
Eine Haftpflichtversicherung braucht das Auto, das ist klar,
aber normalerweise zahlt immer die des Unfallverursachers, also hier die des Fussgaengers
der auf die Strasse laeuft.

Nur, weil sie hier bei Rot über den Zebrastreifen geht.
Hätte sie Grün, hätte sie Vorfahrt.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 12/20/2022 06:52, Gerrit Heitsch wrote:
On 12/20/22 00:32, Helmut Schellong wrote:

Fehlerfreie Software ist selbstverständlich möglich.

Meinst du. Schon bei eher simplen Programmen ist der Beweis der Korrektheit nicht mehr möglich.

Meine ich, ausdrücklich ja!
Fehlerfreie Software ist doch nicht prinzipiell unmöglich!

Die meisten Library-Funktionen sind garantiert fehlerfrei.
Das kann ich leicht per Stichproben beweisen.

Was schrieb ich vorstehend?
\'Library-Funktionen\'!
Daß also __diese__ tatsächlich meistens fehlerfrei sind.
Die können jedoch vielschichtig falsch aufgerufen werden! (Je nach Programmiersprache)
Das ist jedoch eine _ganz andere_ Angelegenheit!

Außerdem hat jede Programmiersprache inhärente Mängel, die nicht
die Schuld des Anwenders (Programmierers) sind.

Sicherheitsrelevante Software wird entsprechend geprüft, bis sie
keine Fehler mehr enthält bzw. bis sich kein Fehler mehr zeigt.

Letzteres ist aber nicht dasselbe wie ersteres,

Ja, genau deshalb schrieb ich das.

denn es kann einfach nur bedeuten, daß du nicht ausführlich genug getestet hast.

Eine Menge Software schien fehlerfrei zu sein bis ein Hacker das Gegenteil bewiesen hat.

Das traf genau für diese Menge an Software zu.

Der Ariane_5-Fehler ist bekannt.
Es wurde ein Programmierfehler bekannt (Überlauf).
Jedoch mehrere Fehler im Entwicklungsprozeß, wobei jeder einzelne, wäre er
nicht gemacht worden, den Verlust verhindert hätte.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 12/23/2022 15:50, Peter Heirich wrote:
Helmut Schellong wrote:

Unter den 67 µC sind z.B. 34 redundant.

Das spricht für Redundanz gegen Ausfall, nicht für 2 aus 3 Logik, um hoffentlich unerkannte Softwarefehler auszugleichen. Auch wenn mir nicht klar ist, ob 2 aus 3 Logik dabei überhaupt machbar ist.

Meine Zeile oben soll einfach nur Redundanz (überflüssig) bedeuten.
Keine sehr spezielle Redundanz.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 2022-12-19, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
Wenn man es nicht ein bißchen glitcht.

Bei einem EPROM oder Masken-ROM sehe ich da wenig Chancen auf
Veränderung des Codes in selbigem.

Brauchst Du nicht, es reicht, den Code auf dem Weg in die CPU oder bei der
Vararbeitung in der CPU zu beeinflussen:

https://hackaday.com/2022/11/28/a-modchip-to-root-starlink-user-terminal-through-voltage-glitching/

https://voidstarsec.com/blog/replicant-part-1

Das erfordert natürlich physikalischen Zugriff aus das Board.

Und: EPROM und Maskenrom ist tot - Maskenrom gibt es maximal noch für
on-chip-Bootloader, nahezu alles andere ist heute Flash. Wie will man sonst
nach der ersten Auslieferung funktionierende Software nachliefern? ;-)

cu
Michael
 
On 12/23/2022 16:17, Michael Schwingen wrote:
On 2022-12-22, Helmut Schellong <rip@schellong.biz> wrote:
Ja, das hat bei der Ariane 5 super funktioniert ;-)


Bei Ariane 5 war das Gegenteil der Fall.
Der betreffende Parameter hatte Werte eben _nicht_ zugelassen!
Es entstand ein Überlauf, ein Abschneiden der höherwertigen Bits.
(Umwandlung 64bit-gleitkomma -> 16bit-integer)

Man war vorher (bei der Ariane 4) sicher, daß eben genau das nicht passieren
könnte, und hat den Überlauf daher absichtlich nicht abgefangen.

Bei der 5 hat man dann vergessen, diese Prüfung mit den neuen
Randbedingungen zu wiederholen.

Ja, bei Ariane 5 waren die Werte 5-mal so hoch.
Das paßte dann nicht mehr in 16 Bit hinein.

Wobei ich mich wunderte, daß da überhaupt 16bit-Einzelobjekte Verwendung fanden,
als ich zum ersten Mal den WP-Artikel las.
Ich weiß allerdings nicht, ob da 16bit-Prozessoren sind.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 12/20/2022 09:41, Gerrit Heitsch wrote:
On 12/20/22 09:10, Rupert Haselbeck wrote:
Gerrit Heitsch schrieb:
Helmut Schellong wrote:
Fehlerfreie Software ist selbstverständlich möglich.

Meinst du. Schon bei eher simplen Programmen ist der Beweis der Korrektheit nicht mehr möglich.

Doch. Bei all dem Unsinn, den er ständig zusammenfaselt, das stimmt immerhin.

[...]

> Ich habe immer noch Zweifel, daß bei komplexer Software ein \'garantiert fehlerfrei\' möglich ist.

Das bedeutet ja, daß jede komplexe Software fehlerbehaftet sein _muß_!

Das liegt daran, daß fast alle Protagonisten irgendwie von den Hackern traumatisiert
und in der Folge konditioniert sind.
Dies wiederum liegt daran, daß die wenigsten Jahrzehnte lang komplexe Software entwickel(te)n.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
Am 23.12.2022 um 15:02 schrieb Alexander Schreiber:

Soweit ich weiss hat bisher noch niemand Monsterwellen in Luft
nachgewiesen.
Woher kommt das Muschelrauschen?

--
Servus
Christoph Müller
www.astrail.de
 
Helmut Schellong schrieb:
On 01/04/2023 22:37, Rolf Bombach wrote:

1985 kam die Cray-2 raus.
50 Mio DM, 1 Tonne Kühlmittel, 2 GFLOPs, 200 kW.

Zu der Zeit war ich von der Bundeswehr zurück ... und studierte noch.
Echt Ahnung hatte ich da noch nicht.

Wer hat damals vorausgesehen, dass 2015 ein Apple-Computer
die doppelte Rechenkraft aufweisen wird?

Und um welchen Apple handelt es sich?


Kann ich beides nicht beantworten.
Ich hatte nie einen Apple (McIntosh) und auch fast keine Ahnung davon.

Es war die Apple-Watch!
Solche Voraussagen haben mich auch frühzeitig nicht (mehr) interessiert.
Warum?
Die Voraussage, daß die 1990er Jahre das Kommunikations-Jahrzehnt werden würde, stimmte.
Die Voraussage, daß (~2000) bei 30um Strukturgröße endgültig Schluß sein würde, liegt total daneben.

Ja und nein. In der Tat wurde bei 30 nm das Verhältnis von Oberfläche zu Volumen
pathologisch; Restströme wurden zu hoch, Ladungsträgerbeweglichkeit zu klein.
Es mussten neue FET erfunden und entwickelt werden, um diese Barriere zu überwinden.

https://de.wikipedia.org/wiki/Metall-Oxid-Halbleiter-Feldeffekttransistor#FinFET

--
mfg Rolf Bombach
 
Christoph Müller schrieb:
Am 23.12.2022 um 15:02 schrieb Alexander Schreiber:

Soweit ich weiss hat bisher noch niemand Monsterwellen in Luft
nachgewiesen.
Woher kommt das Muschelrauschen?

Weisses Rauschen - Resonanz

https://de.wikipedia.org/wiki/Helmholtz-Resonator

--
mfg Rolf Bombach
 
Carla Schneider schrieb:
Rolf Bombach wrote:

1985 kam die Cray-2 raus.
50 Mio DM, 1 Tonne Kühlmittel, 2 GFLOPs, 200 kW.

Wer hat damals vorausgesehen, dass 2015 ein Apple-Computer
die doppelte Rechenkraft aufweisen wird?

Das sind immerhin 30 Jahre und Moores Law war schon bekannt.

Nunja, das ist ja kein physikalisches Gesetz. Es ist eine
empirische Feststellung der ungefähren Geschwindigkeit einer
technischen Entwicklung. Hier eben die Dichte an Halbleitern
auf einem Chip. Diese Entwicklung hängt stark von der wirt-
schaftlichen Leistungsfähigkeit ab und diese von zahlreichen
unberechenbaren Faktoren.

> Ich haette nicht darauf gewettet dass es dann Apple noch geben wird...

Das war ja gelegentlich sehr knapp. Microsoft hat Apple dann mit
Millionenbeträgen gestützt.
Und um welchen Apple handelt es sich?

Keine Ahnung, ich weiss nur dass ich 2012 eine Grafikkarte gekauft habe
fuer etwas ueber 200Euro die hat bei 64Bit float Zahlen 700 GFLOPS.
Wer haette damals (2012) gedacht dass diese Leistung zu dem Preis
10 Jahre spaeter nicht mehr zu bekommen ist.

Apple Watch.

--
mfg Rolf Bombach
 
On 12/20/22 9:10 AM, Rupert Haselbeck wrote:
Gerrit Heitsch schrieb:

Man kann durchaus gesichert fehlerfreie Software erstellen, welche auch
wirklich in jedem Fall genau das macht, was sie gemäß den Anforderungen
machen soll.

Und die beliebig in allen Fällen verfahren kann, die nicht in den
Anforderungen stehen. Das verschiebt den Test auf Fehlerfreiheit zur
Spezifikation, die alle zu vermeidenden Fehler aufzählen müßte.

Abgesehen davon ist erfahrungsgemäß der einfachste Weg zu einem
unbrauchbaren Programm die genaue Einhaltung der Spezifikation. Das
macht dann garantiert keine Fehler, aber üblicherweise auch sonst nichts
brauchbares.


Eine Menge Software schien fehlerfrei zu sein bis ein Hacker das
Gegenteil bewiesen hat.

Eine Menge Softwareklitschen ist erstens nicht zu wirklich guter
Leistung in der Lage, zumeist schon mangels hinreichend viel hinreichend
guten und damit teuren Personals, aber es gibt durchaus Methoden zur
Entwicklung sicher fehlerfreier Software und wenn der Auftraggeber die
Anforderung \"garantiert fehlerfrei\" ins Pflichtenheft schreibt und die
entsprechend höheren Kosten tragen mag, dann kann er das auch bekommen.

Er *könnte*, wenn er einen Dummen fände, der so einen Auftrag annimmt.
Möchtest Du der erste sein? Bis zu welchem Betrag der Vertragsstrafe
könntest Du für die Fehlerfreiheit haften?


Es sollte eigentlich allgemein bekannt sein, daß die *Abwesenheit* von
irgendwas nicht mit Sicherheit feststellbar ist. Dies gilt auch für die
Abwesenheit von Fehlern. Wer das Gegenteil fehlerfrei beweisen kann
bekommt den nächsten Nobelpreis etc.

Aber vielleicht hat ja schon ein Mathematiker bewiesen, daß der Beweis
von Fehlerfreiheit unmöglich ist, z.B. Turing mit dem Halteproblem...

DoDi
 
On 01/01/2023 23:17, Christoph Müller wrote:
Am 01.01.2023 um 12:49 schrieb Helmut Schellong:

Ich schätze den Preis eines Level_5 in Großserie (zumindest anfangs) auf 150000..250000 EUR.

Mit solchen Einschätzungen wäre ich etwas vorsichtiger.

Schätzungen sind Schätzungen.
Andere Beträge sehe ich eben nicht.

Gewinn = Gewinn/Stück * Stück

Der Gewinn soll i.d.R. optimiert werden. Man kann den Gewinn/Stück in die Höhe schrauben. Dann kann man nur wenige Stück verkaufen. Der Gewinn kann dann trotz horrendenden Margen ziemlich gering ausfallen. Wer ein fixfertiges Händler- und Servicenetz hat (der Aufbau eines solchen ist durchaus teuer und langwierig), kann auch mit kleinen Margen, dafür aber mit großen Stückzahlen punkten.


In der Tabelle schneiden Bosch und Mercedes absolut erbärmlich ab!
Ich sehe bis jetzt eine totale Chancenlosigkeit bei diesen Herstellern.

In der Branche ist es ganz normal, dass die Großen das Geschehen aus der Ferne im bequemen Sessel beobachten und dann zum richtigen Zeitpunkt eine erfolgreiche Firma einfach kaufen. Wer ein dickes Finanzpolster hat, kann sich solches Verhalten leisten. Bosch und Mercedes haben sowas.

Waymo und Cruise gehören Google/Alphabet bzw. GM und können höchstwahrscheinlich nicht gekauft werden.
Wenn die erfolgreich fertig sind mit der Entwicklung, werden die doch nicht verkaufen!

Du meinst, Google und General Motors sind klein?


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On Mon, 19 Dec 2022 20:22:46 +0100, Gerrit Heitsch wrote:
On 12/19/22 20:17, Volker Bartheld wrote:
On Mon, 19 Dec 2022 18:19:25 +0100, Gerrit Heitsch wrote:
On 12/19/22 17:55, Helmut Schellong wrote:
Der Code im ROM war zur Runtime absolut unänderbar.
Das hat ein ROM so an sich. ;)
Wenn man es nicht ein bißchen glitcht.
Bei einem EPROM oder Masken-ROM sehe ich da wenig Chancen auf
Veränderung des Codes in selbigem.

Du mußt das ROM bzw. dessen Code nicht permanent verändern. Es reicht
möglicherweise schon, die Programmausführung eines Microcontrollers
einmal etwas aus der Bahn zu schubsen. Preisfrage: Wann \"rebootet\" denn
so ein Kfz-Steuergerät typischerweise? Tip: Klemmenwechsel ist es
schonmal nicht. Daher auch die Angst gewisser Regulars, lieber nicht
die Batterie länger vom Bordnetz zu trennen.

Volker
 
Sieghard Schicktanz schrieb:
Hallo Rolf,

Du schriebst am Thu, 22 Dec 2022 12:19:00 +0100:

...
You cannot unscramble the egg.

Dazu gibt\'s ein nettes Experiment, nicht mit \'nem Ei, sondern mit
Farbklecksen in einem Behälter:
https://www.youtube.com/watch?v=j2_dJY_mIys
Unmixing Color Machine Ultra Laminar Reversible Flow - Smarter Every
Day 217.mp4
(Leider ist das Video gegen Ende mit einem dicken Werbeeinschub ver...
äh ...sehen.

Das war ja auch nicht \"scrambled\", sondern nur in der dritten Dimension
reversibel verschoben.

--
mfg Rolf Bombach
 
Helmut Schellong schrieb:
On 12/22/2022 12:26, Rolf Bombach wrote:
Helmut Schellong schrieb:

Nein, Maschinen können keine Fehler machen!
Hingegen die Software in Maschinen kann fehlerhaft programmiert worden sein.

Wie war das mit dem AT&T telephone crash in Kanada?

Die Software war fehlerfrei.
Die Hardware war fehlerfrei.
Alle Eingaben waren fehlerfrei.

Trotzdem Totalcrash.


War da nicht was mit besonders starken Sonnenwinden?!

Die Hardware funktionierte fehlerfrei!
Ich hatte noch vergessen zu schreiben: Der Compiler war fehlerfrei.

Es stellte sich im Nachhinein heraus, dass das Verhalten bei
einem speziellen Absprung aus einer verschachtelten Struktur gar
nicht definiert war. Es existierten verschiedene \"Standards\"
für C, offenbar wurde das nicht kommuniziert.
Es zeigt nur, dass man _nicht_ an _alles_ denken kann.

--
mfg Rolf Bombach
 
Christoph Müller <chrnewsgroup@astrail.de> wrote:
Am 23.12.2022 um 15:02 schrieb Alexander Schreiber:

Soweit ich weiss hat bisher noch niemand Monsterwellen in Luft
nachgewiesen.
Woher kommt das Muschelrauschen?

Muschel wirkt als Resonator.

Man liest sich,
Alex.
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison
 
On 12/20/22 15:41, Michael Schwingen wrote:
On 2022-12-19, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
Wenn man es nicht ein bißchen glitcht.

Bei einem EPROM oder Masken-ROM sehe ich da wenig Chancen auf
Veränderung des Codes in selbigem.

Brauchst Du nicht, es reicht, den Code auf dem Weg in die CPU oder bei der
Vararbeitung in der CPU zu beeinflussen:

https://hackaday.com/2022/11/28/a-modchip-to-root-starlink-user-terminal-through-voltage-glitching/

https://voidstarsec.com/blog/replicant-part-1

Das erfordert natürlich physikalischen Zugriff aus das Board.

Ja, und damit mehr als man meist hat. Solche Angriffe werden
durchgeführt weil der Hersteller was verbergen will. Remote-Angriffe
hingegen weil man Daten des Users rankommen will.


Und: EPROM und Maskenrom ist tot - Maskenrom gibt es maximal noch für
on-chip-Bootloader, nahezu alles andere ist heute Flash. Wie will man sonst
nach der ersten Auslieferung funktionierende Software nachliefern? ;-)

Ja, eben... zur Zeit von Masken-ROMs musste man sich bei der
Programmierung noch Mühe geben. Selbst mit EPROMs war das noch nötig.
Heute kann man Software behandeln wie Bananen, grün ausliefern und beim
Kunden reifen lassen.

Gerrit
 
Volker Bartheld schrieb:
1. Der Mensch fährt besser als gedacht [1].

Nun, in DE ca. 2.5 Mio polizeilich erfasste Unfälle im Jahr.
(Ich weiss nicht, ob in DE eine Anzeige nötig ist, um Versicherungs-
leistungen bei Bagatellunfällen einfordern zu können.)
Mit all den nicht gemeldeten Bagatellunfällen können das
dann auch 10 Mio sein.
0.25 M Personenschäden, 2500 tödlich.

Also so rund 25\'000 mal am Tag knallt\'s. Und einer meinte hier,
ihn wundere es, dass so _wenig_ passiere.

\"Der Mensch fährt besser als KI, als gedacht\", OK.
Aber so absolut gesehen, eher nein.

Die meisten Meldungen über Unfälle fangen an mit: \"Ich dachte, dass...\"

--
mfg Rolf Bombach
 
On 12/20/22 15:51, Helmut Schellong wrote:
On 12/20/2022 09:41, Gerrit Heitsch wrote:
On 12/20/22 09:10, Rupert Haselbeck wrote:
Gerrit Heitsch schrieb:
Helmut Schellong wrote:
Fehlerfreie Software ist selbstverständlich möglich.

Meinst du. Schon bei eher simplen Programmen ist der Beweis der
Korrektheit nicht mehr möglich.

Doch. Bei all dem Unsinn, den er ständig zusammenfaselt, das stimmt
immerhin.

[...]

Ich habe immer noch Zweifel, daß bei komplexer Software ein
\'garantiert fehlerfrei\' möglich ist.

Das bedeutet ja, daß jede komplexe Software fehlerbehaftet sein _muß_!

Nein, der Schluss ist falsch. Sie kann natürlich fehlerfrei sein. Aber
das zu beweisen ist das Problem.

Dazu kommen noch mögliche Fehler im Compiler. Dein Sourcecode ist
fehlerfrei, aber das was der Compiler draus macht nicht mehr.

Gerrit
 
Gerrit Heitsch schrieb:
Oder auch morgens einsteigen und zur Arbeit wollen... Und das Auto meldet ein \'Update in progress, this might take a few minutes\'. ;)

\'Bitte legen Sie die Original-CD ein\'

\'Bitte geben Sie den Aktivierungs-Code ein\'

--
mfg Rolf Bombach
 

Welcome to EDABoard.com

Sponsor

Back
Top