UNIXwork

Kürzlich erschien auf Golem ein Artikel über Webassembly, und in den Kommentaren dazu ist mir aufgefallen, dass viele auf Grund von falschen Vorstellungen eine Ablehnung gegen WASM haben.

Bei Bytecode denken viele offenbar an Java, und im Context eines Browsers erinnern sich einige sicherlich an Java-Applets. Auch das ungeliebte Flash nutzt Bytecode. Also warum will man sowas jetzt standardmäßig im Browser integriert haben?

Dabei ist der Vergleich völlig unpassend. Javascript und Flash (oder Java-Applets) sind völlig unterschiedliche Dinge. Flash hat seine ganz eigene Runtime, seine ganz eigene Version einer Sandbox und bietet auch ganz andere Möglichkeiten als Javascript.

Webassembly hingegen ist quasi nur Javascript, nur nicht in Textform, sondern in einer für Menschen eher unlesbaren Binärform. Beides wird in der gleichen Runtime ausgeführt. Alles was Webassembly kann, geht auch mit Javascript. Somit gibt es auch wenig neue Angriffsfläche.

Wer also wirklich kein Webassembly will, sollte dann auch gleich Javascript ausmachen. Kann ich auch nachvollziehen, wieso man kein Javascript will, denn der exzessive Gebrauch davon verbrennt massiv viel CPU-Leistung. Viel zu viele Webentwickler übertreiben es leider damit.

Trotz Allem möchte man natürlich nicht auf dynamischen Webcontent verzichten. Und dafür muss man nunmal Javascript nutzen. Das Problem mit Javascript ist, dass es die schlechteste Programmiersprache ist, die ernsthaft von Leuten verwendet wird. Davon wegzukommen halte ich für ein absolut erstrebenswertes Ziel. Dass man die Wahl hat, für Webentwicklung eine gut durchdachte Programmiersprache zu wählen, kann also nicht schlecht sein.

Sidenote: Ich habe schon zwei Computer wegschmeißen müssen (sprich: bei ebay verkauft), weil diese zu langsam zum Surfen waren. Für alles andere hätten diese noch locker gereicht. Einer dieser Computer war eine HP Z600 Workstation, und diese hatte mit ihren zwei Quadcore-Xeons sogar mehr Rechenleistung als ich jetzt habe. Es gab allerdings noch andere Gründe für einen Wechsel der Hardware.

Ein kleines Update für dav, welches 3 Probleme behebt.

HTTP-Redirects wurden nur unzureichend unterstützt, denn sie funktionierten nur mit einfachen GET-Requests richtig. Jetzt werden bei allen Methoden Redirects richtig behandelt.

Des Weiteren wurde die Kompatiblität mit älteren libcurl-Versionen verbessert. Statt libcurl 7.32 reicht jetzt auch die Version 7.18. Somit lässt sich dav problemlos auch auf älteren Distributionen kompilieren.

Aus Kompatiblitätsgründen werden von dav-sync jetzt Dateien nicht mehr mit Chunked Transfer-Encoding geuploadet, sondern die PUT-Requests enthalten einen Content-Lengh Header. Mit schlecht konfigurierten oder verbuggten Webservern im Zusammenspiel mit php gab es da bisher ein paar Probleme.

dav Projektseite SourceForge Projektseite

Versucht man eine VirtualBox-VM auf einem Solaris 11.4 Host zu starten, verursacht dies eventuell einen Panic. Wenn dies geschieht, dann ist die Ursache laut Release-Notes die Supervisor Mode Access Prevention. Diese kann man aber deaktivieren, und dann funktioniert VirtualBox auch.

$ sxadm disable smap
$ reboot

Und womit macht ihr so eure Präsentationen? Powerpoint, Impress oder LaTeX? Wieso nicht mit Glade, das Klickibunti-Tool um GTK-Interfaces zusammenzubasteln. Ein paar Slides, oder ein GUI, wo ist da der Unterschied.

Die spannende Frage ist, ob man dann irgendwann mit Powerpoint GUI-Anwendungen designen kann. Das wäre doch der absolute Durchbruch. Direkt aus einer Bullshit-Präsentation eine App generieren.

Aber mal ernsthaft, egal womit man seine Präsentation erstellt, ich bin der Meinung, dass das Ausgabeformat immer pdf sein sollte. Das maximiert zum einen die Wahrscheinlichkeit, dass man es auf jedem Gerät fehlerfrei anzeigen kann, zum anderen kommt man gar nicht erst in die Versuchung mit Animationen zu arbeiten.

Die neue Armv8.5-A Architektur hat ein sehr interessantes neues Feature, nämlich Memory Tagging. Ein großer Teil heutiger Sicherheitslücken in Software ist auf Memory-Access-Fehler zurückzuführen, verursacht beispielsweise durch Bufferoverflows oder Use-after-free.

Memory Tagging soll dem entgegen wirken, indem Speicherbereichen und den dazugehörigen Pointern Tags zugeordnet werden. Nur wenn der Tag des Pointers dem des Speicherbereichs entspricht wird der Speicherzugriff gestattet.

Die Idee ist nicht neu, die SPARC M7 CPU hat das ähnliche Feature Silicon Secured Memory.

Jetzt gibt es natürlich auch Software-Profiling-Tools, die auch Speicherzugriffsfehler erkennen können, jedoch können die Programme damit schon mal 100 mal langsamer laufen. Mit Memory Tagging hingegen hat man praktisch keinen Performanceverlust und damit kann dies auch bei Software im Produktiveinsatz verwendet werden.

Insgesammt also ein sehr interessantes Feature, das hoffentlich auch von Intel und AMD eingeführt wird. Wer auch immer dies zuerst anbietet, könnte auf dem Servermarkt einen deutlichen Pluspunkt sammeln.