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

OpenSSL 3.0 erschienen

07. September 2021 um 16:21

OpenSSL ist eine Softwarebibliothek, die Implementierungen für bestimmte kryptographische Verfahren, die besonders in der Netzwerkkommunikation eingesetzt werden, bereitstellt. Heute wurde Version 3.0 veröffentlicht.

Neue Versionierung

Anwender und Entwickler, die bereits mit OpenSSL arbeiten, werden mitunter erschrocken sich fragen, warum dieser Versionssprung stattfindet – so war zuletzt Version 1.1.1l aktuell und OpenSSL für eine sehr zurückhaltende Numerierung bekannt.

OpenSSL steigt nun allerdings, wie bereits 2018 angekündigt, auf die Semantische Versionierung um, welche ein klares Schema vorgibt, welche Änderungen zu welcher Anhebung der Versionsnummer führen. Dabei liegt der Dreh- und Angelpunkt bei der API: wird die erste Versionsnummer (Major) erhöht, gibt es Änderungen an der API, die nicht abwärtskompatibel sind. Ergänzungen erhöhen die Versionnummer hinter dem ersten Punkt und Patches die nach dem zweiten Punkt. Ein Sprung von 1.1.1 auf 3.0 steht also für nicht abwärtskompatible API-Änderungen, weswegen alle, die auf OpenSSL setzen, einen Blick auf die Neuerungen werfen sollten, die wir uns gleich anschauen werden. Die Versionnummer 2.0 wurde im Übrigen übersprungen, da teilweise das FIPS-Modul schon auf die Weise numeriert wurde.

Änderungen

Folgende Änderungen fallen im Changelog auf:

  • Mit Version 3.0 wird ein neues Konzept zur Modularisierung eingeführt: die Provider. Sie ersetzen die ENGINE API sowie dessen Implementierungen und sollen die Wartbarkeit der Implementierungen erhöhen. Algorithmen können nun flexibel eingeführt werden, solange es eine API gibt, die den entsprechenden Typen unterstützt. Das Kontext wird in der entsprechenden Man-Page ausführlich erklärt. Die Algorithm Types heißen nun Operationen (operations).

  • Weiterhin soll vor allem aufgeräumt werden. Dafür wurden viele API-Funktionen als veraltet deklariert, darunter TLS_MAX_VERSION, DTLS_MAX_VERSION, DTLS_MIN_VERSION und viele Low-Level-Funktionen.

  • Ein Byte-Order-Mark am Anfang von PEM-formatierten Dateien wird nun ignoriert.

  • Die Validierung der Operationsparameter kann nun solange verzögert werden, bis die eigentliche Operation stattfindet, da die Implementierungen der kryptographischen Operationen in die Provider verschoben wurde. Somit lässt sich das Verhalten und die Fehlerbehandlung verändern. Als Beispiel wird angeführt, dass der Funktionsaufruf einer nicht unterstützen Kurve mit EVP_PKEY_CTX_set_ec_paramgen_curve_nid() nicht fehlschlagen wird, wohl aber Funktionen zur Schlüsselgenerierung mit EVP_PKEY_CTX.

  • ERR_GET_FUNC() wurde vollständig entfernt.

  • Datumsangaben können nun gemäß ISO 8601 formatiert werden. Dies ist allerdings keine Standardeinstellung.

  • Weiterhin gibt es Änderungen bei den Funktionssignaturen. So wechseln die Signaturen der Funktionen zum Setzen oder Ausgebnen von Optionen für SSL und SSL_CTX von unsigned long auf uint64_t. Somit kann sichergestellt werden, dass die Datentypen auf allen Systemen exakt 64 Bit lang sind statt der bisherigen Anforderung auf mindestens 32 Bit. Nebenbei entspricht ein uint64_t einem long long.

  • Clientseitig initiierte Renegotiations sind nun standardmäßig deaktiviert und können mit z. B. -client_renegotiation oder SSL_OP_ALLOW_CLIENT_RENEGOTIATION wieder aktiviert werden.

  • abspath- und includedir-Pragmas werden im Code verwendet, um Sicherheitsrisiken durch relative Inkludierung aus dem Weg zu gehen.

  • Die APIs für PKCS#12-Dateien, die oft eingesetzt werden, um Private Key und Zertifikat in einer Datei zu speichern, wurden so erweitert, dass sie nun einen Bibliothekskontext akzeptieren. pkcs12 selber nutzt nun PBKDF2, AES und SHA-256 mit einem MAC-Iterationszähler gemäß PKCS12_DEFAULT_ITER. openssl pkcs12 gibt überdies nun alle PKCS#12-Attribute und nicht mehr nur das erste aus.

  • Linux' Kernel TLS wird nun unterstützt.

  • Ausgaben verschiedener Kommandos wurden leicht angepasst.

  • openssl speed greift nun nicht mehr auf Low-Level-APIs zurück.

  • Die verfügbaren Provider können nun per openssl list -providers angezeigt werden.

  • CMP und CRMF gemäß RFC 4210, 4211 und 6712 wurden hinzugefügt.

  • DH Modulos müssen nun mindestens 512 Bits lang sein.

  • FFDHE Key Exchange in TLS 1.3 wird nun unterstützt.

Der Fokus lag bei diesem Release besonders beim FIPS-Modul. Darüber hinaus strebt OpenSSL eine Zertifizierung nach FIPS 140-2 an, weswegen einige Änderungen Anpassungen an Standards enthalten. So wird z. B. nicht mehr möglich sein, mehr als 264 TLS Records in einem Zug mit AES-GCM zu verschlüsseln, um die Einzigartigkeit von Schlüssel und Intialisierungsvektor (IV) zu gewährleisten. PBKDF2 orientiert sich überdies nun an SP800-132 statt an PKCS#5 RFC 2898.

Diese zahlreichen Änderungen machen mitunter eine Migrationen bei allen OpenSSL-einsetzenden Programmen notwendig. Die OpenSSL-Entwickler stellen hierfür eine entsprechende Migrationsanleitung bereit.

Neue Lizenz

Zu guter Letzt gibt es Anpassungen bei der Lizenz. OpenSSL 3.0 steht unter der Apache License 2.0. Somit gilt nun nicht mehr die angepasste BSD-Lizenz, die eine Werbeklausel enthält. Die Umstellung wurde bereits vor vier Jahren anvisiert.

Kurzeinordnung

Es freut mich, dass sich einiges beim OpenSSL-Projekt tut. Die Liste der Änderungen ist lang, es wird viel bereinigt. Allerdings bleibt in meinen Augen die Sorge, dass dieser große Release langsamer als sonst seinen Weg in die Endprodukte findet. OpenSSL wird in allen möglichen Systemen auch fernab von klassischen Computersystemen eingesetzt und stellt somit das Rückgrat sicherer Netzwerkkommunikation dar. Die Umstellung der Versionierung sorgt nicht nur für kurze Verwirrung, sondern sollte auch im Hinterkopf behalten werden, wenn Versionsprüfungen fehlschlagen: sie könnten so programmiert sein, dass sie nur den Major-Release überprüfen - dabei sollte der überwiegende Teil der Software, die bereits mit 1.1.1l lief, auch mit OpenSSL 3.0 laufen.

Linux wird 30 Jahre alt

25. August 2021 um 23:20

Genau auf den Tag vor 30 Jahren erreichte in diesen Minuten die Welt eine Nachricht, die sie nachhaltig gestaltete: Linus Torvalds hat in der Usenet-Gruppe comp.os.minix seine Arbeit an einem Betriebssystem angekündigt, das später als Linux bekannt werden und große Teile der Computerindustrie, vor allem das Internet, dominieren sollte. Der Rest ist Geschichte.

Ich bin zwar erst seit 2010 dabei, aber doch überrascht, dass ein solches System wie Linux niemals einen „fertigen“ Status erreichen wird. Klar, neue Geräte und neue Treiber braucht es immer, aber selbst Kernkomponenten befinden sich in einem ständigen Wandel. Beispiel: Paketfilter. Während sich iptables gewissermaßen etabliert hat, gilt es schon längst als veraltet: nftables soll hier für die Ablösung sorgen. Aber auch hier steht mit eBPF ein weiterer potentieller Nachfolger bereits in den Startlöchern. All dies hat natürlich auch mit den stetig wechselnden Anforderungen zu tun, aber auch hier zeigt sich mit der Anpassungsfähigkeit der Vorteil von Open Source. Programmierer können stetig eigenmächtig neue Module entwickeln, die dann in den Hauptzweig aufgenommen werden können.

Und die größten Änderungen stehen erst noch an: so bereitet das Projekt Rust for Linux eine zweite Programmiersprache neben C für die Treiberentwicklung vor. Es bleibt also spannend.

Happy Birthday, Linux!

Uniswap erscheint auf Optimistic Ethereum in Alpha-Version

15. Juli 2021 um 17:16

Kurz notiert: Uniswap, die Kryptowährungsbörse, die sich komplett in einem Smart Contract abbildet und Anfang des Jahres ihre dritte Generation veröffentlicht hat, kündigt nun an, mit Optimistic Etheruem ein erstes Layer-2-System testweise zu unterstützen. Dabei handelt es sich um einen Alpha-Release, der höchstens für Tests geeignet ist, da das Risko des vollständigen Verlustes eingezahlter Werte noch hoch ist.

Vorteile sollen geringere Transaktionsgebühren und eine höhere Geschwindigkeit sein. Um Optimistic zu nutzen, transferiert man den gewünschten Beitrag zum Optimstic Gateway-Contract, der eine Art Portal dargestellt. Dann stellt dann seine Ethereum-Clients auf Optimistic um und kann Uniswap über Optimistic Ethereum nutzen.

Momentan sind noch diverse Einschränkungen vorhanden, da es sich um eine Demo handelt, die das theoretische Potential in einem Feldversuch demonstrieren soll. Rücktransfers auf Ethereum sind mit einer Sperrfrist von 7 Tagen belastet, es gibt nur fünf handelbare Token, Störungen sind nicht zu vermeiden und der Transaktionsdurchsatz ist bewusst auf 0,6 Transaktionen pro Sekunde beschränkt.

Unix-Timestamp im Terminal anzeigen

30. Juni 2021 um 22:40

Kurzer Tipp: in der Linux-Welt ist häufig, wenn es um Zeitangaben geht, die sog. Unixzeit anzutreffen. Hierbei werden die Sekunden nach dem 01.01.1970 00:00 Uhr UTC angegeben. So kann einfach eine Datumsangabe abgespeichert werden und anschließend mit den richtigen Methoden wieder umgerechnet werden. Möchte man den aktuellen Zeitstempel im Terminal anzeigen, kann man folgenden Aufruf nutzen:

date +%s

Nicht intuitiv zu finden, aber doch effektiv. So muss man nicht den Umweg über Webseiten oder eigens dafür entwickelte Programme gehen.

Linux 5.12.13 und Probleme mit AMD GPU

26. Juni 2021 um 12:20

Kurz notiert: wer eine AMD GPU mit VEGA-Technologie nutzt, wird wenig Freude mit Linux 5.12.13 haben. Nach dem Kernelupdate fiel mir auf, dass der GPU-Lüfter durchgängig lief und sensors einen durchgängig hohen Stromverbrauch, auch bei abgeschaltetem Display Manager, angab. Komischerweise war der Google-Vorschlag bei "linux 5.12.13" auch sofort "gpu usage". Ein kurzer Blick ins 5.12.13 shortlog zeigt, dass es tatsächlich Änderungen an den amdgpu-Treibern gab.

Hier ist der dazugehörige Bug im Bugtracker des Kernelteams und hier der Revert im Code.

Der Autor Yifan Zhang von AMD gibt als Grund an:

Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases.

Der Fix sollte somit in den nächsten Versionen inkludiert sein.

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

❌