Seit gestern bin ich frisch aus dem Slowenien Urlaub zurück. Dieses Jahr haben wir uns für das Soćatal¹, nicht weit von der italienischen Grenzen entfernt, entschieden. Coronapandemie bedingt ist man dieses Jahr ein wenig eingeschränkt und ich wollte nicht so gerne in ein Hotel, da kam meine bessere Hälfte mit der Idee Soća um die Ecke (eine Kollegin von ihr war wohl vorher auch da).

Sieben Tage waren wir da, auf einem netten kleinen abgelegenen Campingplatz und haben einen schönen Wanderurlaub verbracht.
Ich finde dieses nette kleine Tal, abseits des Massentourismus ist auch ohne Coronapandemie sehr empfehlenswert. Wandern, Mounten-Bike fahren, Rafting & Kanu fahren, geht da alles :-).

1) Soća

Es war mal wieder soweit, es wurde ein Voptop Release fertig. Mit diesem Release ist Voptop endlich unabhängig von libnice¹ und ich verabschiede mich damit vom ICE² Protokoll.
Der Verbindungsaufbau mit ICE hat einfach viel zu lange gedauert und sehr zuverlässig war das auch nicht. Außerdem war es am Ende doch immer so, dass es nie ohne TURN³ Server ging. Also habe ich mich entschiedenen ein Voptop eigenes Relay bzw. Gateway zu schreiben, für den Fall das keine direkte Kommunikation zwischen einzelnen Voptop peers zustande kommen kann oder wegen Inkompatibilitäten zwischen IPv4 <-> IPv6 und Ähnlichem.
Das war alles andere als einfach, ist jetzt aber fertig und bisher scheinbar sehr stabil. Der Verbindungsaufbau mittels meines Gateways ist mehr als zehnmal so schnell, wie es mit libnice in Kombination mit einem TURN-Server war.
Außerdem hab ich eine Reihe von Bugs behoben, von nicht korrekter Initialisierung der Audioaufzeichnung für Videochats bis hin zum fixen der Webcam Auswahl für Videochats.
Ferner kann man mittlerweile Voptop nicht nur auf der Voptop Webseite runterladen, sondern auch im Snapcraft Store.
Von Flatpak zur Erstellung eines Installationspaketes hab ich mittlerweile wieder abstand genommen. Das Argument für Flatpak, nämlich das es vollständig Open Source ist, ist leider auch sein stärkstes Gegenargument. Man hat zwar mit Flathub⁴ einen zentrale Paketquelle, diese wird aber durch Github⁵ gespeist (es gibt also keine eigene vernünftige Infrastruktur). Um es kurz zu machen; auf Github habe ich keinen Bock, ich will da keinen Account für Voptop haben und außerhalb einer allgemein bekannten und zugänglichen Paketquelle macht das keinen großen Sinn.

1) libnice
2) ICE
3) Turn
4) Flathub
5) Github

Es ist bald mal wieder soweit, absehbar werde ich eine neue Version von Voptop¹ freigeben. Womit ich mich wieder meinem alten „Voptop Release - Management“² Problem annähere. Bis jetzt bin ich noch immer nicht so richtig dazu bekommen, mir mittels Jenkins einen Build Server aufzusetzen, das hole ich jetzt nach. In dem Zuge werde ich jetzt erstmals zusätzlich zu „deb“³ Paketen auch „Snappy“⁴ Pakete anbieten. Snappy ist ein Paket Format von Canoncial⁵ (dem Unternehmen hinter Ubuntu⁶ Linux).
Für das Erste werde ich mich auf das automatisierte bauen von Snappy Paketen konzentrieren, denn ich bin mir nicht sicher, ob ich mit Voptop noch langfristig die Paketierung mit deb weiter unterstützen will (der Aufwand ist einfach zu hoch, man paketiert ab Ende für x Distributionen und deren Versionen).
Snappy bringt eine Vielzahl von Vorteilen gegenüber deb. Der wichtigste Vorteil ist für mich, dass ich mit einem einzigen Installationspaket sehr viele Linux Distributionen auf einmal unterstütze⁷. Auch sehr wichtig für mich ist, dass ich mit Snappy einen zusätzlichen „Vertriebskanal“ für Voptop bekomme (der ist aber auch einer der Kritikpunkte von Snappy, dazu später mehr), den Snappy App-Store.

Das Paketieren mit Snappy ist auf den ersten Blick sehr einfach. Man schreibt eine Konfigurationsdatei (im yaml⁸ Format). In dieser Konfigurationsdatei gibt man einige Metadaten an (Name, Beschreibung etc.), wo der Quellcode zu finden ist (im Dateisystem, in einem Source-Repository oder Ähnlichem) und gibt ein sogenanntes „build plugin“ an (make, cmake, qmake etc.). Im Weiteren spezifiziert man die Abhängigkeiten, die benötigt werden, um das Projekt zu bauen (im Grunde die deb - dev Pakete der verwendeten Bibliotheken) und die Pakete, die benötigt werden, um die Anwendung laufen zu lassen.
Außerdem bestimmt man eine Art Laufzeitumgebung, core18 oder core20 zum Beispiel. Da das Ganze von Canoncial kommt, basiert die Laufzeitumgebung natürlich auf Ubuntu (jeweils die LTS Versionen, wie man schon am Namen core18 und core20 sieht). Im Wesentlichen wird am Ende mit Snappy eine Ubuntu Distribution um die eigentliche Anwendung herum aufgebaut, die aber nur die Abhängigkeiten besitzt, welche die mit Snappy paketierte Anwendung zur Laufzeit braucht (was die Pakete im Vergleich zu „nativ“ paketierten Anwendungen immer noch extrem „voluminös“ macht).

Einer der am häufigsten kritisierten Eigenschaften von Snappy ist, dass man die Paketquelle nicht frei wählen kann. Canoncial betreibt die einzige Paketquelle, alternative App-Stores kann man nicht verwenden (zumindest ist das bisher so). Für mich ist das zumindest für das erste kein Problem, ob ich das jedoch dauerhaft will weiß ich noch nicht. Auf jeden Fall gibt es aber Alternativen, am interessantesten scheint mir dabei Flatpak⁹ zu sein (damit habe ich mich aber noch nicht tief greifend genug befasst). Flatpak hat wohl derzeit einer der größten User und Entwicklungs Basen, absehbar werde ich mich also auch damit befassen.

1) Voptop
2) Voptop Release - Management
3) deb
4) Snappy
5) Canoncial
6) Ubuntu
7) Unterstützte Distributionen
8) YAML
9) Flatpak

Wir stehen vor der nächsten Bücherverbrennung. Ein weiteres Mal in der Geschichte ist man nicht einverstanden mit dem, was niedergeschrieben wurde. Dieses Mal geht es aber nicht um das geschriebene und gedruckte Wort auf Papier, sondern um Quellcode in digitaler Form. Wir sind verdammt die Geschichte zu wiederholen.

Quelle: Linux-Kernel: Richtlinien für inklusive Sprache integriert

Lest euch mal diesen Heise¹ Beitrag durch und schaut euch an, was Trump getwittert¹¹ hat. Ein Leser hat dazu einen Kommentar² geschrieben, den möchte ich hier mal vollständig zitieren, denn dem ist nichts hinzuzufügen:

Die Worte "serious force" mit "massiver Gewalt" zu übersetzen, scheint mir mindestens schlecht übersetzt, man gewinnt sogar das Gefühl, es ist eine tendenzielle Übersetzung, neudeutsch "Framing"
"serious" kann auch "massiv" bedeuten, aber in aller Regel ist "ernsthaft" damit gemeint, oder "schwerwiegend", "ernstzunehmend", "gravierend"
"force" hat verschiedene Bedeutung, "Gewalt" ist eine, aber nicht die einzige
es kann "Stärke", "Macht", "Energie", "Zwang", "Druck", "Kraft" bedeuten, als Verb kann es auch "durchsetzen" bedeuten
"may the force be with you" wäre mit "Möge die Gewalt mit dir sein" auch falsch übersetzt...
"police force" sind die "Einsatzkräfte" und nicht "Polizeigewalt" (das wäre "police violence")...
"labour force" ist die "erwerbstätige Bevölkerung" und nicht die "Arbeitergewalt"...
"magnetic force field" ist ja das "magnetische Kraftfeld" und nicht die "magnetische Gewalt"...
"driving force" ist die "Antriebskraft" und nicht die "fahrende Gewalt"...
die korrekte Übersetzung für "serious force" würde ich in Anlehnung an das behördensprech etwa so sehen:
"ernsthafte Anwendung von Zwangsmitteln"
wenn Trump wirklich von "massive Gewalt" hätte schreiben wollen, dann hätte er doch vermutlich "massive violence" oder ggf. auch "brute force" geschriebe

PS: Ihr wisst nicht was Framing ist? Dann sei euch dieser Artikel³ in „die Welt“ ans Herz gelegt.

1) heise.de

11) Twitter.com

2) heise.de

3) die Welt

Seit einiger Zeit (eigentlich schon recht lange) arbeite ich daran ICE¹ aus meinem Videochat und Instant Messenger Projekt Voptop² zu entfernen. Bisher verwende ich dafür eine Bibliothek Namens libnice³, mit der bin ich aber nicht besonders zufrieden. Der Verbindungsaufbau dauert ewig und die Verbindung, die damit entsteht, ist auch nicht besonders stabil. Von Datendurchsatz und Latenz ganz zu schweigen. Für Videokonferenzen meiner Meinung nach völlig ungeeignet und besonders toll ist die API auch nicht gerade. Am Ende war es im Grunde auch immer so, dass via ICE nur eine Verbindung mittels eines TURN⁴ Server erzeugt werden konnte, man also bei üblichen Internetanbindungen in unseren Breitengraden über einen Router quasi nie ohne Relay auskam. STUN⁵ funktionierte bestenfalls in ausnahmen.
Am Ende habe ich mich dafür entschieden ein eigenes Gateway/Relay für Voptop zu programmieren. Das Ganze wollte ich auf Basis von „none blocking sockets“ machen und tat ich auch. Dafür habe ich die Sockets folgendermaßen zu nicht blockierend erklärt:

bool
CSockStream::setNoneBlocking() {
  if (mSocket < 0) return false;

  int flags = fcntl(mSocket, F_GETFL, 0);
  if (flags == -1) return false;
  flags = (flags | O_NONBLOCK);
  return fcntl(mSocket, F_SETFL, flags) == 0;
}

Das ganze funktioniert auch wunderbar, so lange man es als Client <-> Client Anwendung auf dem eigenen Rechner laufen lässt, es funktioniert sogar noch hervorragend, wenn man es auf Rechnern im eigenen lokalen Netzwerk laufen lässt Aber wehe man versucht es über ein weniger transparentes und zuverlässiges Netzwerk (unser gutes altes Internet zum Beispiel). Da wird das Ganze quasi zum Flöhehüten. Das, was man sendet, kommt bestenfalls sporadisch so an, wie man es raus schickt. Gerne kommt es teilweise an, oder in mehreren Häppchen, von Zeit zu Zeit auch mal gar nicht. Wenn es darum geht, verschlüsselte Daten zu transferieren, ist das der Super GAU.
Ich habe mich letztlich entschieden quasi eigene „None blocking sockets“ zu entwickeln, einfach in dem ich zuvor prüfe ob das Lesen eines Sockets blockieren würde, und sollte es so seien darauf zu verzichten bis der Socket verspricht es nicht zu tun. Das Ganze habe ich mit folgender Methode gemacht:

bool
CSockStream::isSocketReady() {
  bool             res;
  fd_set          sReady;
  struct timeval  nowait{};

  FD_ZERO(&sReady);
  FD_SET(this->mSocket,&sReady);
  memset((char *)&nowait,0,sizeof(nowait));

  select(this->mSocket + 1, &sReady, nullptr, nullptr, &nowait);
  if( FD_ISSET(this->mSocket,&sReady) )
    res = true;
  else
    res = false;

  return res;
}

Nur wenn mir diese Methode true zurückgibt und damit signalisiert das der Socket gelesen werden kann, ohne zu blockieren, wird von dem Socket gelesen. Auf die Art und Weise habe ich mir quasi lesende nicht blockierende Sockets programmiert, mit der Zuverlässigkeit blockierender Sockets.
Mittlerweile betreibe ich das ganze seit einigen Tagen auf einem Testserver sehr erfolgreich und kann das ganze bald mit einem neuen Release von Voptop komplett in die freie Wildbahn entlassen.

1) https://tools.ietf.org/html/rfc5245
2) https://www.voptop.com
3) https://libnice.freedesktop.org/
4) https://tools.ietf.org/html/rfc5766
5) https://tools.ietf.org/html/rfc5389

Vor fast einem Jahr hatte ich hier im Blog ein Youtube Video, das verdeutlichte, warum Einwanderung nicht die Lösung für das „Dritte Welt“ Problem ist.
Heute ist mir ein Youtube Video über den Weg gelaufen, das eine Rede des ghanaischen Präsidenten zeigt, mit der Lösung des „Dritte Welt“ Problems. Dem kann ich inhaltlich nur bedingungslos zustimmen (Man beachte die Gesichtsentgleisungen des französischen Präsidenten daneben)!

Gerade war ich mit meiner Freundin und unseren beiden Hunden Gassi gehen, und irgendwann pinkelte unser Hund an irgend eine Mauer, was Hunde eben so tun. Da kam eine Dame mittleren Alters wie eine Furie aus ihrem Haus gerannt und keifte, das wäre eine versiegelte Fläche! Wir sollen das doch bitte abstellen! Ich wies die Dame freundlich daraufhin, das kein Wasserhahn am Hund ist und man das nicht abstellen könne. Darauf entgegnete die Dame mit leicht Schaum vorm Mund, ob wir unseren Hund nicht erziehen können. Daraufhin fragte ich Sie ob sie mir das mal erklären möchte, wie man einem Hund beibringt die eine Mauer oder Laterne sei eine gute um dagegen zu pinkeln, eine andere aber nicht. Schließlich räumen in Deutschland Millionen von Hundebesitzern den Kot ihrer Vierbeiner weg und wir alle Würden liebend gerne das Geheimnis erfahren, wie man dem possierlichen Tierchen beibringt seine Notdurft nicht nur vor der Tür, sondern auch noch an einem besonders gefälligen Ort zu verrichten. Darauf wusste Madam nichts mehr zu erwidern außer „Sie müssen ihre Hunde schon selbst im Griff haben“. Um so gleich vorzuschlagen, man könne ja eine andere Ruthe Gassi gehen, dann würde der Hund nicht mehr dahin pinkeln. Meine Freundin entgegnete daraufhin, das würde das Problem nicht lösen, nur zu einem anderen Ort verlagern. Das fand Sie nicht weiter schlimm, schließlich wäre Sie das Problem damit los. „O heiliger Sankt Florian, verschon' mein Haus, zünd' and're an.“ Eine gewisse Ironie birgt noch der Umstand, dass es nicht ihre Mauer ist und Sie sich im Wesentlichen nur an dem Fleck auf dem Asphalt stört, wohnend auf der anderen Straßenseite.
Es ist schon beschreibend, wenn man bedenkt, dass diese Stadt hier sozialdemokratisch regiert wird, angesichts der Stimmenverteilung vielleicht auch von besagter Madam gewählt wurde und Sie sich selbst vermutlich auch noch für sozial hält. Entweder das. Oder es ist, wie meine Freundin meinte, vielleicht was Corona aus den Leuten macht. Dauerhaftes Stubenhocken scheint bei manchen vielleicht nicht spurlos an der Festplatte vorbei zu gehen.

Man sollte meinen, ich habe durch die Coronakrise mal wieder ein bisschen mehr Zeit zum bloggen, dem ist aber nicht so. Ich habe mehr Arbeit als je zu vor, nur eben vom Home Office aus. Dafür ist die Freizeitgestaltung zum Wochenende hin ein wenig eingeschränkter als sonst. Vielleicht komme ich ja dieses Wochenende dazu, etwas Vernünftiges zu bloggen.
Informatiker haben gerade Hochkonjunktur und lösen ausnahmsweise mal Probleme, die es auch ohne uns gäbe ;-).