programmierer-nachrichten.de:
News für Programmierer

programmierer-nachrichten.de

direkt aus dem Technologiezentrum Bottrop
Startseite Podcast RSS Archiv Impressum

Schneller Scala Compiler von Twitter


Twitter hat nach eigenen Angaben damit begonnen einen Scala Compiler zu entwickeln, der als Ziel hat deutlich schneller zu sein als der originale. Sie nennen das Projekt "Reasonable Scala" und stellen es auf GitHub zur Verfügung. Bis jetzt gibt es aber noch nicht viel zu sehen.

Reasonable Scala wird nur eine bestimmte Untermenge der Scala Sprachfeatures unterstützen. Streng genommen ist es somit kein "Scala Compiler" mehr, aber deswegen nennen sie es auch "Reasonable Scala".

Aktuell steht der Quellcode der Software noch nicht zur Verfügung. Man verspricht aber, dass in naher Zukunft damit zu rechnen sei.


Oracle gibt Java EE Verantwortung ab


Oracle plant Java EE einer OpenSource Stiftung zu übergeben, mit dem Ziel den Entwicklungsprozess von Java EE zukünftig agil durchzuführen. Sie wollen die Lizenzierungsmodelle flexibler gestalten und sie möchten schneller auf Nachfragen und Anforderungen der Industrie reagieren. Redhat und andere Firmen begrüßen diesen Schritt sehr.

Effektiv bedeutet dies, dass Oracle die Verantwortung und Führung von Java EE an andere Firmen und Menschen abgeben möchte. Man könnte auf den ersten Blick meinen sie würden Java EE aufgeben; das ist aber Unsinn. Sie fühlen sich nur nicht mehr in der Lage entsprechend schnell auf die Bedürfnisse der Industrie zu reagieren. Und offensichtlich ist Oracle auch einfach nicht mehr bereit Java EE zu unterstützen. Letztes Jahr wurde bekannt, dass Oracle die finanzielle Unterstützung für Java EE zurückgefahren hat. Auch wurde bekannt, dass Oracle Programmierer von dem Projekt abgezogen hat und anwies an anderen Projekten zu arbeiten. Ein ganz interessanter Bericht dazu wurde letztes Jahr auf arstechnica.com veröffentlicht.

In Anbetracht der Fakten und der Geschichte von Oracle ist diese Nachricht für die Java EE Community die Beste seit langem.


Podcast Folge 26


Wie versprochen der wöchentliche Podcast!

In dieser Folge also folgende Themen:

Viel Spaß mit dieser Folge!


Ist Atom wirklich so fett?


Im Netz hatte sich jemand darüber aufgeregt, dass der Atom Editor so viel Arbeitsspeicher verbraucht. Nun soll die aktuelle Version 1.19 aber mit viel weniger auskommen. Das war Anlass für mich das doch mal zu überprüfen.

Für den Test habe ich mir ein Tool, "xmlgen", von http://www.xml-benchmark.org/downloads.html runtergeladen und eine ca. 100MB große "test.xml" damit erzeugt (./xmlgen -f 0.89 > test.xml).

Atom scheint bei einer derart großen Datei überfordert zu sein. Beim öffnen der Datei warnt es mich und fragt, ob ich die Datei wirklich öffnen möchte. Natürlich möchte ich das! Die Datei wird anscheinend angezeigt, man kann auch scrollen. Was fehlt ist die Farbe; das deaktiviert Atom bei so großen Dateien. Auch kann man nicht bis zum Ende der Datei scrollen. Atom wird beim Scrollen immer langsamer und bevor man bis an das Ende der Datei angekommen ist, scheint es einzufrieren. In diesem Zustand gibt es sogar Darstellungsfehler, so dass auf einmal der halbe Editor "leer" ist.

Atom hat bei diesem Versuch aber nie mehr als 596 MB Ram verbraucht. Das scheint offensichtlich das "hard"-Limit zu sein.

Neugierig, wie sich andere Editoren schlagen, testete ich "nano", "vim", "emacs", "joe" und "sublime_text 3".

"nano" öffnet die Datei ohne Probleme, zeigt auch Farben an und man kann das Ende der Datei erreichen. "nano" nutzte maximal 396MB Ram. Getestet hatte ich Version 2.8.4.

"vim" öffnet die Datei viel schneller als "nano" und zeigt auch Farben an. Auch kann man in "vim" das Ende der Datei erreichen. "vim" nutzte maximal 278MB Ram. Getestet hatte ich Version 8.0.

"emacs" verhält sich wie Atom 1.19. Beim Öffnen der "test.xml" fragt es mich, ob ich die Datei wirklich öffnen will, da sie sehr groß ist. Wenn ich das mit "ja" beantworte, zeigt es die Datei gar nicht erst an. Es passiert einfach nichts. "emacs" hat dafür maximal 569MB Ram benötigt. Getestet hatte ich Version 25.2.1.

Mein Lieblingseditor "joe" konnte die Testdatei problemlos öffnen; langsamer als "vim", aber dafür ohne Farben. Das Navigieren in der Datei funktioniert problemlos. "joe" nutzte maximal 68MB Ram. Getestet hatte ich "joe" in Version 4.4.

"sublime_text" brauchte sehr lange, um die Datei zu öffnen, aber stellte sie dann sehr gut und flüssig auch in Farbe dar. Das Navigieren innerhalb der Datei war kein Problem und funktionierte sehr gut. "sublime_text" nutzte maximal 486MB Ram. Getestet hatte ich die aktuellste Version 3.

Ist dieser Vergleich sinnvoll? Bestimmt nicht. Interessant? Vielleicht. Mich persönlich hat überrascht, dass "nano" in Relation zu "vim" so viel Ram benötigt. Dass "emacs" so viel Ram in Anspruch nimmt, ohne die Datei überhaupt anzuzeigen, hatte mich schlecht gestimmt. Und dass "joe" so wenig Ram benötigt, liegt einfach daran, dass es erst gar nicht versucht den Inhalt einzufärben (Syntax Highlighting). Bei kleineren XML-Dateien färbt "joe" den Text sehr wohl ein ;). Hier wird also etwas getrickst. Bei "nano" und "vim" kann man das aber auch ausschalten.

Man muss also immer das richtige Tool für den Job benutzen und wenn ich riesige Logs anschauen will, nehme ich nicht "emacs" oder "atom". So einfach ist letztendlich.

Möge dein Editor mit dir sein!


Talos II Workstation


Raptor Computing Systems hat nun endlich die angekündigte Workstation Talos II zum Vorverkauf angeboten. Talos II ist eine auf Power9 basierte Workstation mit völlig offener Hardware. Das System basiert auf OpenPower und garantiert völlige Offenheit auf Hardwareebene.

Die Workstation kostet in der empfohlenen Konfiguration $6,350.00. Wenn man sich nur das Mainboard kaufen möchte, muss man $2,300.00 mit Single-CPU und $2,750.00 mit Dual-CPU bezahlen.

Talos II ist kompatibel mit Linux.


Clojure zu C++


Clojure ist ja eigentlich eine typische JVM Sprache, aber mit Ferret gibt es nun auch einen Clojure Transpiler, der Clojure Code zu C++11 Code transpiliert.

Mit Ferret ist es möglich Clojure Programme zu schreiben, die auch auf embedded Systemen laufen, die nur 2KB Ram haben. Das ist mit einer JVM nur schwer möglich. Man braucht dafür lediglich einen C++11 kompatiblem Compiler.

Genau diese Lücke will Ferret füllen. Es gibt zwar bereits andere Lisps und Schemes, die zu nativem C Code transpilieren, aber je mehr Optionen es gibt, desto besser ist es. Schließlich ist nichts perfekt und eine Wahl zu haben war noch nie falsch.


AMD Ryzen immer noch kaputt!


Es gab zur Einführung der neuen Ryzen CPUs von AMD einige Berichte aus der Haskell Community, dass beim Kompilieren Segfaults nur mit der neuen AMD Ryzen CPU entstehen. Viele Menschen waren sich schnell einig, dass diese Menschen übertaktete Systeme nutzen und der Fehler nur deswegen entstanden ist. Andere Menschen waren sich aber nicht so sicher.

Nun gibt es erneut Berichte darüber, dass AMDs Ryzen Prozessoren in bestimmten Situationen Probleme verursachen. Bestimmte Nutzergruppen konnten eine Situation herbeiführen, welche den Fehler mehr oder weniger zuverlässig reproduzieren lässt.

AMD hat den Fehler bestätigt und arbeitet an einer Lösung.


Podcast Folge 25


Wie versprochen der wöchentliche Podcast!

In dieser Folge also folgende Themen:

Viel Spaß mit dieser Folge!


Debian Pakete sind zu 94% reproduzierbar


Das Debian Projekt arbeitet seit einiger Zeit daran Pakete reproduzierbar zu bauen. Wenn ein Paket auf Rechner A und B gebaut wird, kann man auf beiden Rechnern eine Prüfsumme des fertiggestellten Pakets erzeugen und sie wird identisch sein.

Den aktuellen Status dazu kann man sich hier ansehen; aktuell sind 94% aller Debian Pakete reproduzierbar zu bauen.

Aber wozu soll das gut sein? Nehmen wir an ich bin der Programmierer einer bekannten OpenSource Software. Ich stelle den Quellcode öffentlich zur Verfügung. Jeder kann sich den Quellcode anschauen und überprüfen. Ich stelle neben dem Quellcode aber auch Binärpakete zur Verfügung, damit es der Nutzer einfacher hat. Dieses Paket hat eine bestimmte Prüfsumme. Um dieses Binärpaket zu bauen, hätte ich aber auch einen modifizierten Quellcode nutzen können, welcher Funktionalitäten enthält, die man im öffentlich verfügbaren Quellcode nicht findet. Wenn nun jemand meine Glaubwürdigkeit in Frage stellt, kann er sich den öffentlich verfügbaren Quellcode runterladen und meine Software kompilieren oder auch "bauen". Würde er eine Prüfsumme des Binärpakets erstellen, so würde sie sich von meiner unterscheiden. Das ist bisher das normale Verhalten, weil nur eine minimale Änderung beim Kompilieren reicht, um das Resultat zu verändern. Wenn ich als dieser OpenSource Programmierer aber behaupte, dass mein Paket reproduzierbar ist, so kann jeder mein Paket selber bauen, um zu verifizieren, dass mein binäres Paket auch wirklich das ist, was ich behaupte, denn es wird bei jedem Kompilat immer die gleiche Prüfsumme sein.

Das klingt langweilig, ist aber tatsächlich sehr interessant und sehr wichtig, vor allem, weil immer mehr OpenSource Programmierer vergessen haben was Anstand ist.

Es gibt auch eine Informationsseite für reproduzierbare Builds.


Ring UI nun OpenSource


Ring UI ist eine Sammlung einfacher und komplexer UI Komponenten für React. Es handelt sich dabei um ein Projekt der Firma JetBrains und sie arbeiten schon viele Jahre daran. JetBrains nutzt die Bibliothek für andere Projekte wie YouTrack, Hub, Upsource und vielen anderen.

JetBrains hat ihre eigene Bibliothek Ring UI nun unter eine OpenSource Lizenz gestellt. Ring UI ist auf GitHub verfügbar.

Bestandteil von Ring UI sind viele Widgets, wie zum Beispiel ein DatePicker, ein Table Widget, Grids, Buttons, DropDowns, ComboBoxes und viele mehr. Schau einfach selber mal und klick dich durch, wenn du dich dafür interessierst.


Nim in Action ist fertig!


Ich bin ja ein heimlicher Fan der Programmiersprache Nim, und so hatte ich vor ca. einem Jahr das Buch Nim in Action vorbestellt. Nun ist es fertig!

Dominik Picheta ist nicht nur ein netter Mensch, sondern auch ein sehr aktives Mitglied der Nim Community. Er experimentiert sogar mit Nim und Betriebssystementwicklung. Und dennoch hatte er die Zeit gefunden ein Buch über Nim zu schreiben.

Gratulation!

Nim beschreibt sich selbst mit folgenden Worten:

Nim is a systems and applications programming language. Statically typed and compiled, it provides unparalleled performance in an elegant package.

Nim kann man auch ganz gut einsetzen, um relativ unabhängige Binaries zu erzeugen. Ich hatte darüber mal berichtet. Wenn es dich neugierig gemacht hat, schau dir Nim am besten einfach mal an.


JetBrains arbeitet an Rust Plugin


JetBrains hat verkündet, dass sie an einem OpenSource Rust Plugin für ihre IDEs arbeiten. Man wird also in naher Zukunft Rust mit IntelliJ, CLion und anderen JetBrains IDEs entwickeln können.

Das Plugin ist schon recht weit fortgeschritten. Auf der Projektseite kann man sich auch informieren, wie man es installiert. Gut finde ich, dass IntelliJ IDEA Community Edition OpenSource ist. Man kann also die kostenlose Community Version von IntelliJ IDEA mit diesem Rust Plugin nutzen.


Hy Lisp


Nicht unbedingt neu, aber erwähnenswert ist die Hy Programmiersprache. Hy ist ein Lisp Dialekt und transformiert Lisp Code zum Python Abstract Syntax Tree. Das ermöglicht das komplette Python Ökosystem in Hy zu nutzen.

Hy gibt es schon seit dem 9. Dezember 2012 und wird seit dem ständig weiterentwickelt. Hy ist außerdem extrem gut dokumentiert. Man hat sofort das Gefühl, dass sich hier jemand sehr viel Mühe gegeben hat. Hy ist aber keine One-Man Show. Hy wurde von 100 Programmierern entwickelt und die letzte Version, 0.13.0, wurde am 20. Juni veröffentlicht.


Sicherheitsrisiko: Extensions


Es ist selbstverständlich, dass man gewisse Programme mit Extensions in ihrem Funktionsumfang erweitern kann; deswegen der Name: Extension / Erweiterung. Die Programme stellen in der Regel großzügige Schnittstellen bereit, damit diese Erweiterungen auch etwas Sinnvolles machen können.

Und bis vor kurzem konnte man daran auch nichts Schlechtes finden, denn jeder Programmierer, der eine Erweiterung für ein Programm entwickelt, macht das meistens, weil er die Funktionalität selber benötigt. Das ist zumindest der optimalste Fall, da man sich dann sicher sein kann, dass die Erweiterung auch wirklich funktioniert und keinen Unsinn treibt.

Leider zeigten etliche Berichte, dass man im Grunde jeder Erweiterung, die man installieren möchte, vorher überprüfen muss.

kite.com hat bei diversen Atom Erweiterungen Werbung für ihr Startup integriert und damit das Vertrauen der Nutzer missbraucht. Siehe Atom Minimap Werbung.

Ein node.js Plugin liest Umgebungsvariablen und sendet sie via HTTP an einen entfernten Server (siehe hier). Um zu verstehen, wieso das brisant ist: man empfiehlt in vielen Situationen Zugangs- und andere wichtige Daten via Umgebungsvariablen der Applikation zur Verfügung zu stellen. So kann man relativ flexibel Entwicklungs- und Produktivsysteme gleich "aufsetzen". Und genau darauf zielt dieser Dreck eben ab.

Eine Erweiterung für Chrome, "Web Developer", wurde manipuliert und injizierte Werbung bei den Seiten, die der Nutzer besuchte.

Und auch vor Sublime hat kite.com keinen Halt gemacht, denn eine der top Erweiterungen von Sublime Text sendet Telemetriedaten an kite.com. Schau es dir hier an.

Und auch in aktuellen Webbrowsern können Erweiterungen eine Menge Daten sammeln, ohne dass der Nutzer es bemerkt. Ich selber hatte mal eine Erweiterung für Firefox entwickelt, die JavaScript Code im Kontext der Erweiterung nachladen konnte. Zwar über einigen Umwegen, aber es ging. Ich hatte keine bösen Absichten, aber jemand, der eine legitime Erweiterung um "böse" Funktionalitäten erweitern will, kann das auch heute noch tun. Deswegen begrüße ich die Einigung des WebExtensions Standard, auch wenn viele Oldschool Firefox User das nicht mögen, da es den einzigen Vorteil von Firefox entfernt: den Webbrowser extrem verändern.

Im Grunde spricht auch nichts dagegen, dass ein Programm viele Schnittstellen bietet, um die Funktionalitäten zu verändern oder erweitern. In der Vergangenheit war das auch gefühlt nie ein Problem. Mittlerweile wird sowas aber immer öfter ausgenutzt. Und ich kann irgendwie nachvollziehen, wieso der Everyday-Joe auf einmal Gefallen an Windows 10S findet, obwohl das eigentlich keine gute Entwicklung ist.

Aber auch Windows 10S würde daran wenig ändern, denn Edge unterstützt ja mittlerweile auch Erweiterungen. Anfang des Jahres war das noch nicht der Fall. Somit könnte man auch in Edge Erweiterungen installieren, die das Vertrauen des Benutzers ausnutzen.

Als kite.com einige Atom Erweiterungen "infiziert" hatte, wurde darüber diskutiert, ob es Sinn macht nicht einen Adblocker für Erweiterungen zu haben. Die Idee ist total krank! Aber sie ist nicht so dumm! Im Grunde sollte es aber nicht so einfach sein eine Erweiterung zu veröffentlichen. Bei Apple werden App Submissions relativ "streng" kontrolliert. Bei Google wird zwar rein gar nichts geprüft, aber hinterher werden immer viele Apps gelöscht, wenn Benutzer sie gemeldet haben.

Deswegen finde ich, dass man als Programmierer einer wichtigen und beliebten Anwendung nur Erweiterungen zulassen sollte, wenn man sicherstellen kann, dass sie keinen Unsinn treiben. Heute sind ja Portale "hip", wo man seine Erweiterungen finden und installieren kann. Der Zugang zu diesen zentralen Portalen ist aber sehr einfach. Im Falle von "npm" kann jedes Scriptkiddie innerhalb weniger Minuten einen Trojaner zur Verfügung stellen. Wer mir nicht glaubt, dem beweise ich gerne das Gegenteil; natürlich mit einem harmlosen Virus, der nichts kaputt macht.

Man sorgt also entweder dafür, dass diese Portale die übermittelten Erweiterungen entweder besser prüfen oder aber, dass das Programm nur begrenzte Schnittstellen zur Verfügung stellt, so dass erst gar kein Unsinn mit dem Nutzer getrieben werden kann.

Dass man sich heute aber bei einem Editor Gedanken darüber machen muss, dass sein Quellcode eventuell irgendwo in der Cloud landet, ist schon übel...

Und weil "deki" aus dem IRC so geil ist, hat er einen Beitrag verlinkt, der "leichte" Zweifel an allem aufkommen lassen. Aber schau selber.

:(!


Podcast Folge 24


Wie versprochen der wöchentliche Podcast!

In dieser Folge also folgende Themen:

Viel Spaß mit dieser Folge!


PHP 7.2 wird noch schneller


Michael Larabel hat die neueste PHP 7.2 Beta unter die Lupe genommen und dabei festgestellt, dass PHP 7.2 Beta noch mal deutlich schneller ist als PHP 7.1.x.

In seinem Benchmark kann man sich einige interessante Grafiken ansehen, um sich selbst davon zu überzeugen, wie viel schneller PHP 7.2 sein wird. Erschreckend sind die Vergleiche mit PHP 5.6.x.

Trotzdem ist es eigenwillig, dass PHP als Skript und/oder Programmiersprache immer besser wird, aber gleichzeitig konstant an Beliebtheit verliert.

Mein persönlicher Eindruck ist der, dass man hier im Ruhrgebiet ein sehr hohes Angebot an PHP Jobs hat. Wenn man also PHP beherrscht, bekommt man hier im Ruhrgebiet immer einen Job. Meine Erfahrung sagt mir aber auch, dass die wenigsten Firmen, würden sie heute neu gegründet werden, ein Projekt mit PHP starten würden. Es gibt sehr viele Bestandsprojekte, die in der Hochzeit von PHP entstanden sind. Und die Zeit, in der PHP sehr beliebt war, hat lange angehalten. Insofern wird man trotz der drastischen Verschlechterung der Beliebtheit vermutlich weiterhin Jobs mit PHP finden.

Würde man heute ein Projekt mit PHP beginnen, könnte man aber vermutlich die professionellsten und zuverlässigsten Zeilen Code schreiben, die mit vorigen PHP Versionen einfach nicht möglich gewesen wären. Dass man mit der aktuellen PHP Version eine hohe Geschwindigkeit erreichen kann, ist ein Bonus.


Gedit ohne Maintainer


Sébastien Wilmet, der ehemalige Maintainer von Gedit hat das Handtuch geschmissen. Gedit wird somit nicht länger aktiv weiterentwickelt.

Sébastien Wilmet arbeitet aktuell an Tepl und er wünscht sich, dass der zukünftige Maintainer von Gedit Tepl als Basis nutzt.

Er kritisiert außerdem, dass in vielen Projekten bei Gnome Funktionalitäten entwickelt werden, die man nicht als Bibliothek nutzen kann. Er erwähnt ganz konkret das Gnome-Builder Projekt, wo Features entwickelt wurden, die für einen Texteditor sehr hilfreich sind; in diesem Fall ein Vim-Mode. Er regt sich darüber auf, dass man sowas nicht als wiederverwendbare Bibliothek entwickelt. Er stört sich daran, dass Funktionalitäten immer und immer wieder neu implementiert werden, obwohl es sie schon gibt. Als negatives Beispiel zeigt er seinen eigenen Code; in Gedit hat er ca. 8000 Zeilen geschrieben, um Dateien zu schreiben und lesen und da ist noch keine Zeile Code für das UI enthalten.

Sébastien Wilmet möchte sich nun voll und ganz auf die Entwicklung von Tepl konzentrieren.


Paint bleibt!


Es wurde ja berichtet, dass Microsofts Paint in den nächsten Versionen von Windows 10 nicht mehr enthalten sein wird. Das entspricht zwar der Tatsache, jedoch hat Microsoft gestern verkündet, dass man Paint nicht aufgibt.

Paint wird zwar nicht mehr Bestandteil zukünftiger Windows Versionen sein, jedoch kann man es dann kostenlos aus dem Windows Store runterladen.

Der Hintergrund ist, dass man Paint 3D besonders hervorheben möchte. Tatsächlich bietet Paint 3D einiges mehr, aber aus Gewohnheit startet man vermutlich trotzdem "nur" Paint. Das will Microsoft wohl "korrigieren".

Wie auch immer; Paint bleibt!


Flash nun offiziell beerdigt!


Es ist soweit! Adobe hat endlich das Ende von Flash datiert. Ende 2020 wird nun offiziell das Ende von Flash sein.

Inoffiziell wurde Flash zwar schon vor einigen Jahren begraben, aber dass nun Adobe selbst ein konkretes EOL-Datum angibt, ist eine gute Sache.

Auf diese Nachricht stoße ich an!


Podcast Folge 23


Wie versprochen der wöchentliche Podcast!

In dieser Folge also folgende Themen:

Viel Spaß mit dieser Folge!


Startseite Podcast RSS Archiv Impressum