y0o.de · GNU/Linux Nachrichten u.Ä.

🔒
❌ Über y0o.de
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeVNotes

Ether durchbricht erstmals die 4.000 US-Dollar-Marke

10. Mai 2021 um 15:06

Für die zweitgrößte Kryptowährung Ether, die zum Ökosystem von Ethereum gehört, läuft es momentan richtig gut: ihr Preis durchbrach heute morgen um ca. 05:00 Uhr deutscher Zeit die 4.000 US-Dollar-Marke (umgerechnet 3.280 Euro) und erreicht somit das Allzeithoch.

Im Gegensatz zu Bitcoin ist Ethereum breiter aufgestellt und stellt mehr Möglichkeiten zur Anwendung in den Vordergrund: so ist dieses verteilte System für die Smart Contracts bekannt und wird auch gerne als „World Computer“ bezeichnet, da die Transaktionen auf allen Nodes aller Teilnehmer gemeinschaftlich verarbeitet werden. Bitcoin verfügt zwar auch über eine Scriptsprache, diese ist allerdings nicht Turing-vollständig. Die Ethereum VM, die über diese Eigenschaft verfügt, kann somit im theoretischen Sinne jedes berechenbare Problem lösen – wie die meisten üblichen Programmiersprachen. Auf der Etherum-Blockchain können somit klassische Computerprogramme laufen – sofern sie entsprechend portiert wurden.

Ether steht seit einigen Wochen mit Allzeithochs in den Schlagzeilen: so stieg die Kryptowährung vor 3 Monaten auf über 2.000 US-Dollar und passierte vor einer Woche die 3.000 USD-Marke.

Weitere aktuelle Daten liefert CoinMarketCap: momentan verfügt Ether über eine Marktkapitalisierung von 475 Milliarden US-Dollar. Das Handelsvolumen der letzten 24 Stunden bemisst sich gemäß der Quelle auf über 52 Milliarden US-Dollar. Während der Rivale Bitcoin die doppelte Marktkapitalisierung aufweist, verhält sich das Volumen in den letzten 24 Stunde ähnlich (zum Vergleich: BTC Volumen 60 Mrd. US-Dollar).

Wichtig in dem Zusammenhang ist auch der strukturelle Aufbau der Währung: Ether verfügt bisher über keine fixe, maximale Geldmenge, während Bitcoin bei etwa 21 Millionen BTC gedeckelt ist. Ein solches oberes Limit ist allerdings nicht zuletzt wegen Ethereum 2.0 im Gespräch, um bestimmten Effekten, darunter Inflation, entgegenzuwirken. Die Diskussion des am 01. April 2018 von Ethereum-Gründer Vitalik Buterin eingebrachten Vorschlags wird momentan im Rahmen des EIP-960 diskutiert. Als EIP (Ethereum Improvement Proposals) werden gemeinschaftliche Vorschläge bezeichnet, die die Verfahrensweise des Ethereum-Systems ändern können und als Maßgabe für alle Teilnehmer am System gelten. (ähnlich wie eine ISO-Norm oder eine Internet-RFC)

Die hohen Preise haben allerdings nicht nur Vorteile: da die Gebühren für Transaktionen weiterhin in Ether berechnet werden, werden Transaktionen auf Ethereum-Blockchain in US-Dollar oder Euro gemessen immer teurer. Abhilfe soll hier der EIP-1559 bringen: hiermit soll das Gebührensystem neu strukturiert werden, um die Gebühren faktisch zu senken. Dies ist vorteilhaft für die Nutzer und nachteilhaft für die Miner.

Ethereum stehen verschiedene Schlüsselereignisse bevor: so gehören Miner mit Ethereum 2.0 mehr und mehr der Geschichte an, da der Konsensalgorithmus von Proof of Work auf Proof of Stake umgestellt wird. Die Umstellung wird in diesem Jahr weiter vorangetrieben.

Auch außerhalb der Kryptowährungswelt richten sich die Augen mittlerweile auf Ethereum: so hat die Europäische Investitionsbank (EIB) vor knapp zwei Wochen bekannt gegeben, einen 120 Millionen US-Dollar-Bond aufzusetzen.

Kommentar

Die durchbrochenen Preismarken sind in meinen Augen besonders psychologisch wichtig und steigern die Akzeptanz des gesamten Systems. Es wird spannend zu sehen sein, wie sich Ethereum in den nächsten Monaten entwickelt. Besonders der Fakt mit den möglichen Anwendungen durch die Smart Contracts werden meiner Meinung ausschlaggebend für die Entwicklung sein.

Ich werde die nächste Zeit weiter in meinem Blog die technischen Entwicklungen erläutern und euch auf dem aktuellen Stand halten!

Weitere Informationen

Regulatorischer Hinweis / Haftungsausschluss

Dieser Artikel beschäftigt sich mit technischen Aspekten von Ethereum. Dieses Informationsangebot ist keine Anlageberatung. Die hier gegebenen persönlichen Einschätzungen stellen **keine Handlungsempfehlung**, keine Handlungsaufforderung und keinen Ersatz für eigene Recherche oder professionelle Beratung dar. Kryptowährungen sind hochriskant und können mindestens zum Totalverlust des Einsatzes führen.

Audacity, eine Übernahme und Telemetriefunktionen

08. Mai 2021 um 20:07

Audacity soll nach der Übernahme durch die Muse Group Telemetriefunktionen erhalten. Ein Kommentar über den Sinn und Unsinn solcher Funktionen, Diskussionen und Übernahmen von Open Source-Projekten.

Vor einigen Tagen ging die Meldung durch den Ticker, dass die Audiobearbeitungssoftware Audacity (Link zu audacityteam.org) durch Muse Group gekauft wurde. (LinuxNews und heise.de berichteten). Ich war über diese Meldung etwas überrascht, weil es etwas seltsam ist, ein OSS-Projekt zu „kaufen“. Die Software an sich ist GPLv2-lizenziert und ansonsten lässt sich lediglich eine US-Wortmarke finden. Ich konnte nicht einmal eine deutsche/europäische Marke hierzu ausfindig machen. Es geht bei dem Vorhaben der Muse Group sicherlich eher darum, den Einfluss auf die Entwicklung von Audacity auszubauen, um das eigene Produktportfolio zu erweitern.

Tantacrul hat diesbezüglich ein 15-minütiges Video zu seinen neuen Aufgaben erstellt, das auf YouTube verfügbar ist.

Es ist sehr zu begrüßen, dass ein Unternehmen die Mittel bereitstellt, eine Software wie Audacity weiterzuentwickeln. Ein Vorteil von kommerziell getriebener Entwicklung ist es, dass Leute dafür bezahlt werden, die unschöne, aber nötige Arbeit zu erledigen, um die Qualität beim Gesamtprodukt zu steigern. Auf der anderen Seite tauchen natürlich bei einer solchen „Übernahme“, die sich bei so einem Projekt immer noch ungewohnt anhört, Befürchtungen auf, dass Interessenkonflikte zu einer Strategieänderung bei der Entwicklung führen. Darüber hinaus ändert sich mitunter die Kultur der Entwicklung und die Gemeinschaft wird mit neuen Vorstellungen konfrontiert.

Dass es irgendwann Krach gibt, habe ich nicht ausgeschlossen. Dass es aber so schnell geht, hätte ich auch nicht gedacht. Am Dienstag, dem 04. Mai wurde ein Pull Request eröffnet, der den Namen „Basic telemetry for the Audacity“ trägt. Zum Zeitpunkt, an dem ich diesen Artikel hier schreibe, umfasst der Diskussionsthread schon über 850 Beiträge und wurde als „Draft“ zurückgestuft. Bei diesem offenbar kontrovers diskutierten Thema geht es darum, Audacity Telemetriefunktionen zu verpassen.

Ich könnte jetzt mit euch die konkreten Änderungen Stück für Stück auseinander nehmen, aber die dort verknüpften GitHub-Kommentare (besonders die Emojis) sprechen für sich. Alle, die einen C++-Hintergrund haben und CMake kennen, können sich die Implementierung zu Gemüte führen. Ich werde an geeigneter Stelle vereinzelt darauf eingehen.

Ein Glaubenskrieg

Telemetrie ist immer ein heikles Thema, besonders in der Open-Source-Welt. Hierbei geht es darum, die Nutzungsweise der Software an eine zentrale Stelle, dem Hersteller, zu melden, damit dieser Schlüsse daraus ziehen kann. Geht man noch einen Schritt weiter zurück, geht es darum, die Nutzung der Software messbar zu machen. Dies ist besonders im Management beliebt, da es Außenstehenden die Möglichkeit gibt, die Nutzung der Software zu analysieren und die Entwicklung zu regeln. Fragen wie „Entwickle ich an der richtigen Stelle?“, „Wollen die Nutzer das?“ oder „Haben wir genug Nutzer?“ sollen damit beantwortet werden.

In der vollen Ausbaustufe gleicht die Telemetrie einer Bildschirmaufnahme, bei der jeder Klick, jede Eingabe und jede Ausgabe an den Hersteller versendet werden. Das alles ist bei dem oben genannten Pull Request nicht der Fall, wie das Team nachdrücklich beteuert. Datenschutzrechtliche Aspekte lasse ich in dieser Betrachtung erst einmal außen vor, weil diese Diskussion das eigentliche Problem verschleiert.

Das Problem an diesem gesamten Umstand mit der Telemetrie ist, dass FOSS, also freie, offene Software, vom „mündigen Anwender“ ausgeht. Ich habe dieses Thema schon mal im Blog thematisiert. Dabei wird eine sehr aufgeklärte Weltanschauung vertreten: hat ein Anwender ein Problem, meldet er sich in einem Issue Tracker oder der Mailing Liste. Nur hat dieses Wunschdenken nichts mehr mit der Realität zu tun, vor allem, wenn die Zielgruppe nicht größtenteils aus Softwareentwicklern besteht, die diese Verfahrenswege kennen. Jetzt gibt es zwei Möglichkeiten: entweder auf das Feedback verzichten oder andere Wege finden, die Metriken zu erheben. Die Metriken sind zudem nur dann aussagekräftig, wenn sie eine repräsentative Nutzermenge abbilden - ergo: man müsste sie bei allen erzwingen.

Erschwerend kommt bei Audacity dazu, dass wir es hier mit einer Offline-Anwendung zu tun haben. Ist man es bei Webseiten gewohnt, dass die Inanspruchnahme von solchen zwangsläufig Verkehrsdaten erzeugt (seien es die Browserhistory, Logfiles auf dem Server, Analytics, o. ä.), so erwartet man bei lokaler Software nicht, dass diese „nach Hause telefoniert“. Zumindest früher.

Genau das soll bei Audacity jetzt allerdings passieren. Hierzu wurde extra die cURL-Bibliothek in den Source Tree eingefügt, was nebenbei noch eine komplett neue Abhängigkeit mit sich bringt. Diese Abhängigkeit wurde sogar sehr brachial hinzugefügt, wie aus dem diff hervorgeht, da während des Bauens sich Inhalte aus dem Git-Repository heruntergeladen werden sollen.

Die Telemetriedaten werden an ein zentrales Konto bei Google Analytics und Yandex geschickt.

FOSS-Prinzipein

Hier ergibt sich teilweise ein Bruch mit den üblichen FOSS-Prinzipien. Bei FOSS gibt man seinen Quelltext nicht frei, damit andere in diesem lediglich Lesen können, sondern, damit andere ihn in ihre Systeme integrieren können. Nutze ich z. B. den NetworkManager, der einen Connectivity Check durchführt, um zu erkennen, ob ich in das Internet komme, wird als Endpunkt meist ein von meinem Distributor bereitgestellter Server genutzt. Der Distributor ist es auch, dem ich mein ultimatives Vertrauen schenken muss, da dieser oft vorkompilierte Pakete bereitstellt. Ist ein Build nicht reproduzierbar, kann ich als Anwender nicht zweifelsfrei feststellen, ob lediglich die Inhalte ausgeführt werden, die auch angegeben sind. Unter diesem Aspekt ist der Umstand, dass der Distributor durch oben genannte Connectivity Checks meine IP-Adresse erfahren kann, fast zu vernachlässigen.

Freie Open Source Programme sind somit nur Bausteine, die von einem Intermediär aufbereitet und zur Verfügung gestellt werden. Somit sollte es aus meiner Sicht faktisch keinen Durchgriff von FOSS-Maintainern auf die Endnutzer geben, sofern nicht ein triftiger Grund dafür spricht.

Ein solcher triftiger Grund wären in meinen Augen Crashdumps: stürzt ein Programm ab, bieten einige Programme die Möglichkeit an, hilfreiche Daten zur Crash-Ursache (Tracebacks, Umgebungsvariablen, etc.) an die Hersteller zu melden. Oftmals wird dem Nutzer hier die Wahl gelassen, ob er diese Informationen mit den Entwicklern teilen möchte.

FOSS-Geschäftsmodelle

Freilich ist es schwierig, Geschäftsmodelle bei einer solch schwierigen Beziehung zwischen Softwarehersteller und -anwender zu etablieren. Dabei ist die „letzte Meile“ zwischen Distributor/OEM und Endkunden am attraktivsten, da dort Support verkauft werden kann. Beste Beispiele sind hier Red Hat und SUSE. Red Hat wurde für 34 Milliarden US-Dollar an IBM verkauft und der in Deutschland ansässigen SUSE GmbH steht am 19. Mai ein mit 5,7 Milliarden Euro bewerteter Börsengang bevor. Das bloße Schaffen und (entgeltliche) Zurverfügungstellen von Softwarequelltext und den Binaries wird heutzutage immer unattraktiver.

Fazit

Was Audacity angeht, bin ich optimistisch. Am Ende kann der Anwender nur gewinnen: entweder wird die Software verbessert oder es bildet sich ein Fork (wie schon geschehen), der die Nutzerschaft übernimmt.

Audacity ist eine Software, die ihren Zweck erfüllt. In meinen Augen kein Anwärter für Designauszeichnungen, aber plattformübergreifend und funktional.

Trotzdem muss man schauen, wie sich Audacity nun weiterentwickelt. Meine Prognose ist, dass die nächste Änderung, die ähnliche Kritik hervorruft, ein Auto-Updater wie bei MuseScore sein wird. ;-)

Uniswap v3 erfolgreich gestartet

07. Mai 2021 um 17:56

Uniswap v3 ging vor einigen Tagen an den Start. Dabei handelt es sich um eine Plattform, die ohne zentrale Börse den Austausch von Token-Paaren (z. B. ETH gegen DAI) über Smart Contracts ermöglichen soll. Diese Plattform werden auch als Decentral Exchange (DEX) bezeichnet und sind in der DeFi-Welt zu verorten.

Hayden Adams, der Initiator, hat nun gestern Abend auf Twitter verkündet, dass der Start der dritten Version des Systems besonders erfolgreich war: so wurde Uniswap v3 am ersten Tag mehr gehandelt als Uniswap v2 im gesamten ersten Monat.

Es gibt allerdings Kritik, die in zwei Richtungen geht:

  1. Die Verarbeitungsgebüren für die Ethereum-Transaktionen, die teilweise vom Design des Smart Contracts abhängen, sind weiter angestiegen. So kann eine Transaktion schnell um die 100 Euro an „Überweisungsgebühren“ kosten. (Q)

  2. Die neue Version bringt deutlich mehr Komplexität mit. Möchte man Geld einem Pool hinzufügen, genügte es hier, das Geld dort einzuzahlen. In Version 3 müssen verschiedenste Parameter eingestellt werden, deren Wirkung erst erlernt werden muss, um sinnvoll zu handeln. (Q)

Uniswap und DeFi bleiben weiterhin also interessant.

Weitere Links

Schnitzeljagd für Netzwerkprobleme

06. Mai 2021 um 13:40

Heute bin ich auf eine interessante Webseite gestoßen: https://mysteries.wizardzines.com/. Hier sind momentan vier „Fälle“ verfügbar, die sich allesamt mit typischen oder weniger bekannten Netzwerkproblemen beschäftigen. Das wären:

  • The Case of the Slow Websites
  • The Case of the Connection Timeout
  • The Case of the DNS Update that Didn't Work
  • The Case of the 50ms Request

Ich habe mir die Puzzles heute angeschaut und bin begeistert, weil es Netzwerkthemen auf eine Art und Weise abseits von Lehrbüchern und Q&A-Seiten einem näher bringt.

Man wird vor ein Problem gestellt, das es zu lösen gilt. Dabei stehen einem verschiedene Mittel zur Verfügung, die interaktiv aufgerufen werden können. Das ganze Spiel ist geführt gestaltet, sodass man nicht alleine gelassen wird und man gleichzeitig verschiedene Werkzeuge kennenlernt, die zur Problemlösung herangezogen werden können. An einigen Stellen wird man selber nach Problemlösungen, Kommandozeilenprogrammaufrufen (strace, tcpdump, ...) gefragt, die allerdings in vielen Fällen nur informativ sind und keinen großen Einfluss auf das Spiel haben.

Wie so oft führen viele Wege nach Rom, so auch bei den hier angesprochenen Fällen. An vielen Stellen ist Zusatzwissen zu finden, das über den Hintergrund aufklärt. Am Abschluss eines jeden Falls wird die Ursache erläutert.

Ich werde nicht weiter die konkreten Fälle spoilern, sie sind auf jeden Fall ganz nett. Besonders in der Netzwerkwelt ist es schwierig, zu debuggen, weil es keine klassische statische Analyse wie aus der Softwareentwicklung gibt. Gerade erst habe ich wieder einen Fall gehabt, bei dem ein Port an einem VLAN-fähigen Switch konfiguriert werden sollte. Access Port konfigurieren reichte scheinbar nicht aus, denn seltsamerweise kam nur ein Teil der Pakete durch. Die Lösung war, dass noch die PVID für den Port konfiguriert werden muss. Das Debugging wird dahingehend erschwert, dass Dinge gerne mal einfach „nicht funktionieren“ und keine Fehler werfen. Um Probleme zu lösen ist es wichtig, Muster zu erkennen und diese zu bewerten. Und genau darauf zielen die Mysteries ab.

Aus diesem Grund ist es wichtig, immer in der Übung zu bleiben, und da kann ich mir solche Spiele gut als Lernwerkzeug vorstellen, auch, wenn sie nicht aktiv auf einem System arbeiten.

Der Source für das Projekt ist auf GitHub verfügbar.

Django 3.2 veröffentlicht

10. April 2021 um 16:26

Anfang der Woche wurde das Webframework Django in Version 3.2 veröffentlicht. Der LTS-Release bringt einige Neuerungen, Breaking Changes und Abkündigungen von Funktionen mit.

Neuerungen

Die AppConfig ist seit vielen Versionen ein wichtiger Bestandteil von Django, um Projekte in Apps zu strukturieren. Die apps.py tritt in der normalen Entwicklung normalerweise eher in den Hintergrund, übernimmt aber entscheidende Aufgaben. Dies trifft insbesondere auf besonders austauschbare Applikationen zu. Wer eine default_app_config gesetzt hat, sollte allerdings bei Django 3.2 aufhorchen: Django 3.2 kann automatisch die AppConfig ermitteln, wenn in der App eine apps.py mit einer einzigen AppConfig existiert. Damit wird die nun veraltete Variable default_app_config nicht mehr benötigt.

Weiterhin lässt sich der standardmäßige Typ des Primärschlüssels ab sofort zentral anpassen. Ein Primarschlüssel wird automatisch mit dem Typ AutoField immer dann angelegt, wenn kein Feld mit primary_key=True in einem Model vorhanden ist. Sollte der Typ über die ganze App oder gar das ganze Projekt verändert werden, musste bisher jedes Model einzeln einen benutzerdefinierten Typ bereitstellen. Mit der globalen Einstellung DEFAULT_AUTO_FIELD sowie der anwendungsweiten Einstellung AppConfig.default_auto_field lässt sich das nun zentral ändern. Weiterhin wird für neu erstellte Projekte als automatischer Primärschlüsseltyp BigAutoField eingestellt, sodass die Primärschlüssel 64-bit statt bisher 32-bit große Integer speichern. Das ist besonders dann hilfreich, wenn von einem Model mehr als 2 Milliarden Instanzen abgespeichert werden sollen.

Die dritte große Änderung betrifft ebenfalls die Models: so ist es nun möglich, funktionelle Indizes über den positionsabhängigen Parameter *expressions anzulegen.

Der @admin.display-Dekorator ermöglicht es nun, für Property-Funktionen wie is_published direkt aus dem Model heraus die Darstellung auf der Adminoberfläche, die nun ein Dark Theme unterstützt, zu definieren. Weiterhin leitet die Adminoberfläche in jedem Fall unangemeldete Benutzer auf die Anmeldeseite weiter, um nicht durch Statusmeldungen (z. B. Not Found) Aufschluss über die Existenz von Objekten zu geben.

pymemcache wird nun ebenfalls unterstützt, sofern es in Version 3.4.0 installiert ist.

Das in Django 3.1 eingeführte JSONField besitzt nun auch mit JSONObject ein Pendant für Datenbankoperationen.

Wer einen Blog betreibt, kann mit Django besonders einfach RSS-Feeds für Models, hier konkret Artikel, erstellen, indem er auf das mitgelieferte django.contrib.syndication zurückgreift. Nun ist es möglich, mit item_comments direkt einen Link auf eine Kommentarsektion von Models zu spezifizieren, was in einigen RSS-Readern wie Tiny Tiny RSS an gesonderter Stelle angezeigt wird, um schneller in die Kommentare zu springen. Auf diese Änderung bin ich besonders stolz, weil ich sie selber beigetragen habe. ;)

Inkompatibilitäten

Die neue DatabaseFeatures.introspected_field_types ersetzt eine Reihe alter Features wie can_introspect_autofield, etc.

In der Adminoberfläche wird nun bei den Seiten ab 1 statt wie bisher ab 0 gezählt.

Abkündigungen

Die Unterstützung von PostgreSQL 9.5, MySQL 5.6 sowie PostGIS 2.2 wurde entfernt.

Verfügbarkeit

Django 3.2 unterstützt Python 3.9 bis 3.6. Die Unterstützung ist mindestens drei Jahre ab Veröffentlichung gewährleistet. Der vorherige LTS-Release 2.2 wird die Unterstützung nächstes Jahr im April 2022 verlieren.

Die Auflistung aller Änderungen samt Verweise und Codebeispiele ist in den Django 3.2 release notes verfügbar.

KDE Qt 5 Patch Collection angekündigt

06. April 2021 um 13:10

Wie ich bereits vor einigen Wochen berichtet habe, wurde Qt in Version 6 veröffentlicht. Dies hat auch Signalwirkung für eines der wichtigsten in Qt umgesetzten Projekte, KDE. Auch hier wird in den nächsten Monaten auf Qt 6 umgestellt.

Offene Fragen gab es bisher beim Support des auslaufenden Qt 5-Versionsstrangs, der die Grundlage für alle aktuellen KDE-Projekte bildet. Hier hat The Qt Company die Daumenschrauben angezogen (LinuxNews und ich berichteten) und den LTS-Support, der jetzt für die letzten Qt 5-Version 5.15 relevant werden würde, für die kommerziellen Kunden vorbehalten.

KDE kündigte heute nun an, eine eigene Qt 5 Patch Collection bereitzustellen, um den Übergang abzusichern.

Mit dieser Patch Collection werden Sicherheitsprobleme, Abstürze und Funktionsdefekte gelöst. Für die Entwicklung gelten gesonderte Bedingungen im Bezug auf die Verfahrensweisen für die Aufnahme von Patches, veröffentlicht wird aber weiterhin unter der gleichen Lizenz wie der von der Qt Open Source Edition. Releases wird es von dieser Patch Collection allerdings nicht geben. Die Repositories für die Patch Collection sind im KDE-eigenen GitLab verfügbar.

Ist man selber Entwickler von Qt 5-Anwendungen, sollte man im Hinterkopf haben, dass diese Patch Collection speziell auf KDE zugeschnitten ist. Ist der Umstieg auf Qt 6 bei KDE abgeschlossen, wird diese Patch Collection auch eingestellt. Wie aus der Pressemitteilung hervorgeht, zeigt der Hersteller von Qt Verständnis bei den Bemühungen. Man kann davon ausgehen, dass KDE trotz des Lizenztrubels in den letzten Monaten weiterhin gut im Kontakt mit The Qt Company steht. KDE betreibt eine spezielle Intermediärsorganisation mit der The Qt Company: die KDE Free Qt Foundation. Sie kümmert sich um Lizenzbelange und stellt sicher, dass weiterhin eine frei verfügbare Version von Qt für das KDE-Projekt zur Verfügung steht.

Google gewinnt Prozess gegen Oracle

05. April 2021 um 19:58

Heute ist es nun soweit: das lang erwartete Urteil im Verfahren zwischen Google und Oracle ist gefallen. Im Kern ging es um die Einordnung von Application Programming Interfaces (API) und Copyright (hier: Fair Use) in einem speziellen Fall.

Google hat für Android in früheren Versionen auf Java-APIs zurückgegriffen, die von Sun Microsystems entwickelt wurden, das von Oracle 2009 aufgekauft wurde. Oracle sah sich in seinen Rechten verletzt, Google argumentiert, dass die ursprüngliche Nutzung unter Fair Use fällt. Zwischenzeitlich hat Google auf eine rechtlich sicherere Variante umgestellt und nutzt nicht mehr das originale API.

Die Frage, inwiefern APIs urheberrechtlich geschützt werden können, ging schon durch mehrere Gerichtsinstanzen. Während zwei District-Gerichte für Google urteilten, hat der Federal Circuit beide Urteile aufgehoben. Der Supreme Court hat nun als letzte Instanz die finale Entscheidung getroffen. In einer 6:2-Entscheidung wurde heute mitgeteilt, dass Googles Nutzung der APIs unter Fair Use fiel.

Die heutige Entscheidung ist wegweisend für Open Source-Projekte, weil eine Entscheidung für Oracle einschneidende Konsequenzen im Bezug auf Interoperabilität von Programmen hätte – einer Gefahr, der sich die Richter bewusst waren, wie aus dem Statement hervorgeht. Wired hat sich dies vor einigen Jahren schon einmal angesehen und angeführt, dass auch Linux mit der POSIX-API Probleme bekommen hätte. Diese Entscheidung ist allerdings auch kein Freifahrtschein, da es in dieser Instanz nicht mehr um die Schutzfähigkeit von APIs generell ging, sondern eher um die Zugänglichkeit von Fair Use in diesem speziellen Fall. Das Fair Use-Prinzip beschränkt sich auf das US-Urheberrecht.

Wer sich weiter zu dem Thema informieren möchte, kann sich das Dokument vom Supreme Court, die Nachricht von CNN sowie den Artikel von Wikipedia zu dem gesamten Fall in allen Facetten durchlesen.

PHP-Repository-Server mutmaßlich kurzzeitig kompromittiert

29. März 2021 um 11:31

Auf den Git-Server des PHP-Projekts wurden gestern zwei verdächtige Commits (1, 2) hochgeladen. Das lässt vermuten, dass ein Teil der Infrastruktur rund um den Git-Dienst des Projekts angegriffen wurde.

Das Team ermittelt noch den genauen Hergang, hat allerdings als Konsequenz festgelegt, GitHub anstatt der eigenen Infrastruktur zu nutzen. Das umfasst auch den Einsatz der dort angesiedelten Organisation anstatt des eigenen Autorisierungssystems karma.

In diesem Zusammenhang ist es spannend und erschreckend, wie es live aussieht, wenn bösartiger Code eingeschleust wird. Der erste Commit schleust eine Remote Code Execution-Lücke ein, die über einen zusätzlichen Header HTTP_USER_AGENTT (sic) angesprochen werden kann. Auch beim zweiten Commit wird besagter Header in Verbindung mit der eval-Funktion angesprochen. Besonderes Augenmerk ist hierbei auf die Commit-Header zu legen, die die Änderungen tarnen sollen. So ist dies auch noch einmal ein Appell, Code Reviews einzusetzen – und auch bei Standard-Commit-Messages genau hinzuschauen.

Diese Lücken wurden zeitnah entfernt. Es betrifft "nur" den Entwicklungszweig, sollte allerdings keinen Weg in einen Release gefunden haben.

Structs und die Strict Aliasing Rule in C

28. Februar 2021 um 21:00

Ein kurzer Blick in den TIOBE-Index zeigt: auch wenn Go und Rust als die Systemsprachen der Zukunft gelten, ist C weiterhin omnipräsent. Eine gute Gelegenheit, ein interessantes Thema aufzugreifen: die Strict Aliasing Rule.

Wer mit C programmiert, dirigiert Speicher – genauer gesagt Arbeitsspeicher. C wird gerne als portable Assemblersprache betrachtet, diese stellt den Speicher allerdings besonders in den Vordergrund. Der Kontakt mit Speicher tritt einerseits bei der dynamischen Speicherverwaltung mit malloc() und free() auf, erfolgt allerdings bereits mit der Verwendung von Datentypen. Ich umschreibe Datentypen gerne als „Schablone“ bzw. „Maske“ für Speicher. Der kleinste Datentyp ist der char, er umfasst 1 Byte. Hiernach folgt der short, der 2 Byte groß ist. Für besonders große Zahlen gibt es long mit 4 Byte. Spielt die Anzahl der Bytes keine Rolle, kann man den int nehmen, der mindestens 2 Byte groß sein soll, ich habe also keine Garantie, dass ein int immer wie unter Linux 4 Byte umfasst, wenn ich meinen Code auf eine andere Maschine zum Laufen bringen will. Im Zweifel muss ich ihn also portieren.

Zahlen im Speicher

Obenstehende Abbildung zeigt, wie zwei Zahlen im Speicher liegen: im einfachsten Fall in Binärdarstellung, dicht an dicht. Haben wir zwei zusammenliegende Speicherstellen, die als char markiert sind, können wir in Versuchung kommen, diesen Speicher umzuinterpretieren. Was passiert, wenn wir diese 2 Bytes nicht als zwei chars, sondern als ein short betrachten? C gilt als schwach typisiert, weil wir genau das tun können. Und das geht so:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    unsigned char *chrs = malloc(2);
    *chrs = 5;
    *(chrs + 1) = 44;

    unsigned short *shrt = chrs;
    printf("%d\n", *shrt);

    free(chrs);
    return 0;
}

Intern sieht es jetzt (fast) folgendermaßen aus:

Zahlen im Speicher

Das ist der Grund, warum ich bei C an Programmierung mit Typenschablonen als Sicht auf den Speicher denke. Rechnen wir jetzt alles zusammen, müsste das Programm uns 1324 ausgeben – tut es aber nicht. Auf einem aktuellen 64-bit Linux-System wird stattdessen 11269 ausgegeben. Wir haben trotzdem fast alles richtig gedacht, nur müssen wir uns ins Gedächtnis rufen, dass x86-CPUs mit Little Endian arbeiten und wir deshalb die Bytes verdreht denken müssen. Dieser Fallstrick soll uns aber ein Gefühl dafür geben, wie oft bei C-Programmierung die lockere Standardisierung sowie die lokalen (i. S. v. Architektur) Gegebenheiten Herausforderungen bescheren.

Structs in C

Informationen kommen selten einzeln daher. Um sie sinnvoll im Code und im Speicher zu strukturieren, bietet C die structs, die eine Reihe von Mitgliedern (ähnlich wie Variablen) organisieren. Ein Beispiel:

struct country {
    char *name;
    char iso3166[3];
    unsigned short formation;
    char *capital;
};

Im Speicher können wir uns das so vorstellen, auch wenn wir ein entscheidendes Detail noch im Laufe des Beitrags kennenlernen werden:

Struct im Speicher

Diese Vorstellung hilft zwar an der einen oder anderen Stelle, kann allerdings auch zu Missverständnissen führen, wenn wir uns zu sehr auf diese Speicherdarstellung verlassen.

Wir könnten zum Beispiel denken, dass wir vereinfacht die Werte verdrehen können:

#include <stdio.h>

struct country {
  char *name;
  char iso3166[3];
  unsigned short formation;
  char *capital;
};

struct country2 {
  char *capital;
  char iso3166[3];
  unsigned short formation;
  char *name;
};

int main (void)
{
  char *de_name = "Deutschland";
  char *de_capital = "Berlin";
  struct country germany = {
    de_name, "DE", 1949, de_capital
  };

  printf("Country Name: %s\n", germany.name);

  struct country2 *germany2 = (struct country2 *) &germany;

  printf("Country Name: %s\n", germany2->name);

  return 0;
}

Bei structs kommt es vor allem auf die Reihenfolge und die Datentypen an – allerdings kann man nicht darauf vertrauen.

Objektorientierung in C

Im voherigen Beispiel konnten wir eindrucksvoll sehen, dass wir besonders einfach Pointer auf structs umcasten – und somit uminterpretieren – können. Diese Technik ist als type punning bekannt, wurde schon vor knapp 40 Jahren bei den Berkley sockets (vgl. struct sockaddr_in) eingesetzt und lässt sich nun für viele verschiedene Zwecke einsetzen: zum Beispiel für Vererbung oder Bäume – oder die Kombination aus beidem.

Zur Veranschaulichung möchte ich einen Baum aus der Verwaltungsgliederung heranziehen: hier gibt es den Staat, die Bundesländer und die Landkreise, die jeweils unterschiedliche Informationen besitzen.

Beispiel Baum

Ziel ist es, jeden Knoten am Baum aufzuhängen. Allerdings ist die Struktur komplex: so hilft es nicht, den Typen anhand der Ebene festzulegen, weil sonst Landkreise und kreisfreie Städte nicht unterschieden werden können. Die Lösung wäre, ein Unterscheidungsfeld am Anfang eines jeden Knotens festzulegen. Bei der Implementierung müssen wir bedenken, dass natürlich technsiche Informationen zur Baumimplementierung mitgegeben werden sollen:

struct country {
    char type;
    void *child;
    void *sibling;

    // data
    char *name;
    char *capital;
    //...
};


struct state {
    char type;
    void *child;
    void *sibling;

    // data
    char *name;
    //...
};


struct district {
    char type;
    void *child;
    void *sibling;

    // data
    char *name;
    //...
};

Strict Aliasing Rule

Doch halt! Wir dürfen bei C nicht vergessen, dass wir im Zweifel alles hinterfragen müssen. Unser Ziel ist es, dass die ersten drei Felder immer an der gleichen Stelle im Speicher liegen, sodass wir unabhängig von der Wahl der drei structs immer die gleichen Member an der gleichen Stelle erreichen können. Doch können wir uns darauf verlassen? Die Antwort ist im C-Standard zu finden und hier gibt der C99-Standard unter der Sektion „6.7.2.1 Structureand union specifiers“, Punkt 13 Aufschluss. Dieser Punkt beschreibt, dass bei structs die Reihenfolge der Members im Speicher unverändert sein und das erste Element auch am Anfang beginnen muss – er erlaubt aber auch Freiraum zwischen den Feldern, die der Compiler in Verbindung mit seinem Optimierungssystem selber bestimmen darf.

Strict Aliasing Rule am Beispiel dreier Structs

Für den Compiler hat dies Vorteile – für uns als Programmierer wird dies allerdings eine Herausforderung. Wir können uns also nur sicher sein, dass die Adresse des ersten Elements mit der Adresse des Structs selber übereinstimmt. Die Strict Aliasing Rule ist eine Folge aus diesem Umstand und sagt aus, dass wir nur dann standardkonform einen Pointer dereferenzieren können, wenn dessen Typ kompatibel zu dem Typ ist, der für die Speicherstelle festgelegt wurde.

Die Lösung

Wie können wir denn aber nun effizient unseren Baum umsetzen? Indem wir den Umstand ausnutzen und den gemeinsamen Anfang auslagern:

struct node_base {
    char type;
    void *child;
    void *sibling;
};

struct country {
    struct node_base base;

    // data
    char *name;
    char *capital;
    //...
};


struct state {
    struct node_base base;

    // data
    char *name;
    //...
};


struct district {
    struct node_base base;

    // data
    char *name;
    //...
};

Hierdurch erreichen wir, dass das (erste) Element garantiert an der gleichen Stelle (d. h. am Anfang) liegt und wir auf zusätzliche Indirektionen / Pointer oder Abstraktionen verzichten können.

Speicher bei der Lösung mit base-Member

Fazit

C ist weiterhin eine sehr effiziente und systemnahe Sprache, die einen unverblümten Blick auf das wichtigste Material eines Programmiers gibt, mit dem dieser seine Programme formt: den Speicher. Mit zunehmendem Optimierungswunsch gibt es jedoch seit knapp 20 Jahren eine Regel, die nur wenige kennen, aber große Auswirkungen besonders dem Portieren hat: die Strict Aliasing Rule. Es gibt noch weitere Anwendungsfälle für sie, ein wichtiger Anwendungsfall wurde in diesem Artikel besprochen. Dieser Fall tritt besonders dann auf, wenn Strukturen aus der Objektorientierten Programmierung (OOP) in C nachgebildet werden sollen.

Dass diese Regel eher unbekannt ist, lässt sich auch daran erkennen, dass die Referenzimplementierung von Python, CPython, noch bis zur Version 2.7 gegen diese Regel verstieß – was allerdings dank PEP 3123 mit CPython 3.0 gelöst wurde.

Strict Aliasing lässt sich übrigens in den meisten Compilern ausschalten, wer allerdings plattform- und compilerübergreifenden Code schreiben will, sollte die Regel allerdings beachten.

Weitere Informationen zu diesem Thema bietet dieses Gist sowie der StackOverflow-Thread zu diesem Thema.

pip 21 stellt Unterstützung für Python 2 ein

24. Januar 2021 um 12:04

(Ganz) kurz notiert: pip, der Paketmanager für Python, ist in der Version 21 erschienen. Größte Neuerung des Major-Releases ist das Ende der Unterstützung von Python 2 (#6148), dem alten Versionsstrang von Python, der seit Anfang 2020 schon EOL ist. Im gleichen Atemzug wurde der Support für Python 3.5 entfernt. (Siehe Changelog.)

Aus meiner Sicht ist es ein guter Schritt, ein Jahr nach dem offiziellen EOL nun auch mit den Aufräumarbeiten zu beginnen, da Python 2 und insbesondere der zehnjährige Migrationszustand viele Abhängigkeiten (wie bspw. der six library) hinterlassen hat, die nun zugunsten der Codequalität aufgelöst werden können.

Qt und die Lizenzänderung

05. Januar 2021 um 10:00

Die neue Lizenzpolitik von Qt wird langsam umgesetzt, wodurch die offenen LTS-Releaes entfallen. Ein Kurzkommentar.

Gerade habe ich bei LinuxNews das gelesen, was ich schon seit einigen Monaten befürchtet habe: zwar ist es bei der Veröffentlichung von Qt 6 ein wenig untergegangen, aber das Team hinter Qt zieht die Daumenschrauben für Open-Source-Entwickler kräftig an an. Kurzzusammenfassung: die Open-Source-Aktivitäten werden weiter heruntergefahren und Lizenznehmer der proprietären Lizenz bevorzugt.

Lesenswert in diesem Zusammenhang wäre einerseits die Mail von Olaf Schmidt-Wischhöfer vor einigen Monaten oder auch die Zusammenfassung von heise online.

Die ganze Geschichte ist ehrlich gesagt schwer durchsichtig, denn einerseits wurde ja entgegen der Befürchtung Qt 6 quelloffen veröffentlicht, andererseits machen die Maintainer mit dem auslaufenden LTS-Support ernst.

Dass erst kommerzielle Kunden die neuen Versionen erhalten und dann die Open-Source-Community wäre aus meiner Sicht auch eine Loose-Loose-Situation, denn zahlende Kunden wollen sicherlich ausgereifte, getestete Software und die Open-Source-Entwickler probieren eher Neues aus. Scheint aber (vorerst?) noch nicht so eingetreten zu sein.

Aus Entwicklersicht wird der Einsatz von Qt zunehmend problematischer – aber nicht wegen des Frameworks selber. Qt ist quasi wie ein Aufsatz auf C++ und in extrem vielen Komponenten besonders verzahnt. Das war mitunter noch kritischer als die C++-STL nicht so umfangreich war, gilt aber meines Erachtens weiter uneingeschränkt für die GUI-Komponenten.

Bei Qt droht tatsächlich wieder die Lizenzpolitik zum Ausschlusskriterium zu werden. Wieder? Ja, denn das hat 1998 schon einmal zu Problemen geführt. Da hat eines der größten Qt-basierten Projekte, die Desktopumgebung KDE, mit der Lizenz Schwierigkeiten gehabt. Zwei Ergebnisse hiervon sind die Desktopumgebung GNOME als Antwort auf genau dieses Lizenzproblem (GNOME setzte von Anfang an auf das freiere GTK) sowie eine Vereinbarung bzw. Intermediärsorganisation zwischen dem Qt- und KDE-Team, die erlaubt, bei Einstellung der Qt Free Version die letzte Version unter einer BSD-Lizenz o. ä. zu veröffentlichen.

Die Folgen wären allerdings für alle Beteiligten wenig wünschenswert, was wir an Forks wie LibreOffice oder LEDE (mittlerweile wieder zusammengeführt) sehen können.

Bleibt also die präventive Frage nach Alternativen, allerdings sieht es hier schlecht aus. Ich kenne bisher kein vergleichbares Framework in Umfang, Plattformunabhängigkeit und Stabilität. Am nächsten würde vielleicht noch Electron kommen, aber ich würde eher etwas Kompiliertes für Desktopanwendungen vorziehen.

2021 beginnt also mit so einigen offenen Fragen.

Eine halbe Stunde, um Rust zu lernen

02. Januar 2021 um 12:47

Dieser englischsprachige Artikel über eine Rust-Einführung ist mir soeben ins Auge gefallen.

Rust gewinnt in den letzten Jahren zunehmend an Bedeutung. Ich habe bereits öfter über Rust geschrieben und prophezeie der Sprache den Aufstieg in den C/C++/Java-Olymp – nicht all zuletzt wegen des Hypes und der guten PR. So werden wir sicherlich schon bald Rust-Code im Linux-Kernel begutachten können.

Ein klein wenig wundert es mich trotzdem, warum alle auf einmal auf diesen hype train aufspringen, da es im Gegensatz zu Python tatsächlich mit steigender Projektgröße schwieriger wird, validen Rust-Code zu formulieren. Dies wird besonders dann herausfordernd, wenn Traits, Lifetimes und Generics zusammenspielen sollen, da sich hier gerne mal die Sprache in den Weg stellt. Auf der anderen Seite gibt es üble Tricks, um doch noch Rusts „Zwang zu gutem Code“ zu umgehen. Wie dem auch sei.

Der oben verlinkte Artikel bietet einen kompakten Überblick über die Syntax und Paradigmen von Rust. Trotzdem gilt weiterhin und besonders für Rust: Übung macht den Meister.

Frohes neues Jahr 2021 und ein paar Worte zu 2020

31. Dezember 2020 um 23:00

In guter alter Tradition melde ich mich auch dieses Jahr „zwischen den Jahren“ und wünsche allen Lesern meines Blogs ein gesundes, glückliches und frohes neues Jahr 2021!

Die IT hat im vergangenen Jahr gezeigt, dass sie entscheidende Unterstützung im Bezug auf das Arbeitsleben sowie die Bildungslandschaft liefern kann – wenn man denn will. Es traten verschiedenste Akteure zum Vorschein. Akteure, von denen ich wie im Beispiel Zoom bisher wenig gehört habe, da ich bis dato mit Videokonferenzen nur Skype verbunden habe. Oder aber auch Akteure, die lange Zeit ein Schattendasein fristeten wie BigBlueButton. Wir haben gelernt, dass dieser Umstand positive wie auch negative Auswirkungen haben kann. Aber ehrlich gesagt kenne ich BigBlueButton noch aus den Flash-Zeiten, der Umstieg auf HTML5 ist schon bemerkenswert. Apropos Flash: hier endet heute auch der Support, ab 12.01.2021 wird die Software gänzlich ihren Dienst verweigern.

2020 wird seine Spuren hinterlassen, nicht nur in den Statistiken vom DE-CIX. Was man allerdings hieraus macht, bleibt jedem selber überlassen. Egal wie gut oder schlecht das jeweilig eingesetzte Tool ist, was man nutzt – am Ende des Tages kommt es zu einem Großteil auch darauf an, wie gewillt man ist, die Situation zu gestalten. Wo ein Wille ist, da ist auch ein Weg.

Kurz noch ein paar Sätze zum Blog: In diesem Jahr habe ich in 30 Artikeln nicht nur die üblichen Open Source-Themen beleuchtet, sondern manchmal über kleine Lichtblicke berichtet, soweit es möglich war.

Meine Matomo-Installation habe ich mittlerweile komplett aus dem Blog entfernt, weshalb ich euch keine Zahlen berichten kann. Allerdings ist laut Google der Artikel über das Kopieren von ISO-Images auf USB-Sticks weiterhin der beliebteste auf dem gesamten Blog – dieses Jahr eingeschlossen.

Auch im Jahr 2021 versuche ich meinen Blog in alter Frische weiterzuführen sowie die eine oder andere Neuerung einzuspielen. Der geneigte Leser mag schon einmal in meinem Blog die Microblogging-Sektion entdeckt haben, die ich seit zwei Jahren breit ausrollen und nutzen möchte. Vielleicht wird es 2021 etwas. ;)

Ich würde mich freuen, auch euch im neuen Jahr wieder begrüßen zu können und schließe diesen Artikel mit dem üblichen PS zum Jahreswechsel: denkt an eure Footer!

GTK 4.0 veröffentlicht

17. Dezember 2020 um 22:13

Kurz nach der Veröffentlichung des neusten Major-Releases von Qt, Version 6.0, gibt es auch aus dem GTK/GNOME-Lager Neuigkeiten. Das Anwendungsframework GTK (früher als GIMP Toolkit bekannt) erscheint in Version 4.0. Dies hat das Entwicklungsteam gestern im GTK-Blog verkündet.

Für diesen Major-Release wurden viele Komponenten überarbeitet, darunter APIs für den Datentransfer (Clipboard, Drag-and-Drop), Layoutverwaltung, Eventhandling, Rendering, Medienwiedergabe, Listen, Shader oder Bedienungshilfen.

Bezogen werden kann GTK 4.0 aus den Quellen sowie über Flatpak (org.gtk.Demo4).

GTK bildet die Grundlage für das GNOME-Ökosystem und stellt eine Alternative zu Frameworks wie Qt (C++) dar. Hierbei greift GTK auf C als Programmiersprache zurück.

Erste GTK 4.0-Anwendungen sollen mit dem kommenden Release GNOME 40 präsentiert werden.

Quelle: GTK-Blog

Qt 6.0 veröffentlicht

09. Dezember 2020 um 12:55

Am 08. Dezember 2020 wurde wie geplant zum Jahresende Qt 6.0 veröffentlicht. Unterstützung für C++17, eine neue Generation von QML, ein CMake Buildsystem sowie eine neue Grafikarchitektur sind die wichtigsten Änderungen.

Qt ist ein sehr verbreitetes plattformübergreifendes Anwendungsframework. Dabei steht klar die Entwicklung graphischer Benutzeroberflächen (GUIs) im Vordergrund, allerdings erweitert Qt generell die übliche Standardbibliothek um eine Vielzahl von Funktionen, die die Entwicklung vereinfachen sollen.

Nun wurde Version 6 des 25 Jahre alten Frameworks veröffentlicht, wie gestern im Qt-Blog angekündigt wurde. Dem Release vorausgegangen war die Vision aus August 2019.

Die Änderungen im Überblick

Qt 6.0 greift nun auf C++17 zurück, wodurch nun ein C++17-kompatibler Compiler Voraussetzung ist, um das Framework zu bauen.

Qt Core wurde an vielen Stellen verbessert: so ist nun das property und binding system neu, das direkt aus C++-Code angesprochen werden kann. Dabei lassen sich bestimmte Zusammenhänge festlegen, die dann vom Framework umgesetzt werden, wie bereits im dazugehörigen Blogartikel dazu umrissen wird:

class Rectangle {
public:
    Property<int> width;
    Property<int> height;
    Property<int> border;

    Rectangle() {
        height.setBinding(width);
        border.setBinding([this]() {
            return height / 10;
        });
    }
};

Mit diesem Code soll nun beispielsweise ermöglicht werden, dass ein Rechteck quadratisch ist (width == height) und ein Zehntel der Höhe die Rahmenbreite ist.

Die Integration von Unicode in Strings soll weitestgehend abgeschlossen sein.

QList und QVector werden vereinigt, wobei QVector als Grundlage nun dient und Elemente nun direkt im allokierten Speicher abgelegt werden, ohne nun mehr auf die komplexere Heap-Struktur zurückzugreifen.

Weitere Komponenten aus Qt Core wurden überarbeitet, darunter Qt Concurrent, Qt Network oder auch QMetaType und QVariant.

Während Qt 5 bisher auf OpenGL für die hardwareunterstütze Grafikbeschleunigung gesetzt hat, bekommt Qt Quick, ein Unterframework, das sich auf die schnelle deklarative Erstellung von Benutzeroberflächen fokussiert, mit dem neuen Major-Release einen Abstraktionslayer namens Rendering Hardware Interface (RHI). Dadurch kann auf die native Grafikarchitektur der Laufzeitumgebung zurückgegriffen werden, sodass auf Windows nun Direct3D und auf macOS Metal als Grafik-API genutzt wird.

Von der RHI profitieren auch Qt 3D sowie Qt Quick 3D, wobei letzteres die Qt Quick um 3D-Funktionalitäten erweitern und es ermöglicht, performant 2D-Inhalte in einer 3D-Szene zu platzieren.

Qt Quick Controls unterstützt darüber hinaus nun desktop styling.

Qt läuft auf einer Reihe von Plattformen, darunter die verbreiteten Desktopsysteme, aber auch mobile Plattformen und eingebettete Systeme. Um den spezifischen Anforderungen gerecht zu werden, wurden bisher Add-on-Module eingesetzt. Diese Funktionalität wurde nun in Qt integriert, wie im dazugehörigen Blogbeitrag beschrieben wird.

Beim Buildsystem stehen auch Änderungen an. Führen wir uns die bisherige Implementierung vor Augen, erkennen wir direkt die Bedeutung von qmake, welches aus .pro-Dateien Makefiles erzeugt. Qt 6.0 setzt nun allerdings auf CMake, wird in dieser Version allerdings noch qmake weiterhin unterstützen.

Portierung, Unterstützung, Ausblick

Das Qt-Team bietet eine Anleitung zur Umstellung auf Qt 6.0 an.

Unterstützut werden die verbreiteten Plattformen: Linux-Desktop, Windows 10, macOS ≥ 10.14, iOS ≥ 13, Android ≥ 6. Der Support von Embedded RTOS steht noch aus.

Zusammenfassung und IMHO

Der Major-Release setzt eine Vielzahl an Änderungen um, zum einen an der Oberfläche, zum anderen im Unterbau. Die Unterstützung von C++17 ist eine sinnvolle Neuerung. Eine vollständige Liste der Neuerungen ist hier im Qt Wiki verfügbar.

Wie bei Major-Releases von eng in Anwendungen verzahnten Frameworks üblich, wird wieder einige Zeit ins Land gehen, bis die Portierung erfolgt ist.

Mit keinem Wort im Blogpost wird allerdings die neue Lizenzpolitik erwähnt. Potentielle Änderungen hatten im April die KDE-Community bereits verunsichert. Diese würde Verzögerungen bei der FOSS-Veröffentlichung mit sich ziehen. Im Qt Wiki erklärt allerdings ein Artikel, wie Qt 6 weiterhin aus FOSS-Quellen bezogen werden kann. Dabei wird momentan noch auf das Qt5-Repo zurückgegriffen, welches auch Qt 6 beherbergt. Somit kann wohl vorerst noch Entwarnung gegeben werden, was die Quellen angeht.

Quelle: Blogartikel „Qt 6.0 Released“. Lars Knoll. 08. Dezember 2020.

CentOS ändert Ausrichtung

08. Dezember 2020 um 23:02

Kurz notiert: das Team hinter CentOS, der Red Hat Enterprise Linux-baiserten Distribution, das sich Januar 2014 mit dem RHEL-Herausgeber Red Hat zusammengeschlossen hat, hat heute eine folgenschwere Ankündigung (CentOS, Red Hat) gemacht. Das Projekt wird sich zukünftig auf CentOS Stream konzentrieren. CentOS 8, die aktuelle Version, wird Ende 2021 aufgegeben – und damit drei Jahre vor dem Vorgänger CentOS 7. Die Nachfolge soll CentOS Stream antreten.

Das ist keine simple Namensänderung, sondern eine fundamentale Neuausrichtung: wurde bisher CentOS als RHEL-Nachbau (d. h. downstream) entwickelt, so ist CentOS Stream upstream, d. h. näher an der Softwarequelle, angelegt.

IMHO ist CentOS zukünftig wohl nicht mehr attraktiv für Produktivumgebungen, die eine stabile Umgebung und eine lange Supportzeit (bisher ca. 10 Jahre) erwarten. Kunden, die so etwas wünschen, werden nun zur Kasse gebeten, entweder mit RHEL selbst oder mit Alternativen wie Oracle Linux. Überraschend ist aus meiner Sicht, dass CentOS nun im upstream-Umfeld herumwildert, da dies eigentlich schon das Gebiet von Fedora ist.

Ebenfalls lesenswert ist hierzu der Kommentar von Michael Kofler.

Excel kann nun Lambda-Funktionen

08. Dezember 2020 um 12:39

Auch das noch in 2020. ;)

Microsoft hat angekündigt, dass Excel zukünftig auch Lambda-Funktionen beherrscht. Das bedeutet, dass Excel-Formeln selber mit Argumenten aufgerufen werden können.

Beispiel:

=LAMBDA(x, x + 1)

bedeutet in Excel nun, was man in Python als

def foo(x):
    return x + 1

schreiben würde. Und wo wird der Funktionsname festgelegt? Im sog. Name Manager. Das ist zwar etwas ungewohnt, aber möglicherweise eine passable Lösung. Damit sollen die Mappen vereinfacht werden, da eine so erstellte Funktion in anderen Zellen wiederbenutzt werden kann, z. B. durch =A1+A2*FOO(A2).

Technisch bedeutet dies, dass Excel nun auch Turing-complete ist. Damit wäre es nach PowerPoint und Word das dritte Office-Tool in der Reihe, aber das ist noch eine ganze andere Sache. ;)

The Register regt sich nicht nur über Anmerkung von Microsoft auf, Excel sei die meistgenutzte Programmiersprache, sondern auch über das neue Level von Problemen, welches diese Funktion dank Rekursion, etc. mitbringt.

Andererseits bietet dieses Feature vielleicht die Möglichkeit, dass endlich die Makros rausgeworfen werden können. Wir können gespannt bleiben - und sollten es auch.

Nun müssen wir aufpassen, dass wenigstens die Copy-Paste-Horror-Excel-Mappen halten. What could possibly go wrong?

Ethereum 2.0 Phase 0 erfolgreich gestartet

01. Dezember 2020 um 18:30

Und noch eine Kryptowährungsnachricht, heute sicherlich die letzte. ;)

Ethereum, ebenfalls eine Open Source-Kryptowährung, die ihren Fokus auf Smart Contracts in einer Form von „Cloud Computing für alle (und mit allen, die eine Node betreiben)“ legt, hat die Phase 0 des Umstiegs auf Ethereum 2.0 abgeschlossen.

Dabei geht es darum, vom Proof-of-Work (PoW) auf den Proof-of-Stake (PoS) umzustellen. Kurz zusammengefasst, was die beiden Konsensalgorithmen bedeuten: beim Proof-of-Work muss jeder Block „gemined“ werden, also eine bestimmte Nonce ermittelt werden, mit der der kryptographische Hash des Blocks eine bestimmte Anzahl an führenden Nullen hat (siehe auch mein Video dazu). Das Suchen dieser Nonce verursacht einen gewissen Aufwand und es gilt im Protokoll der Branch als „wahr“, in den der meiste Aufwand gesteckt wurde. Anders Proof-of-Stake: hier können kapitalstarke Nutzer ihre Ether in einen Contract einzahlen und somit das Privileg erhalten, den nächsten Block auszuwählen. Konkret nimmt man an einer Art Lotterie teil und hat die Chance, als Gewinner einer Ziehung den nächsten Block zu bestimmen. Hält man sich dabei an vorher aufgestellte Regeln, erhält man einen Anteil der Transaktionskosten, hält man sich nicht an die Regeln, wird (soweit mir bekannt mindestens ein Teil) des eingezahlten Geldes einbehalten. Soviel zu den Anreizen des Konzepts.

Heute fiel der Startschuss für die Migration von Proof-of-Work zu Proof-of-Stake, die noch einige Jahre andauern wird. Der erste Block wurde um ca. 13:00 deutscher Zeit „validiert“, wie es zukünftig statt „gemined“ heißt.

Es gibt nun für diese spezielle Beacon Chain, in der das Proof-of-Stake-Verfahren abläuft, einen eigenen Explorer, der unter beaconscan.com erreichbar ist.

Die Umstellung auf Proof-of-Stake wird nun schon seit gut 6 Jahren vorangetrieben. Die ersten Konzepte hierzu stammen aus dem Jahr 2014. Vom neuen Konsensalgorithmus wird sich ein geringerer Ressourcenaufwand erhofft, um die Skalierbarkeit zu gewährleisten.

Quelle: Cointelegraph

Libra wird in Diem umbenannt

01. Dezember 2020 um 18:00

Kurze News aus der Welt der Kryptowährungen: Libra, die durch den Facebook-Konzern bekanntgewordene Internetwährung, wird in Diem umbenannt. Dies wurde heute in Genf bekanntgegeben.

Mit der Namensänderung solle eine Unabhängigkeit signalisiert werden, so der CEO Stuart Levey. Diem ist lateinisch und bedeutet „Tag“. Momentan stehen weiterhin die Genehmigungen der Schweizer Behörde FINMA für eine Einführung des Tokens aus.

Zum Projekt gehört die gleichnamige in Rust geschriebene und unter der Apache 2.0-Lizenz lizenzierte Software, die weiterhin unter https://github.com/libra/libra abgerufen werden kann. Die Namensänderung wird zeitnah auch dort umgesetzt.

Diem verfolgt weiterhin das Ziel, eine sichere Komplementärwährung aufzubauen, die von Nutzern und Unternehmen auf der ganzen Welt eingesetzt werden kann.

weitere Quelle: Reuters

Traceback-Helfer für Python

30. November 2020 um 18:48

Tracebacks helfen in Python beim Aufspüren von Fehlern nach einer nicht abgefangenen Exception. Nachteil ist allerdings, dass die standardmäßige Ausgabeform dieses Hilfsmittels nicht so aussagekräftig ist wie z. B. eine GDB-Session: so werden nur der Aufrufstack sowie die konkrete Exception angezeigt.

Oftmals ist man allerdings an bestimmten Variablen interessiert, die einen bestimmten edge case erzeugen, der zum Absturz führt. Mit klassischen Tracebacks kommt man da nur schwerlich weiter und behilft sich, indem man eigene Ausnahmebehandlungen (except) einfügt, welche dann z. B. die Variablen im Fehlerfall anzeigen.

Es gibt allerdings auch weitaus angenehmere Möglichkeiten, um dies umzusetzen. Zwei beispielhafte Tools möchte ich euch kurz in diesem Artikel vorstellen. Hierzu verwende ich folgendes Programm, welches bei bestimmten Werten zu einer ZeroDivisionError-Exception führt.

# hier werden dann die traceback helper importiert

def foo(x, y):
    z = y - 3
    return bar(x, z)

def bar(x, y):
    return baz(x, y + 1)

def baz(x, y):
    return x / y

foo(1, 2)

traceback_with_variables

traceback_with_variables ist ein Python-Package, welches die oben angesprochene Exception-Meldung gegen eine andere austauscht. Der Fokus liegt hierbei auf der Anzeige der Variablen. So werden direkt im Traceback alle relevanten Variablen im Kontext für jedes Element im call stack angezeigt, sodass edge cases klar identifziert werden können.

Der Einsatz dieses Packages gestaltet sich relativ einfach, da nur ein Import genügt, um die Funktionalität zu aktivieren:

from traceback_with_variables import activate_by_import

Diese Tracebacks sehen dann folgendermaßen aus.

Traceback with variables (most recent call last):
  File "/tmp/demo.py", line 15, in <module>
    foo(1, 2)       
      __name__ = '__main__'
      __doc__ = None
      __package__ = None
      __loader__ = <...>  # gekuerzt fuer den Blog
      __spec__ = None   
      __annotations__ = {}
      __builtins__ = <module 'builtins' (built-in)>
      __file__ = '/tmp/demo.py'
      __cached__ = None
      activate_by_import = <> <...>  # gekuerzt fuer den Blog
      foo = <function foo at 0x7f65076ca040>
      bar = <function bar at 0x7f65073a2670>
      baz = <function baz at 0x7f65073a2820>
  File "/tmp/demo.py", line 7, in foo
    return bar(x, z) 
      x = 1
      y = 2
      z = -1
  File "/tmp/demo.py", line 10, in bar
    return baz(x, y + 1)
      x = 1         
      y = -1
  File "/tmp/demo.py", line 13, in baz
    return x / y        
      x = 1
      y = 0   
builtins.ZeroDivisionError: division by zero

Stackprinter

Ein weiteres Package, welches in ähnlicher Art und Weise hilft, ist stackprinter. Stackprinter muss zur Aktivierung importiert und manuell aktiviert werden:

import stackprinter
stackprinter.set_excepthook(style='darkbg2')

Dieses Python-Package zeigt ebenfalls für jede Aufrufebene die Variablen im Kontext an, ergänzt dies allerdings bereits in der Standardkonfiguration um Codesnippets, sodass das Debugging ebenfalls deutlich vereinfacht werden kann. Somit wird ein Komfort ermöglicht, der sonst nur von z. B. IDEs bekannt ist.

Tracebacks sehen dann so aus:

File "/tmp/demo.py", line 15, in <module>
    11   
    12   def baz(x, y):
    13       return x / y
    14   
--> 15   foo(1, 2)

File "/tmp/demo.py", line 7, in foo
    5    def foo(x, y):
    6        z = y - 3
--> 7        return bar(x, z)
    ..................................................
     x = 1
     y = 2
     z = -1
    ..................................................

File "/tmp/demo.py", line 10, in bar
    9    def bar(x, y):
--> 10       return baz(x, y + 1)
    ..................................................
     x = 1
     y = -1
    ..................................................

File "/tmp/demo.py", line 13, in baz
    12   def baz(x, y):
--> 13       return x / y
    ..................................................
     x = 1
     y = 0
    ..................................................

ZeroDivisionError: division by zero

Sentry

Während die obigen Python-Packages besonders bei der Entwicklung helfen, ist Sentry konzeptionell eher für die Fehlersuche in Production-Umgebungen gedacht. Hier werden die Fehler an eine Webanwendung gemeldet, von wo aus der Traceback samt Codeauszug analysiert werden kann. Auf Programmseite kommt das Sentry Python SDK dann zum Einsatz.

Sentry ist weitaus aufwändiger zu installieren, soll allerdings an dieser Stelle nicht unerwähnt bleiben.

Fazit

Für das klassische Debugging auf dem Terminal gibt es einige Packages, die die Standard-Exception-Meldung gegen eine eigene austauschen können und somit die Entwicklung weiter vereinfachen. Dabei gibt es verschiedene Lösungen, die auch verschieden komplex implementiert werden können. Am Ende kommt es jedoch auf die persönlichen Präferenzen sowie auf die Umgebung an, in der die Tracebacks angezeigt bzw. gesammelt werden sollen.

PHP 8 veröffentlicht

29. November 2020 um 18:25

Version 8 der speziell für Webseiten beliebten Programmiersprache ist erschienen. In diesem Artikel werden wir einen kurzen Blick auf die Neuerungen werfen.

PHP sollte den meisten ein Begriff sein. Ursprünglich angedacht als Werkzeug zur Verarbeitung von Formulardaten, ist die Programmiersprache heute weit verbreitet und schwer aus dem Internet wegzudenken. Applikationen wie WordPress, MediaWiki, phpMyAdmin, phpBB, aber auch Internetportale wie Facebook basieren zu einem Großteil auf dieser Skriptsprache.

Nun wurde Version 8 veröffentlicht. Das PHP-Team präsentiert die wichtigsten Änderungen auf einer eigens dazu eingerichteten Webseite. Werfen wir einen kleinen Blick auf die Änderungen.

Die Änderungen im Kurzüberblick

Eines der Aushängeschilder ist der neue Just-in-time-Compiler (JIT), der Performanceverbesserungen ermöglichen soll. Diese Verbesserungen können allerdings anwendungsabhängig sein.

Viele der neu eingeführten Features sind schon von anderen Programmiersprachen bekannt. So werden sog. named arguments eingeführt, die stark an die keyword arguments aus Python erinnern. Damit wurde eine Alternative zu den klassischen positionsabhängigen Argumenten geschaffen, sodass ab sofort Funktionsaufrufe so gestaltet werden können, dass die Bedeutung der einzelnen Argumente sofort deutlich wird.

Die Arbeit mit Klassen wurde in zweierlei Hinsicht verbessert: zum einen verbindet die neue constructor property promotion Ideen aus C++ und Python, bei der die Klassenattribute ausschließlich als Parameter im Konstruktor deklariert und mit Standardwerten versehen werden können. Somit entfällt die Deklaration in der Klasse und die Wertzuweisung im Rumpf des Konstruktors.

Zum anderen verbessert PHP 8 die Typsicherheit in Klassen. Mit den union types können mehrere erlaubte Typen für eine Variable festgelegt werden.

Zwei weitere Verbesserungen sind die aus Rust sowie vielen funktionalen Programmiersprachen bekannten match expressions, die eine Alternative zur switch-Anweisung darstellt. Weiterhin wird der nullsafe operator $foo?->bar?->baz eingeführt, der if (... !== null)-Kaskaden ersetzen soll.

Während die bisher aufgezählten Änderungen Ergänzungen oder Vereinfachungen für die Sprache darstellen, enthält dieser Release auch breaking changes, mit denen vor allem die API geradegerückt wird: so wird ein String-Zahl-Vergleich nun nicht mehr pauschal mit true beantwortet, sondern nur noch, wenn der String als Zahl umgewandelt im Vergleich wahr ist. Das würde z.B. auf 0 == "0", aber auch 0 == "0.0" zutreffen. Dieses Verhalten erinnert an JavaScript mit den beiden Operatoren == (Vergleich mit erlaubter Umwandlung) sowie === (Vergleich ohne erlaubte Umwandlung).

Darüber hinaus wurden Typfehler konsistenter gestaltet sowie eine Vielzahl an kleineren Änderungen eingearbeitet.

Einschätzung

PHP begleitet mich nun seit mittlerweile 10 Jahren. Dabei hat die Sprache in diesen Jahren einen bemerkenswerten Wandel hingelegt. Angetreten als simples Server Side Scripting reift die Sprache in den letzten Jahren aus und wird für größere Projekte attraktiver, wobei aus meiner Sicht besonders das verbesserte Typensystem dazu beitragen kann.

Von starker und statischer Typisierung ist diese Sprache noch ein gutes Stück entfernt, was Vor- und Nachteile haben kann. Eine Möglichkeit anzubieten, auf Wunsch statischere Typisierung zu nutzen, ist allerdings begrüßenswert – dass String-Zahl-Vergleiche trotzdem noch schwächer typisiert bleiben, aber schade.

Entscheidend bei der Verbreitung wird allerdings auch der Fakt sein, dass bestehender Code aufwändiger auf PHP 8 migriert werden muss als es noch bei vorherigen Versionen der Fall war. An dieser Stelle sei auch an Python erinnert, wo die Migration von Version 2 auf 3 noch nach 10 Jahren und einem knapp seit einem Jahr nicht mehr unterstütztem Versionsstrang noch immer andauert.

PHP sichert mit Version 8 seine Existenz für die nächsten Jahre und versucht von Erfahrungen anderer Programmiersprachen zu lernen, wie die Implementierung der match expressions zeigt. Bis von diesen Verbesserungen die Entwickler allerdings profitieren, kann es noch dauern, da zwar vor einigen Tagen mit der Veröffentlichung der Startschuss gegeben wurde, die Verfügbarkeit in Distributionen und bei Webhostern allerdings noch auf sich warten lassen kann.

PostgreSQL Observability: Graphische Übersicht der Statistik-Views

14. November 2020 um 14:20

PostgreSQL ist ein komplexes relationales Datenbankmanagementsystem und bietet viele Möglichkeiten zur Überwachung und Optimierung. Doch vor der Optimierung steht erst einmal eine Analyse an, bei welcher die Komponenten mit Nachbesserungsbedarf ausfindig gemacht werden können. Dies ist bei PostgreSQL an vielen Stellen möglich.

Der heutige Linktipp beschäftigt sich mit dieser Aufgabe: pgstats.dev. Diese Webseite visualisiert verschiedene PostgreSQL-Komponenten und die Funktionen, die bei der Analyse helfen. Mit einem Klick auf eine der Komponenten gibt es eine kleine Funktionsreferenz dazu.

Weitere Informationen im Blogartikel vom Autor dazu. PostgreSQL Observability wurde vor einigen Tagen auf das kürzlich veröffentlichte PostgreSQL 13 aktualisiert.

Programmierung mit Ontologien kombinieren

10. Oktober 2020 um 22:00

Heute stelle ich euch mein aktuelles Projekt vor: eine Programmiersprache, die das imperative Programmiersprachenparadigma um logische Aspekte ergänzt, um durch logische Schlussfolgerung weniger Code schreiben zu müssen.

→ Schnellzugriffe für diesen Artikel: Arbeitspapier (engl., PDF), GitHub-Repository

Programmierung ist heutzutage ein extrem wichtiges Werkzeug geworden. Dabei hat sich in den vergangenen Jahren der Fokus geändert: war der „portable Assembler“ namens C in den 1970ern noch dafür da, Abstraktion für verschiedene Plattformen zu ermöglichen, geht es heutzutage eher darum, Funktionalität so zusammenzustecken, dass das resultierende Programm den Anforderungen genügt. Bis heute ist allerdings der imperative Ansatz derjenige, der unangefochten die Programmierlandschaft beherrscht. Dabei spezifiziert der Programmierer Schritt für Schritt den Lösungsweg, den der Computer dann ausführt.

Ein Blick in die Geschichte

Es ergeben sich allerdings einige Probleme, die früher keine größere Aufmerksamkeit benötigten, heute allerdings die Arbeit erheblich erschweren: so konnte man es sich in den 1980ern leisten, die komplette Codebase selber zu entwickeln. Ken Thompson formulierte dabei das Credo „You can't trust code that you did not totally create yourself.“ Dieser Satz gilt heute eigentlich nach wie vor, da importierter Code auf dem gleichen Level wie die eigene Software agiert.

Nun gibt es verschiedene Programmiersprachen, die auch verschiedene Zwecke erfüllen: während das zuvor erwähnte C auf der Low-Level-Ebene unterwegs ist, gibt es Sprachen wie Python, die immer weiter abstrahieren.

Diese Abstraktion nimmt allerdings keineswegs ein Ende und das macht die Sache besonders interessant. Denn eigentlich befinden wir uns bei den imperativen bzw. prozedularen Sprachen auf Stufe 3 von insgesamt 5. Auf den tieferen Stufen haben wir Maschinencode oder Assemblersprachen, auf deren darüberliegenden Stufen liegen SQL, die Unix Shell und R (4GL) sowie Mercury und OPS5 (5GL). Während die Sprachen der 4. Generation noch den meisten geläufig sind, werden sicherlich die wenigsten von Mercury o.ä. gehört haben.

Ziel dieser Abstraktion ist es übrigens, dem Computer nur noch das Problem zu beschreiben und diesen dann den Lösungsweg ermitteln zu lassen.

Als ich davon vor einigen Jahren gehört habe, hat es mich nicht mehr losgelassen. Und so überlege ich seit einigen Jahren, wie man neben C, C++, Rust und Python eine Möglichkeit nutzen kann, abstrakt Programme zusammenzustellen, die dann vom Computer zusammengeschweißt werden (und zwar ohne dynamische Typisierung). Eben wie die klassische Unix-Philosophie, die sich in den Code hineinzieht.

Vor einigen Monaten hat sich abgezeichnet, dass sich die Idee am besten in einer (vorerst experimentellen) Programmiersprache umsetzen lässt.

XKCD 2309: X, License: CC BY-NC 2.5

xkcd 2309: X, License: CC BY-NC 2.5

Was aber ist nun die Besonderheit der Sprache? Die oben eingeführten Sprachen der fünften Generation sind sehr funktional, deklarativ – und vielen unhandlich. Man ist zu sehr an die imperative Arbeitsweise gewöhnt, um sie komplett auszutauschen. Trotzdem blieb bei mir der Aspekt, die imperative Arbeitsweise durch logische Programmierung zu erweitern, irgendwie hängen. Ausschlaggebend hierfür war das Semantic Web, das in den 2000ern besonders Konjunktur hatte. Aber auch Wikidata fasziniert mich mit der Art und Weise, wie Informationen formalisiert werden können, um anschließend Wissen daraus ableiten zu können. So ist es heute schon möglich, die Mondphase am Geburtstag von John von Neumann abzufragen, ohne einen genauen Algorithmus hierfür spezifzieren zu müssen. Ehrlich gesagt finde ich das extrem spannend und überlege, wie sich das sinnvoll in der Programmierung einsetzen lässt. Denn für obiges Szenario müssen wir nicht einmal auf maschinelles Lernen zurückgreifen, sondern können uns an einem regelbasierten System bedienen, das in formalen Umgebungen besonders hilfreich ist.

Um was es geht

Dafür habe ich nebenbei begonnen, die Ontology-assisted Experimal Programming Language, kurz OXPL, in eine Grammatik zu gießen.

Die OXPL geht dabei auf einen Ausflug in die Welt der Ontologien: bei diesen geht es grob gesagt darum, Wissen dem Computer zugänglich zu machen, damit dieser dies Verarbeiten kann. Teilweise wird dies schon heute umgesetzt, wenn wir uns Klassenhierarchien in z.B. Java anschauen.

Ich möchte nur einmal kurz die Schlüsselaspekte umreißen: beginnen wir mit dem „Hello world“.

fn main() {
    println("hello, world");
}

So weit, so unspektualär. Wie wir sehen, sind wir allerdings auf dem Gebiet der imperativen Programmierung unterwegs - und das ist ein entscheidender Aspekt: man kann sie jederzeit als Fallback nutzen. Wagen wir aber nun den Sprung ins kalte Wasser: der folgende Codeblock implementiert einmal eine Addition: zwei Summanden werden abgefragt, das Ergebnis wird ausgegeben.

instance Summand1: integer {
    std::fetchesFrom <std::io::stdin>.
    <std::io::stdin> std::io::prompts "Summand 1: ".
}

instance Summand2: integer {
    std::fetchesFrom <std::io::stdin>.
    <std::io::stdin> std::io::prompts "Summand 2: ".
}

instance Sum: std::math::sum {
    std::math::sum::hasSummand <Summand1>.
    std::math::sum::hasSummand <Summand2>.
}

fn main() {
    println("The sum is " + string::from(Sum));
}

Hier sehen wir das charakteristische Merkmal der Sprache: das Programm ist bis auf die main-Funktion lediglich eine Beschreibung zweier Summanden sowie einer Summe. Die Tripel (Subjekt - Prädikat - Objekt - Punkt) formulieren explizit die Beziehungen und Anforderungen untereinander. Nun soll der Interpreter bzw. Compiler im nächsten Schritt über Regeln sowie viele Informationen ableiten, dass eine imperative Ausführung möglich und eine Executable entsteht. Auch wenn man mit Python dieses Vorhaben in einer Zeile lösen könnte, würde das obige Beispiel rein konstruktiv bereits die Summanden als Ganzzahlen erkennen, sodass Bugs wie eine Summe "11" bei den Summanden 1 und 1 vermieden werden.

Ein weiterer Aspekt: Sicherheit. Der Super-Gau unter importierten Bibliotheken sind unerwartete, bösartige Seiteneffekte. Wie wäre es, wenn jegliche Kommunikation nach außen hin erlaubt werden muss? Dann fällt besonders auf, wenn eine Calculator-Bibliothek auf einmal Festplatten- und Netzwerkzugriff möchte. Für das Ausgabebeispiel würde das Ganze so aussehen:

allows(this, std::io::print, main).     

fn main() {
    println("hello, world!");
}

OXPL wird dieses Permissionsystem von Anfang an implementieren, sodass spätere Nachbesserungen wie die libseccomp im Normalfall by-design nicht mehr notwendig ist.

Was ich bereits habe

Ich habe bereits angefangen, als Sideproject an der ontology toolchain (ontc) zu entwickeln. Das wird die Referenzimplementierung sein. Sie ist in C geschrieben und steht bereits auf GitHub zur Verfügung.

Mit

sudo apt install build-essential git bison flex
git clone https://github.com/v-gar/ontc.git
make

kann die Anwendung gebaut werden. Die Executable ontc liegt dann im Buildverzeichnis. Nun kann eine Datei helloworld (eine Dateiendung habe ich noch nicht festgelegt) erstellt werden, die das obige Hello world enthält. Das Ausführen ist mitteils ./build/ontc run helloworld möglich. Um die Ontologie zu testen, habe ich folgendes Beispiel:

fn hey() {
    println("Hey!");
}

fn main() {
    println("Hello world!");
}

<main> isPreceededBy <hey>.

Dieses Beispiel zeigt, dass über diese Tripel auch Einfluss auf den Programmablauf genommen werden kann, sofern (wie im Beispiel) der Interpreter bestimmte Prädikate berücksichtigt.

Ein Anfang

Diese beiden Beispiele sind Teil des Proof-of-Concepts dieses Projekts. Großartig mehr ist noch nicht möglich. Zwei Dinge sind für die Sprache entscheidend: gute Entwicklungswerkzeuge und eine vielfältige, hochqualitative Standardbibliothek. Die Standardbibliothek gibt, ähnlich wie bei schema.org, den Rahmen und definiert, wie üblicherweise Prädikate aufgebaut sind, wie mit dem Compiler interagiert werden kann, etc. Die ontc soll dabei mit gemeinsamer Codebase als Toolchain dienen und einen Interpreter, Debugger und Analyzer beherbergen, um schnell gute Programme zu schreiben.

Wer gerne mehr zu meinem Projekt lesen möchte, kann sich mein Arbeitspapier (PDF) hierzu anschauen.

Da dieses Vorhaben unmöglich in absehbarer Zeit alleine umsetzbar ist, suche ich nach Mitstreitern, die sich an diesem Projekt beteiligen wollen. Ihr könnt euch hierzu unter meiner Kontaktadresse melden!

Combining Programming with Ontologies

10. Oktober 2020 um 22:00

Today I'll present my newest project to you: a programming langauge which incorporates the imperative programming paradigm but extends it aspects of the logic programming paradigm.

→ Quick access: working paper (PDF), GitHub repository

Programming is a very important tool today. During the last decades the focus has been changed: C started as a „portable assembler“ to abstract different target platforms. That was back the 1970s. Today is about combining different components to compose applications fulfilling requirements. But one thing remains until today: the imperative approach. In this paradigm, the programmer specifies every step to reach a desired state or result.

A look at the history

However, there are some problems that didn't need more attention in the past, but which make work much more difficult today: for example, in the 1980s, people could afford to develop the whole codebase themselves. Ken Thompson puts it in a nutshell: “You can't trust code that you did not totally create yourself.” This sentence is still valid today because imported code executes on the same level as your own one.

There are different programming languages that also serve different purposes: while the previously mentioned C works on the low level, there are languages like Python that abstract further and further.

This abstraction does not end here and this makes it particularly interesting. Actually, we are at level 3 of 5 for the imperative or procedural languages. Level 1 and 2 are machine code or assembly languages. The higher levels 4 and 5 contain SQL, the Unix shell and R (4GL) as well as Mercury and OPS5 (5GL). While most people are still familiar with some of the 4th generation languages, very few will have heard of Mercury or similar.

By the way, the goal of this abstraction is to describe only the problem to the computer and to let it find the solution itself.

When I heard about it a few years ago, it did keep preying on my mind. I started thinking about a solution located between system programming langauges like C, C++ or Rust and dynamic scripting langauges like Python. A solution where you can specify an abstract program with the support of high-quality components from a standard library which can be linked together. Just like the classic Unix philosophy, just on code-level.

Classification

A few months ago it became apparent that the idea could best be implemented in a (experimental) programming language.

XKCD 2309: X, License: CC BY-NC 2.5

xkcd 2309: X, License: CC BY-NC 2.5

But what is the special feature of language? The fifth generation of programming languages was very functional, declarative - and that might be unfamiliar for many developers. What about not replacing but extending imperative programming style with logical programming?

What is the project about?

I've started to develop a grammar for the Ontology-assisted Experimental Programming Language (OXPL).

The OXPL dives into the world of ontologies: roughly speaking, ontologies are about making knowledge accessible to the computer so that it can process it. This type of knowledge representation is present today already: Java class structures are a good example.

Java class hierarchy

Let me just briefly outline the key aspects: let's start with the "Hello world".

fn main() {
    println("hello, world");
}

As we can see, we are in the field of imperative programming - and this is a crucial aspect: you can use it as a fallback at any time. But now let's take the plunge: the following code block implements an addition: two summands are can be input and the result is output.

instance Summand1: integer {
    std::fetchesFrom <std::io::stdin>.
    <std::io::stdin> std::io::prompts "Summand 1: ".
}

instance Summand2: integer {
    std::fetchesFrom <std::io::stdin>.
    <std::io::stdin> std::io::prompts "Summand 2: ".
}

instance Sum: std::math::sum {
    std::math::sum::hasSummand <Summand1>.
    std::math::sum::hasSummand <Summand2>.
}

fn main() {
    println("The sum is " + string::from(Sum));
}

Here we see the most important feature of the language: the program is, except for the main function, only a description of two summands and a sum. The triples (subject - predicate - object - period) explicitly state the relations and requirements among each other. In the next step the interpreter or compiler is supposed to derive rules and a lot of information in order to create the executable. Even if Python would be able to solve this task in one line, the above example would already recognize the summands as integers by-design, so that bugs like a sum "11" of the summands 1 and 1 can be avoided.

The program creates this universe of discourse and states the following relations:

Visualization of the example program

Instances (singletons) are blue, classes are red, special built-in resources like the stdin are green.

Using logical rules, the interpreter and reasoner can now infer additional facts and relations. Thus, it automatically concludes that it needs to create two input procedures to calculate the sum which is queried in the main function.

Another aspect: security. Malicious side effects are a serious problem when importing third-party libraries. But what if all communication to the outside world has to be permitted by the developer? A calculation library requiring hard disk and network access will propably attract attention by the programmer. For the "hello world" example it would look like this (if enforced):

allows(this, std::io::print, main).        

fn main() {
    println("hello, world!");
}

The first line means that the program (root) allows the main resource/function to use the std::io::print permission which is needed in order to write to the stdout. You don't need to write this every time for the built-in printing features as they are trusted specially but you will be able to disable this behavior so that every communication of the program with the outside world has to be permitted.

OXPL will implement this permission system from the beginning, so that later improvements like with libseccomp are no longer necessary.

What is already done

I have already started to develop the ontology toolchain (ontc) as a sideproject. This will be the reference implementation. It is written in C and is already available on GitHub. ontc will contain an interpreter (later perhaps a LLVM compiler), a debugger and an analyzer which accelerates programming as it support developers with the ontology while writing the code. The ontc binary will be licensed under the GNU GPLv3, the underlying libraries for the execution and compilation of ontc programs (i.e. libontg and liboxpl, also included in the repository) will be licensed under the GNU LGPL v2.1.

You can build the application using:

sudo apt install build-essential git bison flex
git clone https://github.com/v-gar/ontc.git
make

The executable ontc is then located in the build directory. Now you can create a file called helloworld (I haven't defined a file extension yet) which contains the hello world program from above. You can execute it by running ./build/ontc run helloworld. To test the ontology there is the following example you can use:

fn hey() {
    println("Hey!");
}

fn main() {
    println("Hello world!");
}

<main> isPreceededBy <hey>.

This example shows, that these triples can be used to influence the program flow, if (like in the example) the interpreter considers certain predicates.

A starting point

These two examples are part of the proof of concept of this project. This is a starting point. Two things are crucial for the language: good development tools and a high-quality standard library covering many application fields. The standard library gives, similar to schema.org, the framework and defines how predicates are usually constructed, how to interact with the compiler, etc. The ontc should serve as a toolchain with a common codebase and contains an interpreter, debugger and analyzer to write good programs quickly.

If you like to read more about my project, you can have a look at my working paper (PDF).

Since this project is impossible to realize alone in the foreseeable future, I am looking for people who want to participate in this project. You can contact me via email!

❌