Linux - 32

Beim Humble Bundle gibt es derzeit Hearts of Iron IV (optional: Partner-Link) mit einigen Erweiterungen. Jürgen hatte bei bitblokes auch schon darüber geschrieben, ich will es hier nochmal aufgreifen. Das Bundle ist ein gutes Angebot für ein nativ unter Linux laufendes und bekannteres Nischenspiel.

Das Spiel und das Bundle

Hearts of Iron IV ist ein Globalstrategiespiel. Start ist kurz vor dem zweiten Weltkrieg, 1936 oder 1939. Der Spieler kann ein Land auswählen, die Vorauswahl sind die großen Kriegsteilnehmer. Dann gilt es die Wirtschaft auf die Militärproduktion auszurichten, zu forschen, in nationalen Projekten z.B. politische Entscheidungen zu treffen und natürlich Militär zu rekrutieren, sodass beim unweigerlich eintretenden Kriegsbeginn eine Überlebenschance besteht.

Das Bundle ist wie üblich unterteilt: Für 1€ gibt es das Grundspiel. Die nächste Stufe hat dann drei Erweiterungen dabei, die nächste sieben. Ob man mehr Musikstücke wirklich braucht sei dahingestellt, aber mit Waking the Tiger einzelne Länder besser auszugestalten könnte es wert sein.

Bei diesem Bundle mit Hearts of Iron IV jetzt habe ich etwas gemacht, was ich noch nie gemacht habe: Ich habe erstmal nur die Grundversion gekauft und jetzt den Kaufpreis erhöht, um die anderen Erweiterungen doch noch mitzunehmen. Die 18 Stunden, die ich jetzt schon mit dem Spiel verbracht habe, haben mich gefesselt.

Vielseitige Strategien sind möglich

Ich habe sehr positive Erinnerungen an die Reihe. Vor vielen Jahren spielte ich einen der Vorgänger in der Doomsday-Variante: Nach dem zweiten Weltkrieg folgt sofort der dritte. Ich hatte mir Polen ausgesucht und in dessen Rolle viel Spaß an den Spielsystemen. Die Produktion zu verstehen und anzufeuern, dann mit meinen Einheiten an der Seite der Sowjetunion gegen die Alliierten nur wichtige Schlachten zu finden und zu gewinnen. Knifflig, aber (anders als das Spielthema) nett. Sogar an die Marschmusik erinnere ich mich noch.

Mit HoI4 ist das Spiel mit Polen nun ein ganz anderes: Vor dem zweiten Weltkrieg gilt es zwar immer noch zu forschen und zu produzieren, aber durch die diversen Nationalprojekte gibt es mehr Möglichkeiten. Die brauchen immer 70 Tage und sie können ganz unterschiedliche Auswirkungen haben – eins gibt einfach eine neue Fabrik, ein anderes gründet eine unabhängige Fraktion mit den baltischen Staaten. Die Möglichkeiten! Gleichzeitig war ich bis jetzt chancenlos, sobald die deutsche Armee anrollt. Und bin jetzt am ausprobieren, ob es hier eine Chance gibt. Es ist letzten Endes ein riesiges Knobelspiel.

Um eine Idee der Herausforderungen zu geben: Mein erster Ansatz war, mit ausgewogener Produktion über die dann historisch eintretende Allianz mit den Alliierten mich zu verteidigen. Das scheiterte zweimal; zweimal, weil ich beim ersten mal ganz viele Anfängerfehler machte und z.B. Politikpunkte auf nicht zielführende Diplomatie verschwendete. Beim dritten mal versuchte ich es über die Allianz mit den baltischen Staaten – ein Desaster, weil Litauen wegen der nahen Grenze zu Deutschland nicht in den Krieg eintreten wollte und auch die drei Länder zusammen viel zu wenig Militär hatten. Außerdem wollten die Briten und Franzosen nichts mehr mit Polen zu tun haben, der deutsche Überfall führte nicht zum Weltkrieg und ließ mich chancenlos. Mein vierter und derzeitiger Versuch: Litauen vor dem Kriegsbeginn mit Deutschland einzunehmen, gleichzeitig massiv Infanterie mit Artillereeinheiten herstellen, sodass mit geeinter Produktion und Militärkraft vielleicht eine Chance besteht.

Ich vermute, um eine Chance zu haben muss ich noch mehr der Spielsysteme verstehen. Es gibt ein Tutorial – ohne wäre ich kaum reingekommen, meine Erfahrung mit der Reihe ist zu lange her. Aber es erklärt nur die Grundlagen, nicht Details wie das Konfigurieren der Divisionen, erst recht nicht, dass dafür Erfahrungspunkte gebraucht werden die man durch Kämpfe oder Übungen ergattern kann bzw. wann man das tun sollte.

Stimmen die negativen Bewertungen?

Vielleicht muss ich auch in die Kämpfe selbst stärker eingreifen. Dass die KI nicht gut funktioniert (und die Performance miserabel sei) war der große Kritikpunkt im sehr negativen Test bei GamersGlobal. Er hatte mich bisher auch vom Kauf abgehalten. Aber das obige zeigt ja: Möglichen Schwächen zum Trotz ist Hearts of Iron IV erstmal faszinierend. In einem späteren Artikel von Vampiro hat die 2020 aktuelle Version mit allen Erweiterungen viel besser abgeschnitten. Er mag Paradox-Spiele zwar generell, aber da geht es mir ja nicht anders.

Er empfiehlt, die Erweiterungen zu kaufen um das Spiel aufzuwerten. Zum gleichen Schluss kam ich auch gerade unabhängig, zumindest die im Bundle enthaltenen würde ich mir holen. Mit Polen zu spielen macht vor allem wegen der vielen Möglichkeiten Spaß, die durch ein erstes DLC (das der 1€-Version beiliegt) dem Grundspiel hinzugefügt wurde. Die DLCs machen das für andere Staaten, für die Länder im Balkan zum Beispiel, ein anderer erweitert die Ausgestaltung von Großbritannien. Es besteht zwar bei mir die Gefahr, dass ich mich jetzt am aktuellen Knobelspiel festbeiße und danach nichts anderes mehr ausprobiere, aber so habe ich wenigstens die Chance und muss mich nachher nicht über die vergebene sowie die normalerweise zu hohen Preise der Paradox-Erweiterungen ärgern. Von daher: Ich würde das volle Bundle empfehlen.

Und das Spiel generell, wenn man sich an selbstgestellten Aufgaben in einem solchen Kriegsszenario messen will. Man braucht die Motivation, etwas die Spielsysteme verstehen zu wollen, etwas auch außerhalb des Spiels nachzulesen und Szenarien mehrmals mit unterschiedlichen Strategien zu versuchen. Bei der Hardware dagegen scheint mittlerweile ein normaler Vierkern-i5 zu reichen, die Grafik kann von der integrierten Grafikeinheit gestemmt werden – dass es bei längerer Spieldauer nicht noch zu Problemen mit der Performance der Engine kommt kann ich allerdings nicht ausschließen.

Neben IceWM ist der eigentliche Kern meines Linux-Desktops wahrscheinlich Simdock. Das kleine Dock habe ich vor ziemlich genau zehn Jahren adoptiert. Seine Daseinsberechtigung: Es macht die Fensterverwaltung einfach richtig und ist perfekt mit kleinen Fenstermanagern kompatibel (mehr dazu im Artikel).

Zwar halte ich das Dock am Laufen, aber das bedeutet eben nicht konstante Weiterentwicklung. Da passierte am Anfang mehr, als das Programm erstmal in Form gebracht werden musste. Allerdings kann Software immer verbessert werden, wie ein kürzlich eingegangener Pull-Request auch zeigte – perfekt ist gar nichts. Für Simdocks Weiterentwicklung habe ich sogar ein paar Ideen. Um die zu sammeln habe ich auf Github ein Projekt erstellt:

Da sind kleinere Verbesserungen dabei, die wirklich machbar wären, wie das verbesserte Klick-Feedback. Und Großprojekte wie die Waylandunterstützung, die wahrscheinlich nicht ansatzweise realistisch ist. Aber wer weiß, vielleicht geht es ja doch, und perspektivisch könnte sie beim zwanzigjährigen Jubiläum der Software (seit meiner Übernahme) notwendig geworden sein.

Ideen zu haben ist zwar nicht das gleiche wie sie umzusetzen, was natürlich am meisten wert wäre. Aber sie könnten als Ankerpunkt für zukünftige Arbeiten dienen, sei es von mir oder von anderen.
Wer Interesse an alternativer Linux-Desktopsoftware und am Perfektionieren eines Docks hat sei daher eingeladen, einen Blick auf Simdock selbst und auf diese Ideen zu werfen. Vielleicht ist ja etwas dabei, was für einen der Leser hier interessant und von ihm umsetzbar wäre.

Githubs Copilot, also die neue Software, die KI-betrieben vollständigere Codeschnipsel vorschlägt, wird teilweise sehr kritisiert. Keineswegs der einzige Einlass in diese Richtung, schreibt ein OSBN-Blognachbar auf kaiserbarbarossa beispielsweise:

Ich schreibe also Programme, stelle sie unter die GPL und weiß nicht, ob diese “Intelligenz” nicht meinen Code irgendwo anders vorschlägt. Da könnte ich mir dann auch die GPL sparen. … Ich gehe also davon aus, dass meine Projekte und dieser Blog in Kürze auf eine andere Plattform umziehen.

Ignorieren wir mal, dass das Umziehen auf eine andere Plattform nicht zwingend Copilot den Zugriff auf nun halt anderswo öffentlich lesbaren Code entzieht. Ich finde, gerade als FOSS-Entwickler sollte man der Sache entspannter entgegentreten. Denn wir Entwickler müssen aufpassen, hier in dieser Frage nicht eine Urheberrechts-Maximierungsposition zu vertreten, die in anderen Fällen viele von uns ablehnen würden.

Lernen muss erlaubt sein, auch für KIs

Wenn wir als Entwickler einen Code lesen und Konzepte lernen, interessiert es erstmal nicht unter welcher Lizenz dieser Code steht. Das Urheberrecht gibt dem Urheber Rechte zur Kontrolle der Weiterverbreitung und der direkten Nutzung des konkreten Werks, also der Software und dem Quellcode als Text. Es gibt dem Nutzer kein Anrecht auf im Werk enthaltene Konzepte. Wenn ich also in einer Software eine neue Art von LinkedLists beschreibe, gehören die nicht per Urheberrecht mir. Dafür gäbe es Patente, wobei Softwarepatente von jedem vernünftigen Menschen auf diesem Planeten abgelehnt werden, weil sie zur völligen Unmöglichkeit des Schreibens neuer Software führen.

Ich kann also einen Code lesen, völlig egal welcher Lizenz, und davon lernen. Es muss ja nichtmal etwas abgehobenes wie eine neue Datenstruktur sein. Vielleicht lerne ich einfach, wie if-Abfragen funktionieren. Wenn ich als Mensch mit dem gewonnenen Wissen eine neue Software schreibe, gehört diese mir – nicht dem, von dem ich Konzepte gelernt habe.

Genau das gleiche sollte auch für KIs gelten. Auch wenn das, was wir als Künstliche Intelligenz bezeichnen, derzeit nicht besonders intelligent ist und keinesfalls eine starke künstliche Intelligenz ist: Selbst diese schwachen künstlichen Intelligenzen – pure Algorithmen ohne Bewusstsein – sind von der Funktionsweise her mittlerweile so abstrakt, dass ihr gespeichertes Wissen keine reine Reproduktion ist. Sie lernen daher auf durchaus abstraktem Level. Bei einem neuronalen Netz als Funktionsweise hinter der KI beispielsweise kann man die entstandenen Konfigurationen nicht mehr originär dem eingelernten Code zuordnen.

Täte man das, dann gälte das gleiche auch für den Lernprozess von Menschen. Denn je nach Sichtweise auf den menschlichen Organismus passiert bei uns ja nichts anderes, ordnet Lernen unsere Neuronen in anderen Konfigurationen an.

Ich weiß: Manchmal machen Unternehmen das. Programmierer Anton darf nicht an Projekt Y arbeiten, weil dort X der Softwareschmiede abc nachprogrammiert wird, Anton dessen originalen Quellcode mal gelesen hat, und die Firma nicht von abc verklagt werden will. Aber das sind Risikominimierungen. Es sind nicht echte, direkte Ansprüche, die abc aus dem Urheberrecht ziehen kann.

Das ist nur ein Argument, nennen wir es das ethische. Das andere ist rein verfahrenstechnisch: Copilot ist Software. Der Code, den es ausspuckt, kann es nicht per Urheberrecht schützen, weil es keine Person – kein Urheber – ist. Entsprechend dürfte es unmöglich sein, der Nichtperson Copilot Urheberrechtsverletzungen vorzuwerfen. Und was sonst sollte man dem System vorwerfen können? Patentverletzungen?

Wie spielt die GPL hier mit rein

Es ist kein Wunder, dass die Kritik an Copilot oft von GPL-Entwicklern kommt. Auch ich greife gerne zu dieser Lizenz und kenne daher ihre Bedingungen. Die GPL schützt die Freiheit von Software, indem es freiheitswahrende Bedingungen an ihre Weiterverbreitung knüpft. Anders als bei permissiven Lizenzen wie BSD/MIT müssen abgeleitete Werke den Nutzern Freiheitsrechte zugestehen: Den Code zu lesen, ihn ändern und unter gleicher Lizenz weiterverbreiten zu können. Bei der AGPL gilt das sogar für Software, auf die über ein Netzwerk (=dem Internet) zugegriffen wird. Der Zugriff übers Netz gilt dann schon als Weiterverbreitung und schließt so das Schlupfloch, das von GPL-Software abgeleitete proprietäre Serversoftware ausnutzte.

Um diese Rechte durchzusetzen benutzt die GPL das Urheberrecht. Mit ihr sagt der Entwickler: Ich, als Urheber, gebe dir diese und jene Rechte, dafür musst du das und das machen. Weil ich der Urheber bin und über das Urheberrecht dazu befähigt musst du auf mich hören, willst du meine Software nutzen. Wenn nun Copilot hingeht, GPL-Code vorne einliest und hinten ohne GPL-Lizenz wieder ausspuckt, dann verfehlt die GPL ihre Wirkung.

Aber hier muss man eben wieder berücksichtigen, was oben gilt: Nur weil ich in einem GPL-Quellcode gelernt habe wie if-Abfragen funktionieren, muss ich nicht alle zukünftigen if-Abfragen unter die GPL stellen. Bei diesen Lizenzen geht es ums stumpfe Kopieren von (etwaig sogar kompletten) Werken mit einer ausreichend hohen Schöpfungshöhe, nicht um das Lernen kleinteiliger Konzepte. So weit zu gehen käme im Effekt wieder der Patentierung von Software gleich, dem Unmöglichmachen der Softwareentwicklung. Es überhöhte das Urheberrecht weit über die Grenze, bei der es derzeit liegt. Der RIAA würde das gefallen, Leistungsschutzrechtvertreter hätten Dollarzeichen in den Augen, das manifestierte Böse namens Oracle hat mit dieser Auffassung Milliarden von Google gefordert, Abmahnanwälte würden jubeln. Entsprechend muss jeder Softwareentwickler diese Position ablehnen.

Ein lernendes System darf unabhängig der Lizenz von Code lernen. Auch von GPL-Software.

Allerdings: Reines Lizenzwegwaschen geht auch nicht

Es gilt eine Einschränkung zu machen: Wenn Copilot zeilenweise komplette Funktionen aus GPL-Codequellen kopiert, dann fällt es irgendwann schwer diese Position aufrechtzuhalten. Es geht dann noch über die nicht erreichte Schöpfungshöhe, sodass das Urheberrecht vll nicht greift, aber je länger und wie mehr 1:1 die Codeübernahme ist desto kritischer wird das. Armin Ronacher (mitsuhiko) hat auf Twitter ein entsprechendes Beispiel gezeigt, bei dem sogar die Kommentare noch aus der Originalquelle sind.

Aber letzten Endes ist das eine Frage der Feinabstimmung, wie abstrakt Codepilot lernt, und dass die gezeigten paar Zeilen vom Urheberrecht geschützt wären darf getrost bezweifelt werden. Wenn das also das Extrembeispiel der Verfehlungen Copilots sind, dann gibt es kaum einen validen Grund zur Kritik. Wenn Copilot beispielsweise lizenzignorierend ganze Dateien kopieren würde, dann wäre es vorbei, aber so verhält sich die Software nicht. Trotzdem müssen Copilots Schöpfer hier aufpassen, dass mein "Es ist ein lernendes System, keine Kopiermaschine" gültig bleibt.

Githubs Copilot schlägt zurecht Wellen. Im ersten Moment ist die ablehnende Position im FOSS-Umfeld völlig verständlich, mein Blognachbar möge sich bitte nicht vorgeführt fühlen. Wir kommen hier ins hochkomplizierte Medien- und Urheberrecht, das dann auch noch in jedem Land unterschiedlich ausfällt. Aber ich hoffe, dass viele Entwickler meiner entspannten Argumentation folgen werden, da die negativen Implikationen einer juristischen Ablehnung eines solchen Systems viel zu groß sind und allen Entwicklern massiv schaden würden. Und langfristig sind es unsere Überzeugungen, die im Konflikt mit der Lobbyarbeit der Großkonzerne und der Anwaltsfraktion diese uns betreffenden Gesetze formen. Unsere Überzeugungen als Entwickler, unsere Reaktionen auf solche Systeme sind daher unheimlich wichtig.

Firefox fragte bei jeder Seite mit DRM-Videos nach, ob er nicht die DRM-Unterstützung aktivieren soll. Scheinbar wird das fürs Tracking benutzt, so fragt die Zeit bei jedem Artikel nach dieser Funktion, selbst wenn die Artikel gar keine Videos haben. Auf Dauer wird das nervig.

Um das zu deaktivieren gehe in about:config und setze diese beiden Einträge auf false:

media.gmp-widevinecdm.enabled
media.gmp-widevinecdm.visible

via

Ich bin froh über diese Lösung gestolpert zu sein. Ich fand sonst nur Lösungen über die Anpassung der userChrome.css, die seit dem Neudesign nicht mehr funktionierten.

Dass es zum Deaktivieren der Abfrage keinen einfacheren Weg gibt, und dass sie den Nutzer zu einer schlechten Entscheidung drängt, dafür gibt es mit https://bugzilla.mozilla.org/show_bug.cgi?id=1451762 einen Bugreport.

Ein netter Nebeneffekt der Steam-Kuratorseite, bei der ich die Spielereviews dieses Blogs zusammenfasse, ist die Specials-Box. Das ist ein Abschnitt auf der Seite, in der alle vom Kurator empfohlenen Spiele präsentiert werden die gerade im Angebot sind. Mir verschafft das einen klaren Überblick über gute Deals für Spiele, die ich klasse fand.

Da ich selbst schon eine ganze Weile nur noch unter Linux spiele, laufen alle Spiele, die in den letzten Jahren hier im Blog besprochen wurden, entweder nativ oder mit Proton unter Linux. Dementsprechend gilt das gleiche für die folgenden. Ich werde zu meiner Besprechung und zu den Angeboten linken (es sind übrigens keine Affiliate-Links). Geheimtipps sind vielleicht auch dabei, ich werde aber auch beliebte und bekannte Spiele nicht aussparen, wenn denn ihr Preis stimmt – irgendjemand wird sie garantiert verpasst haben.

Doch zuerst: Shadowrun-Trilogie umsonst bei GOG

GOG hat ebenfalls einen Sale und will wohl mal wieder mit einem kostenlosen Spiel Aufmerksamkeit erregen. Es möge ihnen gelingen. Denn die Shadowrun-Spiele sind allesamt klasse. Shadowrun Returns war ein guter Einstieg, Dragonfall und Hongkong legten beide eine Schippe drauf. Es sind klassische CRPGs wie Baldur's Gate, aber im interessanteren Shadowrun-Universum und mit mehr Skill-Checks.

Blogartikel: Shadowrun Returns, Shadowrun Returns: Dragonfall, Shadowrun: Hong Kong
Link (0,00€ für die nächsten 66h)

Die Witcher-Serie

Lange vor Cyberpunk hat CD PROJEKT RED mit der Saga um den Hexer Geralt eine erfolgreiche Spieleserie gebaut. Obwohl sie es eigentlich anfangs ähnlich verkackten: Das erste Witcher-Spiel war zu Beginn unspielbar. Es brauchte viel Nachbessern der Entwickler. Auf meiner Seite brauchte ich die Bücher um in der Fantasy-Welt durchzublicken. Der zweite und vor allem der dritte Teil waren dann die großen Hits, sie sind es heute noch – wobei inzwischen auch der erste sehr charmant ist. Ihnen gemein: Es sind hübsche (beim ersten gilt das mit Abstrichen fürs Alter) 3D-Rollenspiele mit einer tollen Story und vielen Entscheidungen.

Tipp: Hol dir das Bundle mit allen drei Spielen. Und danach die Erweiterungen für den dritten Teil, entweder über die GOTY-Edition oder über den Expansion-Pass, je nachdem was billiger ist. Wobei du dann den Artikel hier abbrechen kannst, denn das ist dann genug Beschäftigung für das Jahr.

Vorher unbedingt prüfen, dass keiner der Teile schon bei GOG in der Sammlung ist.

Blogartikel: Witcher 3, Witcher 2, Witcher 1 (sehr kurz)
Links: Witcher-Bundle (9,15€), GOTY des dritten Teils / Expansion-Pass (9,99€ / 7,49€)

Shadow Tactics: Blades of the Shogun

Wenn du früher Commandos, Desperados oder Robin Hood gespielst hast, weißt du was dich hier erwartet. Schleich-Knobelspiele, bei denen eine Einheit auf großen Karten durch Gegnermassen geführt werden muss. Nur dass die Karten in diesem neuen Ableger des Konzepts viel hübscher sind und das Leveldesign etwas weniger unfair, zumindest im Vergleich zu meiner Erinnerung an Commandos. Es ist fast schade, dass dieses gar nicht so alte Spiele so günstig verscherbelt wird, ich habe es in bester Erinnerung.

Blogartikel: Shadow Tactics: Blades of the Shogun ist ziemlich gut
Link (3,99€)

Die Deus-Ex-Reihe

Das erste Deus Ex war 2000 das beste Computerspiel aller Zeiten. Erst kürzlich spielte ich es wieder und fand es immer noch hervorragend. Klar, es ist klobiger als es ein modernes Spiel wäre, aber die aufgebaute Welt und das Spielgefühl ist immer noch erstklassig.

Die modernen Nachfolger sind auch tolle Spiele. Sie schaffen es, trotz neuer Technik sehr ähnlich zu wirken. Objektiv sind sie in allen spielerischen Belangen besser, nur bei der Story sind beide meiner Meinung nach weniger gelungen. Beim dritten Teil Mankind Divided kommt hinzu, dass manche Spieler es als unfertiges Episodenspiel empfunden haben – ich konnte mit den verbliebenen offenen Fragen gut leben.

Es gibt hier wieder ein Bundle, in dem aber auch der schwächere zweite Teil der Serie und das von mir aufgrund der schlechten Kritiken ungespielte The Fall drin ist. Daher ist das ein bisschen teurer als wenn man sich nur die drei Hauptspiele holt. Andererseits ist der zweite Teil nicht unspielbar schlecht, warum er insgesamt scheitert ist interessant zu sehen. Bei Interesse also auch eine Option.

Blogartikel: Deus Ex: Das 2020-Review, Deus Ex: HR ist würdig, Deus Ex: Mankind Divided ist besser als erwartet
Links: Deus Ex (0,97€), Human Revolution (2,99€), Mankind Divided (4,49€), Bundle (10,60€)

The Incredible Adventures of Van Helsing

Es gibt von diesem Hack'n-Slash auch einen zweiten Teil, aber der erste traf für mich besser die richtige Mischung. Es hat viel von Diablo 2, aber es ist lustiger. Die Skills und Items sind interessant genug um sich spezialisieren zu können, aber ohne zu abschreckend kompliziert zu werden, zudem fand ich die Story nett – wobei sie in dem Genre ja eigentlich nicht viel tragen muss, das Fortschrittsgefühl erledigt den Rest.

Blogartikel: The Incredible Adventures of Van Helsing
Link (1,49€)

Tomb Raider

Lara Crofts erster Teil im Reboot war auch das erste Spiel mit ihr, das ich gespielt habe. Ich fands großartig. Klar ist die Story Quatsch, der Spielinhalt nicht einzigartig, die tausend tödlichen Verletzungen der Protagonistin reißen einen manchmal raus. Doch es ist doch ein großes unterhaltsames Actionspektakel, mit Lara durch eine mystische Insel zu klettern, rätseln und schießen.

Die beiden anderen Teile der Serie sind auch im Angebot. Von mir ungetestet sind ihre Kritiken noch besser als die des ersten Spiels.

Blogartikel: Tomb Raider (2013)
Link (2,69€)

Gunpoint

Gunpoint fand ich zu kurz, es ist weder neu noch hübsch. Es ist auf der Liste, weil es den geringen Preis trotzdem auf jeden Fall wert ist. Weil es voller toller Ideen ist, die auch noch gut umgesetzt werden, nur das richtige auswalzen zu einem echten Spiel fehlte. In den 2D-Levels ist man ein Spion mit Spezialfähigkeiten und manipuliert die Welt, um die Gegner auszutricksen.

Blogartikel: Gunpoint
Link (1,75€)

Die Saints-Row-Reihe

Saints Row 2 war ein besser geschriebener GTA-Klon, mit mehr Freiheiten und noch mehr eine Parodie der ganzen Gangsterkultur als es die GTA-Spiele damals schon waren. Im dritten Teil wurde Story und Spiel dann absurd, aller im zweiten Teil noch vorhandene Ernst war verschwunden, stattdessen gab es Scifi-Kampfjets oder gleich fliegende Panzer. Der vierte Teil toppte das dann nochmal mit Aliens und Superkräften.

Es war die offizielle Linuxversion, die mir die Reihe anfangs interessant machte – gerade im Kontrast zu den Technikproblemen, die ich vorher mit GTA gehabt hatte (der vierte Teil wollte lange nichtmal unter Windows starten). Doch die Serie fing mich dann schnell ein, sie ist herrlich abgefahren und auf jedem Betriebssystem spielenswert.

Vom dritten Teil, wahrscheinlich der insgesamt stärkste der Serie, gibt es einen Remaster. Der ist aber mit 20€ auch im Sale noch relativ teuer. Seine Bewertung auf Steam ist wohl aufgrund einiger Bugs negativ, wobei Digital Foundry ihn hervorragend fand. Er hat keine Linuxversion mehr, dafür ist seine ProtonDB-Bewertung Platinum, allerdings basiert sie auf sehr wenigen Einschätzungen. Ich würde mich noch ans Original halten.

Blogartikel: Saints Row 2, Massive Verbesserungen des AMD-Treibers // Saints Row 3, Saints Row 4
Links: Saints Row 2 (2,49€), Saints Row: The Third (4,99€), Saints Row IV (4,99€)

Fallout: New Vegas

Die Story geht so: Fallout 1 und 2 waren hervorragende Rollenspiele mit eine Prise schwarzem Humor, die in einer apokalyptischen Zukunft spielen, die aber gleichzeitig in den 50ern steckengeblieben ist. Der dritte Teil war dann 3D und brach leider auch abseits der Grafik zu sehr mit den Vorgängern. Dass es an der Grafik nicht lag zeigte dann Obsidian in einer unheimlich kurzen Entwicklungszeit mit diesem viel besseren Spiel. Denn New Vegas orientierte sich beim Rollenspiel stärker an den Vorgängern, ohne die Annehmlichkeiten des (damals) modernen dritten Teils zu vergessen.

Über FNV habe ich sehr viel geschrieben. Was schlicht daran liegt, dass ich es viel gespielt habe. Mit Modding und Erweiterungen kannst du hier hunderte Stunden versenken. Keine Sorge, nur das Spiel durchzuspielen geht auch schneller.

Ich bin zwiegespalten, ob ich das Bundle oder nur das Grundspiel empfehlen soll. Beim Bundle sind zwei gute Addons dabei, aber auch zwei weniger gute und eigentlich unakzeptable Moneygrab-DLCs, was den Preis unnötig erhöht. Nur das Grundspiel durchzuspielen geht auch, aber zwei der Addons zu verpassen wäre schon schade, und selbst die anderen sind noch hilfreich für das Levellimit. Zudem ist das Bundle, gleichzeitig die Ultimate-Edition, nicht zensiert (ich habe die geschnittene deutsche Version nie gespielt und weiß nicht, wie kaputt sie ist).

Blogartikel: 10 Jahre später: Fallout New Vegas (verlinkt auch Artikel zu allen Erweiterungen, zu Mods und Spielweisen)
Links: New Vegas (2,99€), Bundle (9,99€)

Dishonored

Dishonored war lange auf meiner Liste zu spielender Spiele, weil es oft im Zusammenhang mit Deus Ex erwähnt wird. Es spielt zwar in einer ganz anderen Welt, aber es spielt sich als 3D-Schleichspiel mit Spezialfähigkeiten ähnlich dem wie zumindest viele Deus Ex angehen. Es gibt wohl sogar Überschneidungen bei den Entwicklern. Dishonored ist dann auch wirklich so gut wie das klingt, ein hervorragendes Schleichspiel mit einer motivierenden Story.

Blogartikel: Dishonored (mit Proton)
Link (5,99€)

Hitman: Blood Money

Blood Money ist der Teil der Hitman-Reihe, bei dem es endlich Klick gemacht hat. Die Hitman-Spiele damals waren weniger Actionspiele als Puzzles, bei denen der Spieler die Level vorsichtig auskundschaften sollte um dann den bestmöglichen Mord zu verüben. Und das nicht einmal, sondern in allen möglichen Varianten. Hier gelang das nahezu perfekt.

Die neuen Episodenspiele folgen dem Konzept immer noch, aber das macht diesen Teil von 2006 kein bisschen schlechter.

Blogartikel: Hitman: Blood Money
Link (2,49€)

Mad Max

Als Mad Max in der Wüste herumzufahren und eine an die Story des tollen Films angelehnte Geschichte zu erleben hebt die Qualität dieses Open-World-Spiels deutlich. Die Kämpfe zu Fuß und zu Gefährt wären sonst Grund genug es zu spielen, aber so ist es nochmal besser. Es gibt viele Sammelaufgaben, für notorische Komplettionisten wird es zur Qual werden, aber wer rechtzeitig den Sprung zur Hauptstory schafft wird mit einem tollen Spielerlebnis belohnt.

Blogartikel: Open-World in Bestform bei Mad Max
Link (4,99€)

Dead Space

Mit diesem Horrorspiel endet die Liste. Dead Space ist dabei ein hervorragend gemachtes Horrorspiel. Düster in Atmosphäre und Gestaltung, aber ohne das mit Dunkelheit auf dem Bildschirm zu verwechseln. Die Klasse des Spiels zeigt sich vielleicht auch am HUD, das nicht existiert, sondern in sinnnvolle Anzeigen an der Spielfigur und der der Spielwelt umgewandelt wurde. Das sollte die Immersion fördern, was völlig gelang.

Es könnte zu diesem Spiel bald eine Adaption geben. Eventuell ist das ein guter Anlass, das Original vorher zu spielen.

Blogartikel: Dead Space
Link (4,19€)

Gerne als Kommentar: Gibt es außerhalb der von mir besprochenen Spiele dieses Jahr besonders gute Angebote?

In Road Redemption ist man ein waffenschwingender Motorradfahrer, der auf einer wilden Verfolgungsjagd einen anderen waffenschwingenden Motorradfahrer erledigen soll. Zwischen ihnen: Noch mehr Motorradfahrer, mit Waffen.

Road Redemption ist keine direkte Umsetzung eines Arcade-Spiels, sondern orientiert sich wohl an Road Rash und damit an alten Konsolenspielen. Aber die wiederum waren damals oft an Arcade-Automaten angelehnt. Bei diesem Spiel meint man diese Herkunft sehr deutlich zu spüren; bei "Fahrphysik", Schwierigkeitsgrad, dem Kern als Geschicklichkeitsspiel sowie der nötigen Übung.

Klare Ziele

In den Levels geht es darum, entweder als erster das Ziel zu erreichen oder in einem Zeitlimit alle Gegner zu erledigen. Dafür gibt es Nah- und Fernkampfwaffen, dazu können die Gegner in Hindernisse geschubst werden. Auf den Strecken sind Icons verteilt, die dann beim Drüberfahren z.B. Munition geben. Zudem erscheinen auch farbkodierte Gegner, die Boni geben wenn du sie ausschaltest.

Zwischen den Levels können temporäre Upgrades gekauft werden, zwischen den Anläufen können permanente gekauft werden. So hilft dann selbst ein Scheitern dabei, nächstes mal eine bessere Chance zu haben. Das Sammeln von Upgrades ist auch ein nettes Zwischenziel.

Kniffliger als es scheint

Tatsächlich braucht es ein paar Upgrades und etwas Übung, bis das Spiel beherrscht wird. Die Steuerung mit Maus/Tastatur oder dem Controller ist nicht ganz intuitiv, gerade wie das Motorrad sich steuert. Das ist aber nicht ungewöhnlich für Arcade-Spiele. Road Redemption wird auch genauso absurd – wenn anfangs die Strecken noch gewöhnlichere heruntergekommene Wüstenhighways sind, regnet es später explodierende Autos und führt die Strecke auf vermeintlichen Häuserdächern über die Wolken, wobei das Motorrad auf einmal eine Schwebefunktion hat.

Der Koop-Modus wirkte mit seinem Split-Screen kompetent und spaßig, obwohl in meinem Fall die Mitspielerin von der Geschwindigkeit des Spiels plus der Hakeligkeit der Steuerung überfordert war.

Denn es reicht nicht, einfach zu fahren. Man muss lernen, wie welcher Gegner ausgeschaltet werden kann. In welchem Moment man nach links oder rechts schlagen muss. Dass bei solchen mit Helm die stumpfe Waffe besser ist, während bei denen ohne das Schwert besser funktioniert, wobei andere erst geblockt werden müssen. Es braucht etwas Erfahrung um zu wissen, wann die Munition der verschiedenen Schusswaffen gespart und wann sie besser eingesetzt werden sollte. Genau so, dass der Sprengstoff wie die Haftminen für die Missionen besonders praktisch ist, in denen neben feindlichen Motorrädern auch feindliche Transporter zu beseitigen sind. Während all dem sollte der Spieler die Abkürzungen wahrnehmen und nutzen. Kein Wunder, dass das Anfänger erstmal überfordert.

Fazit: Spaßig

Aber das Spiel belohnt dann auch, weil all das erlernbar ist und dann gar nicht mehr schwer scheint. Selbst während dem Lernprozess bietet Road Redemption rasante Arcade-Action. Die aber, dank den verschiedenen Leveltypen, dem drübergelegten Upgradesystem und den freischaltbaren Fahrern, länger motiviert als es ein simples Automatenspiel oder altes Konsolenspiel getan hätte. Dass die Grafik eher zweckdienlich als hübsch ist macht dabei gar nichts. Denn es ist am Ende ein ausreichend aufgebauschtes, doch im Kern schnörkelloses Actionspiel, und für eine kurze Weile purer Spaß.

MuHa Games zeigt mit Thea: The Awakening, dass es für ein gutes Spiel nicht viel braucht. Es braucht nur eine gute Idee, viele gute Spielmechaniken, eine ansehnliche Grafik, eine interessante Story und die Fähigkeit, das sauber zu programmieren sowie voller Inhalt zu füllen. Nichts leichter als das, oder?

Das oben ist natürlich ein Witz, ein gutes Spiel zu erschaffen ist schwer. Aber tatsächlich fand ich Thea wirklich gut gelungen, und wenn MuHa Games auf der Webseite nicht die Größe ihres Spielestudios mit 5 Leuten angeben würden hätte ich ein größeres Studio dahinter erwartet.

Erkunden wie in HoMM

Das Spiel ist eine Mischung aus einigen Spieleelementen. Ähnlich wie in Heroes of Might & Magic startet ihr mit einer Siedlung und könnt eine Gruppe Einheiten aussenden, um die Karte zu erkunden. Die Siedlung kann auch ausgebaut werden, es braucht dafür Ressourcen. Doch anders als in HoMM braucht auch die Expedition Ressourcen, nämlich Nahrung und Brennmaterial, um in der Wildnis zu bestehen. Die Einheiten werden, ein weiterer Unterschied, nicht produziert, sondern sie sind die Dorfbewohner mit ihren Werten, Klassen und Ausrüstung. Im Dorf gelassen bauen sie Gebäude, sammeln Rohstoffe oder stellen Gegenstände her. In einer Expedition handeln sie in den verschiedenen Ereignissen oder Kämpfen.

In unregelmäßigen Abständen zufällig oder wenn die Expedition andere Einheiten oder besondere Orte findet gilt es Entscheidungen zu treffen. Teilweise sind das einfach Multiple-Choice-Entscheidungen, deren Ausgang je nach gewählter Entscheidung berechnet wird, wobei die Fähigkeiten und der Hintergrund der Expedition Optionen freischalten kann. Schon die fand ich gut geschrieben und unterhaltsam.

Kämpfe, angelehnt an Gwent

Andere male kommt es zu Kämpfen, wobei Kämpfe nicht gleich Kämpfe sind. In erster Linie sind die Kämpfe Kartenlegespiele wie Gwent oder Magic, bei denen nach einer Legephase in einer Kampfrunde Schaden verteilt wird. Aber nur wenn der Kampf ein echter Kampf ist gefährdet das die Lebenspunkte. Ist der Wettstreit dagegen z.B. eine Redeprobe sieht alles gleich aus, aber die Karten haben andere Werte und bei einem Scheitern ist das Leben der Expeditionsteilnehmer normalerweise nicht gefährdet. Thea benutzt das meist, um den Spieler eine Risikoabwägung machen zu lassen: Lohnt sich hier ein echter Kampf, um dadurch den gesamten Schatz zu ergattern? Oder reicht ein Kampf der Taktikwerte, der sicherer ist, aber bei dem manche Gegner samt der Beute entkommen werden?
Die jeweils benutzten Karten sind dabei immer die reisenden Dorfbewohner mit ihren jeweiligen Fähigkeiten.

Viel hängt dabei von der Ausrüstung ab, gerade in echten Kämpfen. Die wird gefunden oder im Dorf hergestellt. Die Qualität der selbstgebauten Ausrüstung hängt an den genutzten Ressource, die es in verschiedenen Güteklassen gibt – z.B. normales Holz, Elfenholz und Dunkelholz. Aber sowohl der Abbau besserer Ressourcen als auch die stärkeren Rezepte sowie weitere Gebäude müssen erst mit jeder Runde eintreffenden Forschungspunkten freigeschaltet werden.

Schwachstellen in einem motivierenden Spiel

Im Laufe der Runden entpuppen sich auch die Schwachstellen des Spiels. Denn doch einiges könnten besser sein. Manche der Ereignisse wiederholen sich zu häufig. Bei Spielende beklagte das Outro, ich habe eine Bedrohung der Giganten nicht aufgehalten, obwohl von der im Spiel nichts zu sehen war – ich vermute, dass der sie enthaltende Gratis-DLC nicht richtig installiert war. Der Inventarverwaltung fehlen Komfortfunktionen. Ich sah erst spät, dass im Forschungsmenü mehr als nur Ressourcen freigeschaltet werden können, dass die anderen Bereiche wie im Dorfmenü in Tabs versteckt sind. Das wiederum entlarvte, dass Forschung kaum nötig ist um das Spiel zu gewinnen. Und dass die verschiedenen Kämpfe identisch funktionieren ist an sich ein bisschen billig.

Doch das alles schadet kaum der Motivation, die sich durch Spielmechanik und Story ergibt. Im Laufe der Zeit, durch Forschung, Ausrüstung und den Wertesteigerungen wird die Gruppe immer stärker werden. Und ist dann besser gewappnet, die Story aufzulösen. In Thea war die Sonne verschwunden, die Dunkelheit folgte einem Kampf der Menschen gegen Götter und Magie, fast alles Leben wurde zerstört. Ihr wählt anfangs einen Gott und sollt in seinem Namen die Welt retten, nun da die Sonne wiedergekehrt ist. Es ist also eine Position der Schwäche am Anfang, was wunderbar zu den Survivalelementen passt. Denn anfangs sind die Ressourcen knapp, die Monster stark und die Welt wirkt durchaus bedrohlich, wenn nichtmal genug Nahrung für ein mittelweit entferntes Expeditionsziel da ist.

Diese Story wird dann ergänzt durch die vielen Zufallsereignisse, aber auch durch die Ereignisse der Hauptstory selbst. Denn auch für sie gibt es auf der Weltkarte Orte zu entdecken und Aufgaben zu lösen. Es motiviert sehr, so die langsam stärker und zahlreicher werdende Gruppe einem konkreten Ziel widmen zu können.

Thea: The Awakening kombiniert interessante Spielemechaniken zu einem gelungenen Ganzen, packt es in eine ausreichend motivierende Story und hat mit seinen vielen Ereignissen genug Spielinhalt, um mich nahezu zu begeistern. Ich war zumindest beeindruckt, wie gut das alles funktioniert – wobei mir viele der Spielinhalte auch liegen. So mag ich generell Textentscheidungen in Spielen, wie bei Knights of San Francisco selbst wenn es der Kern des Spiels ist; auch Kartenkämpfe mochte ich schon als Kind mit Magic, in weniger ferner Vergangenheit in Witcher oder kürzlich in Slay the Spire.

Dass dieser Mix an sich nicht übermäßig kompliziert ist, darauf bezog sich die Einleitung, aber das ist egal. Er wurde hier einfach sehr gut umgesetzt.

Obwohl es die Steamseite verschweigt – wohl weil sie die Unterstützung nicht offiziell machen wollten – läuft das Spiel nativ unter Linux. Das fehlende Bekenntnis zu dieser Version will ich einem kleinen Studio wirklich nicht ankreiden. So war sie einfach eine schöne Überraschung. Wie auch das Spiel selbst.

Ich bin über ein Video gestolpert, in dem das Framework-Laptop näher gezeigt wird:

Das Framework-Laptop ist so modular, wie sie es hinbekommen haben. Das Gerät hat zuerst ein potentiell auswechselbares Mainboard, aufsteckbaren Ram und SSD, natürlich eine wechselbare Batterie.
Damit könnte ein guter Thinkpad jetzt fast noch mithalten. Aber mit den auswechselbaren Anschlüssen an der Seite nicht. Die sind nicht etwa fest eingebaut, sondern werden ebenfalls eingesteckt. Basierend auf USB-C kann so USB-C, USB-A, HDMI, Displayport, ein SD-Kartenleser und hoffentlich in Zukunft auch Ethernet frei gewählt werden. Und sogar Speicherplatz mit 250GB oder 1TB kann statt einem Anschluss eingebaut werden. USB-C 3.2 ist dafür schnell genug, wer mehr Speicherplatz haben will ohne den Aufpreis für extra-große SSDs zu bezahlen, für den ist das eine tolle Option.

Leider sind es nur vier Seitenanschlüsse, aber es ist auch nur ein 13.5"-Gerät. Es ist schade, dass der Prozessor nicht in einem Sockel sitzt, wie es früher auch bei Laptops üblich war. Bei dem R50 konnte ich noch den Prozessor wechseln, was ein nettes Upgrade war. Aber vielleicht war das mit Intels modernen Laptopprozessoren nicht mehr möglich. Dass es generell nur Intel-Prozessoren sind ist ebenfalls schade, AMD-Prozessoren sind auch für Laptops derzeit stärker. Und die farbigen Monitor-Bezels, die auf der Webseite z.B. in Orange zu sehen sind, gibt es noch nicht.

Sollte ich derzeit einen Laptop brauchen würde ich angesichts des regulären Preis vorher auch bestätigt haben wollen, dass Kühlung, Monitor, Tastatur und Touchpad so gut sind wie sie auf den ersten Blick wirken. Aber im Zweifel käme der hier ganz oben auf die Liste – vielleicht neben das günstige Pinebook Pro, falls auch ein schwächerer Laptop ausreichen würde. Ich finde das Konzept toll.

Man kann das Gerät in den USA und Kanada bereits vorbestellen, weitere Länder sollen später dieses Jahr folgen, wobei dann auch Deutschland dabei sein müsste. Die Webseite lässt bei der DIY-Version auch wirklich recht frei auswählen, welche Bestandteile sie liefern sollen und welche man selbst kauft. Inklusive des Betriebssystems, als Linuxer kann also der Preis für Windows gespart werden, den andere Kunden voll zahlen – so soll es sein.

Unepic ist ein 2D-Platformer-RPG von 2011. Viele von euch könnten es durch diverse Bundles schon in der Sammlung haben. Wer es aber wie ich bisher ignoriert hat darf sich freuen, denn es nachzuholen ist ziemlich spaßig.

Plötzlich Computerspielfigur

In Unepic spielt ihr Daniel, der eben noch auf dem Klo saß und plötzlich in der Spielwelt aufwacht. In diesem Schloss wird er direkt von einem körperübernehmenden Schattenwesen angegriffen, das aber mit Erschrecken feststellt, den jungen Mann nicht kontrollieren und seinem Körper auch nicht entfliehen zu können. Die Rolle des Begleiters ist damit besetzt, wobei das Schattenwesen wenig hilfreich an einem schnellen Ableben des Spielers interessiert ist.

Es gilt, Abschnitt für Abschnitt das Schloss zu erkunden. Überall lauern Gegner. Sie zu erledigen bringt Erfahrung, bei einem Levelaufstieg können die Fähigkeiten Daniels erhöht werden. Zum einen sind das die Waffenfähigkeiten, jede Waffengattung hat ihre eigene Stufe und man sollte sich spezialisieren. Dazu kommen Konstitution, das Brauen von Tränken und das Tragen von Rüstungen, was jeweils mehr Tränke bzw Rüstungen aktivierbar macht. Nach einer Weile stolpert Daniel zudem über Magie, z.B. Feuer- oder Schutzmagie, was ebenfalls gesteigert werden kann und ihn dann zusätzliche Zaubersprüche wirken lässt.

Spielinhalt: Mehr als Humor

Das Schloss ist eigentlich keins – die Abschnitte sind zu divers, so kommt man ziemlich direkt am Anfang in eine Mine. Aber es gibt Wächter, große Monster die einmal besiegt Schlüssel fallen lassen, mit denen dann der nächste Abschnitt geöffnet werden kann. Sie zu besiegen ist oft Knobelarbeit. Wie besteht man zum Beispiel gegen ein fliegendes Gehirn, das Daniel dazu bringt alle Tränke im Inventar auszukippen, während dessen er blockiert ist und kontinuierlich Schaden nimmt? Aber auch außerhalb der Bossgegner gibt es viele kleine Rätsel zu lösen und Tricks herauszufinden. Dazu kommen Nebenquests, die von teil sehr merkwürdigen Charakteren vergeben werden.

Denn das ist eine des Besonderheiten dieses Spiels: Unepic nimmt sich nicht besonders ernst. Oder zumindest pflegt es einen Humor, den das Spiel selbst als nerdig bezeichnet. So ist Daniel sehr lange davon überzeugt, dass er in einem Drogentrip festhängt und nichts was er erlebt echt ist, entsprechend reißt er Sprüche und scheint lange nur durch seinen distanzierten Übermut weiterzukommen.

Fazit: Mehr als erst sichtbar

Unepic hat minimale Hardwareanforderungen und ist damit ein guter Kandidat, falls man keine dedizierte Grafikkarte besitzt und trotzdem etwas spielen will. Die 2D-Grafik ist weit entfernt von einem Hollow Knight (und auch die Atmosphäre reicht nicht an diese schwerere Alternative heran), aber sie funktioniert und ist – anders als so mancher Pixellook – nicht abschreckend. Die Steuerung ist das schon eher. Bei mir funktionierte die im Menü aktivierbare Controllersteuerung gar nicht, aber das Interface ist sowieso 100% auf Bedienung per Tastatur ausgelegt. Das liegt mir bei diesem Genre nicht, aber bei Unepic man kann sich in die Tastatursteuerung reinfinden.

Das Spiel mag im ersten Moment so wirken als wäre es zu sperrig. Doch Unepic entpuppt sich dann als ein ziemlich solider Genrevertreter, der anfangs abgesehen von der Steuerung eher simpel ist, dann im Spielverlauf mit Leveldesign, Items und den Magiesystemen sich ausbaut. Der Ton des Spiels mag humorig sein, aber der Spielinhalt ist völlig ernst und auch die Story wird gut erzählt. Empfehlenswert.

Drüben bei gnulinux.ch bin ich über Gource gestolpert. Gource braucht man nur ein Git-Repository zu geben, damit es aus der der dort gespeicherten Aufzeichung ein Video mit einer Visualisierung der Entwicklung erstellt. Tatsächlich kannte ich die Visualisierung aus einem Youtubevideo, aber ich hatte keine Ahnung, dass sie mit frei verfügbarer Linxusoftware erstellt wurde. Und mir gefiel die Konfiguration der Darstellung, die im Artikel vorgeschlagen wird.

Das ist die nicht ganz komplette Entwicklung von Serendipity:

Ich finde es toll zu sehen, wie viele Entwickler da am Wirken waren und wie Garvin von der Software ins Zentrum gestellt wird. Und natürlich bereitet es ganz besonders Freude, wenn der eigene Name auftaucht und den Dateibaum verändern beginnt.

So ein Video zu erstellen ist einfach. Gource war auch bei Void Linux in den Quellen. Einmal installiert, muss nur das Git-Verzeichnis erstellt, darein gewechselt, Gource gestartet und die Ausgabe an FFmpeg übergeben werden:

git clone git@github.com:s9y/Serendipity.git Serendipity.git
cd Serendipity.git
gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o - | ffmpeg -y -r 30 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset medium -pix_fmt yuv420p -crf 18 gource.mp4

Tatsächlich habe ich aber viel Zeit in den Versuch versenkt, das zu optimieren. Ich wollte FFmpeg statt .mp4 erst .ogv und dann .webm mit VP9 erstellen lassen. Denn das mit H.264 gebaute und oben eingebundene .mp4 ist immerhin 77 MB groß.

Übrigens das erste mal seit langer Zeit, dass ich mir einen stärkeren Prozessor gewünscht habe. Videos zu enkodieren ist einfach heftig. Aber auch beeindruckend, dass die 4GB große .ppm problemlos auf unter 100MB gebracht werden kann.

Beim Versuch, eine kleinere Datei als die obige für diesen Artikel zu erhalten, orientierte ich mich an der Dokumentation von FFmpeg und den Hinweisen von Google. Aber die Videos waren entweder größer oder mit mehr sichtbaren Kompressionsartefakten. Und das selbst bei der Two-Pass-Enkodierung, die ich so versuchte:

gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o gource.ppm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -c:v libvpx-vp9 -b:v 0 -crf 37 -pass 1 -row-mt 1 -an gourceq37.webm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -c:v libvpx-vp9 -b:v 0 -crf 37 -pass 2 -row-mt 1 -an gourceq37.webm

Das produzierte relativ große Dateien (hier 130MB), während die Google-Vorgaben sehr kleine (22MB), aber deutlich sichtbar komprimierte Videos erstellten:

ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vf scale=1280x720 -b:v 1800k -minrate 900k -maxrate 2610k -tile-columns 2 -g 240 -threads 4 -quality good -crf 32 -c:v libvpx-vp9 -an -pass 2 -speed 4-y gource_google.webm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vf scale=1280x720 -b:v 1800k -minrate 900k -maxrate 2610k -tile-columns 2 -g 240 -threads 4 -quality good -crf 32 -c:v libvpx-vp9 -an -pass 2 -speed 4 gource_google.webm

Kein guter Startpunkt.

Die Single-Pass-Kodierung ist laut der Dokumentation nicht empfohlen, und tatsächlich lässt sich mit ihr zwar etwa die gleiche Größe erreichen:

gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o - | ffmpeg -y -r 30 -f image2pipe -vcodec ppm -i - -vcodec libvpx-vp9  -preset medium -pix_fmt yuv420p -crf 30 -row-mt 1 gource.webm

Aber das Video sieht ein bisschen schlechter aus. Und mit schlechterer Qualitätsstufe (hier 35) leidet die Darstellung dann deutlich:

Wenn ich mir die Dateigrößen und die Qualität von ja oft deutlich längeren Youtube-Videos anschaue glaube ich, dass das besser gehen müsste.

Kommt VP9 generell schlecht mit dem Blur zurecht? Oder ist der Kodierer in FFmpeg subobtimal? Gibt es doch einen Weg, die Komprimierung des .mp4-Video bei visuell gleicher Qualität zu schlagen?

Bei meinem ersten Kontakt mit dem Pinetab funktionierte im Grunde noch nichts. Mein Fazit war entsprechend verhalten. So konnte ich mit dem Gerät wenig anfangen und mir auch nicht vorstellen, darauf oder dafür etwas zu entwickeln. Nach dem Artikel schaute ich ab und an mal nach Updates für Ubuntu Touch, aber da erschien nichts. Jetzt kam ich endlich dazu ein anderes Betriebssystem auszuprobieren und es ist wie von den Kommentatoren prophezeit: Das Pinetab steht gleich viel besser da.

postmarketOS als Rettung

Mein doch noch positiver Ersteindruck des Konzepts war mit der Zeit von der Unbrauchbarkeit der Software überlagert worden. Ohne den Blogartikel hätte ich ihn vergessen. Teilweise geht das nunmal fließend ineinander über: Wenn Youtube-Videos abzuspielen ruckelt, ist dann die Software schuld oder schlicht der Prozessor zu schwach? Im Fall des Pinetabs war die Software schuld, denn mit dem von postmarketOS (v21.03) bereitgestelltem Firefox funktioniert sowas. Wobei Firefox auch mit seiner besseren Performance und Adblocker generell das Internet nutzbar macht.

Plasmas Mobilvariante wirkt generell wie eine gute Oberfläche, aber es ist die Kombination mit postmarketOS und den zugänglichen Linuxprogrammen, die das Pinetab plötzlich wirklich brauchbar wirken lassen. Einen echten Editor zu haben ist Gold wert, dazu VLC und eben Firefox, schon ist das System nutzbar. Dazu kommt die nun funktionierende Tastatur. Wann immer die Toucheingabe zu nervig wird (was schnell passiert) wird eben die Tastatur angesteckt. Zusammen mit den Desktopprogrammen ist das Pinetab dann kein Tablet mehr, sondern ein kleiner Laptop. Das ist nicht nur nett, dafür könnte ich tatsächlich einen Nutzen haben.

Aktueller Eindruck der Hardware

Wird das Pinetab also ausschließlich von der Software zurückgehalten und ist ansonsten das perfekte Tablet/Laptopmischgerät? Nein, das nun auch nicht. Tablets sind für mich immer reine Multimediagerät gewesen (mit einer Ausnahme, als ich ein Notfallgerät für einen Urlaub brauchte), wofür das Pinetab sich nicht wirklich eignet, denn die Lautsprecher sind schlecht und zeigen nach hinten.

Zudem ist das Display an sich gut, aber die Displayhelligkeit etwas zu gering wenn sich die Sonne im Bildschirm blendet. Das schränkt die Nutzbarkeit als Multimediatablet noch weiter ein. Beides wird nicht durch Software gelöst werden können.

Bleibt der Laptopmodus. Hier könnten die beiden Hardwareschwächen eher ignoriert werden. Allerdings: So cool ich die Magnettastatur mit ihrem Faltständer auch finde, wabbelt sie beim Schreiben doch deutlich. Auch ist das Touchpad kein besonders gutes.

Das geht zur Not, ich könnte damit arbeiten, aber dass ich es nicht unbedingt ausprobieren will ist kein gutes Zeichen. Und ob die eingebaute Kamera nach Softwareupdates mal gut genug für eine Videokonferenz sein wird? Es fehlt auch schlicht ein Scharnier, um das Tabletlaptop zuklappen zu können, ohne das der obere Abschnitt auf die Tastatur kracht.

Dazu kommen generelle Qualitätsprobleme der in diesen Punkten dann prototypisch wirkenden Hardware. Wenn das Tablet aus ist will es manchmal nicht angehen, ich muss mehrfach – und unterschiedlich lange? – auf den Anschalter drücken. Vorhin wollte der Einrastmodus der SD-Karte einfach nicht greifen, bis es irgendwann doch ging. Auch die Abdeckung des SD-Kartenslots ist unglücklich gestaltet, zum einen schwer aufzumachen, zum anderen nur gesichert mit einem dünnen Plastikstreifen der garantiert irgendwann abreißen wird. Und dass das Ladegerät nicht USB-C ist: Schade; Dass es nichtmal Mikro-USB ist: Schwer verdaulich.

Diese frühe Version des Pinetab könnte sich auch mit bester Software am Markt nicht behaupten. Es fehlen ein paar Upgrades, eine Revision 2. Wobei solche Hardwarerevisionen tatsächlich in den Blogartikeln von Pine64 immer mal wieder erwähnt werden, ich habe nur nicht den Überblick auf welchem Stand die nächste ausgelieferte Variante sein wird.

Aktueller Eindruck der Software

Wobei die Software sowieso nicht fertig ist. Doch immerhin ist der Unterschied zur Anfangssituation mit der damaligen Version von Ubuntu Touch, dass ich damit nichtmal ansatzweise gewusst hätte wo man ansetzen müsste um das System fertigzustellen.

Bei postmarketOS mit Plasma sind die Macken klar und scheinen beherrschbar:

• Die Autorotation streikt wenn beim Start die Tastatur angesteckt war,
• Wlan verbindet sich nicht automatisch,
• die Pineingabe beim Login lässt sich nicht deaktivieren,
• im Firefox geht die Bildschirmtastatur nicht zuverlässig auf,
• es fehlen Icons in Programmen wie gedit,
• die Anzeige der Benachrichtigungen in komischen KDE-Fenstern ist hässlich.

In der Summe blockieren solche Probleme die komfortable Nutzung durchaus. Aber es ist nicht mehr zum Haare raufen. Zumal diese Fehler alle lösbar scheinen. Als Entwickler des Systems mit einem solchen Testgerät wäre mir klar, welche Probleme anzugehen sind. Dementsprechend ist es völlig möglich, dass Mobian und Phosh oder eine zukünftigen Variante von postmarketOS (ob mit Phosh oder Plasma) all diese Probleme lösen.

Das als erreichbar sehen zu können stimmt mich zuversichtlich. Nicht nur für die Zukunft des Pinetabs, sondern auch für Standardlinux als Alternative zu Android generell. Die Grundlage ist da. Mit einer soliden Grundauswahl an Apps wird das System als Alternative taugen. Und wie toll wäre es, neben Androidvarianten wie LineageOS und /e/ dann postmarketOS bei sustaphones aufnehmen zu können?

Fazit: Es wird

Die Softwareverbesserungen verwandeln das Pinetab. Vorher wurde der Reiz des Konzepts überdeckt von all den Problemen. Jetzt gibt es immer noch Macken, aber sie sind geringfügiger, sodass das Konzept wieder scheinen kann. So wird deutlich, was für ein nettes Gerät das Pinetab im Kern ist. Mit seiner ansteckbaren Tastatur und mit den außerhalb von Ubuntu Touch verfügbaren Linuxprogrammen wird es zum ultraleichten Laptop mit abnehmbaren Touchdisplay. Was ein Format ist, in dem GNU/Linux als Windows- und Androidalternative eine gute Nische haben könnte.

Das Pinetab was ich hier habe ist eindeutig noch eine Entwicklervariante, unfertig und mit Macken die es vom Massenmarkt disqualifizieren. Aber so wie es jetzt ist kann es die Rolle eines Entwicklergeräts durchaus füllen. Wollte ich jetzt eine NewPipe-Alternative für mobile Linuxgeräte schaffen wäre das Pinetab nun ein gutes Testgerät dafür. Damit erfüllt es völlig sein erklärtes Ziel. Und erfüllte es vielleicht auch vorher schon, wenn es neben dem Pinephone, dem Librem 5 und den als Entwicklungsplattform genutzten Androidgeräten dazu beitragen konnte, dass die Entwickler von Plasma und postmarketOS und den anderen Alternativen diesen Stand erreichen konnten.

Das Softwareprojekt kann es nicht gewesen sein.

Der vermeintliche Verkauf von Audacity wirft weiterhin Fragen auf. Das kam jetzt wieder auf im Nachklang des Telemetrie-Debakels, als Audacity direkt nach der sogenannten Übernahme Telemetriedaten an Google und Yandex senden wollte. Doch was wissen wir über diese Änderung im Projekt überhaupt?

Was wurde berichtet

Caschy nannte es in seinem Blog eine Übernahme. Bei Audacity auf der Webseite wurde nur eine Mini-Nachricht gepostet, Audacity has just joined Muse Group. Das ist auch dort nur ein Zitat von Martin Keary (Tantacrul), der dort ein Projekt leitet und jetzt auch Audacity leiten soll. Er selbst hat dazu ein Youtube-Video veröffentlicht und das hat einen eindeutigen Titel: I’m now in charge of Audacity. Seriously.

Tantacrul kommt in dem Video positiv und überlegt rüber, interessiert am Projekt. Das ist nicht das Problem. Die Frage ist, wie diese Übernahme zustandegekommen sein soll. Er beschreibt das zu Beginn des Videos so:

Well, in short: Audacity has just joined Muse Group, a collection of brands that includes another popular open source music app called MuseScore, which I’m currently in charge of. And since things are going rather well at MuseScore, I was asked to step up and also manage Audacity in partnership with its open source community.

Was genau das ist, was auch bei der Audacity-Webseite als Zitat genommen wurde.

Was genau ist Muse Group? Sie beschreiben sich selbst auf ihrer Webseite. Es ist ein Unternehmen. Und in der Timeline steht auch, wie sie Audacity einordnen: Als acquired, also gekauft, oder zumindest unter der eigenen Kontrolle stehend.

Was, wie ich eingangs behauptet habe, nicht sein kann. Doch dafür müssen wir uns angucken, aus welchen Bestandteilen Audacity besteht und was davon kaufbar ist.

Audacitys Bestandteile als kaufbare Objekte

Ohne in irgendeiner Form bei Audacity involviert zu sein, ist das folgende mein Verständnis des Projekts.

Der Code

Die einfachste Variante bei einem proprietären Softwareprojekt wäre der Kauf der Rechte am Code, also dass jemand den Code einer Software und damit die Software selbst kauft. Doch das ist bei Audacity kaum möglich. Zuallererst, weil die Software unter der GPL 2 steht, wie die Webseite selbst verlinkt. Im Kern bedeutet diese Lizenz, dass jedem Nutzer der Software vier Freiheitsrechte zustehen:

1. Sie zu nutzen wie man will, für jeden Zweck
2. Die Software anzupassen
3. Die Software weiterzugeben
4. Die Software in veränderter Form weitergeben zu dürfen

Die GPL formuliert das anders und hat andere konkrete Klauseln bezüglich der Urheberauflistung etc, aber auf das läuft es hinaus.

Gleichzeitig hat die GPL die Klausel, dass abgeleitete Varianten der Software ebenfalls unter der GPL bzw kompatiblen freien Lizenzen stehen müssen. Was der Kernunterschied zu BSD- und MIT-Lizenzen sind, die insoweit "freier" sind, als dass bei ihnen die Freiheiten nicht für abgeleitete Werke gelten müssen.

Allerdings berührt die GPL nicht das Urheberrecht. Der Erschaffer ist weiterhin der Urheber. Das ist im deutschen Urheberrecht sowieso so, in den USA aber nicht, dort hat das massiv Bedeutung. Lizenzen wie die GPL nutzen das Urheberrecht, um die Rechte die sie einräumen wollen durchzusetzen.

Jetzt kann natürlich die Muse Group hingehen und das Urheberrecht kaufen. Bzw in Deutschland könnten sie die Verwertungsrechte kaufen. Allerdings stünde die Software weiterhin unter der GPL 2. Die Lizenz kann nicht nachträglich entzogen werden. Der Käufer hätte also Rechte an einem Produkt gekauft, das jedem Empfänger desselben umfassendste Rechte einräumt. Inklusive aller Verwertungsrechte, die bei proprietärer Software ein Käufer für sich beanspruchen würde, wie das Weiterverbreiten des Produkts zu einem beliebigen Preis bei zwingend offenem Quellcode.

Das komplette Urheberrecht zu besitzen könnte ihnen dann aber erlauben, neben Audacity unter GPL-Lizenz eine Variante unter einer anderen Lizenz zu veröffentlichen. Sogar unter einer proprietären. Solche Konstruktionen gibt es, sie sind nichtmal besonders unüblich.

Allerdings: Alleine auf Github werden 127 Mitentwickler gelistet. Bei einem so alten Projekt wie Audacity reicht der Quellcode noch viel weiter zurück als Github bekannt, die Liste ist in Wirklichkeit viel länger, endet Githubs Aufzeichnung doch bereits 2015. Es ist höchst unwahrscheinlich, dass bisher alle diese Entwickler ihre Urheber- bzw Verwertungsrechte an eine wie auch immer geartete bisher unbekannte Audacity-Institution übertragen haben. Denn zum einen ist diese Idee der Rechteübertragung bei FOSS-Projekten relativ neu. Zudem ist sie wahrscheinlich nicht über alle verschiedenen Rechtssysteme hinweg umsetzbar. Und außerdem finde ich dazu nichts in der Entwicklerdokumentation, während solche zu treffenden Erklärungen sonst normalerweise prominent erwähnt werden.

Es gab also höchstwahrscheinlich keinen einzelnen Ansprechspartner um den Code zu kaufen. Die Muse Group hätte mit jedem einzelnen Entwickler reden müssen, sie alle überzeugen und im Zweifel fürstlich bezahlen müssen. Unwahrscheinlich. Wenn das doch gelang bin ich beeindruckt.

Doch selbst wenn ich mich da vertue und seit zwanzig Jahren jeder einzelne Entwickler sein Urheberrecht nach US-Rechtssprechung auf eine natürliche Person oder ein Unternehmen übertragen hat: Selbst dann stünde noch die GPL. Und die kommerzielle Vermarktung einer solchen Desktop-Audiosoftware unter Doppelt-Lizensierung erscheint mir sehr schwierig.

Zusammenfassend: Rein praktisch war der Code und damit die Software nicht kaufbar, und selbst wenn dieser Kauf gelungen wäre hätte der Käufer in diesem Fall einer Desktopsoftware damit kaum praktisch verwertbare Rechte erworben.

Das Team

Manchmal ist bei Übernahmen gar nicht die Software das Ziel, sondern es sind die Entwickler, deren Arbeitsverträge gewonnen werden sollen. Auch das ist hier höchst unwahrscheinlich.

Zum einen passt es nicht zu dem Video. Was dort beschrieben wurde ist das Ziel, Audacity weiterzuentwickeln. Und das mit einem Ernst, Respekt und in einem Detailgrad, dass diese Ankündigung nicht das durchaus übliche Gelaber bei Silicon-Valley-Übernahmen zu sein scheint.

Zum anderen müssen dafür die Entwickler Teil einer kaufbaren Organisation sein. Gab es denn ein Unternehmen, das die Audacity-Entwickler beschäftigt hat? Ein solches Unternehmen wird zumindest weder auf Wikipedia noch auf der Webseite des Projekts erwähnt. Nein, Audacity wirkt wie die meisten FOSS-Projekte, bei denen die Entwicklung von wenigen Frewilligen getragen wird.

Von Paul Licameli zum Beispiel, der auch im obigen Video auftritt. Er ist zwar laut LinkedIn von einem audacity-Team beschäftigt. Dieser vermeintliche Arbeitgeber verlinkt aber nur zur Audacity-Webseite, die kein Impressum hat und keinerlei Unternehmensform auflistet.

Eine mögliche Konstruktion könnte sein: Es gab hier zwar kein Unternehmen. Aber es gab ein Team, das sich als moralischer Besitzer von Audacity gesehen hat. Und diese Entwickler werden jetzt von der Muse Group beschäftigt. Aber davon war bisher keine Rede. Und auch Paul hat bisher seinen Arbeitgeber auf LinkedIn nicht angepasst.

Und selbst wenn in irgendeiner Form die Kernetwickler gewonnen werden konnten: Selbst dann wäre Audacity selbst nicht Teil des Deals gewesen. Fortan Kernentwickler zu beschäftigen gibt in der Praxis Macht, aber es gibt dem Unternehmen am vorher geschaffenen keine Eigentumsrechte. Audacity wäre weiterhin rechtlich nicht Teil der Muse Group.

Intellectual Property

Intellectual Property (IP) gibt es eigentlich nicht, es ist eine Wahnsinnsidee bekloppter Kapitalisten. Aber okay, wenn es etwas als Idee gibt, dann existiert es eben doch. Und es gibt existierende legale Konstrukte, die so bezeichnet werden. Patente zum Beispiel. Es könnte eine Instutition geben, die mittelbar durch Audacity Patente besitzt. Audacity wurde 1999 an der Carnegie Mellon University gestartet und Universitäten sind berüchtigt dafür, solche diffuse Eigentumsrechte geltend zu machen. Vielleicht hat Muse diese Universität bezahlt, damit etwaige Ansprüche abgetreten wurden. Darauf gibt es aber keine Hinweise.

Ein anderes Beispiel für IP sind Marken (Warenzeichen). Und die sind hier wahrscheinlich im Spiel. Denn es ist auffällig, dass auf der Webseite von Audacity immer von Audacity® die Rede ist. Das ist sehr unüblich für nicht unternehmensgetragene FOSS-Projekte. Es sei eine registered trademark. Sowas wäre kaufbar. Und die Marke gibt es tatsächlich:

Dem Eintrag zufolge registriert von Dominic Mazzoni, einem der Gründer der Software, und jetzt im Besitz der uns bekannten Muse Group. Das einzige direkt greifbare Element im ganzen Puzzle, das gekauft werden konnte, wurde von der Muse Group tatsächlich erworben.

Nur ändert das nicht unbedingt viel. Denn die Marke zu besitzen bedeutet nur, die Marke zu besitzen. Es bedeutet nicht, zusätzliche Ansprüche an Quellcode oder an Loyalität der Entwickler zu haben; An dem Produkt, auf das sich die Marke bezieht.

Audacity wurde nicht verkauft

Mein Ergebnis ist, dass Audacity nicht verkauft wurde. Also nicht das Softwareprojekt. Es konnte nicht verkauft werden. Es gab keinen vorherigen klaren Besitzer und deswegen keine verwertbaren Eigentumsrechte.

Ich vermute es ist folgendes passiert: Die Leute im Audacity-Projekt und die Muse Group haben gesprochen. Und vielleicht waren die aktiven Projektteilnehmer auch wirklich daran interessiert, Audacity mit einer Firma zusammen zu entwickeln. Da könnten Absichtserklärungen abgegeben worden sein. Und an irgendeinem Punkt floss bestimmt sogar Geld. Aber alles, was damit praktisch gekauft werden konnte war die Marke Audacity.

Die Marke und damit das geflossene Geld gibt der Muse Group praktisch null Rechte. Sie könnten damit Forks der Software zwingen, einen anderen Namen zu benutzen. Aber es ändert nichts an den gewährten Freiheitsrechten via der GPL 2, nichts an den Eigentumsverhältnissen des Codes. Und auch nichts an der Machtstruktur im Projekt – außer praktisch, wenn sie die Adminrechte am Github-Projekt übertragen bekommen haben.

Muse Group kann aber natürlich trotz der fehlenden rechtlichen Bindung mit den FOSS-Entwicklern von Audacity zusammenarbeiten. Sie wollen Usability-Studien machen, scheinbar Usability als Prozess in die Entwicklung einbringen. Das könnte eine gute Sache sein.

Aber diese vermeintliche Übernahme gibt ihnen in Wirklichkeit wenig Macht über das Projekt. Muse hat wahrscheinlich nur eine fast wertlose Wortmarke gekauft. Nicht ganz wertlos, weil man ja mit einer so bekannten Marke doch irgendwie Geld verdienen kann. Aber doch fast wertlos, weil mit ihr kaum Kontrolle über das Produkt und Projekt selbst ausgeübt werden kann.

Nun frage ich mich: Wissen die das? Es ist zwar schwer vorstellbar bei einer Firma, die mit FOSS arbeitet, aber Fehler können immer passieren. Hatte die Muse Group vielleicht den Eindruck, wirklich das Audacity-Projekt zu kaufen?

Und: Wissen die Audacity-Entwickler, dass in Wirklichkeit weiterhin sie das Projekt kontrollieren könnten? Oder meinen sie wirklich, dass ihr Code und ihre Urheber-/Verwertungsrechte nun jemand anderem gehören?

Viel könnte hier auch einfach falsch kommuniziert worden sein. Vielleicht ist allen Beteiligten die Lage durchaus klar. Tantacrul könnte der Projektleiter des internen Audacity-Projekts bei Muse Group sein und das eigentliche Audacity-FOSS-Projekt gewillt, ihn mal eine Weile walten zu lassen. Geschenkter Usability-Arbeit sollte man nicht ins Maul schauen. Gekauft wurde nur die Marke, aber effektiv die Leitung aus Gutdünken eben auch überlassen, weil es sonst niemand machen wollte oder weil die Überzeugung da war, dass er das am besten kann. Wie es in einer Meritokratie eben passieren kann. Und als die Verlautbarungen dann erstmal missverstanden wurden hatte niemand Interesse daran, das sofort öffentlich auszudiskutieren.

Oder nur einer täuschte sich hier lautstark. Tantacrul schrieb ja selbst im Issue zur Telemetrie-Korrektur:

The first few questions are the ones most people want to know the answer to, I think. The only reason I'm not jumping on it right away is because I don't want to get any details wrong.

My role is product direction and design and I really want to publish a vision properly so it can be commented on more broadly. I'd prefer not to outline it all in text here.

I hope you understand. The issue I'm addressing in this discussion is super sensitive and I don't want to get anything wrong that might come back to haunt me. We are painfully aware there is a dearth of information and it is being sorting out.

Er hat also von dieser Übernahme gar nicht wirklich Ahnung. Wenn nur er missverstanden hat, wovon er jetzt tatsächlich der Leiter ist, wollte ihn vielleicht niemand blamieren.

Audacity wurde gekapert?

Wie auch immer: Ich bin ziemlich sicher, dass die Muse Group nicht wirklich der Besitzer des Softwareprojekts Audacity ist. Sie hätten dafür die urheberrechtlichen Verwertungsrechte aller bisherigen Entwickler kaufen müssen. Ganz vielleicht haben sie stattdessen eine Rechteabtretung der aktiven Kernentwickler und/oder die Absprache gekauft, ab jetzt das Projekt zu kontrollieren. Und wollen später mit proprietären Zusatzdiensten Gewinn erzielen. Das könnte funktionieren, wenn sie direkt oder indirekt Adminrechte auf der Webseite und im Github-Projekt haben und solange niemand mit ähnlicher praktischer Macht sie herausfordert, ist aber keinesfalls wasserdicht.

Der Kauf der Audacity-Marke wäre für eine solche Machtübernahme allerdings ein verwertbarer Baustein. Wenn das aber hier so gelaufen ist, dann ist es höchst bedenklich. Praktisch würde es bedeuten: Jedes Softwareprojekt kann von einer Firma gekapert werden, wenn die Firma alle Entwickler mit Adminrechten an der existierenden Entwicklungsstruktur (Github, Webseite) bestechen kann. Entwickler ohne solche Rechte hätten dabei kein Mitspracherecht. Nur bei der GPL könnten sie zumindest eine Lizenzänderung verhindern.

Ich könnte mich natürlich täuschen. Der Artikel ist auch deswegen so lang, weil ich im Laufe des Schreibens immer mehr Optionen gesehen habe, wie die Muse Group nun doch faktisch das Projekt kontrollieren könnte ohne der echte Besitzer zu sein. Ich bin daher gespannt, ob und wie sie die Übernahme erklären werden. Denn wenn es ein simples Kapern der Leute mit Adminrechten war: Dann stinkt die Aktion mehr als ich initial glaubte.

Wer regelmäßig am PC sitzt, aber gleichzeitig zum Beispiel eine Chatapp auf dem Androidtelefon laufen hat, kennt das Szenario: Jemand sendet dir einen Link am Telefon aber du würdest ihn viel lieber mit dem Desktopbrowser öffnen. Oder: Auf dem PC läuft bereits ein Video, aber mit dem Telefon in der Hand wird das gerade störend, doch jetzt müsstest du umgreifen um mit der Maus das Video zu pausieren. Auch nicht selten: Ein auf dem PC gefundener Link sollte per Android-Chatapp verschickt werden, doch wie bekommt man ihn jetzt vom Desktop aufs Telefon?

KDE Connect ist ein Projekt, das genau solche Szenarien löst. Es erstellt eine möglichst nahtlose Integration zwischen Linuxdesktop und Androidtelefon. So können Dateien ausgetauscht werden, der PC kommt im Share-Dialog vor, die Zwischenablage wird synchronisiert, Videos im PC-Browser sind am Telefon kontrollierbar und es gibt noch mehr Funktionen.

Bei void liegt das Programm im Repository. kdeconnect am Desktop besteht aus zwei Bestandteilen: Dem Daemon /usr/lib64/libexec/kdeconnectd, der bei mir mit sudo gestartet werden musste, und die Kontrollprogramme kdeconnect-app bzw kdeconnect-cli. Mit ihnen verbindest du PC und Telefon, wobei auf dem Android die App KDE Connect laufen muss, die ich per F-Droid installiert habe.

Es muss sich bei mir noch zeigen, ob sich das im Alltag bewährt. Aber bisher funktionierte das System gut und ich finde gerade das schnelle Rüberkopieren von Links sehr praktisch.

Dass ich mir mal ein als DAC beworbenes Gerät kaufen würde hätte ich auch nicht gedacht. Aber der Sharkoon DAC Pro S V2 dient bei mir weit abseits von audiophilen Phantasien schlicht als Alternative zum defekten Kopfhöreranschluss meines PC-Gehäuses, aus dem Ton nur noch einseitig herauskam.

Das ist in der Box

Es ist wirklich nur ein USB-Stick mit Kopfhörereingang:

Wobei von wegen Kopfhörereingang, tatsächlich kann dort wie bei Telefonen auch ein kombiniertes Mikrofon mit angeschlossen werden. Zusätzlich gibt es an der Seite drei Leuchten für die gerade genutzte Abtastrate, 44.1, 48 und 96 kHz. Es lag noch eine kleine Anleitung unter dem schwarzen Einsatz.

Installation

Im laufenden Betrieb angeschlossen wurde der Stick sofort erkannt:

onli@fallout:~$ cat /proc/asound/cards
 0 [HDMI           ]: HDA-Intel - HDA Intel HDMI
                      HDA Intel HDMI at 0xf7114000 irq 33
 1 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xf7110000 irq 34
 2 [Device         ]: USB-Audio - USB Audio Device
                      UC Mic USB Audio Device at usb-0000:00:14.0-5.1, full speed
 3 [S              ]: USB-Audio - Sharkoon Gaming DAC Pro S

Bei einem normalen Linuxsystem müsste dann nur er in der grafischen Konfiguration als Ausgabegerät gewählt werden. Weil ich pures ALSA benutze musste ich stattdessen meine ~/.asoundrc editieren und das dmix-Device anpassen. Von:

pcm.dmixer {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:PCH"
        buffer_size 16384
        period_time 0
        period_size 1024
     }
}

zu:

pcm.dmixer {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:S"
        buffer_size 16384
        period_time 0
        period_size 1024
     }
}

Firefox neustarten und der Ton erschien sofort, ein Reboot war nicht nötig.

Klangqualität

Eine naheliegende Frage wäre: Und, klingt es besser? Die Antwort: Vielleicht? Ich habe mit Tempel von Colour Haze mein Lieblingsalbum angehört. Klang gut. Klang aber auch vorher schon gut. Es fällt auf, wie laut die Musik jetzt sein kann, ich muss mit meinen Kopfhörern die Lautstärkeregelung auf 10 von 100 setzen (db Gain: -35) um in etwa das vorherige Niveau zu erreichen, das bei 31 von 100 lag. Und im Zweifel bedeutet lauter bei Musik ja besser, so ist kein Vergleich möglich. Allerdings: Meine Logitech-Kopfhörer haben eine Boost-Funktion, die ich anfangs verschmäht habe und später dann doch akzeptierte (bei solchen geschlossenen Kopfhörern mit starker Isolierung sei sie angemessen las ich, und musste dann zustimmen). Da meine ich deutlich wahrzunehmen, dass der Unterschied zwischen Boost an und aus geringer geworden ist. Mag Einbildung sein, vielleicht hängt auch das nur an der leicht anderen Lautstärke, vielleicht passte die Funktion auch einfach nie für dieses Album und meine initiale Abneigung kam hierher.

Wer fundiertes über die Qualität lesen will sollte den Test samt den Messungen von Igor ansehen. Er schrieb:

Stichwort Zielgruppe. Jeder Gamer, der ein ordentliches Headset hat, kann den Onboard-Sound genüsslich abhaken. Wir haben hier nämlich weder die Einflüsse der Grafikkarte noch ein zu hohes Grundrauschen. Und ordentlich Verstärkerleistung gibt es sogar für hochohmige Headsets noch genug. Der Frequenzgang ist linear und sauber und genau das wird die Liebhaber des differenzierten Hörens und des räumlichen Tiefgangs begeistern. Die Protagonisten der Badewannen-Fraktion, die mit ihren Spaßkopfhörern noch den ultimativen Bass-Booster für die gepflegte Gehirnmassage suchen, werden allerdings herb enttäuscht.

Gut, dedizierte Grafikkarte habe ich derzeit nicht, auch schon als eine im System war weder Einflüsse von ihr bemerkt noch irgendein Grundrauschen. Aber immerhin liest sich das so als ob der Sharkoon-Stick zumindest nichts falsch macht.

Letzten Endes eine direkt linuxkompatible USB-Soundkarte mit Kopfhörerverstärker, der auch einen Kopfhörer mit Bedarf für ein wesentlich lauteres Signal als die meinen brauchen versorgen könnte. Wer das sucht, für den könnte der Sharkoon-Stick passen. Und als Lösung für den defekten Kopfhöreranschluss des Gehäuses taugt er auch. Ich habe ihn bei equippr für 30€ plus Versand gekauft. Pfeilschneller Verstand - spätabends bestellt, einen Tag gewartet, am nächsten war er schon da.

Meine Tastatur soll mit englischem Tastaturlayout laufen. Gleichzeitig muss das nervige CapsLock deaktiviert sein. Die Taste dient dann zusammen mit dem rechten Alt dem Setzen von Umlauten. CapsLock-q steht für ä, CapsLock-y für ü und CapsLock-p für ö. Um diese Belegung umzusetzen braucht es eine Mischung aus setxkbmap und xmodmap:

setxkbmap -variant altgr-intl -option -option compose:rctrl -option lv3:ralt_switch -option terminate:ctrl_alt_bkspc -option eurosign:e -option nbsp:level3n
xmodmap /home/onli/.Xmodmap

Wobei in der .Xmodmap nur das hier steht:

clear lock
keycode 66 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift

Diese Befehle sendet meine ~/.icewm/startup bei jedem Login. Aber seit ich wegen der Heimarbeit regelmäßig die Tastatur zwischen Arbeitslaptop und eigenem PC wechselte, störte es mich langsam, dass ich nach jedem Wechsel bei angeschaltetem PC die Befehle neu ausführen musste. Das müsste man doch auch ohne Desktopumgebung automatisieren könnte. Desktopumgebungen wie KDE und Gnome könnten die Tastaturbelebung dauerhaft setzen, dafür ist dort meine Zielkonfiguration mit dem deaktivierten CapsLock und den erreichbaren Umlauten trotz US-Layout gar nicht so einfach umzusetzen.

Und tatsächlich gibt es für sowas udev. Damit können bei jedem Hardwarewechsel Berechtigungen gesetzt, Namen verteilt und eben auch beliebige Befehle ausgeführt werden. Doch leider ausgerechnet diese Tastaturumstellung nicht. Die Befehle werden einfach geschluckt, als ob nach udev nochmal der XServer auf den Hardwarewechsel reagiert und die Tastatur zurücksetzt. Zum Glück bin ich dann über diesen Artikel gestolpert, der zusammen mit einem Arch-Forenbeitrag beschreibt wie hier udev doch noch eingesetzt werden kann. Der Trick: Anstatt die Befehle direkt auszuführen schreibe in eine Datei, worauf ein inotify-Watcher reagiert daraufhin und im richtigen Kontext die Befehle ausführt.

Konfiguration udev

Wir starten mit udev. Zuerst gucken wir, wie die Tastatur identifiziert werden kann:

onli@fallout:~$ lsusb
Bus 003 Device 002: ID 8087:8001 Intel Corp. 
…
Bus 002 Device 007: ID 046a:a087 Cherry GmbH Wireless Mouse 
Bus 002 Device 009: ID 258a:1006 SINO WEALTH USB KEYBOARD

258a:1006 ist die gesuchte Kombination. Das packen wir nun in die udev-Regel unter /etc/udev/rules.d/80-ajazzmapping.rules (der Abschnitt vor .rules kann natürlich anders benannt werden):

ACTION!="add|change", GOTO="ajazz_rules_end"

ATTRS{idVendor}=="258a", ATTRS{idProduct}=="1006", RUN+="/usr/local/bin/keyboard-udev.sh"

LABEL="ajazz_rules_end"

Das Skript reagiert nur auf die Aktionen add oder change des Hardwaresystems, also wenn die Tastatur angesteckt wird. Per idVendor und idProduct schränken wir die Regel weiter ein auf genau die Hardwareidentifikatoren, die wir oben lsusb entnomment haben. Und dann soll ein Skript ausgeführt werden.

Aktion: keyboard-udev.sh

Und zwar dieses, gespeichert als /usr/local/bin/keyboard-udev.sh:

#!/bin/bash

# Path to lock file
lock="/tmp/keyboard.lock"

# Lock the file (other atomic alternatives would be "ln" or "mkdir")
exec 9>"$lock"
if ! flock -n 9; then
	notify-send -t 5000 "Keyboard script is already running."
	exit 1
fi

echo '' > /tmp/keyboard.lock &

# The lock file will be unlocked when the script ends

Das mit dem Lock ist gar nicht so ganz simpel, aber eigentlich müssen uns die Details hier nicht weiter interessieren. Wichtig ist: Nach /tmp/keyboard.lock wird geschrieben, und darauf können wir nun reagieren.

Die Reaktion

Dafür wird bei Start des Xservers der inotify-Watcher gestartet. Dafür kommt ein Aufruf zu file-inotify.sh in die $HOME/.xinitrc, sodass sie bei mir nun so aussieht:

/usr/local/bin/keyboardMapping.sh
file-inotify.sh /tmp/keyboard.lock /usr/local/bin/keyboardMapping.sh &  # Triggered by udev rule
xrdb -merge -I$HOME ~/.Xresources
exec dbus-run-session /usr/bin/icewm-session --notray

file-inotify.sh müssen wir noch anlegen, ich erstellte es als /usr/local/bin/file-inotify.sh:

#!/bin/bash
# Usage: file-inotify <file> 
# Command is run when file is written.

path=$(realpath "$1")
job="$2"
#basename=$(basename "$1")
dirname=$(dirname "$1")

inotifywait -m -e close_write --format '%w%f' "$dirname" \
	| while read file
do
	if [[ $(realpath "$file") == "$path" ]]; then
		sh -c "$job"
	fi
done

Und die /usr/local/bin/keyboardMapping.sh? Das sind einfach die Tastatursetzbefehle von oben:

#!/bin/bash
echo "remapping keyboard"
setxkbmap -variant altgr-intl -option -option compose:rctrl -option lv3:ralt_switch -option terminate:ctrl_alt_bkspc -option eurosign:e -option nbsp:level3n
xmodmap /home/onli/.Xmodmap

Die Tastatur sitzt

Jetzt steht das ganze System. Bei Systemstart wird per xinitrc der inotify-Watcher gestartet, der auf Dateisystemaktionen reagiert. Wenn udev das Einstöpseln der Tastatur mitbekommt schreibt es in die beobachtete Datei, woraufhin das Tastaturlayout gesetzt wird. Das funktioniert verlässlich und verursacht beim Warten keine Systemlast.

Die keyboardMapping.sh und damit die setxkbmap- und xmodmap-Befehle nicht manuell ausführen zu müssen ist an sich nur eine Kleinigkeit. Aber das automatisiert zu haben ist eine sehr angenehme Kleinigkeit. Ich vergaß es doch immer mal wieder, tippte daraufhin Unsinn zusammen und musste das Umschalten dann nachholen. So brauch ich nicht mehr dran zu denken.