Mit schöner Regelmäßigkeit kursieren Gerüchte und Spekulationen darüber, welche Firma Apple demnächst übernehmen werde. Aktuell will der Boy Genius Report aus einer „unproven source“ erfahren haben, Apple plane die Übernahme der US-Buchhandelskette Barnes & Noble. Diesen ziemlich offensichtlichen Unfug hat Harry McCracken zum Anlass genommen, einmal in einer Brief History of Apple Not Buying Things zusammenzutragen, welche Firmen Apple angeblich in den letzten Jahre schon alles hat übernehmen sollen: Universal Music, Pixar, TiVo, Palm, Disney, Nintendo, Sun, AMD, Adobe, Sony, Yahoo, Electronic Arts, Twitter, Netflix und Facebook. Anscheinend denkt man in Cupertino einfach anders als die ganzen Analysten, die bei jedem Gerücht sofort begründen können, warum Apple jetzt aber unbedingt dieses oder jenes Unternehmen aufkaufen müsse. Oder wie Harry McCracken sehr schön formuliert:
For years, Apple has confounded the rest of us by not buying things that it should clearly be buying. Not purchasing other well-known companies is so core to Apple’s strategy that it must have a whole department devoted to non-mergers and un-acquisitions.
Das Resume-Feature von Lion ist eigentlich eine feine Sache: eine App, die beendet wird, lädt beim Neustart alle zuvor geöffneten Dokumente genau in dem Zustand, in dem sie verlassen wurden. Normalerweise ist das ungemein praktisch, mitunter aber auch nervig. Dann zum Beispiel, wenn man (wie ich aktuell bei der Arbeit am Lion-Buch) permanent Screenshots in der Vorschau bearbeitet und irgendwann so um die zehn Fenster mit Dokumenten geöffnet hat, die man allesamt nicht mehr benötigt. Normalerweise habe ich da mit ⌘Q aufgeräumt, in Lion geht das nicht mehr, da beim Neustart alle Fenster wieder da sind. Also: ⌘W,⌘W, ⌘W ….
Doch das muss nicht sein, wie ich da gerade bei der Macworld lese: Schließt man eine App mit ⌥⌘Q öffnet sich ein Programm beim nächsten Start ohne Altlasten. Sinnvolle Ausnahme: Fenster, die beim Verlassen ungespeicherte Dokumente enthielten, werden beim Neustart wieder geöffnet.
Auch das von vielen (nicht unbedingt von mir) vermisste „Ausschneiden & Einfügen“ im Finder hat nun Einzug in Lion gehalten, wie man bei MacOSXHints erfahren kann. Ein im Finder mit ⌘C kopierter Eintrag kann mit ⌥⌘V in den Zielordner verschoben werden. Das ist insofern eine bessere Lösung als ⌘X, ⌘V als die Entscheidung, ob ein Eintrag nur kopiert oder doch verschoben werden soll, erst am Ziel fällt – und nicht schon an der Quelle, was doch ziemlich fehleranfällig ist.
Wo ich gerade dabei bin, kann ich auch gleich auf einen blöden Bug in der Vorschau hinweisen. Manche Screenshots mache ich nicht über die üblichen Tastenkürzel ⇧⌘3 bzw. ⇧⌘4, sondern mit dem Programm Bildschirmfoto (zum Beispiel, weil ich den Mauszeiger im Bild brauche). Bildschirmfoto speichert von Haus als TIFF auf dem Schreibtisch, ich brauche die Screenshots als PNG im Dokumentenverzeichnis. Kein Problem, lässt sich mit Vorschau erledigen. Und hier schlägt der Bug zu: ändert man die einzugebenden Daten, in der Reihenfolge, in der es der Speichern-Dialog anbietet – nämlich Name, Speicherort, Format – dann haut einen die Änderung des Formats zurück auf den Anfang. Es wird zwar das Dateiformat geändert, aber der Name und der Speicherort werden zurückgesetzt und müssen erneut eingegeben werden. Man muss also zuerst das Format ändern, und kann erst dann Name und Speicherort festlegen. Sehr lästig.
Mit Lion hat Apple ein neues, systemweites Feature namens „Versionen“ eingeführt. Eine App, die diese Funktion unterstützt, überschreibt beim Speichern nicht mehr die gespeichert und aktuell geöffnete Version eines Dokuments, sondern sichert lediglich die Unterschiede zwischen den Fassungen. So kann man jederzeit in den verschiedenen Versionen eines Dokuments blättern, ältere Fassungen problemlos wiederherstellen oder auch Passagen aus früheren Versionen in die aktuelle Version eines Dokuments übernehmen.
Diese sehr erfreuliche Änderung hat allerdings Konsequenzen, die (so zumindest mein Eindruck aus Gesprächen und Diskussionen) manche Anwender verwirren: die vertraute „Sichern unter“-Funktion gibt es nicht mehr.
Mit Lion hat Apple das vertraute „Sichern unter“ abgeschafft …
Wer ein Dokument unter anderem Namen, an anderer Stelle oder in einem anderen Format ablegen möchte, der muss das Dokument nun zuerst duplizieren und kann dieses Duplikat schließlich wie gewünscht speichern.
… stattdessen wird ein Dokument nun zuerst dupliziert, bevor es als neues Dokument gespeichert werden kann.
Das mag auf den ersten Blick widersinnig und unnötig mühsam wirken, doch ist unterm Strich die ungleich bessere Lösung.
Dazu ein Standardbeispiele aus meiner Praxis.
Ich stehe immer wieder vor der Aufgabe, dass ich Details aus einem Screenshot in einen Artikel einbauen muss. Bislang habe ich dafür den Screenshot mit einem Doppelklick vom Schreibtisch geöffnet, die gewünschte Stelle markiert, mit ⌘K ausgeschnitten und mit ⇧⌘S im Dokumentenordner gespeichert. Anschließend wurde mit ⌘W das Fenster geschlossen.
Bei Lion sieht die Sache nun so aus: Screenshot mit Doppelklick öffnen, Stelle markieren, mit ⌘C und ⌘N ein neues Dokument aus dem Ausschnitt anlegen und mit ⌘S speichern. Anschließend sind beide Dokumente – Original und Ausschnitt – noch in Vorschau geöffnet, ich muss also zweimal ⌘W drücken, um beide Fenster zu schließen (ein ⌘Q würde nichts helfen, da Vorschau beim nächsten Start beide Dokumente erneut öffnet *).
Bisher brauchte ich also drei Tastenkombinationen, nun sind es fünf. Da könnte man auf die Idee kommen, das neue Verfahren sei einfach nur lästig. Doch das ist es nicht. Nicht nur, weil die Tastenkombinationen in Bruchteilen von Sekunden gedrückt werden, sondern auch, weil das neue Verfahren „Duplizieren“ unvergleichlich viel sicherer und transparenter ist als „Sichern unter“. Warum?
Beim „Sichern unter“ kann es sehr schnell passieren, dass man statt ⇧⌘S die Tastenkombination ⌘S erwischt – und so nicht das aktuelle Dokument an anderer Stelle speichert, sondern die bislang gespeicherte Fassung versehentlich überschreibt. Ich habe das nie mitgezählt, aber mir passiert das durchaus häufiger. Normalerweise merke ich das sehr schnell und kann mit ⌘Z die Ursprungsversion wiederherstellen und erneut speichern. Aber es ist auch schon vorgekommen, dass ich durch Unachtsamkeit Texte und Bilder komplett verloren habe.
Eine andere Stolperfalle von „Sichern unter“ ist noch verheerender und hat mich schon komplette Artikel gekostet. Bei der Arbeit an längeren Manuskripten gerät man mitunter etwa vom Thema ab, schreibt aber, weil man gerade in Schwung ist, weiter und stellt nach zwei, drei Seiten fest, dass die letzten Abschnitte besser in einem anderen Zusammenhang aufgehoben sind. Wie bin ich damit bislang umgegangen? So: Ich habe das Manuskript mit „Sichern unter“ an anderer Stelle gespeichert, die entsprechenden Abschnitte gelöscht, das Dokument mit erneutem „Sichern unter“ wieder an seinem ursprünglichen Platz abgelegt und weitergearbeitet.
Bei diesem Vorgehen passiert es mir mit unschöner Regelmäßigkeit, dass ich das zweite „Sichern unter“ vergesse. Die Konsequenz: Jedes erneute Sichern überschreibt die mit „Sichern unter“ angelegte Kopie und alle Müh’ war für die Katz’.
Das Problem beim „Sichern unter“ besteht generell darin, dass der Arbeitsfluss umgebogen und vom Anwender eine eigentlich unnötige Abstraktionsleistung verlangt wird. Man öffnet ein Dokument aus Verzeichnis A, bearbeiten es und sichert es zwischendurch mit „Sichern unter“ im Verzheichnis B. Äußerlich hat sich überhaupt nichts geändert, man arbeitet nach wie vor an seinem Dokument im gleichen Fenster und das GUI gibt keinerlei Rückmeldung. Doch tatsächlich ist die Situation nun völlig anders und man arbeitet an einem komplett neuen Dokument. Der Vorgang wird mit jedem „Sichern unter“ – es gibt in der Praxis immer wieder Fälle, wo ein Dokument als Vorlage für zwei, drei oder mehr Dokumente benutzt wird – komplizierter und fehleranfälliger.
Mit „Duplizieren“ kann das nicht mehr so schnell passieren, da das GUI deutliche Signale sendet. Nicht nur, dass man nun zwei Dokukmentenfenster auf dem Bildschirm hat (es sind ja auch zwei Dokumente), das zweite Fenster mit dem Duplikat hüpft in einer kleinen Animation vor das Original. Dabei handelt es sich mitnichten um eine nette, aber überflüssige Spielerei, sondern um eine visuell überzeugende Information über das, was da gerade auf Systemebene passiert ist. Bei „Sichern unter“ weiß nur das OS jederzeit, mit welchem Dokument man da gerade arbeitet, beim „Duplizieren“ weiß es auch der Anwender (und zwar ohne nachdenken oder sich im Finder vergewissern zu müssen).
Anders gesagt: Die Zeiten, in denen man durch Unachtsamkeit Inhalte verloren hat, sind mit Lion vorbei.
Es gibt keine fehlerfreie Software, klar. Aber ich hatte doch gehofft, dass diese beiden Bugs auf dem Weg von der Goldmaster zur Final noch rasch gefixt werden. Wurden Sie leider nicht.
Tausender- und Dezeimaltrennzeichen im Rechner
Bei den Tausender- und Dezimaltrennzeichen mischt Lion in der Rechner-App die amerikanische und die deutsche Notation. Zur Erinnerung: bei uns ist das Tausendertrennezichen ein Punkt, das Dezimaltrennzeichen ein Komma. Im angelsächsischen Raum ist es genau umgekehrt. Hierzulande notiert man „1.000,12345“, in den USA dagegen „1,000.12345“.
Die Rechner-App in Lion vermischt beide Schreibweisen nun auf verwirrende Weise und setzt überall ein Komma. Das sieht dann so aus:
Unschön: Tausender- und Dezimaltrennzeichen sind bei Lion derzeit identisch.
Wi-Fi-Menü
Auch im Wi-Fi-Menü steckt ein Bug. Normalerweise sollte neben dem Netzwerk, mit dem man verbunden ist, ein kleiner Pfeil auftauchen. Mit einem Klick auf den Eintrag blendet man dann ein Kontextmenü ein, in dem man die aktuelle Verbindung manuell trennen kann (benötigt man etwa, wenn man sich eine neue IP zuweisen lassen möchte). Das ist bei Lion anfangs auch der Fall:
Nach dem Start sieht im Wi-Fi-Menü noch alles normal aus …
Doch beim nächsten oder übernächsten Klick vergisst Lion diesen Pfeil und bietet auch keine Möglichkeit mehr, das kleine Kontextmenü aufzurufen:
… doch beim erneuten Aufruf verschwindet das Kontextmenü.
Die einzige Möglichkeit, die ich bislang entdeckt habe, den Pfeil samt Kontextmenü wieder einzublenden: Wi-Fi deaktivieren und erneut aktivieren. Lästig.
Heute hatte ich eines der seltenen Schreckerlebnisse am Mac: Beim Booten meines Test-iMac (20 Zoll, Ende 2006) kam das System nicht einmal bis zum Startup-Sound und zeigte mir einen weißen Bildschirm. Alle Versuche von DVD oder von einer zweiten Partition zu starten, schlugen fehl, der iMac ignorierte beharrlich eine gedrückte „alt“- bzw. „C“-Taste. Bevor ich mich meiner Ratlosigkeit überantwortete fiel mein Blick auf meinen alten 80-GB-iPod. Den hatte ich vor dem Neustart als externe Festplatte benutzt. Und der zeigte beharrlich seine „Nicht trennen“-Meldung, obgleich ihn das System noch gar nicht hatte ansprechen oder einbinden können. Als letzten Versuch zog ich den iPod ab – und siehe da: es erschien prompt das Apple-Logo und der Mac bootet wie gewohnt.
Puah.
Merke: vor dem Neustart den iPod vom Mac trennen.
P. S.: Ach ja, auch der iPod hat die Prozedur gut überstanden.
Wenn Sie sich darauf verlassen, dass ein Passcode Ihr iPhone vor unbefugtem Zugriff schützt, dann habt ich leider eine sehr schlechte Nachricht für sie: der einfache, vierstellige Passcode ist im Falle eines Falles praktisch nutzlos
Schon vor ein paar Wochen hatte das russische Sicherheitsunternehmen Elcomsoft mit der Meldung für Aufsehen gesorgt, man habe ein Tool entwickelt, mit dem sich der Passcode problemlos aushebeln lasse (PDF). Da Elmsoft den Beweis in Form einer öffentlichen Demonstration allerdings schuldig blieb, und
den Zugang zu dieser Fuktionalität … nur Strafverfolgungsbehörden, forensischen Organisationen, Geheimdiensten und gewissen Regierungsbehörden
gewähren wollte, konnte man hier noch hoffen, da wolle ein Unternehmen durch kesse Behautpungen für Schlagzeilen sorgen.
In dem Video wird gezeigt, wie ein spezieller Jailbreak Kontakt zu einem passcodegeschützten iPhone aufnimmt und den Code kurzerhand ändert. Dazu wird das iPhone in den DFU-Modus versetzt, der Jailbreak ins RAM kopiert und ein Bruteforce-Programm gestartet, das den vorhandenen Code knackt und durch einen neuen ersetzt. Laut Apple sollte das eigentlich unmöglich sein, da sich das iPhone nach mehreren Fehlversuchen stur stellt:
Falls Sie mehrmals hintereinander einen falschen Code eingeben, wird das iPhone, das iPad oder der iPod touch für eine längere Zeit deaktiviert, bevor Sie den Code erneut eingeben können. Wenn die zulässige Anzahl ungültiger Versuche überschritten wurde, können Sie einen erneuten Eingabeversuch erst dann unternehmen, wenn Sie das Gerät mit dem Computer verbinden, mit dem es zuletzt synchronisiert wurde.
Klingt gut, hat aber einen Haken. Denn damit wie beschrieben funktioniert, muss das unveränderte iOS laufen – doch genau das tut es bei dem von Heise demonstrierten Verfahren nicht. Ein Programm, das innerhalb einer Jailbreak-Umgebung agiert, kann anscheinend so lange rumprobieren, bis es Erfolg hat.
Da Heise frei verfügbare Software eingesetzt hat, kann man wohl davon ausgehen, dass jeder, der ein iPhone wirklich knacken will, es auch knacken kann, ohne auf Spezialsoftware von Anbietern wie Elcomsoft angewiesen zu sein.
All das gilt, wie erwähnt, für den Vierziffern-Code. Der dürfte für den normalen Einsatz eines iPhones wohl immer noch einigermaßen sicher sein. Die Wahrscheinlichkeit, dass ein zufälliger Finder auch über das notwendige Know How verfügt, den Code auszuhebeln, ist vermutlich sehr gering. Das ist natürlich nicht wirklich befriedigend und der Einsatz eines iPhones mit vierziffrigem Code in sicherheitsrelevanten Bereichen verbietet sich praktisch von selbst.
Der einzige aktuelle Schutz gegen diesen Angriff ist der Einsatz eines längeren Passcodes. Je komplexer der Code, desto länger dauert ein Bruteforce-Angriff, bis er nicht mehr praktikabel ist. Wer sein iPhone also wirklich vor fremden Zugriff schützen will oder muss, der sollte unter „Einstellungen > Allgemein > Code-Sperre“ die Option „Einfacher Code“ ausschalten und sich ein hinreichend komplexes Passwort überlegen.
Das ist lästig. Aber Sicherheit gibt es nicht zum bequemen Nulltarif.
Auch bei 9to5mac hat man das neue Thunderbolt-Kabel mit dem Target Disk Mode ausprobiert. Und wie bei Heise machte man auch hier eine eher ernüchternde Erfahrung. Der Datendurchsatz blieb sehr weit hinter den Erwartungen zurück.
Andererseits gibt es ein Video, in dem Jason Ziller (Director of Thunderbolt Marketing & Planing) die Geschwindigkeit von Thunderbolt beim Zugriff auf ein externes Raid demonstriert. Hier werden Geschwindigkeiten von rund 600 bis 800 MB/s erreicht und eine rund 4,5 GB große Datei ist innerhalb kürzester Zeit kopiert. Das Video scheint nicht manipuliert zu sein und nährt den Verdacht, dass der Target Disk Mode (noch?) nicht wirklich gut mit Thunderbolt zusammenarbeitet:
Apple bewirbt die neue Thunderbolt-Schnittstelle in den höchsten Tönen. „Ultraschnell“ soll sie sein, „ultraflexibel“ und nicht nur USB („20x schneller“), sondern auch Firewire 800 („12x schneller“) locker abhängen.
Bislang kann man mangels Masse diese Behauptungen kaum überprüfen, doch bei Heise hat man das neue Thunderbolt-Kabel von Apple zum Anlass genommen, einen iMac (27″) und ein MacBook Pro (13″) im Target Disk Mode zu verbinden (der auch von Thunderbolt unterstützt wird). Das Ergebnis war allerdings ernüchternd. Beim Lesen kam Thunderbolt auf einen Datendurchsatz von 42,9 MB/s, beim Schreiben auf 20,9 MB/s. Zum Vergleich: ein identisches Setup mit Firewire 800 liest die Daten zwar etwas langsamer (38,2 MB/s), übertrifft dafür aber mit 36,1 MB/s Thunderbolt deutlich:
Warum FireWire beim Schreiben deutlich schneller ist als Thunderbolt, ist unerklärlich.
Überraschung! Im Target Disk Mode schreibt Firewire 800 die Daten deutlich schneller als Thunderbolt und muss sich auch beim Lesen nicht verstecken. (Zahlen: Heise.de)
Bleibt nur die Hoffnung, dass es sich hier noch um ein Treiberproblem bzw. eine Besonderheit des Target Disk Modes handelt: Warten wir auf den Löwen. Und, natürlich, auf Peripheriegeräte mit Thunderbolt-Schnittstelle.
P.S. Bei iFixit hat man das Thunderbol-Kabel übrigens zerlegt. Ergebnis: es steckt voller Chips und allerlei Technik, was wohl den recht happigen Preis von knapp 50 Euro erklären kann.
insideMac Blog abonnieren (RSS 2.0)
OS X für Ein- Umsteiger
Heute hatte ich eines der seltenen Schreckerlebnisse am Mac: Beim Booten meines Test-iMac (20 Zoll, Ende 2006) kam das System nicht einmal bis zum Startup-Sound und zeigte mir einen weißen Bildschirm. Alle Versuche von DVD oder von einer zweiten Partition zu starten, schlugen fehl, der iMac ignorierte beharrlich eine gedrückte „alt“- bzw. „C“-Taste. Bevor ich mich meiner Ratlosigkeit überantwortete fiel mein Blick auf meinen alten 80-GB-iPod. Den hatte ich vor dem Neustart als externe Festplatte benutzt. Und der zeigte beharrlich seine „Nicht trennen“-Meldung, obgleich ihn das System noch gar nicht hatte ansprechen oder einbinden können. Als letzten Versuch zog ich den iPod ab – und siehe da: es erschien prompt das Apple-Logo und der Mac bootet wie gewohnt.
