Archive for the ‘gadgets’ Category
NVIDIA verbietet Nutzung von GeForces in Rechenzentren
Die aktuelle Version der EULA für den GeForce-Treiber verbietet die Nutzung des Treibers (der Karten) in Rechenzentren. Als einzige Ausnahme wird in den Nutzungsvereinbarungen explizit Blockchain-Verarbeitung genannt.
Keine Bereitstellung in Rechenzentren: Die SOFTWARE wird nicht für die Bereitstellung in Rechenzentren lizenziert. Als Ausnahme ist Blockchain-Verarbeitung im Rechenzentrum gestattet.
Die Karten – insbesondere die 1080ti – ist allerdings extrem beliebt, da sie mit mehreren tausend Cores und bis zu 11GByte RAM eine Alternative zu den Tesla- und Quadro-Karten mit ihren signifikant höheren Preisen darstellen.
Etliche Hoster bieten Konfigurationen mit einer oder mehreren GeForce-Karten an. Eingesetzt werden diese im professionellen Umfeld für Simulationen und Data-Scientists-Aufgaben. Neben üblichen statistischen Berechnungen zählen dazu auch Machine Learning und Deep Neural Networks (DNN). Das erklärt auch, warum sowohl Golem (die das Thema zuerst im deutschsprachigen Newsland™ aufgegriffen hatten) und Heise zu der Verkürzung “kein Depp Learning mehr mit GeForces” kamen.
Für den “kleinen” Data Scientist in einer Firma ändert sich damit zunächst allerdings nichts: er wird seine Python- und R-Scripte weiterhin auf seinem Arbeitsplatzrechner auf einem kleinen Sample entwickeln und dann auf der Computational Engine im Rechenzentrum auf dem vollständigen Datensatz rechnen lassen.
Die spannende Frage ist jetzt, welche Karte in dem Server im Rechenzentrum steckt. Falls es sich um eine virtualisierte Umgebung handelt, kann es bereits jetzt nur eine Karte aus der Tesla- oder Quadro-Liga sein. Auch bisher hatte NVIDIA Funktionen aus dem Umfeld des High Perfomance Computing auf bestimmte Karten beschränkt, u.a. die Virtualisierung.
Solche Umgebungen sind bei Data Scientists sehr beliebt. In den meisten Fällen sind die Kalkulationen und damit die wahrscheinlich anfallenden Kosten relativ genau bekannt und damit die Kosten überschaubar. Ein typisches ML-Model benötigt bei gegebener Rechenpower dort vielleicht ein/zwei Tage. Man bezahlt dafür möglicherweise einige hundert Dollar. Eine Workstation, die das gleiche Model rechnet, kostet demgegenüber gerne zehntausend Dollar oder mehr und verlangt eigenen administrativen Aufwand, der in einer Enterprise-Umgebung nicht gegeben ist. Mögen sich die Kosten nach 10 Aufgaben amortisiert haben, die Workstation braucht allerdings für das gleiche Model eine Woche statt nur zwei Tage.
Ebenfalls unproblematisch ist die neue Einschränkung für Wald- und Wiesen-Hoster. Wenn ein Kunde sich einen Server mit vier 1080ti clickt muss der Hoster den Kunden – wahrscheinlich – nicht mal darauf hinweisen, dass der GeForce-Treiber bestimmte Restriktionen auferlegt. Im Normalfall wird der Hoster den Treiber auch nicht selbst installieren. Es bleibt dem Kunden überlassen sich dem unternehmerischen Risiko auszusetzen, von NVIDIA rechtlich belangt zu werden. Und auch dieses Risiko hält sich in Grenzen: der Treiber selbst dürfte in solchen Umgebungen keine Möglichkeit haben, zu ermitteln, dass er in einem Rechenzentrum läuft, welches Framework grade ausgeführt wird und überhaupt darf ein Treiber nicht ins Netz. Die Firewall-Rules müssen ihn daran hindern.
Zu einem Problem wird die Neureglung jedoch für die vielen kleinen Spezialhoster, die sich auf Data Scientists und Machine Learning als Marktnische eingelassen haben. Um mit Amazon und Google konkurrieren zu können haben sie eigentlich nur den Preis als Hebel. Und für sie boten sich die GeForce-Karten ideal an. Bei den meisten Anwendungen erreicht eine 1080ti ein Viertel Rechenpower im Vergleich zu einer Tesla-Karte und das zu fast einem Zwanzigstel des Preises. Es verwundert also nicht, dass NVIDIA sich bei einem solchen Betreiber gemeldet hat.
Vor diesem Hintergrund würde es nicht verwundern, wenn Amazon als größter NVIDIA-Kunde ein “aktives” Interesse an dieser Einschränkung bekundet hat; so unter Freunden, wissen schon …
Poor-Man’s-Blockchain mit ARMs Speicherzugriffsprotokoll
Im Rahmen einer Machbarkeitsstudie stellte sich grade die grundsätzliche Frage, ob eine Blockchain-Implementierung prinzipiell für IoT-Kommunikation denkbar ist und welche Probleme es dabei geben könnte. Es zeigte sich sehr schnell, dass einer der Parameter mit großem Hebel, die Kosten (Operations/Watt) für die Berechnung (Hash-Validierung, Signing, En-/Decryption) der Blockchain ist. Eine sehr kleine Veränderung dieses Parameters führt umgehend zu einem “rechnet sich nicht mehr”.
Viele IoT-Devices basieren derzeit auf ARM-Chips verschiedenster Ausprägung. Teil der ARM-Lizenz ist in vielen Fällen auch das AXI-Protokoll. Dieses Protokoll bietet verschiedene Modi für den schnellen Zugriff auf den Speicher und kommuniziert über ein DMA-Register mit der jeweiligen Memory Management Unit(MMU). Der schnellste Modus ist dabei Scatter/Gather. Ein Verfahren, das noch aus den Urzeiten der IT kommt und erstmals bei SCSI verbreitet eingesetzt wurde. Es wird auch als Vectored I/O bezeichnet und stellt im Kern eine verkettete Liste dar.
In das MMU-Register wird bei dem AXI-Protokoll die erste und die letzte Speicheradresse geschrieben. In den Blöcken der Liste ist jeweils die Adresse des nächsten Speicherblocks hinterlegt. Die jeweilige AXI-Implementierung legt fest, wann der eigentliche Transfer des Speichers stattfindet. Im Allgemeinen geschieht dies, wenn die letzte Adresse in das MMU-Register geschrieben wird.
Eine Blockchain selbst ist im Prinzip nichts anderes als eine verkettete Liste. Das bedeutet, dass man lediglich das Format der Blockchain so definieren müsste, dass es die Anforderungen des Scatter/Gather-Protokolls erfüllt. Im Wesentlichen sind dies die Position der Next-Block-Adresse und die Größe des einzelnen Blocks. Diese Größe ist bei AXI variabel muss aber auf Speicheradressen 0×40 aligned sein. Wichtig ist dabei, dass alle Blöcke einer Chain eine identische Größe haben müssen. Sollten sich die Blöcke als zu klein erweisen wäre ein Resizing notwendig.
Die eigentlichen Kosten für die Validierung und Modifikation der Blockchain belaufen sich mit einer solchen Implementierung lediglich auf die Kosten für den Transport der Block-Daten aus dem Speicher und in den Speicher. Sowohl FPGAs als auch ARM GPUs (Neon, Mali) sind in der Lage, alle notwendigen Kalkulationen (Hash-Validierung, Signing, En-/Decryption) für einen Block durchzuführen, während die MMU damit beschäftigt ist, den Speicherinhalt zu laden/speichern. FPGAs hätten sogar noch den Vorteil, die privaten Schlüssel im Bitstream vorhalten zu können, ohne ein Leak befürchten zu müssen.
FPGA in der Amazon-Cloud
Am 30. November stellte Amazon ein Developer-Programm für ein neues Serverangebot vor. Unter dem schlichten und schlicht schönem Namen F1 stehen nun Rechner mit FPGAs zur Verfügung. Leider sind die Preise noch nicht bekannt, sollen aber schon bald verfügbar sein. Bei der avisierten Ausstattung kann man aber damit rechnen, dass Stundenpreise im zweistelligen Dollar-Bereich zu zahlen sind.
Zum Einsatz kommen Xilinx UltraScale+ VU9P Virtex FPGAs (~2,5M Logic Units). Bis zu sieben Boards sind in einem Server verfügbar. Eine solche Karte kostet auf der Strasse bis zu 20.000 Euro. Das Investment von Amazon kann also als signifikant bezeichnet werden. Und es dürfte sich dabei nicht nur um ein simples “Me Too” gegenüber Microsofts Bekenntnis zu FPGAs handeln.
Auf einer Karte, die über PCIe x16 angebunden ist stecken 64GByte DDR4-RAM. Angebunden ist der Speicher mit einem 288bit Bus. Die Anbindung verspricht (theoretische) 400Gbps Transferraten. Xilinx spricht von einem “bidirectional ring” ohne näher zu erklären, was sie damit genau meinen. Sie weisen darauf hin, dass man das Zugriffsprotokoll selbst implementieren muss. Was in den meisten Fällen auf eine AXI-DMA-Lösung hinausläuft.
Obwohl die 400Gbps noch nicht an die Top-Karten von NVIDIA rankommen sind sie zusammen mit den 64GByte RAM eine echte Alternative zu der Verwendung von GPUs für Machine Learning. Denn im Gegensatz zu einer symmetrischen Core-Konfiguration können FPGA intelligenter auf den Speicher zugreifen. Mit einem Bus von 288 bit Breite stellt sich das neulich beschriebene Problem Resourcen-hungrigen AXI-Implementation als nicht mehr so dramatisch dar.
Die F1-Instanzen stellen eine virtuelle JTAG-Instanz zur Konfiguration des FPGA-Bitstreams bereit. Dabei dürfte es sich vermutlich um einen Device-Driver von Xilinx für CentOS handeln. Allerdings hat Xilinx Vivado offensichtlich auch für den Einsatz auf CentOS selbst fit gemacht. D.h. man kann den gesamten Workflow auf die Cloud auslagern. Was sicher die Synthese beschleunigt, wenn man selbst nur einen kleinen Arbeitsplatzrechner zur Verfügung hat. Ob das aber ein wirklich praktisches Setup ist, muss jeder selbst entscheiden. Bei den zu erwartenden Preisen rechnet sich ein neuer Arbeitsplatzrechner bereits nach einer Woche Download, Install, Konfiguration, Tests mit Vivado.
Jeff Barr (“Chief Evangelist for the Amazon Web Services”) beschreibt in einem kurzen Hands On wie man zu seinem ersten AFI (Amazon FPGA Image) kommt. Leider wird nicht klar, ob es sich dabei nur um einen Bitstream-Wrapper handelt oder tatsächlich um neues Format. Unklar ist derzeit auch noch, ob sequentielle Updates für die Bitstreams möglich sind. Die Chips bieten diese Option prinzipiell. Auch über verschlüsselte Bitstreams ist nichts in Erfahrung zu bringen.
Amazon wird mit der Verfügbarkeit der F1-Instanzen ein Github-Repository unter https://github.com/aws/aws-fpga(derzeit noch 404) veröffentlichen, das Samples und SDK enthält. Es wird spannend, ob sie tatsächlich einen neuen AXI-Stack als freies IP veröffentlichen oder ob man sich das entsprechende Lizenz-File für die lokale Synthetisierung laden kann.
Um eine Preview-Membership kann man sich hier bewerben.
Fazit
Die Idee, FPGAs in der Cloud anzubieten ist nicht neu. Der Anbieter POMMP verspricht seit Jahren signifikante Beschleunigungen für viele rechenintensive Prozesse. Es ist schön zu sehen, dass nun auch die Großen der Branche auf den Zug aufspringen. Wenn sich nun noch etwas an der Tool-Front tut dürfte dem Erfolg nichts mehr im Weg stehen.
Kernschmelze im Rechenzentrum
Ende September schrieb die Wired über Microsofts Wette auf FPGAs in ihren Cloud-Rechenzentren. Es hat dann “nur” drei Wochen gedauert bis auch die großen Medien (Fortune, The Register, Forbes, …) auf das Thema aufmerksam wurden. Verstärkt wurde die Aufmerksamkeitswelle noch durch die Berichte, dass im neuesten Apple iPhone auch ein FPGA sitzt (fälschlicherweise vermutet der Autor, dass dieser für AI zuständig ist). Dass es so lange gedauert hat ist insofern erstaunlich, da Wired von Diane Bryant erfahren haben will, dass Intel die 16 Mrd. Dollar für Altera ausgegeben hat, eben weil Microsoft zukünftig FPGAs in ihren Servern haben will. Und Diane Bryant ist immerhin Intels Vizepräsidentin für die Data Center Group.
Die Übernahme des zweitgrößten FPGA-Herstellers Altera durch den größten CISC-Prozessor-Anbieter für eine Rekordsumme in diesem Markt wurde von Intel begründet mit dem großen Potential der frei programmierbaren Chips im Bereich des machine und deep learnings. Und diese Form der Computation geschieht – zumindest heute noch – in Rechenzentren.
FPGAs für Deep Learning?
Microsoft selbst untersuchte schon länger die Möglichkeiten von FPGAs als Beschleuniger für den Betrieb von AI-Tasks. Sie sind dabei nicht die ersten. Schon 2010 hatte Yann LeCun (heute Leiter des AI-Labors bei Facebook) ein Paper über die Hardware-beschleunigte Umsetzung von Convolutional Neural Networks mitverfasst.
Facebook selbst hatte im Frühjahr verlauten lassen, dass es seine Zusammenarbeit mit Intel bei der Definition neuer Serverprozessoren unterstützt. Dabei sollen zukünftig SoC rauskommen, die neben dem Xeon auch einen FPGA enthalten können.
Zusammen mit Google arbeitet Facebook darüber hinaus an einem Standard für eine schnellere Anbindung unter anderem von “Co-Prozessoren” an den Hauptprozessor. Diese Initiative namens OpenCAPI soll die Bremse PCI Express ablösen. Weder PCIe 3.0 mit 32 Lanes noch PCIe 4.0 sind derzeit in Sicht und damit ist die maximale Transferrate seit Jahren bei 16GByte/s eingefroren. OpenCAPI (Open Coherent Accelerator Processor Interface) soll pro “Link” 25Gbit/s ermöglichen mit initial 8 Links. Damit wäre man bei maximal 25GByte pro Sekunde. (Leider kennt Heise den Unterschied zwischen GBit und GByte nicht.)
Flaschenhals Speicherbandbreite
Stolpern und Zaudern: Erste Schritte mit FPGAs
Mit ein wenig Hintergrundwissen ist jedem eigentlich klar, was man unter einem Field Programmable Gate Array verstehen kann. Ein Gitter aus Schaltungen, die man nach Belieben zusammen stecken kann und die dann Signaleingänge logisch verschalten und entsprechende Signale wieder ausgeben. So weit die Theorie hinter FPGAs. In der Praxis stellt sich das für einen durchschnittlichen Programmierer schon um einiges schwieriger dar.
Dschungel aus unbekannten Chips und Boards
Für FPGAs gibt es keinen Standard-PC, alle Systeme sind Embedded Systeme. Jedes verfügbare Board ist anders als die anderen. Schnittstellen, Adressen, Speicher usw. unterscheiden sich, haben unterschiedliche Größen und sogar Spannungen. Sogar die Chips der gleichen Reihe vom gleichen Hersteller sind verschieden. Ein echter Prozessor-Zoo.
Wichtig im Markt sind drei Chiphersteller: Xilinx, Altera und Lattice. Jeder von ihnen bietet eine große Palette an FPGAs. Die Größten kommen derzeit von Xilinx mit 4 Mio logischen Elementen. Diese kosten dann aber auch mehrere tausend Dollar und Entwicklungsboards etwa mit PCIe kommen gerne auf $70.000 pro Stück. Am unteren Ende der Skala finden sich Chips für wenige Cent. Allerdings sind Boards mit preiswerteren FPGAs auch nicht grade billig. Den Zynq 7010 verkauft Xilinx beispielsweise für unter $10 bei Abnahme von größeren Stückzahlen. Allerdings ist die Entwicklung eines Boards so aufwendig und die Zielgruppe so klein, dass ein typisches Board dann doch gerne $200 kostet.
Allerdings bieten solche Chips und Boards dann gerne auch mehr als es ein Arduino oder ARM-Pendent könnte. Die Zynq-Reihe von Xilinx ebenso wie die Cyclone-Reihe von Altera enthalten neben dem unterschiedlich dimensionierten FPGA auch einen ARM-Core (beim Zynq sogar einen Dual-Core). Diese Form des Designs hat sich schon früher mit PowerPC-Cores durchgesetzt und ist für die Entwicklung eine unglaubliche Erleichterung. Man kann dadurch den FPGA-Core dort einsetzen, wo er wirklich sinnvoll ist: Signalanalyse und -verarbeitung. Entsprechend viele Ein- und Ausgänge bieten solche Boards. Einen Sonderfall stellt das Parallella von Adapteva dar. Neben einem Zynq 7020 (Dual ARM und FPGA mit knapp 90k Logic Cells) hat es noch einen Parallelprozessor mit 16 Cores. Für $100 ein absolut faszinierendes Stück für Experimentalprojekte.
Ohne einen separaten ARM-Core kommt der inzwischen sehr weit verbreitete Spartan 6 von Xilinx. Boards mit diesem Chip bekommt man schon für etwas über $50. Das hervorragend designte Mojo wurde erfolgreich über Kickstarter finanziert. Mit dutzenden digitalen und einigen analogen I/Os ist es ausgezeichnet für Frequenzanalyse, Robotik und Steuerung geeignet.
Entwicklungstools: eingeschränkte Auswahl
Mit der Auswahl auf einen Chip hat man sich leider aber auch auf eine Toolchain für die Entwicklung festgelegt. Jeder Chiphersteller bringt seine eigene Entwicklungsplattform mit. Bei Xilinx nennt sich diese ISE (statt IDE). Es handelt sich um ein Monster, das Eclipse wie einen schlanken Editor erscheinen lässt. Alles soll man damit machen und alles kann man damit machen. Aber für jeden Schritt gibt es verschiedene Subtools, unterschiedliche Interfaces und einen riesigen Katalog an eigenen Begriffen. Wer aus der Softwareentwicklung kommt ist hier vollkommen lost. Es empfiehlt sich vor dem Beginn ein Blick auf die vielen Tutorials bei Youtube.
Bevor man sich die Tutorial jedoch ansieht, muss man sich entscheiden, in welcher Sprache man denn programmieren (Es heisst nicht programmieren!) will. Verilog ist eher in den Staaten verbreitet und VHDL in Europa. Zu den Unterschieden und den Grundlagen von VHDL gibt es eine gute Einführung von der Uni Kiel.
Prinzipiell ist es auch möglich, die Programmierung mit Comandline-Tools zu machen. Allerdings wird man Helfer wie make oder ant vermissen. Je nach Projekt muss man sich mit Shell-Scripten behelfen und diese anpassen. Alle notwendigen Anleitungen findet man in dem Tutorial “Using Xilinx Tools in Command-Line Mode“.
Die Entwicklung unter OSX ist nicht ohne einige Klimmzüge möglich. Mit einer VM in der Linux läuft, die die Xilinx-Tools beherbergt kann man sich aber helfen. Die Übertragung der fertigen Binärfiles funktioniert auch unter OSX z.B. mit verfügbaren Python-Scripten.
Es läuft!
Hat man all die Hürden überwunden, wird man aber ein ähnliches Hochgefühl haben, wie bei seinem ersten Assembler-Programm. FPGAs sind definitiv die hohe Kunst der Programmierung und zeigen erst wirklich, wie (klassische) CPUs tatsächlich funktionieren. Sie sind extrem energiesparend, alle Prozesse laufen gleichzeitig und sie sind in ihren Möglichkeiten nahezu unbeschränkt. Nur an den Tools muss noch gearbeitet werden. Aber es gibt ja auch schon einen FPGA-Assembler und eine Forth-Implementierung für FPGAs.
Schöner Fernsehen mit AppleTV
Am Dienstag nächster Woche findet mal wieder ein Special Event (Motto: “This should brighten everyone’s day”) von Apple statt. Allgemein angenommen wird die Vorstellung des iPhone 5S und des billigeren/farbigeren iPhone 5C. Inzwischen verdichten sich jedoch die Hinweise auf einen kompletten Relaunch des AppleTV. Es gibt obskure Beobachtungen über das Anlanden großer Settopbox-Lieferungen in die USA, intensivierte Verhandlungen mit Kabelprovidern und Contenanbietern und vermehrt freigeschaltete Kanäle im bestehenden Angebot.
@in_aha wies mich darauf hin, dass mit dem iPhone 5S Apple einen neuen A-Chip einführen wird und dann damit zu rechnen ist, dass der bisher verwendete Prozessor dann in die neue Generation des AppleTV wandern könnte. Ausserdem würde die Einführung der Gameconsolen-Module für iPhones und iPods nur Sinn ergeben, wenn die Spiele auch auf einem großen Screen zu sehen seien. Die bestehende AppleTV hätte bisher jedoch weder die Verbreitung noch die Zielgruppe um diesen Markt wirklich zu unterstützen.
Nokia, Microsoft und die seltsamen Vorstellungen der Anleger
Nach 2 1/2 Jahren war es dann heute endlich soweit. Microsoft kauft für 40% des Marktwertes den Kern von Nokias Geschäft. Die Mobilgerätesparte soll komplett an Microsoft übergehen und ausserdem erhält MS Zugriff auf die Patente von Nokia. Diese sollen allerdings offensichtlich nur geliehen sein. Bei den Geräten geht es nicht nur um die Lumia-Reihe sondern auch um die euphemistisch “Featurephones” genannten Asher-Geräte.
Von dieser Nachricht sind die Anleger offensichtlich so begeistert, dass sie den Nokia-Kurs vorbörslich gleich mal um 42% in die Höhe schnellen lassen. Das ist aus verschiedenen Gründen erstaunlich. Erstens: wurde Nokia grade entkernt. D.h. der Wert der Marke Nokia war vor allem im Massenmarkt vertreten. Diesen Massenmarkt gibt es jetzt nicht mehr. Und zweitens: der Kursgewinn macht insgesamt wesentlich mehr aus, als die Kaufsumme. D.h. die Anleger hatten offensichtlich noch mindestens 2Mrd.$ zukünftigen Verlust für die Gerätesparte eingepreist. Diese vermuteten sie entweder bis zum Erreichen der ersten schwarzen Null oder bis zum Einstampfen dieses Geschäftszweiges.
Nokia besteht jetzt im Wesentlichen aus zwei Bereichen, die inhaltlich und geschäftlich nichts miteinander zu tun haben: here und NSN. Here sieht sich als globaler Player im Markt der Maps und Location Based Services. Den Beweis dafür muss es jetzt relativ schnell erbringen. Dabei ist vollkommen unklar, wie ein solcher Beweis aussehen könnte. Als einzige mobile Plattform bleibt auch in Zukunft Windows Phone, Weder Android noch iOS benötigen eine konkurrierende (und noch schlechtere) Map-Anwendung.
Das grade wieder komplett übernommene Nokia Siemens Network Nokia Solutions and Networks hat es in den bestehenden sechs Jahren nicht geschafft, profitabel zu arbeiten. Zu groß ist inzwischen die Konkurrenz aus China mit Huawei. Darunter leidet ebenfalls seit mehreren Jahren Ericsson.
Aber vielleicht flüchten ja viele Anleger einfach nur von Microsoft zu Nokia. Denn MSFT hat im vorbörslichen Handel bis jetzt rund 13 Mrd.$ verloren. Und das ist die Summe aus dem Kaufpreis und dem Kursanstieg von Nokia. Offensichtlich hat sich Microsoft da ein faules Ei gelegt und Steve Ballmer zum wiederholten Male eine grandiose Fehleinschätzung abgeliefert.
Der Rücktritt von Elop vom Vorstandsvorsitzenden wird begründet mit der Aussage, dass so eine saubere Übernahme gewährleistet werden soll. Das ist insofern erstaunlich als dass ja jemand der einen Deal einfädelt auch in der Lage und unvoreingenommen genug sein sollte, einen solchen Deal auch zu finishen. Aber offensichtlich wurde dabei schon ein späterer Schritt berücksichtigt, der der Öffentlichkeit bisher noch vorenthalten werden soll: Elop kommt auf eine hohe, wenn nicht auf die höchste Position bei Microsoft. Wenn sich dabei mal nicht mindestens Elop selbst (mal wieder) verrechnet hat.
sshuttle – VPN für jedermann
Für MacOS und Linux gibt es ein kleines Tool, dass sich als VPN einsetzen lässt: sshuttle. Ziel des Pakets ist das verschlüsselte Tunneln aller Netzaktivitäten von einem lokalen Rechner (oder Router) zu einem entfernten Server. Dieser kann beispielsweise ein ganz normaler virtueller oder dedicated Server bei einem Hoster der Wahl sein. Im Ergebnis sieht ein an dem Netz lauschender Dritter nur einen verschlüsselten Stream. Um die “Meta”-Daten abzugreifen (http-GET, Referrer, Logins, etc.) müsste erheblich mehr Aufwand getrieben werden, der im Einzelfall gerechtfertigt sein möge, aber für die Massenspreicherung wohl nicht sinnvoll ist.
Insbesondere für den Feldeinsatz in Cafés oder anderen fremden Netzen empfiehlt sich der Einsatz von shuttle. Alle typischen Angriffe, die von Passwort-Sniffing bis zum Cookie-Stealing reichen können damit effektiv unterbunden werden.
Voraussetzung ist ein Server mit ssh-Zugang (Root-Rechte sind dort nicht notwendig) im Netz. Von dem lokalen Rechner bis zu diesem wird der gesamte Netzwerktraffic getunnelt. Im Prinzip kann sshuttle auch auf einem Router installiert werden. Dann würde der gesamte Traffic aller angeschlossenen Devices getunnelt werden. Derzeit scheint es allerdings noch nicht gelungen zu sein, sshuttle auf dem freien OpenWRT zu betreiben. Versuche mit einem BeagleBone Black und einem Raspberry Pi verliefen erfolgreich, wenn auch letzteres zumindest unter Debian zu langsam ist. Beide würden sich als mobile SSH-Router für Windows-Nutzer anbieten.
Apples Problem ist die Kundenzufriedenheit und das ist auch gut so.
Die letzten Apple-Zahlen haben offensichtlich wieder einmal Analysten verunsichert. Zwar hat Apple deren Erwartungen übertroffen, aber nur was den Ertrag angeht. Bauchschmerzen macht ihnen die Tatsache, dass Apple so viele alte Geräte verkauft. Mit dem iPhone 4 und 4S hat Apple zwei Geräte im Regal, die auch nach zwei und drei Jahren noch in erheblichen Stückzahlen verkauft werden. Aus Sicht der Analysten ist das ein unhaltbarer Zustand. Denn: Apple ist eine starke Marke und solche Marken sollten in einer Branche wie der von Apple Verbrauchsgüter verkaufen und den Markt künstlich verknappen, um den Preis künstlich hochzuhalten.
Apple verhält sich an dieser Stelle jedoch anders als alle Wettbewerber. Für diese ist ein verkauftes Gerät ein Ärgernis. Es gibt keine Updates, keine Reparatursets und kaum Garantieleistungen. Für HTC, Samsung und ZTE sind Bestandskunden ein Problem. Sie verdienen ihr Geld nicht mit Wiederholungstätern sondern mit Neukunden, die sich enttäuscht von Konkurrenzerzeugnissen abwenden. Vom Regen in die Traufe.
Mein iPhone 4S würde ich erst ersetzen, wenn es das gleiche Modell mit LTE gäbe oder vielleicht mit erheblich längerer Batterielaufzeit. Da beides sicher nicht passiert, werde ich das Gerät wohl so lange benutzen, wie es funktioniert und/oder die Netzbetreiber 3G abschalten.
Apples Pläne mit dem Ex-Adobe-CTO Kevin Lynch
Der Schock war groß bei den Apple-Kennern. Der Adobe-Manager, der am lautesten Apples Politik in Sachen Flash kritisiert und für falsch erklärt hat soll in Zukunft die technische Zukunft Apples mitbestimmen? Das kann doch nur ein schlechter Scherz sein. Vielleicht noch ein strategischer Zug, um Flash den endgültigen Todesstoß zu geben. Als ob es das noch bräuchte!
Worauf deutet die Personalie wirklich hin?
Apple hat wie immer wenig bis gar nichts zu den Motiven gesagt. Schaut man sich die bekannten Fakten an, ergeben sich jedoch neue Perspektiven.
Kevin Lynch (hier seine Vita) ist ein eingefleischter Mac-Fan. In seiner Vita finden sich etliche Berührungspunkte mit Apples Geschichte. So war er unter anderem an der Entwicklung und Portierung von FrameMaker für den Mac beteiligt. Bei Macromedia hatte er mit Phil Schiller zusammengearbeitet. Als Adobe-CTO war er maßgeblich verantwortlich für die Migration des Businessmodells von der Lizenz zur Cloud. Gerade die Cloud-Dienste sind bei Apple eine schwelende Wunde.
Die Hauptaufgabe von Lynch bestand jedoch darin, die Virtuelle Maschine namens Flash auf alle möglichen Geräte, CPUs und Betriebssysteme zu bringen. Adobe versprach sich von einer möglichst flächendeckenden Verbreitung sprudelnde Einnahmequellen in der Zukunft zum Beispiel von Lizenzgebühren aus dem Rechtemanagement von Filmen im Netz. Laut eigener Aussage hätte er allerdings gerne schon früher Flash durch HTML ersetzt, meinte jedoch, dass dies nicht gelänge.
Kevin Lynch wird zukünftig direkt an Bob Mansfield reporten. Dieser ist Chef einer nicht näher spezifizierten Abteilung für zukünftige Technologien. Und Bob Mansfield ist Apples Mann für die Hardware.
Könnte Apple eine JavaScript-VM-CPU planen?
Apple hat in den letzten Jahren mehrere CPU-Schmieden eingekauft. Inzwischen entwickeln sie ihre eigenen ARM-Layouts als SoC für iPhone und iPad. Laut etlicher Quellen gibt es schon länger Referenzdesigns für ein MacBook Air mit einem ARM-Prozessor.
Dieses Know How über Prozessor-Design und Produktion zusammen mit dem Wissen von Lynch über Virtuelle Maschinen für Flash würde es Apple ermöglichen einen neuen Co-Prozessor zu entwickeln: eine JavaScript-CPU.
Der Computer eines Normalanwenders verbringt heute einen großen Teil seiner Zeit mit dem Verarbeiten von JavaScript. Zukünftig wird dieser Anteil noch höher werden. Dies allein schon dadurch, dass eher mehr als weniger verschiedene Plattformen bei Smartphones, Tablets, Fernsehern und Computern zu erwarten sind.
Die Versuche, JavaScript zu beschleunigen sind mit der aktuellen Entwicklung von asm.js jetzt an ihr natürliches Ende gelangt. Das gilt allerdings nur, wenn man sich die Möglichkeiten von Software ansieht. Der nächste logische Schritt ist eine Hardwareunterstützung der VM.
JavaScript ist auf Grund seiner extrem einfachen Struktur hervorragend geeignet, in Hardware gegossen zu werden. Wenige Typen, eine simple Statemaschine, Single Threads und Sandboxing sind ideale Voraussetzungen für einen kleinen Core mit Anbindung an den Haupt- und Grafikspeicher.
Sprachspezifische CPUs gab und gibt es immer wieder. Nicht zuletzt lässt sich ein solches Projekt sogar mit herkömmlicher FPGA-Technik umsetzen. Für Java gab es beispielsweise Ansätze von Sun selbst oder die Open-Source-Variante JOP, ein optimiertes Java auf einem FPGA-Chip.
Chancen am Markt
Für Apple hätte ein solcher Schritt viel Charme. Auf drei wichtigen Geräteklassen (iPhone, iPad und ARM-MacBook) würde JavaScript ohne Anpassung durch die Entwickler plötzlich Dimensionen schneller laufen. Und zwar auch erheblich schneller als auf vergleichbaren Geräten der Android und Chromebook-Konkurrenz. App-Entwickler würden noch häufiger lieber zu Webkit und JavaScript greifen als zu nativer Programmierung.
Viel wichtiger als die Performance wäre jedoch der Gewinn bei der Batterielaufzeit der Geräte. Zwei Tage bei einem iPhone und 12h bei einem MacBook wären durchaus im Rahmen des Möglichen.
Damit hätte Apple zwei Verkaufsargumente, die in einem engen Markt wichtig sind. Zumal die Konkurrenz Jahre bräuchte, um auf den gleichen Stand zu kommen, wenn sie es denn – ob restriktiver Patentauslegung – überhaupt könnte.