Warum der SNEScast nicht auf Spotify zu finden ist

Für den SNEScast, unseren Podcast rund um das Super Nintendo Entertainment System, haben wir am Anfang überlegt, wo genau wir ihn anbieten wollen. Hauptsächlich ging es darum, ob wir ihn auch auf Spotify anbieten wollen. Nach einigen Überlegungen und etwas Recherche sind wir dann zu einem Schluss gekommen das wir dies nicht wollen. Doch was sind dafür die Gründe?

Der SNEScast Podcast ist nicht auf Spotify zu finden

Dafür vielleicht ein Blick darauf was einen Podcast in seinem Wesen ausmacht. Der Ersteller eines Podcasts stellt Audiodateien für die einzelnen Episoden und dazu einen RSS-Feed zusammen. Dieser Feed kann über einen Podcatcher abonniert werden. Er enthält alle notwendigen Informationen über den Podcast und die Links zu den Audiodateien. Damit hat der Ersteller des Podcasts die Kontrolle darüber welche Inhalte ausgeliefert werden. Podcast-Verzeichnisse wie iTunes bzw. mittlerweile Apple Podcasts respektieren diesen Gedanken. Die Inhalte werden auch dort durch die Server des Erstellers ausgeliefert; das Verzeichnis nutzt den Feed nur zur Anzeige des Podcasts im Verzeichnis. Damit erhält der Ersteller des Podcasts, anhand seiner Zugriffsstatistiken ein Bild darüber wie sein Podcast oder gar einzelne Episoden ankommen.

Wie funktioniert ein Podcast?

Spotify hingegen ist eine mehr oder weniger geschlossene Plattform, welche versucht Podcasts für sich zu vereinnahmen. Für diese Plattform darf der Ersteller des Podcasts seine Inhalte liefern und sich dafür den Beschränkungen der Plattform unterwerfen. Am Anfang konnten nur ausgewählte Individuen einen Podcast auf Spotify bringen, mittlerweile gibt es ein entsprechendes Portal um dies zu tun. Wenn der Podcasts nicht bei einem sogenannten zertifizierten Hostingpartner gehostet wird, erhält über den RSS-Feed und die Zugriffe auf die einzelnen Episoden keine Informationen darüber wie oft sie gehört wurden. Der Hintergrund ist das Spotify die Dateien selbst vorhält um eine entsprechende Servicequalität für sich in Anspruch nehmen zu können.

Daneben hat Spotify noch einige andere Probleme, es ist schlicht und ergreifend kein Podcast-Client. Die gesamte App ist darauf optimiert Musik zu streamen. Kaptitelmarken in Podcasts? Fehlanzeige. Das Offline-Hören von Podcasts bei Spotify ist zwar möglich, aber etwas umständlich und nur für Premium-Nutzer verfügbar. Und dann sind da noch die Nutzungsbedingungen für die Spotify for Podcaster-Plattform, die eine Lizenz vorgeben, die nicht jeder Podcast bereit ist einzugehen.

Aus der dezentralen Podcast-Welt wird mit Spotify eine Plattform zentraler Podcasts und das ist etwas, was wir mit dem SNEScast nicht unterstützen wollen. Natürlich kann es dadurch sein, dass der eine oder andere Hörer auf der Strecke bleibt, aber so hat er die Freiheit den SNEScast mit einem Podcatcher seiner Wahl zu hören und die Podcast-Welt bleibt etwas dezentraler. Es sollte nicht passieren das Spotify und Podcasts synonym werden, den das sind sie nicht. Natürlich, wenn ich Spotify habe, warum sollte ich mir zusätzlich noch einen Podcatcher installieren?

Und so begeben wir uns in einen Vendor-Lockin den wir für Podcasts nicht sehen wollen. Wenn Spotify beschließt, dass der eigene Podcast nicht mehr genehm ist und ihn von der Plattform entfernt, verliert der Podcasts so im schlimmsten Fall einen Großteil seiner Hörer. Auch dies ist ein Problem von zentralen Plattformen im Gegensatz zu einem dezentralen offenen System. Ansonsten ist der Podcast der Plattform völlig ausgeliefert. Daneben gehört Spotify mit dem Anchor bereits ein Dienst, der Podcasts-Hosting anbietet und bei denen knapp die Hälfte aller Podcastsfeeds hostet.

So bleibt nur der Appell: installiert euch einen Podcatcher und abonniert eure Lieblingspodcasts direkt beim Ersteller. Sie werden es euch danken.

Fork – Git-Client für macOS und Windows

Auf dem Markt existieren eine Reihe von Git-Clients für die unterschiedlichsten Systeme. Unter macOS nutze ich neben dem Terminal den freien Git-Client GitX. Allerdings wird dieser seit einiger Zeit nicht mehr aktiv weiter entwickelt, sodass ich auf der Suche nach einer Alternative war. Fündig geworden bin ich beim Git-Client Fork.

Der Git-Client Fork mit einem geöffneten Git-Repository

Neben den klassischen Funktionalitäten, bietet Fork erweiterte Funktionalität zur Auflösung von Merge-Konflikten sowie eine interaktive Rebase-Funktionalität. Bezogen werden kann der Client über die offizielle Seite unter git-fork.com. Fork steht für macOS und Windows zur Verfügung. Vertrieben wird der Client als Freeware.

MQTT Explorer

Für die unterschiedlichsten Betriebssysteme existieren eine Reihe von Clients für MQTT. MQTT Explorer ist einer dieser Clients, welcher plattformübergreifend (Linux, macOS, Windows) verfügbar ist. Der MQTT Exporer ist auf Performanz optimiert und kommt mühelos mit mehreren tausend Nachrichten pro Minute zurecht. Damit eignet er sich unter anderem für das Debugging größerer Installationen, in welchen unterschiedlichste Topics definiert sind.

Der MQTT Explorer unter macOS

Bezogen werden kann der Client über die Projektseite unter mqtt-explorer.com. Der Quellcode dies Clients kann über GitHub bezogen werden. Lizenziert ist der Quellcode unter der Creative Commons-Lizenz CC-BY-ND und damit keine freie Software.

Maximale URL-Länge bei HTTP

Der Uniform Resource Locator, oder in der Kurzform die URL, wird sicherlich jedem schon begegnet sein. Die URL setzt sich aus einem Schema und einem für das Schema spezifischen Part zusammen. Getrennt werden die beiden Bestandteile durch einen Doppelpunkt. Bei HTTP wäre die Angabe des Schemas (http) und dem anschließenden spezifischen Teil mit dem Host, eventuellen Informationen über den Port, Kennwörter und ähnliches und anschließend der Pfad zur gewünschten Ressource. Interessant ist allerdings die Frage, wie lang darf eine solche URL sein? Kurze URLs wie:

http://api.example.com

machen keinerlei Probleme. In der RFC 2616 finden sich erste Anhaltspunkte dazu. Die RFC trägt den Namen Hypertext Transfer Protocol — HTTP/1.1 und definiert eben dieses Protokoll. Im Abschnitt 3.2, der sich um Uniform Resource Identifiers dreht, findet sich im Unterpunkt 3.2.1 folgender Abschnitt:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Aus diesem Abschnitt ergibt sich das URLs so lang wie benötigt sein dürfen und das HTTP-Protokoll keinerlei Beschränkung vornimmt. Sollte der Server eine lange URL nicht verarbeiten können, so soll dieser mit dem Statuscode 414 (URI Too Long) antworten. Gleich danach finden sich ein weiterer Hinweis in der RFC:

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

Dort wird darauf hingewiesen das es Probleme geben kann, wenn die URL länger als 255 Byte ist. Je nach Kodierung und Sprache (wie z.B. Deutsch oder Japanisch), lassen sich eine unterschiedliche Menge an Informationen in diesen 255 Byte kodieren. Allerdings wurde die RFC 2616 durch die RFC 7230 für obsolet erklärt. In dieser RFC findet sich folgender Absatz:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

Mit diesem Absatz wird definiert das HTTP-Clients und Server eine Mindestlänge von 8000 Byte unterstützen sollen. In der Praxis stellt sich nun die Frage was wirklich funktioniert. Es existieren durchaus längere URLs, z.B. sogenannte Data-URLs, allerdings sind dies keine HTTP-URLs, sondern definierten ein eigenes Schema. Daneben existieren alte Untersuchungen zu dem Thema. Unabhängig von der theoretischen Machbarkeit existieren weitere Kriterien, wie die maximale Länge die von Suchmaschinen indiziert werden. Hier schwanken die Zahlen zwischen knapp 1800 Byte bis zu 2048 Byte.

Damit lässt sich die Frage nach der maximalen URL-Länge nicht pauschal beantworten. Mit aktueller Software auf Server- und Client-Seite, sollten 1024 Byte für die URL kein Problem sein. Längere URLs sollten mit Vorsicht genossen werden und ihre Sinnhaftigkeit noch einmal hinterfragt werden.

Windows 10 mit integriertem SSH-Client

Seit mittlerweile einigen Monaten findet sich in Windows 10 ein eigener SSH-Client so dass auf Alternativen wie PuTTY zur Not verzichtet werden kann. Ob der Client bereits auf dem Windows-System installiert ist, kann über Systemsteuerung überprüft werden. Dort findet sich der Punkt Optionale Features verwalten.

In der Systemsteuerung kann überprüft werden, welche optionalen Features installiert sind

Ist dort der Punkt OpenSSH-Client aufgeführt so kann dieser, wie der gewöhnliche SSH-Client unter Linux, genutzt werden:

ssh root@example.org

Ist der SSH-Client nicht installiert, muss das entsprechende Feature erst hinzugefügt werden. Das Projekt bzw. der Quelltext desselben findet sich auf GitHub.