MBP Late 08 und 10.8.3

[Markus Elsken]

Moin!

Hier steht ein 17" MBP Late 08, welches voreilig von 10.7.5 auf 10.8.3
hochgerüstet wurde. Natürlich mit allen Optionen wie verschlüsselte
Platte etc. Natürlich lahmt die Kiste grausam, zusätzlich lassen sich
keine Drucker mehr einrichten. Sowohl wenn ich die Treiber selbst
herunterlade als auch, wenn das System das selbst macht - es gibt Fehler
bei der Installation. Auch nach Neuinstallation und Import der Daten
bleibt der Fehler. Jemand eine Idee, wo ich suchen könnte? Komplett from
Scratch aufsetzen ist nicht wirklich eine Option...

mfg Markus

[Joerg Lorenz]

Am 23.04.13 10:05, schrieb Markus Elsken:

> Moin!
>
> Hier steht ein 17" MBP Late 08, welches voreilig von 10.7.5 auf 10.8.3

> hochgerï¿œstet wurde. Natï¿œrlich mit allen Optionen wie verschlï¿œsselte
> Platte etc. Natï¿œrlich lahmt die Kiste grausam, zusï¿œtzlich lassen sich

> keine Drucker mehr einrichten. Sowohl wenn ich die Treiber selbst
> herunterlade als auch, wenn das System das selbst macht - es gibt Fehler
> bei der Installation. Auch nach Neuinstallation und Import der Daten

> bleibt der Fehler. Jemand eine Idee, wo ich suchen kï¿œnnte? Komplett from

> Scratch aufsetzen ist nicht wirklich eine Option...

Ich fï¿œrchte: Die einzige, die Dir ein sauberes System garantieren kann,
sofern alle Hardwarekomponenten in Ordnung sind.

>
> mfg Markus

Gruss, Jï¿œrg


--
http://www.albasani.net/index.html.de
Ein freier und kostenloser Server fï¿œr Usenet/NetNews (NNTP)

[Thomas Kaiser]

Joerg Lorenz schrieb in <news:kl62vh$g5t$1...@news.albasani.net>

> Am 23.04.13 10:05, schrieb Markus Elsken:

>> Hier steht ein 17" MBP Late 08, welches voreilig von 10.7.5 auf

>> 10.8.3 hochgerüstet wurde. Natürlich mit allen Optionen wie
>> verschlüsselte Platte etc. Natürlich lahmt die Kiste grausam,

>> zusätzlich lassen sich keine Drucker mehr einrichten. Sowohl wenn ich

>> die Treiber selbst herunterlade als auch, wenn das System das selbst
>> macht - es gibt Fehler bei der Installation. Auch nach
>> Neuinstallation und Import der Daten bleibt der Fehler. Jemand eine

>> Idee, wo ich suchen könnte? Komplett from Scratch aufsetzen ist nicht
>> wirklich eine Option...
>
> Ich fürchte: Die einzige, die Dir ein sauberes System garantieren kann

Fürchte ich auch angesichts Markus' latenter Resistenz gegen Analyse,
wenn diese nicht "Mac-like" ausfällt. Also alles Naheliegende wie in
Log-Dateien schauen, ob irgendwas amokläuft oder per Aktivitätsanzeige
(oder iostat, vm_stat und top) nachgucken, warum das System an seine
Grenzen stößt.

Wegen der gefühlten Lahmheit wäre zusätzlich interessant, ob die FS-
Verschlüsselung überhaupt schon durch ist oder noch im Hintergrund
läuft:

diskutil corestorage list

Und wegen dem Installationsproblem _könnte_ ein Blick in
/var/log/install.log erhellend sein. Oder 'ne konkrete Fehlermeldung.

Gruss,

Thomas

[Markus Elsken]

Moin!

Am 23.04.13 16:00, schrieb Thomas Kaiser:

> Fürchte ich auch angesichts Markus' latenter Resistenz gegen Analyse,
> wenn diese nicht "Mac-like" ausfällt. Also alles Naheliegende wie in
> Log-Dateien schauen, ob irgendwas amokläuft oder per Aktivitätsanzeige
> (oder iostat, vm_stat und top) nachgucken, warum das System an seine
> Grenzen stößt.

Da braucht man jemanden, der diese Sachen auch versteht. Das Terminal
ist für mich ein Buch mit 7 Siegeln, da kann ich maximal ferige Strings
reinkopieren und gucken, was passiert. Was ich ungern mache, weil ich
weiss, dass man da sehr viel zerstören kann. Warum das System lahmt
weiss ich: oller Core2Duo und nur 4GB RAM.

> Wegen der gefühlten Lahmheit wäre zusätzlich interessant, ob die FS-
> Verschlüsselung überhaupt schon durch ist oder noch im Hintergrund
> läuft:
>
> diskutil corestorage list

Wie lange läuft so etwas? Der Umstieg auf 10.8 erfolgte schon vor
Wochen, das Problem trat aber erst jetzt auf, als ein neuer Drucker ins
Haus kam.

> Und wegen dem Installationsproblem_könnte_ ein Blick in

> /var/log/install.log erhellend sein. Oder 'ne konkrete Fehlermeldung.

Die Fehlermeldung war nur lapidar, dass die Installation aufgrund eines
Fehlers nicht abgeschlossen werden konnte. Die Das Logfile müsste ich
mal hier reinkopieren, das ist mir zu kryptisch - bin ja schliesslich
weder Programmierer noch Unix-Guru.

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb in <news:5176a40c$0$30115$8e6e...@newsreader.ewetel.de>

> Am 23.04.13 16:00, schrieb Thomas Kaiser:
>> Fürchte ich auch angesichts Markus' latenter Resistenz gegen Analyse,
>> wenn diese nicht "Mac-like" ausfällt. Also alles Naheliegende wie in
>> Log-Dateien schauen, ob irgendwas amokläuft oder per
>> Aktivitätsanzeige (oder iostat, vm_stat und top) nachgucken, warum
>> das System an seine Grenzen stößt.
>
> Da braucht man jemanden, der diese Sachen auch versteht.

Da braucht man eigentlich nur den Willen, simple Zusammenhänge zu
verstehen bzw. ein bisschen zu lernen, wie man was interpretiert. Ne
Checkliste, warum Rechner lahmen können, hat Götz neulich gepostet.

Und mit simplen Zusammenhängen meine ich so Sachen wie "Wenn in der
Aktivitätsanzeige sichtbar ist, daß irgendein Task andauernd auf Vollgas
läuft, dann bremst der halt den Rest aus". Wenn in system.log (dafür
brauchst Du kein "Terminal", dafür gibt's Konsole.app, wenn man's bunt
mag) was von andauernd abstürzenden Prozessen steht, dann ist klar, daß
da irgendwas ausbremst. Usw. usf. -- ganz simple Zusammenhänge. Man muß
sich ihnen nur gegenüber öffnen.

> Das Terminal ist für mich ein Buch mit 7 Siegeln, da kann ich maximal
> ferige Strings reinkopieren und gucken, was passiert.

Dann halt Dich an die Aktivitätsanzeige, wenn Du davor Angst hast. Du
willst aber einfach nicht.

> Was ich ungern mache, weil ich weiss, dass man da sehr viel zerstören
> kann.

Geh in den Finder, klick auf das Symbol der internen Platte, ruf den
Info-Dialog auf, klicks rechts unten auf das Schloßsymbol und
autentifiziere Dich als Admin. Dann bei den Berechtigungen bei "jeder"
das "Lesen" wegmachen und drunter bei dem Rädchen "Auf alle Unterobjekte
anwenden" durchführen. Und dann genüßlich dem System beim Sterben
zuschauen. Das kriegst Du nie und nimmer in der Shell, die unter einem
normalen User-Account läuft, hin.

> Warum das System lahmt weiss ich: oller Core2Duo und nur 4GB RAM.

Ein Core2Duo mit 2,5 oder 2,6 GHz ist halb so schnell wie ein
Dual-Core-i7. Und 4 GByte reichen eigentlich völlig für Allerwelts-
Aufgaben. Wenn sie nicht reichen, dann swappt die Kiste andauernd. Ob
sie das tut, kann man nachschauen (evtl. in bunt, in jedem Fall per
"vm_stat 5" in einem Shell-Fensterchen -- aber das willst Du nicht).

>> Wegen der gefühlten Lahmheit wäre zusätzlich interessant, ob die FS-
>> Verschlüsselung überhaupt schon durch ist oder noch im Hintergrund
>> läuft:
>>
>> diskutil corestorage list
>
> Wie lange läuft so etwas?

Na, das kommt drauf an, was denn sonst? Schau halt einfach nach.
Copy&Paste von obiger Zeile in ein Terminal-Fenster. Vorher
Verifizierung, was das alles Böses mit dem Rechner macht, indem Du die
selbe verdammte Textzeile ins Suchfeld eines Browsers eingibst. Wenn das
System noch im Hintergrund am Verschlüsseln sein sollte, dann steht das
im Klartext (wenngleich auch in simplem englisch) in der Ausgabe des
Befehls.

> Der Umstieg auf 10.8 erfolgte schon vor Wochen, das Problem trat aber
> erst jetzt auf, als ein neuer Drucker ins Haus kam.

Aha, d.h. seit der Drucker da ist, ist der Rechner langsam geworden?
Wenn dem so ist (und das nicht wieder eine der üblichen retrospektiven
Problembeschreibungen seitens Usern ist, die zu 10% aus Fakten und zu
90% aus mutwilliger Interpretation bestehen), dann lohnt sich erst recht
ein Blick in besagte Logs. Vielleicht crasht da wirklich unter der Haube
ein Installations-Prozeß im Sekundentakt, der das System lahmlegt.

Außerdem besteht "das Problem" laut Deiner Aussage doch seit 2008, denn
"Warum das System lahmt weiss ich: oller Core2Duo und nur 4GB RAM". An
solch ehernen Wahrheiten ändert doch auch der Kauf eines Druckers oder
dessen Anwesenheit im selben Zimmer oder gar der Installations-Versuch
irgendwelcher Treiber nichts?

>> Und wegen dem Installationsproblem_könnte_ ein Blick in
>> /var/log/install.log erhellend sein. Oder 'ne konkrete Fehlermeldung.
>
> Die Fehlermeldung war nur lapidar, dass die Installation aufgrund
> eines Fehlers nicht abgeschlossen werden konnte. Die Das Logfile
> müsste ich mal hier reinkopieren, das ist mir zu kryptisch - bin ja
> schliesslich weder Programmierer noch Unix-Guru.

Ach Quatsch, installier neu (aber prüfe auf keinen Fall, ob ggf. das
Dateisystem einen an der Klatsche hat, dann kannst Du den Zirkus evtl.
auch noch mehrfach wiederholen). Du wirst doch sicher nach Stunden
bezahlt?

Woher kommt eigentlich immer dieses ulkige "ich bin doch kein
Programmierer"-Gehabe im Zusammenhang mit Logfiles? Warum sollten
ausgerechnet Programmierer Logfiles verstehen können? Das ist doch nur
Ausdruck von "Ich versteh von beidem nix, das ist mir zu aufwändig und
ich _will_ mich weder mit dem einen noch dem anderen beschäftigen"?

Gruss,

Thomas

[Patrick Kormann]

Am 23.04.13 16:00, schrieb Thomas Kaiser:

> Fürchte ich auch angesichts Markus' latenter Resistenz gegen Analyse,
> wenn diese nicht "Mac-like" ausfällt. Also alles Naheliegende wie in
> Log-Dateien schauen, ob irgendwas amokläuft oder per Aktivitätsanzeige
> (oder iostat, vm_stat und top) nachgucken, warum das System an seine
> Grenzen stößt.

Aber seien wir ehrlich, ich sehe mich weiss Gott nicht als blutigen
Anfänger, aber so wirklich viel haben mir die Logs auch noch nicht
genützt unter OS X. Ausser das ungute Gefühl zu erzeugen, dass da auch
wenn alles in Ordnung ist allerlei Warnungen und Fehler im Log landen...

[Thomas Kaiser]

Patrick Kormann schrieb in <news:k4li4a-...@news.sirdir.ch>

> Am 23.04.13 16:00, schrieb Thomas Kaiser:
> > Fürchte ich auch angesichts Markus' latenter Resistenz gegen
> > Analyse, wenn diese nicht "Mac-like" ausfällt. Also alles
> > Naheliegende wie in Log-Dateien schauen, ob irgendwas amokläuft oder
> > per Aktivitätsanzeige (oder iostat, vm_stat und top) nachgucken,
> > warum das System an seine Grenzen stößt.
>
> Aber seien wir ehrlich, ich sehe mich weiss Gott nicht als blutigen
> Anfänger, aber so wirklich viel haben mir die Logs auch noch nicht
> genützt unter OS X.

Der OP berichtet von einem System, das hinreichend potent ist (Core2Duo
mit 2,x GHz und 4 GByte RAM) aber lahmt. Heißt, wenn nicht
offensichtlich ist, daß das Ding andauernd im I/O festklemmt (bspw.
wegen defektem Filesystem oder weil irgendwas amokläuft und permanent an
der Platte herumzuzelt), dann stimmt da was nicht. Und bei sowas _kann_
ein forscher Blick ins Log helfen.

Bei 'nem Kunden hatte eine Kollegin mal 'nen arschlahmen Mac am Start.
Und die ganzen IT-Support-Leute, deren verdammter Job es eigentlich ist,
Dienstleister ihrer User zu sein und denen eine performance Arbeits-
umgebung bereitzustellen, damit die die Kohle verdienen können, damit
die Support-Leute mitdurchgefüttert werden können... haben außer dem
üblichen Voodoo-Vollschwachsinn à la Rechte-Reparieren nichts gemacht.

Ein Blick ins Log uns es war glasklar, was Sache ist. Da ist ein Prozeß
permanent gecrasht und autom. wieder gestartet worden. Die Platte war
fast voll von CrashReports. Und je CrashReport gibt's gratis einen
Eintrag in system.log. D.h. mehrere pro Sekunde. Inkl. Prozeßnamen. Da
brauch ich genau gar kein Hirn haben, um zu sehen, was Sache ist. _Wenn_
ich denn das Problem überhaupt nur eingrenzen (von analysieren rede ich
noch gar nicht) *will*.

> Ausser das ungute Gefühl zu erzeugen, dass da auch wenn alles in
> Ordnung ist allerlei Warnungen und Fehler im Log landen...

Sch*** drauf. Einfach ignorieren. Mir geht's nur um das Offensichtliche.
Das bedingt halt, daß man nicht gleich die Flinte ins Korn wirft,
sondern eben nachschaut. Und ggf. nachfragt. Bei Frau Google und/oder
hier. Die größte Herausforderung ist dabei dann wohl vermutlich, Copy&
Paste zu beherrschen.

Wer das nicht will, installiert halt neu. Und wer das als Dienstleister
macht, dem kann das sogar noch richtig wurscht sein...

Gruss,

Thomas

[Michael Noe]

Markus Elsken <m.el...@ewetel.net> wrote:

> Hier steht ein 17" MBP Late 08, welches voreilig von 10.7.5 auf 10.8.3
> hochgerüstet wurde. Natürlich mit allen Optionen wie verschlüsselte
> Platte etc. Natürlich lahmt die Kiste grausam,

Wie viel Arbeitsspeicher hat denn der Rechner?

Denn an der Hardware an sich sollte es nicht liegen. Mein MacBook Pro
15" Late 2008 samt Core 2 Duo 2,4 GHz läuft unter 10.8.3 gefühlt sogar
etwas flotter als unter 10.7.5. Jedoch samt SSD Samsung 830 und 8 GByte
RAM.

Und es ist übrigens auch nicht langsamer als unter 10.5.8 oder 10.6.8
"damals". (Der Hunger nach Arbeitsspeicher ist sicherlich etwas
gewachsen.)

> zusätzlich lassen sich keine Drucker mehr einrichten.

Das wiederum dürfte ein reines Softwareproblem sein.

> Sowohl wenn ich die Treiber selbst herunterlade als auch, wenn das System
> das selbst macht - es gibt Fehler bei der Installation. Auch nach
> Neuinstallation und Import der Daten bleibt der Fehler. Jemand eine Idee,
> wo ich suchen könnte? Komplett from Scratch aufsetzen ist nicht wirklich
> eine Option...

Was sagt denn das Dienstprogramm Konsole dazu?

--

Gruß
Mac OS X is like a wigwam:
Michael no Windows, no Gates, Apache inside.

[Paul-Wilhelm Hermsen]

Am 23.04.13 17:15, schrieb Patrick Kormann:

> Aber seien wir ehrlich, ich sehe mich weiss Gott nicht als blutigen
> Anfänger, aber so wirklich viel haben mir die Logs auch noch nicht
> genützt unter OS X. Ausser das ungute Gefühl zu erzeugen, dass da auch
> wenn alles in Ordnung ist allerlei Warnungen und Fehler im Log landen...

Ich hasse die Logfiles zwar auch und habe auch Verständnis für Deinen
Einwand, aber sie sind eigentlich immer aufschlussreich. Man könnte ja
mal mit der Aktivitätsanzeige oder mit "top" anfangen, bevor man sich um
die Logfiles kümmert.

Sonst kann man eigentlich keine Lösung erwarten, es sei denn, sie kommt
aus der Glaskugel. Da von hier aus keiner in die Prozesslisten oder auch
in Logfiles hinein schauen kann, muss der Fragende das schon selber tun.
Markus hat zwar nicht nach der Lösung des Problems gefragt, aber nach
einer Idee, und 'ne bessere als Thomas' dürfte eigentlich niemandem
einfallen.

Mit "top" hat man einen sehr guten Überblick über alle laufenden
Prozesse. Dort kann man dann nach einem großen S einen gewünschten
Befehl, z.B. kill, eingeben, und durch Angabe der pid anschließend die
auffälligen Prozesse aktuell zum Schweigen bringen. So muss man damit
eben ein wenig herum spielen und nachschauen, ob das System schneller
wird oder das Festplattengeprassel, falls bereits auffällig, abnimmt.
Das wäre mindestens mal ein Anfang.

In der /var/log/system.log kann man z.B. auch nach so Begriffen wie
"error" oder "failure" suchen. Dazu sind Dateimanager u.a. ja auch da.
Was soll man sonst dazu sagen?

[Patrick Kormann]

Am 23.04.13 18:29, schrieb Thomas Kaiser:

> Der OP berichtet von einem System, das hinreichend potent ist (Core2Duo
> mit 2,x GHz und 4 GByte RAM) aber lahmt. Heißt, wenn nicht
> offensichtlich ist, daß das Ding andauernd im I/O festklemmt (bspw.
> wegen defektem Filesystem oder weil irgendwas amokläuft und permanent an
> der Platte herumzuzelt), dann stimmt da was nicht. Und bei sowas _kann_
> ein forscher Blick ins Log helfen.

Ja, kann, hat es bei mir aber noch nie - so wirklich. Als mein iMac
immer wieder Gedenksekunden bis Minuten eingelegt hat, konnte ich dem
Log nichts Schlaues entnehmen (oder war eben zu doof) - nur eine
Neuinstallation half.

> Ein Blick ins Log uns es war glasklar, was Sache ist. Da ist ein Prozeß
> permanent gecrasht und autom. wieder gestartet worden. Die Platte war
> fast voll von CrashReports. Und je CrashReport gibt's gratis einen
> Eintrag in system.log. D.h. mehrere pro Sekunde. Inkl. Prozeßnamen. Da
> brauch ich genau gar kein Hirn haben, um zu sehen, was Sache ist. _Wenn_
> ich denn das Problem überhaupt nur eingrenzen (von analysieren rede ich
> noch gar nicht) *will*.

Beim iPhone konnte ich mit Mühe rausfinden, dass ein iCloud-Prozess Amok
läuft, aber geholfen hat mir das nichts. Auch auf den Macs macht mir
iCloud Probleme und die Rechte sind so kaputt, dass z.B. TextEdit
meckert, wenn ich ne neue Datei aufmache, es könne kein Backup anlegen.
Aber erst mal müsste man ja wissen wie es richtig aussehen müsste. Ich
kann schon alle Sonderberechtigungen wegbügeln, aber das würde ich auch
nicht so gerne tun.

> Sch*** drauf. Einfach ignorieren. Mir geht's nur um das Offensichtliche.
> Das bedingt halt, daß man nicht gleich die Flinte ins Korn wirft,
> sondern eben nachschaut. Und ggf. nachfragt. Bei Frau Google und/oder

Naja, das braucht dann eben Erfahrung, sonst denkt man all die Meldungen
sind das Problem...

[Thomas Kaiser]

Patrick Kormann schrieb am 23.04.2013 in <news:35ti4a-...@news.sirdir.ch>

> Am 23.04.13 18:29, schrieb Thomas Kaiser:
>
>> Der OP berichtet von einem System, das hinreichend potent ist
>> (Core2Duo mit 2,x GHz und 4 GByte RAM) aber lahmt. Heißt, wenn nicht
>> offensichtlich ist, daß das Ding andauernd im I/O festklemmt (bspw.
>> wegen defektem Filesystem oder weil irgendwas amokläuft und permanent
>> an der Platte herumzuzelt), dann stimmt da was nicht. Und bei sowas
>> _kann_ ein forscher Blick ins Log helfen.
>
> Ja, kann, hat es bei mir aber noch nie - so wirklich. Als mein iMac
> immer wieder Gedenksekunden bis Minuten eingelegt hat, konnte ich dem
> Log nichts Schlaues entnehmen (oder war eben zu doof) - nur eine
> Neuinstallation half.

Das wäre ja auch bei Markus die sinnigste Variante. Und natürlich muß
bei einem System, das "Hänger" hat, nichts Aufschlußreiches im Log
stehen. Kann sein, daß man da mit anderen (Bord-)Mitteln tiefer schauen
müsste. Aber es ist halt das eine, das kategorisch überhaupt abzulehnen
oder sich zumindest mal drauf einzulassen -- entfernte Hilfestellung
wird und wurde ihm ja immer wieder angeboten.

> [Verwirrendes in Log-Files]

>> Sch*** drauf. Einfach ignorieren. Mir geht's nur um das
>> Offensichtliche. Das bedingt halt, daß man nicht gleich die Flinte
>> ins Korn wirft, sondern eben nachschaut. Und ggf. nachfragt. Bei Frau
>> Google und/oder
>
> Naja, das braucht dann eben Erfahrung, sonst denkt man all die Meldungen
> sind das Problem...

Wahrscheinlich hast Du recht. Und das, also das Ausfiltern von
Informationen aus einem Wust, ist etwas, das doch gar nicht so einfach
ist, wie es mir immer erscheint. Hat aber wohl auch nur bedingt mit
Erfahrung zu tun, evtl. sogar mehr mit Instrumentarium oder Intuition.
Mir werden oft bei dubiosen Trouble-Shooting-Einsätzen Berge von Müll
vorgesetzt, die mir völlig fremd sind (bspw. irgendwelche Verbose-Logs
in Ballaballa-Format, die irgendwelche Datenbanken auskotzen). Aber
daraus dann das für die Analyse Wesentliche rauszuziehen, gelingt
eigentlich _immer_.

Ist vielleicht auch wie beim Googlen bzw. allgemein die richtigen Fragen
stellen bzw. aus den Antworten das Wesentliche rauszuziehen. Da versteh
ich regelmäßig auch nicht, wieso andere sich da immer so anstellen und
das Falsche fragen und die Antworten dann noch abermals falsch
interpretieren. Wobei das ja übers Googlen hinausgeht und alle Arten von
potentiellen Antwortgebern umfaßt (mal in absteigender Reihenfolge bzgl.
Empathiefähigkeit sortiert: Userinnen, User, IT-Staff, Suchmaschinen)

Gruss,

Thomas

[Markus Elsken]

Moin!

Am 24.04.13 09:55, schrieb Thomas Kaiser:

> Das wäre ja auch bei Markus die sinnigste Variante.

Unter Verlust aller Daten, denn der Fehler wird bei Übername mit
importiert. Ich habe extern ein 10.8 frisch aufgesetzt (ohne
Verschlüsselung), die Daten importiert, die Systemupdates ein gespielt
und versucht, einen Drucker zu installieren. Gleiche Fehlermeldung - es
ist ein Fehler aufgetreten.

Soll ich wirklich /var/log/install.log hier rein kippen? Sind ja nur 913k...

Der Besitzer überlegt gerade, ob er sich ein neues Book holen soll, aber
ich fürchte, der Fehler wird mitwandern...

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb in <news:51779b72$0$30116$8e6e...@newsreader.ewetel.de>

> Am 24.04.13 09:55, schrieb Thomas Kaiser:
>
>> Das wäre ja auch bei Markus die sinnigste Variante.
>
> Unter Verlust aller Daten, denn der Fehler wird bei Übername mit
> importiert. Ich habe extern ein 10.8 frisch aufgesetzt (ohne
> Verschlüsselung), die Daten importiert, die Systemupdates ein gespielt
> und versucht, einen Drucker zu installieren. Gleiche Fehlermeldung -
> es ist ein Fehler aufgetreten.

Was denn für Drucker? Mit Epsons bspw. sind in Zusammenhang mit 10.8
diverse solche Probleme bekannt (dito Lösungen). Oder tritt das bei egal
welchem Treiber-Installationsversuch für egal welchen Drucker auf?

> Soll ich wirklich /var/log/install.log hier rein kippen? Sind ja nur
> 913k...

Irgendwo online stellen? Zur Not mailen oder über einen der zahlreichen
"Du lädst hoch, wir verschicken 'nen Link" rüberschubsen?

Gruss,

Thomas

[Stefan]

Am 24.04.13 10:44, schrieb Markus Elsken:

> Soll ich wirklich /var/log/install.log hier rein kippen? Sind ja nur
> 913k...

Wenn schon, dann wäre es vielleicht sinnvoller, das File irgendwo im
Internet zu parkieren und hier nur den Link zu posten.

[Markus Elsken]

Moin!

Am 24.04.13 10:59, schrieb Thomas Kaiser:

> Was denn für Drucker? Mit Epsons bspw. sind in Zusammenhang mit 10.8
> diverse solche Probleme bekannt (dito Lösungen). Oder tritt das bei egal
> welchem Treiber-Installationsversuch für egal welchen Drucker auf?

Sowohl mein Epson C1100N als auch ein HP-Laser beim Besitzer des Books.
Der Epson wird von einem 2012er MBP unter 10.8.3 problemlos verarbeitet.

> Irgendwo online stellen? Zur Not mailen oder über einen der zahlreichen
> "Du lädst hoch, wir verschicken 'nen Link" rüberschubsen?

Sollte sich machen lassen. Ist Deine Mailadresse gültig?

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb in <news:5177a57c$0$30111$8e6e...@newsreader.ewetel.de>

> Am 24.04.13 10:59, schrieb Thomas Kaiser:
>
>> Was denn für Drucker? Mit Epsons bspw. sind in Zusammenhang mit 10.8
>> diverse solche Probleme bekannt (dito Lösungen). Oder tritt das bei
>> egal welchem Treiber-Installationsversuch für egal welchen Drucker
>> auf?
>
> Sowohl mein Epson C1100N als auch ein HP-Laser beim Besitzer des Books.
> Der Epson wird von einem 2012er MBP unter 10.8.3 problemlos verarbeitet.

Ok. Bitte noch 'ne kurze Beschreibung, _welches_ install.log das nun ist
und wann ungefähr welches _exakte_ Druckermodell versucht wurde, zu
installieren.

>> Irgendwo online stellen? Zur Not mailen oder über einen der
>> zahlreichen "Du lädst hoch, wir verschicken 'nen Link" rüberschubsen?
>
> Sollte sich machen lassen. Ist Deine Mailadresse gültig?

Logo. Schreib aber noch irgendwas dazu, denn Mails an mich über diese
Domain laufen durch insgesamt 3 Spamfilter auf verschiedenen Systemen
mit einigermaßen agressiven Einstellungen. Oder nutz gleich sowas, um
den Kram online zu stellen und 'ne URL zu posten:

http://www.alternative-zu.de/q/RapidShare

Gruss,

Thomas

[Patrick Kormann]

Am 24.04.13 09:55, schrieb Thomas Kaiser:

> Wahrscheinlich hast Du recht. Und das, also das Ausfiltern von
> Informationen aus einem Wust, ist etwas, das doch gar nicht so einfach
> ist, wie es mir immer erscheint. Hat aber wohl auch nur bedingt mit
> Erfahrung zu tun, evtl. sogar mehr mit Instrumentarium oder Intuition.
> Mir werden oft bei dubiosen Trouble-Shooting-Einsätzen Berge von Müll
> vorgesetzt, die mir völlig fremd sind (bspw. irgendwelche Verbose-Logs
> in Ballaballa-Format, die irgendwelche Datenbanken auskotzen). Aber
> daraus dann das für die Analyse Wesentliche rauszuziehen, gelingt
> eigentlich _immer_.

Mir eigentlich auch, nur bei OS X hab ich da echt Mühe. Wie gesagt,
eigentlich brauch ich nur in's Log zu schauen und ich würde am Liebsten
System wechseln. Da kommen innerhalb von 5 Minuten mehr Warnungen und
Fehler als auf meinen Linux Systemen in 2 Jahren.
Ich könnte Apple z.B. ganz gut dafür treten wenn sie dauernd
irgendwelche APIs als deprecated in 10.7(!) angeben und sie in 10.8
selbst noch wacker nutzen.
Oder was mir schon nur die Messages-App für Fehler in's Log spült...
inkl. halber Traces...
Und sogar 'Just leaking' Messages an allen Ecken und Enden...

[Paul-Wilhelm Hermsen]

Am 24.04.2013 10:44, schrieb Markus Elsken:
> Unter Verlust aller Daten, denn der Fehler wird bei Übername mit importiert.

Gut - also Aktivitätsanzeige, Prozesslisten und Logfiles sind offenbar
weitestgehend abgehandelt.

Was spricht dagegen, sich spätestens jetzt für ein vernünftiges
Sicherungskonzept zu entscheiden!
NICHTS! Schon gar nicht die wenige Kohle, die das kostet.
Wer das nicht hat, sollte mit Datenverlust eigentlich recht gut leben
können.

Neben der gewohnten Time-Machine Sicherung erstelle ich mir z.B. mittels
SuperDuper einen bootfähigen Klon auf einer externen Platte mit dem ich
jederzeit mein beschissenes Originalsystem hochfahren und auf welchem
ich weiterarbeiten kann, während ich mir den betroffenen Rechner zum
Zwecke von Diagnose und Therapie komplett neu aufsetze.

Brauche ich mein altes System, boote ich von der externen Platte,
brauche ich es nicht, boote ich vom neu eingerichteten Rechner und widme
mich dann dort, vor allen anderen Aufgaben, in diesem Fall der
Druckerinstallation, and so on.

Das spart vermutlich eine Menge Zeit und ist zielführender. Nach einer
Neuinstallation wüsste ich wenigstens, ob mein System oder die
Peripherie den Geschwindigkeitsverlust bewirkt.
Das wäre doch schon mal ein Erfolg, oder?

Ich meine mittlerweile festgestellt zu haben, dass hier so Einige über
hervorragende Kenntnisse verfügen. Geht's aber dann mal um die Frage der
richtigen Strategie, verpufft das Ganze.
Und das auch noch bei einem Sicherungskonzept unter OS X, wie es selbst
unter Linux nicht so leicht möglich ist.
Ist mir zu hoch!

[Patrick Kormann]

Am 24.04.13 13:10, schrieb Paul-Wilhelm Hermsen:

> Neben der gewohnten Time-Machine Sicherung erstelle ich mir z.B. mittels
> SuperDuper einen bootfähigen Klon auf einer externen Platte mit dem ich
> jederzeit mein beschissenes Originalsystem hochfahren und auf welchem
> ich weiterarbeiten kann, während ich mir den betroffenen Rechner zum
> Zwecke von Diagnose und Therapie komplett neu aufsetze.

Ich denke das ist durchaus bekannt, nur wüsste ich nicht, wozu man dafür
SuperDuper brauchen würde.

[Markus Elsken]

Moin!

Am 24.04.13 13:10, schrieb Paul-Wilhelm Hermsen:

> Was spricht dagegen, sich spätestens jetzt für ein vernünftiges
> Sicherungskonzept zu entscheiden!

TM-Platte ist ja vorhanden, beinhaltet diesen Fehler aber auch. Ich habe
die Kiste bereits neu aufgesetzt und die Daten importiert. Danach hat
das neue System auch keine Möglichkeit mehr, einen Drucker zur Liste
hinzuzufügen. Selbstredend ist das Drucksystem schon zurückgesetzt,
sogar mehrfach.

Der Besitzer des mackeligen MBP ist übrigens nur ein ganz einfacher User.

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb in <news:5177a57c$0$30111$8e6e...@newsreader.ewetel.de>

> Am 24.04.13 10:59, schrieb Thomas Kaiser:
>
>> Was denn für Drucker? Mit Epsons bspw. sind in Zusammenhang mit 10.8
>> diverse solche Probleme bekannt (dito Lösungen). Oder tritt das bei egal
>> welchem Treiber-Installationsversuch für egal welchen Drucker auf?
>
> Sowohl mein Epson C1100N als auch ein HP-Laser beim Besitzer des Books.
> Der Epson wird von einem 2012er MBP unter 10.8.3 problemlos verarbeitet.

Danke für das Logfile (wirklich Danke, denn dadurch ist mir nebenbei
aufgefallen, daß meine Mails an @phg-online.de offenbar seit Monaten
nicht weitergeleitet werden. Hab dort knappe 10.000 Mails rumeiern,
davon natürlich fast alles Spam).

Nach kurzem Blick ins Log behaupte ich jetzt mal frech, daß es
einigermaßen egal ist, was Du installieren willst (also Druckertreiber)
oder nicht, solange die Installationsroute am Ende ein

kextcache -update-volume / -Installer

aufruft. Das macht sie immer dann, wenn ein Treiber Kernel Extensions
mitgebracht hat (was eben typischerweise viele Druckertreiber tun, um
mit der Hardware sprechen zu können). Ist übrigens auch heute um
09:57:44 schon geschehen, als Du per SoftwareUpdate paar Pakete
(AirPortUtility.pkg, RAWCameraUpdate4.pkg, OSXUpd10.8.3Patch.pkg und
RemoteDesktop.pkg) eingespielt hast.

Besagter Neuaufbau des kext-Caches fällt dann auf die Schnauze, weil die
Kernel Extension mit der Bundle-ID

com.sierrawireless.driver.SierraDIPSupport

Probleme macht. Hat also exakt gar nichts mit dem Treiber, den Du grad
installieren willst zu tun sondern nur mit dem Fakt, daß der Treiber
eine spezifische Form von Erweiterung mitgebracht hat, der Installer den
dazugehörigen Cache neu aufbauen lassen will und das dann nicht klappt.
SoftwareUpdate ist an der Stelle tolerant, der normale Installer gewohnt
brunzdumm.

Problemlösung: Weg mit der kext. Was die macht, weiß ich nicht (aber
Google -- einfach nach obigem Buchstabenbandwort suchen). Wie man sie
entfernt weiß ich nicht (aber Google: einfach nach »os x remove kernel
extension« suchen)

Sensationell auch wie die eigentlich halbwegs zielführende Klartext-
meldung, die das installerd-Framework nach oben hustet, dann für den
User übersetzt wird:

Apr 24 10:27:44 olaf-von-bessers-macbook-pro.local installd[264]: PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=121 "An error occurred while updating system extension information." UserInfo=0x7f7f934c3e80 {NSUnderlyingError=0x7f7f934c30e0 "The operation couldn’t be completed. (kextcache error 71.)", NSLocalizedDescription=An error occurred while updating system extension information., arguments=(
"-update-volume",
"/",
"-Installer"
)} {
NSLocalizedDescription = "An error occurred while updating system extension information.";
NSUnderlyingError = "Error Domain=kextcache Code=71 \"The operation couldn\U2019t be completed. (kextcache error 71.)\"";
arguments = (
"-update-volume",
"/",
"-Installer"
);
}

Aus

Error Domain=kextcache Code=71 "The operation couldn't be completed. (kextcache error 71.)"

wird ein vielsagendes:

"An error occurred while updating system extension information."

So, jetzt doofe Frage: Wenn Du es jetzt sofort nochmal probierst, was
bekommst du dann für lokalisierte Fehlermeldung angezeigt. Stehen da
genau diese Worte drin (die "eigentlich" auch noch ein bissi in die
richtige Richtung weisen) oder isses wirklich nur ein "Fehler!" gewesen?

Gruss,

Thomas, hat für Analyse knappe 3 und für Aufbereitung knappe 10 Min.
gebraucht. Abgerechnet wird nach angefangenen Stunden, 150,- Tacken
netto bitte! ;-)

[Joe Kotroczo]

On 24/04/2013 17:07, Thomas Kaiser wrote:


(...)

> Besagter Neuaufbau des kext-Caches fällt dann auf die Schnauze, weil die
> Kernel Extension mit der Bundle-ID
>
> com.sierrawireless.driver.SierraDIPSupport
>

(...)

>
> Problemlösung: Weg mit der kext. Was die macht, weiß ich nicht (aber
> Google -- einfach nach obigem Buchstabenbandwort suchen).

Ich würde spontan auf den Treiber für eine UMTS/HDSPA-PCMCIA-Karte tippen...

[Stefan]

Am 24.04.13 17:07, schrieb Thomas Kaiser:
> com.sierrawireless.driver.SierraDIPSupport

>
> Google -- einfach nach obigem Buchstabenbandwort suchen).

Gibt bei mir als zweitem Treffer:
https://discussions.apple.com/thread/4188064?start=0&tstart=0

[Markus Elsken]

Moin!

Am 24.04.13 17:07, schrieb Thomas Kaiser:

> Problemlösung: Weg mit der kext.

Ich habe den Ordner Extensions gerade offen - da ist aber keine KEXT mit
dem Namen. Ein NSMSierraWireless.kext kommt dem noch am nächsten, dazu
diverse SierraXXXSupport.kext. Mit denen experimentiere ich mal herum...

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb am 24.04.2013 in <news:5178612e$0$30115$8e6e...@newsreader.ewetel.de>

OK, zur "zielführenden" Vorgehensweise:

Das Tool kextcache fliegt auf die Schnauze. Der Bundle-Identifier ist
bekannt. Ich hab jetzt kurz per "man kextcache" die Doku quergelesen.
Stand nix Zielführendes drin. Also sofort ans Ende des Manuals, wo
Querverweise zu verwandten Tools stehen. Dort Verweis auf kextutil:

DIAGNOSTICS
kextcache exits with a zero status upon success. Upon failure, it prints an error message and exits with a nonzero status.

BUGS
Many single-letter options are inconsistent in meaning with (or directly contradictory to) the same letter options in other kext tools.

SEE ALSO
mkextunpack(8), kext_logging(8), kextd(8), kextload(8), kextutil(8), kextstat(8), kextunload(8)

"kextutil" (Werkzeug) klang am Ansprechendsen. Also dessen Manual Page
aufgerufen und quergelesen...

Probier mal

kextutil -v 1 -b com.sierrawireless.driver.SierraDIPSupport

aus. Es ist ein Cache. Bei jedem Cache ist Grundprinzip, daß irgendwer
bzw. -etwas weiß, was drinnensteckt. Wenn's wer weiß, kann man den/das
auch fragen. Also gibt es ein Tool bzw. Utility dazu. Das muß man nur
finden. Und wenn man die kranke Unix-Denke adaptiert hat, dann ist das
unter OS X sogar ein Leichtes (weil man weiß, daß Manual Pages Quer-
verweise haben ;-).

Mea culpa. Hab das Thema jetzt 2 Tage lang dezentriert zu betrachten
versucht... und sehe ein, dass es wirklich nicht so einfach ist,
zielgerichtetes Trouble-Shooting zu betreiben.

Gruss,

Thomas

[Bernd Fröhlich]

Vielleicht weil es ein wesentlich besseres UI hat als das
Festplatten-Dienstprogramm?

[Thomas Kaiser]

Bernd Fröhlich schrieb in <news:1l1vmih.1anxwnf1rotmquN%be...@eaglesoft.de>

Vielleicht weil SuperDuper in der Bezahlversion inkrementell klonen
kann (was all die User der Gratis-Version nicht mal wissen)?

Und was das rsync 3.0.6, das im Carbon Copy Cloner steckt, genauso kann?
Ganz ohne GUI zumal noch dazu... ;-)

Gruss,

Thomas

[Markus Elsken]

Moin!

Am 25.04.13 08:25, schrieb Thomas Kaiser:
> OK, zur "zielführenden" Vorgehensweise:

Die sah so aus, Launch2Net premium zu deinstallieren. Nach Neustart lief
die Installation dann problemlos durch.

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb in <news:5178f0f9$0$30114$8e6e...@newsreader.ewetel.de>

Klingt hübsch ignorant :-)

Ich hoffe für Deinen Kunden, daß er Launch2Net nicht wirklich "braucht"
und daß Du ihm das nicht allen Ernstes als "einzige Lösung" verkauft hast
(angesichts dessen, daß es nur eine einzige zu 10.8 inkompatible kext
für irgendeinen komischen UMTS-Nöpsel war, die das Problem verursacht
hat, das _nichts_ mit Druckertreibern zu tun hatte sondern weitaus
generischer angelegt war)

Gruss,

Thomas

[Markus Elsken]

Moin!

Am 25.04.13 23:44, schrieb Thomas Kaiser:

> Klingt hübsch ignorant:-)
>
> Ich hoffe für Deinen Kunden, daß er Launch2Net nicht wirklich "braucht"
> und daß Du ihm das nicht allen Ernstes als "einzige Lösung" verkauft hast
> (angesichts dessen, daß es nur eine einzige zu 10.8 inkompatible kext
> für irgendeinen komischen UMTS-Nöpsel war, die das Problem verursacht

> hat, das_nichts_ mit Druckertreibern zu tun hatte sondern weitaus
> generischer angelegt war)

Ich habe die kext (und zwar nacheinander alle, die Sierra hiessen)
rausgeworfen, das Problem blieb aber bestehen - keine Installation eines
Druckers möglich. Erst nach Deinstallation vonL2N war Ruhe, und eine
testweise Neuinstallation des Programms ergab genau die gleichen
Probleme wie vorher. Also hat er die Wahl...
Ich habe dem guten Menschen empfohlen, sich beim Hersteller um ein
10.8.3-kompatibles Update von launch2Net zu bemühen.

mfg Markus

[Thomas Kaiser]

Markus Elsken schrieb in <news:517a4b84$0$30118$8e6e...@newsreader.ewetel.de>

> Am 25.04.13 23:44, schrieb Thomas Kaiser:
>> Klingt hübsch ignorant:-)
>>
>> Ich hoffe für Deinen Kunden, daß er Launch2Net nicht wirklich
>> "braucht" und daß Du ihm das nicht allen Ernstes als "einzige Lösung"
>> verkauft hast (angesichts dessen, daß es nur eine einzige zu 10.8
>> inkompatible kext für irgendeinen komischen UMTS-Nöpsel war, die das
>> Problem verursacht hat, das_nichts_ mit Druckertreibern zu tun hatte
>> sondern weitaus generischer angelegt war)
>
> Ich habe die kext (und zwar nacheinander alle, die Sierra hiessen)

Falsch Nr. 1. Du hast in einem Verzeichnis nach Dateinamen geschaut, in
denen "Sierra" vorkommt, weil Du angenommen hast, der Dateiname wird
schon irgendwie mit dem Bundle-Identifier zusammenhängen. Der Bundle-
Identifier, wie ihn das install.log ausspuckte, war

com.sierrawireless.driver.SierraDIPSupport

Der steht so in der Info.plist der Kernel Extension. Und muß nichts
aber auch gar nichts mit dem Namen im Dateisystem dieser kext zu tun
haben.

Mittels

kextutil -v 1 -b com.sierrawireless.driver.SierraDIPSupport

hättest Du _zielführend_ vorgehen können, um die eine "böse" kext zu
erwischen.

> rausgeworfen, das Problem blieb aber bestehen - keine Installation eines
> Druckers möglich.

Falsch Nr. 2: Du kannst ja ruhig Dateien auf der Platte löschen. Aber
eine _Kernel Extension_ klebt, wie der Name schon sagt, recht innig am
Kernel. Die wirst Du nur durch ein "kextunload" los. Im konkreten
Beispiel wäre der richtige Weg gewesen:

sudo kextunload -b com.sierrawireless.driver.SierraDIPSupport

(da schau her, schon wieder der Bundle Identifier und kein absoluter
Pfad oder Dateiname). Wenn Du noch ein "-v2" hinzugefügt hättest, dann
hätte Dir kextunload auch noch mitgeteilt, welche Dateien zu dieser kext
gehören.

Wenn Du Extensions nur aus /System/Library/Extensions/ rausbewegst, dann
bleibt die zugehörige kext selbstverständlich weiterhin geladen. Erst
ein Neustart (oder das für Laien wenig empfehlenswerte Hantieren mit den
"kext*"-Kommandos) bewegt hier irgendwas, wenn man's schon umständlich
bzw. falsch (siehe oben bzw. kextunload) machen _will_.

> Erst nach Deinstallation vonL2N war Ruhe

Falsch Nr. 3: Wie Du im weiteren Absatz ja schreibst, bist Du gaga
genug, mit einer veralteten Version von launch2net herumzuspielen (das
Problem ist bei denen seit August 2012 bekannt und in Version 2.6.3
gefixt worden). D.h. diese buggy-Version, mit der Du da rumspielst, hat
evtl. einfach nur die nötigen Kommandos unter der Haube getriggert,
damit Dein Löschen im Filesystem, dann auch irgendwelche Auswirkungen
hatte.

> und eine testweise Neuinstallation des Programms

Faszinierend. Du bist beim Einkreisen eines Problems und findest ganz
offensichtlich einen _Bug_ in einer Software! Und kommst nicht auf die
Idee, eine aktuelle Version dieser Software einzusetzen? Aktuellere
Versionen enthalten in der Regel immer auch zahlreiche _Bug_-Fixes. Und
Novamedia hat den Kram in Version 2.6.3 gefixt. Dort beinhaltet sowohl
die Installations- als auch die Deinstallationsroutine jetzt ganz
explizit das Deaktivieren der fraglichen Sierra-kexts. Und ich schreibe
bewusst _deaktivieren_, denn das bedeutet: 1) kextunload, 2) Löschen der
fraglichen Dateien, 3) Neuaufbau kext-Cache und 4) kextd mitteilen, daß
sich was geändert hat -- siehe [1].

Du hast von den 4 nötigen Schritten sinnloserweise nur Nr. 2
durchgeführt und falsche Schlüsse gezogen.

> ergab genau die gleichen Probleme wie vorher. Also hat er die Wahl...

Sich einen kompetenten Mac-Dienstleister zu suchen?

> Ich habe dem guten Menschen empfohlen, sich beim Hersteller um ein
> 10.8.3-kompatibles Update von launch2Net zu bemühen.

Anstatt das Problem aus der Welt zu schaffen, in dem Du die aktuellere
Version mit dem Bugfix einsetzt, die diesbzgl. *nichts anderes macht*
als eben diese fraglichen Sierra-kexts zu _deaktivieren_, da obsolet.

BTW: Falsch Nr. 5: Das Problem hat nix mit 10.8.3 zu tun sondern mit
10.8 generell. Das Problem wurde im August 2012 bekannt und seitens
Hersteller gefixt, also zu einem Zeitpunkt noch nicht mal 10.8.1 draußen
war.

http://www.macupdate.com/app/mac/15570/launch2net-premium

Gruss,

Thomas

[1] Aus der Deinstallations-Routine, die den Vorgang für MacOS X 10.4 -
10.8 richtig macht:

function remove_kext ()
{
full_path="$1"
echo "Remove driver file: $full_path"

kextunload "$full_path"
rm -r "$full_path"
}

remove_kext "/System/Library/Extensions/SierraDevSupport.kext"
remove_kext "/System/Library/Extensions/SierraDIPSupport.kext"
remove_kext "/System/Library/Extensions/SierraFSRSupport.kext"
remove_kext "/System/Library/Extensions/SierraHSRSupport.kext"
remove_kext "/System/Library/Extensions/SierraIPDirect.kext"

######################
# Cleanup kext cache
######################

echo "Reset kext cache"

OSVersion=`sw_vers|grep "ProductVersion"|grep -o "10.6"`

# Handle 10.6
if [ "x$OSVersion" = "x10.6" ]; then
echo "Update kextcache for $OSVersion"
fi

# Handle 10.4/10.5
if [ "x$OSVersion" != "x10.6" ]; then
echo "Update kextcache for 10.4/10.5"
rm -rf "/System/Library/Extensions.kextcache"
kextcache -k "/System/Library/Extensions"
else
kextcache -system-caches
fi

killall -HUP kextd

[Markus Elsken]

Moin!

Am 26.04.13 12:38, schrieb Thomas Kaiser:

> kextutil -v 1 -b com.sierrawireless.driver.SierraDIPSupport

Mit genau dieser Art von Kommandozeile stehe ich ziemlich auf
Kriegsfuss, das ist Unix-Hardcore pur. Gibt es irgendwo ein Buch, wo ich
mich in diese Materie mal einlesen kann? Eine V2 ist für mich eine
übrigens eine Rakete :-)

mfg Markus

[Stefan]

Am 26.04.13 12:38, schrieb Thomas Kaiser:

> (das Problem ist bei denen seit August 2012 bekannt und in
> Version 2.6.3 gefixt worden).

Was er übrigens gewusst hätte, wenn er einfach nur dem Link gefolgt
wäre, den ich weiter oben angegeben habe. (Mal abgesehen von der
Homepage des Herstellers.)

[Thomas Kaiser]

Markus Elsken schrieb in <news:517a66d8$0$30113$8e6e...@newsreader.ewetel.de>

> Am 26.04.13 12:38, schrieb Thomas Kaiser:
>> kextutil -v 1 -b com.sierrawireless.driver.SierraDIPSupport
>
> Mit genau dieser Art von Kommandozeile

Hihi, mit "dieser Art" nur? Nicht mit _jener_? ;-) Im Ernst: Das ist
doch fast immer kryptisch bis hirntot, wie man CLI-Tools aufrufen muß?
Und das, was dann da oft ausgegeben wird, spottet jeder menschlichen
Logik. Wir haben ein CLI-Produkt für 2.000,- Tacken im Portfolio, das
eigentlich nur ein Wrapper um 2 CLI-Tools eines anderen Herstellers ist.
Wohlgemerkt ist das am Ende wiederum ein CLI-Tool, das aber einerseits
simpel und konsistent bedienbar ist und andererseits das tut, was
erwartet wird und nicht andauernd mit Fehlermeldungen abbricht [1]. Da
steckt zwar schon eine riesige Menge an Logik unter der Haube (eben das
"es richtig machen", d.h. automatisch anhand Randbedingungen richtige
Entscheidungen treffen). Aber der eigentliche Clou ist, daß es zwei
ultrakryptische CLI-Tools bedienbar macht (per CLI -- aber das ist auch
sinnvoll so, weil das in diverse Automatisierungslösungen integriert
wird).

Heißt: Das Problem hast Du immer und bei jedem CLI-Tool individuell. Es
gibt welche, die sind gut zu bedienen (im Sinne von: klarer Hilfstext,
logische Schalter, hilfreiche Warnungen/Fehlermeldungen) und es gibt die
aus der Hölle. Und an was Du gerätst, weißt Du vorher nie. Goldene
Regeln: Gucken, ob das Ding eine Manual Page mitbringt:

man kextutil

Dann erstmal nur als unprivilegierter User ausprobieren (keinesfalls als
root oder aus "sudo-Kontext" heraus). Und sich per Websuche einen
Eindruck verschaffen, was das Ding kann und wofür es eingesetzt wird.
Zumal es -- wie im konkreten Fall -- auch Tools gibt, die gleich vor
sich selbst warnen. Aus der Manual Page:

BUGS:
Many single-letter options are inconsistent in meaning with (or directly
contradictory to) the same letter options in other kext tools.

Im konkreten Fall hätteste mir halt vertrauen sollen/müssen :-)

> stehe ich ziemlich auf Kriegsfuss, das ist Unix-Hardcore pur.

Nee, das ist nur ein CLI-Tool, mit dem Du nicht vertraut bist. Das kann
Dich in Umgebungen abseits Unix auch treffen.

> Gibt es irgendwo ein Buch, wo ich mich in diese Materie mal einlesen
> kann?

Puh, keine Ahnung. Da bin ich mit meiner CLI-Vorschädigung (ich hab mit
Batch-Programmierung unter DOS 3.x vor ca. 100 Jahren angefangen) der
falsche Ansprechpartner. Aber ich denke, daß das weniger ein Thema ist,
bei dem man mit Wissen denn eher mit Methodik weiterkommt.

> Eine V2 ist für mich eine übrigens eine Rakete :-)

Das -v ist neben -h einer der ganz seltenen Fälle, in denen ein Schalter
in so ziemlich allen CLI-Tools Identisches bewirkt: -v --> verbose
Ausgabe, schaltet das Tool also geschwätziger hinsichtlich dessen, was
es grad macht. Und "-h" sollte Hilfstexte ausspucken. Und genauso wie
ich im GUI am Mac auf allem Neuen sofort einmal mit gedrückter [alt]-
Taste herumklicke, so kombiniere ich auch sofort -h und -v (ggf.
mehrfach). Immer wieder erstaunlich, wieviele Tools dann massiv Hilfe
spenden.

Aber natürlich bestätigen die Ausnahmen die Regel und "-h" kann auch was
völlig anderes tun als Hilfstexte ausspucken. Und natürlich kann das
gefährlich sein, weshalb man das immer erstmal mit 'nem unprivilegierten
"normalen" Account ausprobiert und 'ne Websuche voranstellt, um eine
Idee dafür zu bekommen, was das Ding macht.

Und zum Thema Gefährlichkeit und "mit GUI wäre das nicht passiert"...
Diese Anleitung hier im Thread, wie man sich einfach so im Finder das
System zerschießen kann (Info-Dialog der Systemplatte aufrufen und
Zugriffsrechte für "jeden" rekursiv der Platte entziehen -- danach
stirbt das System lustig weg und die Kiste bootet nicht mehr bis zum
nächsten "Rechte Reparieren"), basiert auf 'ner wahren Begebenheit.

Ein sehr guter Spezl von mir hat diesen Stunt vor paar Monaten im Urlaub
hingelegt. Hatte sein MacBook Pro dabei, um nebenher zu arbeiten. Dann
saß er eines Abends an der Poolbar, hatte sich schon anständig Cocktails
reingestellt und surfte zusammen mit seiner ebenfalls nicht zu knapp
angeschickerten Holden via Hotel-WLAN im großen weiten Internet.

Dann haben sie wohl irgendwelche Schweinkram-Bilder, die sie gerne mal
voneinander machen, gesichtet und sortiert und sind dabei über den
Finder-Info-Dialog gestolpert. Und dieses Detail mit den Zugriffsrechten:
"Jeder darf zugreifen". JEDER! Auf unsere intimen Bilder. HIER! Promille-
bedingt verschwamm dann die feine Grenze zwischen lokaler Platte, Hotel-
WLAN und dem großen weiten Internet und der Entschluß, diesem skandaläsen
Zustand ein Ende zu bereiten, und "jeden" einfach mal auszuschließen
wurde gefaßt. Und das gleich richtig, also rekursiv. So nahm das Unglück
seinen Lauf, und ich hatte dann in der früh richtig viel zu lachen beim
Durchsehen der ganzen Hilfeschreie per SMS, die von Stunde zu Stunde
ernüchterter ausfielen :-)

Wobei er noch Glück hatte, daß ich ihm erst antworten konnte, als er
schon wieder halbwegs nüchtern war. Mit "Nein, Du kannst jetzt die
nächsten Wochen gar nix machen" und "Ja, mit dieser Recovery Partition,
die Du nicht haben wolltest, wäre das kein Problem" wäre er mit seinen
2,x Promille sicher nicht gut klargekommen und hätte das MacBook Pro
"Feierabend!!" brüllend im Pool versenkt.

Gruss,

Thomas

[1] macbookpro-tk:~ tk$ k-convert
Exactly one inputfile and one outputfile must be specified and at least
one conversion argument.

Usage: k-convert [--format=TIFF|JPEG|BMP|JP2|PNGf|PDF|GIF|EPS]
[--colorspace=None|Grayscale|Indexed|RGB|CMYK|CIELab]
[--renderingintent=0-6] [--compression=0-100] [--xPix=n] [--yPix=n]
[--resolution=n] [--help] inputfile outputfile

k-convert uses Helios' ImageServer and eventually PrintPreview
capabilitites. Currently version UB+ or above is supported.

Both inputfile and outputfile have to be files. Redirection from
pipes or stdin/stdout is not supported. On Windows file/folder paths
can be supplied in Helios' format (/C:/foo/bar) as well as Windows'
style (C:\foo\bar). Please always keep in mind that target file format
and filename suffix should match each other to prevent applications
from being unable to open the files correctly (e.g. Adobe Photoshop).

Options may be:

--format=TIFF|JPEG|BMP|JP2|PNGf|PDF|GIF|EPS

Based on the chosen target image format only some generally supported
color spaces and compression schemes might be available:

BMP (Windows Bitmap File Format) (suffix=bmp)
Colorspaces supported: RGB
Compression schemes supported: None

GIF (Compuserve Graphics Interchange Format) (suffix=gif)
Colorspaces supported: Indexed
Compression schemes supported: LZW

JP2 (JPEG 2000 Fileformat) (suffix=jp2)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: Wavelet (lossy and lossless)

JPEG (JPEG or JFIF format) (suffix=jpg)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: DCT (lossy)

PNGf (Portable Network Graphics Fileformat) (suffix=png)
Colorspaces supported: Grayscale, RGB
Compression schemes supported: Deflate

PDF (Portable Document Format) (suffix=pdf)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: None, DCT/JPEG, Flate/ZIP

TIFF (Tagged Image File Format) (suffix=tif)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: None, LZW, ZIP

EPS (Encapsulated PostScript File) (suffix=eps,epsf)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: None, JPEG

Notes: - If you choose solely a new target format with limited
support for colorspaces and the source image's color space
is not supported by the target image format the conversion
will be aborted with an explanative message on stderr
(this might happen eg. with a CMYK TIFF and PNGf as target
format)

--colorspace=None|Grayscale|Indexed|RGB|CMYK|CIELab

If omitted or set to "None" then no colorspace conversion will take
place. For conversions between CMYK and CIELAB/RGB default profiles
will be used in case the source image has no attached/embedded profile.
Otherwise the profile in question will be used.

Notes: - If you supply illegal color spaces (eg. Bilevel for BMPf)
then no color space conversion will be applied.

- When source color space is CMYK and an illegal target color
space or none is supplied then a fallback to RGB as target
colorspace takes place.

- If target format is either JPEG or JPEG2000, source color
space is Bilevel and no target color space is given an
automagic fallback to Grayscale as target color space happens

- "Indexed" is only supported for the GIF format but there's
no need to specify it since it is the only color space
supported.

--renderingintent=0-6

The different numbers have the following meaning:

0 for perceptual,
1 for relative colorimetric,
2 for saturation,
3 for absolute colorimetric,
4 for perceptual with black point compensation,
5 for relative colorimetric with black point compensation or
6 for saturation with black point compensation.

If omitted reasonable defaults will be used for colorspace conversions.
For details see the table below. Please note that YCbCr is the internal
color space of "RGB JPEG" so it could read similar "RGB".

From: \To: Spot RGB Gray CMYK YCbCr CIELab
Spot 1 1 1 0 1 1
RGB 1 1 1 0 1 1
Gray 1 1 1 0 1 1
CMY 1 1 1 1 1 1
CMYK 1 1 1 1 1 1
YCbCr 1 1 1 0 1 1
CIELab 1 1 1 0 1 1
To: Spot RGB Gray CMYK YCbCr CIELab

--compression=0-100

This parameter depends on the chosen image format. "0" means no
compression at all and may not be applicable for all image formats
(eg. JPEG and JPEG 2000). "100" means maximum quality and the actual
impact depends on the image format in question:

BMP: 0-100 --> uncompressed

GIF: Ignored. Always LZW compressed

JP2: 0 --> not applicable. Default compression (90) will be used
1-99 --> lossy compression level
100 --> losless compression

JPEG: 0 --> not applicable. Default compression (90) will be used
1-100 --> JPEG quality level

PNGf: Ignored. Always "Deflate" compressed

PDF: 0 --> uncompressed
1-99 --> lossy JPEG compression level
100 --> losless ZIP/Flate compression

TIFF: 0 --> no compression
1-99 --> LZW ("Compress") compression will be applied
100 --> Grayscale/RGB/CMYK/CIELab: ZIP ("Flate") compression
Bilevel: CCITTG4 will be used

EPS: 0 --> no compression (binary encoding)
1-100 --> JPEG quality level

If --compression will not be supplied on the command line or as an
illegal value (eg. 0 for both JPEG/JP2) a default of 90 will be used.
Depending on the image format in question different behaviour may
occur -- for details see above.

Examples:

- k-convert --format=TIFF --> LZW compressed TIFF
- k-convert --format=TIFF --compression=0 --> Uncompressed TIFF
- k-convert --format=PDF --> JPEG compressed PDF
- k-convert --format=PDF --compression=100 --> ZIP compressed PDF
- k-convert --format=JPEG --compression=0 --> illegal value,
default will be used:
DCT/JPEG high quality

--xPix=n

The image will be downscaled to this specific width in pixels while
maintaing the image's aspect ratio. If a larger value than the actual
image's width will be supplied no upscaling will take place due to
quality reasons. See below for examples and mutual reactions with the
following both parameters!

--yPix=n

Same as "--xPix" regarding the image's height. If both "--xPix" and
"--yPix" will be supplied the parameter matching the source image's
dimensions closer will be used.

Examples: Given a source image with 4000x2000 pix.:

- k-convert --xPix=1500 --> result with 1500x750 pix.
- k-convert --yPix=1500 --> result with 3000x1500 pix.
- k-convert --xPix=1500 --yPix=1500 --> result with 1500x750 pix.

--resolution=n

If --resolution will be supplied and neither --xPix nor --yPix will
be used the source image's resolution will be downscaled to the
resolution supplied with this parameter. Values are interpreted as
pixels per inch (ppi) and currectly no upscaling is supported due to
quality reasons. This means if you supply a value larger than the
source image's resolution no scaling will happen.

The behaviour of this switch changes completely if either --xPix or
--yPix will be supplied on the command line too. In that case a
scaling will be applied based on the pixel dimensions and afterwards
the resolution metadata of the target image will solely be adjusted
to the resolution value without applying any further scaling to the
image. This applies only to TIFF, JPEG or PNG target formats since
other image formats do not support this specific resolution metadata.

Examples: Given a source image with 4000x2000 pix. and 300 ppi:

- k-convert --resolution=150 --> result with 2000x1000
pix., 150 ppi
- k-convert --resolution=72 --yPix=1500 --> result with 3000x1500
pix., 72 ppi
- k-convert --resolution=300 --yPix=1500 --> result with 3000x1500
pix., 300 ppi

--help

Displays this help text

[Markus Elsken]

Moin!

Am 26.04.13 15:55, schrieb Thomas Kaiser:

> Puh, keine Ahnung. Da bin ich mit meiner CLI-Vorschädigung (ich hab mit
> Batch-Programmierung unter DOS 3.x vor ca. 100 Jahren angefangen) der
> falsche Ansprechpartner. Aber ich denke, daß das weniger ein Thema ist,
> bei dem man mit Wissen denn eher mit Methodik weiterkommt.

Siehste - dafür hatte ich sehr früh einen Lötkolben und sonstiges
Werkzeug in der Hand und habe begonnen, Geräte zu zerlegen (und sie
später auch wieder funktionierend zusammenzusetzen). Das einzige, was
ich "programmieren" kann sind GALs und EPROMs (jeweils am ST). Dafür
habe ich absolut keine Probleme damit, auch haarfeine Beinchen wieder
anzulöten bzs. durch Fädeldraht zu ersetzen. Hauptsache die Hardware
läuft wieder.

mfg Markus

[Thomas Kaiser]

Stefan schrieb in <news:kldse3$n12$1...@dont-email.me>

> Am 26.04.13 12:38, schrieb Thomas Kaiser:
>> (das Problem ist bei denen seit August 2012 bekannt und in Version
>> 2.6.3 gefixt worden).
>
> Was er übrigens gewusst hätte, wenn er einfach nur dem Link gefolgt
> wäre, den ich weiter oben angegeben habe.

Klar. Und Dein Link war Treffer 2 der von mir vorgeschlagenen Websuche
nach eben jenem String des Anstoßes. Alles eigentlich total naheliegend
bzw. eine Frage der Methodik. Aber was soll's, der Fakt, daß blöd
klingende Strings bzw. aufs Wesentliche reduzierte Fehlermeldungen nicht
einfach an Tante Google überantwortet werden, beschert mir regelmäßig
Neukunden.

Die Masche ist immer die selbe. Es taucht ein Problem auf. Das wird
nicht zielführend eingegrenzt sondern versucht, durch kultische und
rituelle Handlungen auszutreiben. Parallel fängt man an, Theorien über
die möglichen Ursachen zu entwickeln, und alles an echten Informationen,
die zum Problem vorliegen, wird retrospektiv passend gemacht bzw.
ausgeblendet, weil's nicht zur Theorie paßt. Das Problem an sich läßt
man aber freundlicherweise einfach mal in Ruhe und so besteht's halt
eben weiter.

Nach Wochen flippt dann irgendwer aus (meist jemand, der für Produktion
zuständig ist), dann $KRISENMEETING, $FINGERPOINTING usw. usf. Dann
irgendwann die Entscheidung, "Typ, der viel zu teuer ist" zu buchen.
Daraufhin flippt dann wieder irgendwer aus (meist jemand, der für Kosten
zuständig ist). Kontaktaufnahme meist Weltklasse: "Wir wollen auf keinen
Fall, müssen aber wohl?" und "Was kostet das?" -- "Ja nun, keine Ahnung.
Ich weiß ja noch nicht mal grob, um was es eigentlich geht. Vorschlag:
Abrechnung nach Aufwand bzw. angefangene Stunden und Ihr sagt halt dann
irgendwann Stop" :-)

(n Wochen Pause, dann flippt wieder der, der für Produktion... -- dann
endlich: Auftritt $teurer-Dienstleister, kaltes Bühnenlicht, frostiger
Empfang, abermals Hinweis auf Kostentransparenz, lalala)

Zum Beweis, daß man sich schon wirklich echt voll viel mit dem Problem
beschäftigt hat, erfährt man von eben jenem exakt gar nix. Sondern wird
erstmal auf einen Holzweg gigantischer Dimensionen geführt (aus edelsten
Hölzern, mit prächtigen Intarsien und Schnitzereien -- man will sich ja
nicht lumpen lassen). Wo's dem Dienstleister aber gar nicht so gut
gefällt.

Dann kommt der schwerste Part: Herausfinden, worum's geht. Wenn
schriftliche Aufzeichnungen aus den Frühtagen des Problems existieren
(Mails von Usern an die IT sind da extrem hilfreich), ist man relativ
schnell am Ziel. Ansonsten muß man das Problem nachstellen lassen, denn
die Problembeschreibungen, die genauso wie die "Fakten" im Lauf der Zeit
immer mehr an die vor Ort als plausibelste geltende Theorie angepaßt
wurden, taugen nichts. Dann ganz großes Staunen, daß völlig andere Dinge
geschehen als erwartet/beschrieben. Gipfelte einmal sogar in "Das ist
nicht das Problem, wegen dem Sie hier sind!" :-)

Fehlermeldung (bereinigt) in Google, Logging auf verbose drehen, wieder
bisserl rumgooglen, bei Google querlesen, daß auf OS x Tool y voll der
Bringer ist, um Problem z zu analysieren, sich über Tool y freuen wie
Schnitzel, weil wirklich geil (und wieder was gelernt -- hat sich das
Aufstehen in der früh also sogar gelohnt). Und dann Problemlage, weil
Problemlösung: Bezahlung nach Aufwand war ausgemacht. Und damit fallen
die Anfahrtskosten plötzlich höher aus als die Gage für $Dienstleister,
der -- oops -- doch gar nicht so teuer ist, weil wider Erwarten schon
fertig.

In den Gesichtern der ITler die nackte Angst: "wir so wochenlang Phantom
nachgejagt, er so bisschen rumgegoogelt". $GESICHTSVERLUST droht...

Und ab jetzt wird's wirklich blöd, weil das drängende Problem zwar
ratzfatz gelöst ist... aber die direkten Beauftrager alles andere als
damit glücklich sind.

Wenn man noch jung und dumm ist, läßt sich man sich dann auf so
Vorschläge à la "Wir erzählen einfach, wir hättens noch nicht gelöst,
Sie bringen uns jetzt mal Troubleshooting in heterogenen Netzwerken bei
und erst in 3 Tagen wird Schampus gesoffen?!" ein. Bedeutet dreierlei:
1) "most expensive inhouse training ever", 2) der Kosten-Typ flippt
wieder, weil die Admins, die alle auf einmal viel mehr können, mehr Geld
wollen, 3) der Produktions-Typ flippt, weil die ITler geschlossen
gekündigt haben, um woanders zu höheren Gagen weniger langweiligen Kram
zu machen.

Jaja, in der IT kanns auch verdammt menscheln :-)

Gruss,

Thomas

[Thomas Kaiser]

Markus Elsken schrieb in <news:517a8e6e$0$30114$8e6e...@newsreader.ewetel.de>

Siehste. Und genau deshalb lang ich Hardware nicht an -- schlicht weil
ich's nicht kann.

Obwohl ich auch ziemlich früh Lötkolben in der Hand gehabt hab. Der fade
Elektronikbaukasten hat schnell gelangweilt, dann hab ich mich mit 'nem
Spezl aufs Auschlachten und lustige Experimente mit Fernsehern verlegt.
Aber irgendwie waren Eltern dagegen. Wir hatten an einem Nachmittag 11
olle Fernseher bei den TV-Läden der Umgebung zusammengeschnorrt. Und
statt elterlicher Begeisterung Gekeife von wegen GEZ, "Haare vom Kopf",
"der Schrott muß sofort weg".

Und so ganz gesund war das auch nicht. Hatte 'nen Röhrenfernseher halb
zerlegt, dann angeschaltet (warum? keine Ahnung!) und dann weiter dran
rumgeschraubt. Überraschenderweise schlug dann irgendwann der Blitz von
einer der Röhren ein. Toller Effekt, ich lag auf dem Boden. Dann den
brillianten Entschluß gefaßt, die Abschirmbleche wieder anzubringen. Bei
laufendem Gerät. Mit einer unisolierten Metallzange. Naja, nochmal auf
dem Boden gelegen, die Zange steckte in der Zimmerdecke. Und keine
Ahnung, wie das ging.

Ach, und die Ausdünstungen von den Dingern haben irgendwie auch eher
dumm gemacht. Da hatten wir ein Riesentrumm von Fernseher erbeutet, in
meinem Zimmer angeschalten und völlig tumb auf die psychedelischen
Muster gestarrt, die das Ding in seinem Todeskampf noch erzeugt hat. Und
dabei nicht gemerkt, daß aus dem Teil hinten schon Flammen loderten. Die
wiederum Muttern 3 Zimmer weiter schon riechen konnte. Und erstaunlich
professionell mit meiner Bettdecke gelöscht hat. Drogen waren übrigens
keine im Spiel, wir waren ja erst 11.

Gruss,

Thomas, läßt seitdem die Finger von sowas...

[Stefan]

Am 26.04.13 16:56, schrieb Thomas Kaiser:

> Klar. Und Dein Link war Treffer 2 der von mir vorgeschlagenen Websuche

Jo, hätt ich noch erwähnen müssen.

Es ging mir eigentlich darum, dass es das eine ist, die zündende Idee
für zielführendes Gugeln nicht zu haben oder mit Kommandozeilen nicht
klar zu kommen, aber etwas ganz anderes, eine Antwort, die auf dem
Präsentierteller eine vollständige Klärung des Problems inkusive
pfannenfertiger Lösung ganz ohne Kommandozeile frei Haus liefert,
einfach zu ignorieren. Da stösst dann sogar meine Empathie an Grenzen,
und das will was heissen.

[Joe Kotroczo]

http://shop.oreilly.com/product/0636920025870.do

Setzt allerdings Englischkenntnisse voraus.

[Markus Elsken]

Moin!

Am 26.04.13 19:27, schrieb Joe Kotroczo:
> Setzt allerdings Englischkenntnisse voraus.

Da war doch mal was, so vor 30 Jahren... :-)

mfg Markus

[Patrick Kormann]

Am 26.04.13 17:25, schrieb Thomas Kaiser:

> Und so ganz gesund war das auch nicht. Hatte 'nen Röhrenfernseher halb
> zerlegt, dann angeschaltet (warum? keine Ahnung!) und dann weiter dran
> rumgeschraubt. Überraschenderweise schlug dann irgendwann der Blitz von

Hmm, vor sowas hat mir mein Vater schon sehr früh Respekt beigerbacht.
An TVs bin ich nie gegangen. Und bis heute geh ich an alles was 230V~
ist nur wenn die Sicherung draussen ist und ich nachgemessen habe, dass
da wirklich nichts mehr ist.
Mag daran liegen dass ich als Kleinkind krabbelnder Weise mal zwischen
Verlängerungskabel und eingesteckes Gerät gegrabscht habe (uraltes
Verlängerungskabel wo sowas möglich war). Ein beeindruckendes Erlebnis
und wahrscheinlich meine frühste Kindheitserinnerung.

[Heiner Veelken]

Patrick Kormann <sir...@hotmail.com> wrote:

> Am 26.04.13 17:25, schrieb Thomas Kaiser:
>

> > Und so ganz gesund war das auch nicht. Hatte 'nen R�hrenfernseher halb

> > zerlegt, dann angeschaltet (warum? keine Ahnung!) und dann weiter dran

> > rumgeschraubt. �berraschenderweise schlug dann irgendwann der Blitz von
>
> Hmm, vor sowas hat mir mein Vater schon sehr fr�h Respekt beigerbacht.

> An TVs bin ich nie gegangen. Und bis heute geh ich an alles was 230V~
> ist nur wenn die Sicherung draussen ist und ich nachgemessen habe, dass
> da wirklich nichts mehr ist.
> Mag daran liegen dass ich als Kleinkind krabbelnder Weise mal zwischen

> Verl�ngerungskabel und eingesteckes Ger�t gegrabscht habe (uraltes
> Verl�ngerungskabel wo sowas m�glich war). Ein beeindruckendes Erlebnis
> und wahrscheinlich meine fr�hste Kindheitserinnerung.

Nach 'zig Jahren usenet-Erfahrung, wo man sich gegenseitig auch ein
wenig kennenlernt, r�ckst Du erst jetzt, nach einer Ewigkeit, mit der
Erkl�rung heraus :-)

--
Gruss Heiner

[Başar Alabay]

Heiner Veelken schrieb:

> Nach 'zig Jahren usenet-Erfahrung, wo man sich gegenseitig auch ein

> wenig kennenlernt, rückst Du erst jetzt, nach einer Ewigkeit, mit der
> Erklärung heraus :-)

Gilt für beide …

:-)

B. Alabay

--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら