Das perfekte Blogsystem
Wednesday, 11. May 2022
Ich fand mich bei einem Gedanken: Wie sähe das perfekte Blogsystem aus? Mit Serendipity bin ich mit dem hier laufendem klassischen PHP-Blogsystem ziemlich vertraut, mit ursprung habe ich mich an einem auf Ruby/Sinatra-basierendem Blogsystem mit ein paar alternativen Ideen versucht. Ich kenne Grundzüge von anderen Systemen wie Jekyll, Wordpress und ProcessWire, außerdem habe ich zwei Generatoren für statische Seiten geschrieben. All diese Lösungen haben Stärken und Schwächen, aber gibt es eine perfekte Kombination für Blogs?
Statisch und dynamisch
Wenn vom Leser eine Blogseite aufgerufen wird sollte diese nicht vom System dynamisch gerendert werden. Es sollte eine statische HTML-Seite sein, die der Webserver direkt ausliefern kann. Dem nahezukommen, das ist was die Cache-Plugins bei Wordpress und Serendipity versuchen, was aber nie optimal funktionieren kann wenn das Grundsystem dynamisch ist. Der Vorteil davon ist Performance: Zum einen geht der Server viel später in die Knie wenn ein Artikel mal populär wird, zudem ist im Normalbetrieb der statische Blog immer schneller als ein dynamisch generierter.
Das Blogsystem sollte aber nicht einfach ein statische Seiten auswerfender Generator sein. Denen fehlt zu viel was einen Blog ausmacht: Kommentare, Trackbacks/Pingbacks, auch das Backend mit seinen Moderatorfunktionen, dem Artikeleditor und der Mediendatenbank. Das sind nur ein paar der wichtigsten Funktionen, auf die ein perfektes System nicht verzichten würde. Dazu kommen beispielweise Dinge wie die Unterstützung mehrerer Nutzer, Veröffentlichungsworkflows, Rechteverwaltung und sicher noch viel mehr, was ich teilweise unten beschreibe.
Das perfekte Blogsystem wäre also zweigeteilt: Im Frontend würden statische Seiten generiert, aber parallel liefe ein dynamisches Backend, das Aufgaben wie das Entgegennehmen von Kommentaren übernimmt.
Stabilität, Erweiterbarkeit und Kompatibilität
Ein perfektes System wäre stabil. Damit meine ich inbesondere den Code und seine Sprache. PHP mit seinen fortwährenden Kompatiblitätsbrüchen ist beispielsweise eine besonders instabile Grundlage, die fortlaufend Entwicklungsarbeit verlangt. Das ist absurd für die Webumgebung, ist die doch grundsätzlich stabil: Selbst vor 30 Jahren erstellte HTML-Seiten können Browser von heute noch anzeigen. Es wäre also viel gewonnen, wenn das System um den Blog zu erstellen ebenfalls einmal gebaut werden könnte und dann gleichsam in 30 Jahren noch HTML/CSS und JS ausspuckt, dann zwar auf veraltetem Stand, der aber sicher noch verstanden werden würde.
Gleichzeitig sollte das System einfach erweiterbar sein. Was derzeit gute Blogsysteme auszeichnet ist ihr Pluginsystem und die Themebarkeit, sodass Entwickler mit wenig Aufwand das System anpassen können. Neue Logik hinzufügen und mit einem Theme die HTML-Ausgabe bzw das Design anpassen zu können, das ermöglicht die Anpassung an sich ändernde Zeiten ohne dauernd der Kern überarbeiten zu müssen.
Weil Blogs im Zweifel schon existieren bräuchte es im Sinne der Stabilität Importer. Die müssten Artikel so importieren können, dass ihre URL sich nicht ändert, wobei unter der alten URL Weiterleitungen auf eine neue sein könnten und Übersichtsseiten meiner Meinung nach nicht unbedingt erhalten bleiben müssen. Auch die Kommentare würden importiert. Bei der Frage wo die Daten dann landen bin ich zwiegespalten: Was ist perfekter, ein System das viele Datenbanken unterstützt oder eines, das sich auf SQLite konzentriert?
Umfassende Kompatibilität bedeutet auch die vollständige Unterstützung von Unicode. Wobei die Realität nunmal ist, dass alte Blogs in anderen Encodings geschrieben wurden. Ein perfekter Importer würde das konvertieren können.
Viele Standardfunktionen
In die großen Blogsysteme sind tausende Arbeitsstunden geflossen, in die meisten kleinen bestimmt immer noch hunderte. Entsprechend groß ist ihr Umfang. Schauen wir uns nur mal an was diesen Artikel hier von einem rohen handgeschriebenen HTML-Artikel unterscheidet.
So ist er nicht einfach in HTML geschrieben, sondern ist der rohe Text eine Mischung aus HTML und einer individuellen Markupsprache. Mit ihr sind Links einfacher setzbar. Umbrüche brauchen dank den nl2p-Plugin keine HTML-Tags. Zum Formatieren des Textes kann ich HTML oder die Markupsprache schreiben, aber alternativ sind hier auch Buttons beim Editor die das übernehmen können. Andere Systeme (und Serendipity optional) haben eine WYSIWYG-Ansicht oder eine Autovorschau, sodass der rohe Text schon beim Schreiben umgewandelt wird. Serendipity mit meinen Einstellungen hat dafür immerhin eine verlässliche Vorschau per Buttonklick, sodass ich Layoutfehler sehen kann bevor ich Artikel veröffentliche.
Im <head> ist in der Artikelansicht eine Anweisung für Suchmaschinen den Artikel zu indexieren, auf Übersichtsseiten dagegen wird das indexieren verboten. Es sind Tags gesetzt um den Artikel auf Twitter etc hübscher zu machen wenn er verlinkt wird, dabei wird auch ein Vorschaubild gesetzt, falls ich diesem Text noch ein Bild aus der Bibliothek hinzufüge wird dieses dafür benutzt werden. Thema Bilder: Die sind responsiv, kleine Bildschirme bekommen so kleinere und sparen Bandbreite.
Beim Schreiben kann ich komfortabel Schlagwörter und Kategorien zuweisen. Ich könnte den Artikel als Entwurf speichern oder die Veröffentlichung auf einen Moment in der Zukunft festsetzen. Er könnte dann sogar passwortgeschützt werden. Veröffentliche ich ihn, werden automatisch Trackbacks ausgesendet, was ich im Backend aber auch abstellen kann.
Gibt es nachher Kommentare kümmern sich direkt drei Plugins mit verschiedenen Ansätzen darum Spam auszusondern. Die sind so gut, dass Spam nur selten durchkommt. Wenn doch bekomme ich eine Email, wie auch bei legitimen Kommentaren. So kann ich auf die schnell reagieren. Eingehende Kommentare werden in einer Thread-Ansicht dargestellt, sodass Kommentatoren einander antworten können. Und natürlich gibt es für die Kommentare einen RSS-Feed, wie auch für die Artikel selbst und alle Kategorien.
Würde ich den Artikel dagegen in ursprung schreiben wäre der Editor komfortabel im Frontend auf der Startseite, der Kontextwechsel in ein Backend unnötig. Auch das ist eine Qualität, die ein perfektes System abdecken oder trumpfen müsste.
Und so ginge das jetzt sicher noch eine Weile weiter wenn ich alles aufzählen wollte. Man sieht schnell wie breit dieses Feld ist, wie viel ein neues System unterstützen müsste um auch nur gleichwertig zu sein.
Konkurrenz und Entwickler
Es gibt ziemlich viele Blogengines und CMS. So viele, dass es unmöglich ist einen Überblick zu behalten. Gleichzeitig gibt es mit Wordpress einen absoluten Gewinner, mit dem das halbe Internet läuft. Tatsächlich sehe ich das als Faktor: Ein perfektes System würde in einer Umgebung existieren in der es sichtbar werden kann, sodass seine Existenzberechtigung auch klar wird. So erwarte ich fast, dass ein Kommentator mir ein System benennen wird was den oben beschriebenen Ansatz teilt.
Und klar: Ein perfektes Blogsystem würde von einem aktiven Team netter und fähiger Entwickler geschrieben. Es wäre so perfekt, dass ich es nicht schreiben müsste (und auch nicht könnte). FOSS wäre es selbstverständlich auch. Sein Code wäre minimal, hätte keine instabilen Abhängigkeiten und wäre hervorragend lesbar.
Fazit
Wie seht ihr das, was habe ich vergessen? Ist was ich oben beschreibe überhaupt perfekt oder hätte sogar das beschriebene schon Macken?
Natürlich juckt es mich in den Fingern mich an einem solchen System zu versuchen. Dabei wäre das Ergebnis unzweifelhaft nicht perfekt – viele der Details wie die richtige Unterstützung der Markupsprachen und ob man das Markup oder das HTML speichert haben nicht die eine richtige Lösung – und einige der Anforderungen oben wie die Importer sind eine fast umstemmbare Mammutaufgabe, aber die Grundidee des statischen Frontends und dynamischen Backends umzusetzen hätte was. Sie hat generell derzeit etwas Aufwind, so geht Jamstack in die gleiche Richtung, ich sah in dem Kontext nur noch keine Umsetzung eines vollständigen Blogsystems.
Aber selbst wenn ich alle meine anderen Projekte zur Seite legen und mich der perfekten Blogengine widmen wollte: Scheiterte es nicht schon an der Sprachwahl? PHP wäre hier wegen seiner Instabilität offensichtlich Unsinn, wobei sein riesiger Vorteil der Hosterunterstützung damit wegfällt und schon deswegen eine Lösung ohne PHP kaum perfekt sein kann. Ich liebe Ruby, aber auch diese Sprache liefert nicht die Stabilitätsgarantien die das Projekt bräuchte. Ob Python da besser wäre erscheint nach dem Sprung auf Python 3 unwahrscheinlich. Vielleicht bräuchte es statischere Sprachen wie Rust, C oder Golang, aber komfortabel für Webanwendungen sind die nicht – und bei ihnen stolpere ich immer wieder über Projekte, die sich auf meinem System nicht kompilieren lassen. Stabilitätsgarantien in meinem Sinne gibt es da also nicht.
Was bleibt da? Etwas Lispiges wie Erlang, Common Lisp oder Racket? Etwas altgedientes wie TCL oder Perl? Eine Nischenlösung wie D?
Da erscheint direkt der erste Schritt zu schwierig.
Man nehme trotzdem den Gedanken mit, dass unsere Blogsysteme ziemlich gut, bessere Lösungen aber vorstellbar sind.
ProtonUp-Qt erleichtert das Protonupdate noch mehr
Monday, 2. May 2022
Mit protonup installiert man im Terminal die neueste Version von Proton-GE, was eine aktuellere und verbesserte Variante von Proton ist. Oft lassen sich so mehr Windowsspiele besser unter Linux spielen. ProtonUp-Qt ist eine GUI für dieses Kommandozeilenprogramm und erleichtert die Bedienung doch erheblich. Zumindest das Entfernen alter Versionen ist damit einfacher. So sieht es aus:
Nett auch, dass damit trotz des Namens nicht nur Proton aktualisiert werden kann. Sondern es kann auch Luxtorpeda, Boxtron und Roberta installieren. Das sind jeweils Helferprogramme, die sich ähnlich wie Proton in Steam vor die Spiele schalten und sie dann durch Auswechseln der Engine (Luxtropeda, Roberta) bzw des Emulators (Boxtron) verbessern.
Da ProtonUp-Qt als AppImage von der Webseite heruntergeladen kann läuft es problemlos auf jeder Linuxdistribution, Nutzer müssen es nicht selbst kompilieren oder warten bis es in die Quellen kommt.
Linksammlung 17/2022
Friday, 29. April 2022
Solo V2, Vorstellung und Einrichtung unter Linux (Void)
Monday, 11. April 2022
Wie auf Zuruf kam hier vorhin der Solo V2 an. Das ist ein USB-Gerät, das als zweiter Faktor zum Passwort dienen kann. Statt also zusätzlich zur Passwortabfrage eine SMS oder eine Email zu bekommen oder einen Code in einer App wie FreeOTP+ zu generieren wird der USB-Stick eingesteckt und aktiviert.
Das ganze war ein Kickstarterprojekt, der Nachfolger zum ersten Open-Source-Stick von SoloKeys. Stichwort ist dabei FIDO2, der Standard nach dem die Abstimmung zwischen Authentifizierungssuchendem und Stick funktioniert.
Das Konzept
Es geht also um den zweiten Faktor beim Einloggen in (im Normalfall) Webseiten. Ein per SMS gesendeter Code ist dafür die simpelste Lösung, hat aber den Nachteil relativ unsicher zu sein. Denn Telefonnummern können ziemlich einfach gestohlen/umgeleitet werden. Zudem braucht man dann immer Telefonempfang, was bei einer Reise auch mal schwierig sein kann.
Da sind die Apps mit ihren synchronisierten Codes (TOTP) besser, denn sie funktionieren offline. Aber auch sie sind nicht ideal: Telefone mit ihren vielen und oft proprietären Apps sind an sich keine sichere Umgebung, außerdem werden sie gern geklaut und können schnell mal kaputtgehen.
Daher wirkt so ein dediziertes Gerät wie der Solo, oder generell Fido-Sticks, wie eine gute Lösung für einen Zweitfaktor. Die Software darauf ist minimal und dient nur dem Zweck der Codegenerierung bzw Keyverwaltung. So ein USB-Stick ist relativ uninteressant zu stehlen und er hat schlicht kein Display was kaputtgehen kann, kann sogar vor Wasser geschützt werden. Zudem ist er einfach zu benutzen: Einfach einstecken, Knopf drücken (oder in diesem Fall: die Seiten berühren) und fertig. Mit FIDO2 samt WebAuthn gibt es auch bereits fertige Standards, die Seiten unterstützen. Und theoretisch kann das ganze auch statt dem Passwort genutzt werden, also als passwortloser Login (und damit als Haupt- statt Zweitfaktor), wobei dann unempfehlenswerterweise die Sicherheit alleine am Besitz des Sticks hängen würde.
Aber was, wenn solch ein Stick verloren oder doch kaputt geht? Das muss kein Problem sein. Webseiten, die solche USB-Sticks unterstützen, sollten immer mehr als einen zweiten Faktor unterstützen. Der zusätzliche kann dann einfach ein zweites Gerät sein, das an einem sicheren Ort aufbewahrt wird. Oder es ist dann eben doch die Telefonapp, die das Backup stellt, wiederum gesichert mit einem Offsitebackup der Appdaten.
Das Gerät
Der Solo V2 sieht nett gemacht aus. Direkt nach dem Auspacken:
Die Zeichnung ist hübsch und die Hardware selbst hat was. Mit der Hülle drumrum sieht man davon zwar nicht mehr viel. Aber dafür bleiben mit ihr nur noch die goldenen Kanten zu sehen, was auch ziemlich gut wirkt.
Ich hatte erst gar nicht verstanden, wie er zu benutzen ist und die Dokumentation erklärt das nirgends deutlich. Anfangs führte mich die runde Ausbuchtung in der Mitte in die Irre, als ob das ein Knopf sein sollte. Aber das ist wohl nur ein Überbleibsel vom Vorgänger. Tatsächlich muss man am PC die goldenen Kanten berühren, damit der Stick seine Arbeit tut.
Highlight dieser USB-A-Version ist das einfache Einstecken. Denn die Seite ist egal, der Stick funktioniert egal wieherum er im USB-Port sitzt. Das beseitigt einen massiven Nervfaktor für so ein Gerät, das ja im Zweifel relativ häufig eingesetzt werden muss und je nach Umgebung auch nicht immer einfach eingestöpselt bleiben kann. USB-C hätte den gleichen Vorteil gehabt, aber am PC hat man nunmal meist mehr USB-A-Anschlüsse, für das Telefon hätte ich den Solo nicht gebraucht.
NFC kann der V2 auch, aber mir ist nicht klar welchen Zweck das hat. Ermöglicht das Einloggen in Webseiten/Apps am Telefon geschützt mit einem Zweitfaktor, ohne den Stick anstecken zu müssen? Es stört mich durchaus, dass ich diese Information nirgends klar beschrieben finde.
Es gibt aber einen klaren Schnitzer: Die grüne LED ist viel zu hell.
Sie blendet trotz der Hülle so sehr, dass ich sie abkleben werde. Schade, dass das nötig ist.
Einrichtung unter Linux
Als ich den Fido-Stick dann bei mir testen wollte funktionierte er erst nicht. Die Packung verweist auf diese Startanleitung, derzufolge er durchaus direkt funktionieren könnte. Aber nicht unbedingt unter Linux. Da gebe es manchmal udev-Probleme, sagt die FAQ. Aber tatsächlich hilft die verlinkte udev-Regeldatei da nicht. Ich vermute, weil der Solo V2 in ihr andere IDs bräuchte.
Da kam ich erstmal nicht weiter, die Datei mit den mir von lsusb angezeigten IDs anzupassen griff nicht. u2f-hidraw-policy zu installieren war dann für mich unter Void die Lösung:
sudo xbps-install u2f-hidraw-policy
Das Paket fügt den System eine udev-Regel hinzu, die mithilfe eines kleinen Helferprogramms alle Fido-Sticks dem Nutzer und damit dem Browser zugänglich macht. Einmal aktivieren:
sudo udevadm control --reload-rules && sudo udevadm trigger
Jetzt sollte es gehen.
Einsatz zur Accountabsicherung
Nach der Einrichtung kann man den Solo V2 als Zweitfaktor einem Account hinzufügen. Ich machte das direkt bei meinem Googleaccount, der trotz meiner stark reduzierten Googlenutzung noch ein Sicherheitsrisiko ist. In den Sicherheitseinstellungen gibt es eine Option für die 2-Faktor-Authentifizierung. Dort kann ein USB-Gerät hinzugefügt werden, ein Security Key:
Und nachdem ich dann darauf kam, dass auf die goldenen Seiten gedrückt werden muss, funktionierte das auch. Jetzt ist der Fidostick ein weiterer Zusatzfaktor, der beim Einloggen statt den anderen Möglichkeiten – wie der Bestätigung im eingeloggten Telefon – genutzt werden kann.
Fazit
Es muss sich noch zeigen, wieviel ich den Solo V2 in der Praxis nutzen werden. Gekauft habe ich ihn um die Option zu haben, statt SMS und Telefonsoftware einen noch sichereren zweiten Faktor einsetzen zu können. Und auch wenn Google da mein erster Testkandidat war geht es mir mehr um Dienste wie Github. Wobei ich auch die Hoffnung habe, dass Banken durch Regulierungen von ihren proprietären Schrottapps wegkommen und dann eher Fido-Sticks als Alternativlösungen unterstützen.
Vor allem aber fand ich es sehr sympathisch, dass SoloKeys in diesem Bereich auf eine FOSS-Lösung setzt. Ihr Firmware-Framework Trussed ist nicht nur auf Github, sondern steht auch unter einer freien Lizenz. Noch dazu ist es in Rust geschrieben, was die richtige Wahl für solch sicherheitskritische Software ist. Das ist eine Seltenheit bei diesen Sicherheitslösungen, bei denen oft große Firmen mit möglichst intransparenten und teuren proprietären Lösungen mit möglichsten vielen ®, ™ und Patenten andere große Firmen adressieren.
Kann man einen Solo V2 gerade kaufen? Ich glaube nein. Für mich sieht es nur so aus, als könnte er immer noch auf Indiegogo vorbestellt werden. Der Vorgänger wird in ihrem Webshop verkauft, ich würde vermuten dass der V2 da irgendwann dazukommt.
Ein Update für pc-kombo während der Grafikkartenhölle
Wednesday, 9. February 2022
Ich kam dazu, einiges an Zeit in meinen Hardwareempfehler pc-kombo zu investieren. Er geht jetzt besser mit neuester Hardware um und warnt vor überteuerten Grafikkartenpreisen.
Anfang der Woche erwähnte ich noch, dass das Elend um die Grafikkartenpreisen für mich demotivierend war. Der Artikel war aber etwas im Voraus geschrieben. Das einmal ausformuliert zu haben half mir, die Situation neu zu bewerten. Denn tatsächlich ist die Lage mittlerweile etwas besser. Grafikkarten sind zwar immer noch dauernd überteuert, aber wenigstens sind fast immer wenigstens ein paar Modelle auf Lager – das war schonmal anders. Und mit der neuen Radeon RX 6500 XT und GeForce RTX 3050 gibt es zwei etwas günstigere Karten – mit Macken, die 6500 XT ist lahm, die 3050 schon wieder teurer; aber immerhin sind das Karten für deutlich weniger als 1000€ die man kaufen könnte. Einem System wie dem meinem, das auf verfügbare Grafikkarten angewiesen ist, hilft das enorm.
Das letzte Update an der Seite kümmerte sich also um eine bessere Anpassung an diese Situation:
- Die neuen Grafikkarten sind im System und passende Benchmarks eingelesen, sodass sie sauber platziert und empfohlen werden.
- Die Alderlake-Intelprozessoren sind jetzt samt ihren neuen nicht übertaktbaren Varianten im System, was insbesondere mit dem i3-12100F einen interessanten Budget-Prozessor, dem i5-12500 eine gute Standardwahl und mit dem i7-12700K einen starken High-End-Prozessor bringt.
- Passend zu den Prozessoren gibt es mehr Mainboards, auch mit den neuen H670- und B660-Chipsätzen. Das Empfehlungssystem wählt die auch für die nicht-übertaktbaren Prozessoren.
- Wenn der Empfehler vorher ein Mainboard mit DDR5-Speicher gewählt hätte, prüft er jetzt ob es eine günstigere DDR4-Variante gibt. DDR5 ist überteuert und nicht schneller, bisher.
- Bei einigen Prozessorkühlern habe ich manuell die Information hinzugefügt, dass sie (mit einem Nachrüstkit) mit dem Sockel 1700 der Alderlake-Prozessoren kompatibel sind.
- Bei der Grafikkartenauswahl werden hohe Preise rot markiert. Eine Hover-Einblendung zeigt dann über dem Preis an, wieviel teurer der aktuell beste Preis im Vergleich zur Preisempfehlung ist.
Zusätzlich habe ich mehrere kleine Bugs behoben. Darunter einen, der ein paar Benchmarkdaten blockierte. Der war vorher für mich unsichtbar und machte das Updaten der Benchmarksammlung schwierig, das gelöst zu haben war unheimlich angenehm. Das ganze System wirkte dann wieder beherrschbar.
Zuvor hatte ich bereits das System angepasst, damit es mehr Daten zu den integrierten Grafikkarten hat und die auch öfter empfiehlt (ich erwähnte es hier im Blog). Das erschien mir jetzt nochmal als superwichtige Änderung, die ich aber fast vergessen hatte. Mit ihr und jetzt dem Hinweis auf die hohen Grafikkartenpreise schon umgesetzt, gibt es noch mehr was pc-kombo machen könnte um mit den hohen Grafikkartenpreisen und ihrer schlechten Verfügbarkeit umzugehen?
Womit ich arbeite (Beginn 2022)
Monday, 7. February 2022
Der Artikel von Thomas hat mich daran erinnert, dass meine Übersicht der von mir für Arbeit genutzten Hard- und Software Anfang 2019 war und ich solche Artikel – wie die Serie von Dirk – gerne lese bzw schreibe. Zeit für ein Update.
Tatsächlich hat sich einiges getan. Vielleicht ist das weniger überraschend als ich erst meinte: 2019 war ich ziemlich frisch in Deutschland zurück, in einem seltsam definierten Job an einem Forschungsinstitut und benutzte daheim größtenteils nicht für die Ewigkeit gedachte Hardware aus meiner Unizeit. Jetzt ist es ein Job, ein Umzug, drei Jahre und eine Pandemie später, da bleibt schon durch den Verschleiß nicht alles gleich.
Hardware
Auf der Arbeit benutze ich einen mir gestellten Laptop, der an einen 1080p-Monitor angeschlossen wird – gleiche Idee wie vorher also. Aber der Laptop steht bei mir daheim, denn ich arbeite von hier, und der Monitor ist meiner. Der Laptop ist ein Thinkpad E495 mit einem Ryzen 7 3700U, der letztes Jahr auf 32GB Arbeitsspeicher aufgerüstet werden musste. Die Maschine ist kein Highlight, aber taugt.
Für mich selbst benutze ich den gleichen Desktoprechner wie vorher, nur dass ich seine Hardware fast komplett ausgewechselt habe: Ein i5-5675C (dessen starke integrierte Grafikeinheit ein Segen war) auf einem Z97M-G43 mit jetzt insgesamt 24GB Ram kam rein, das ist alles gebraucht gekauft. Dazu kommt eine Radeon RX 570, wobei ich die wieder der Physikerin zurückgeben will, wenn sie wieder Lust auf PC-Spiele hat. Denn die Karte war schonmal in ihrem PC, nämlich als ich die RX 580 nutzte, deren Instabilität zu einem Kühlerwechsel zu viel und damit dem Ableben der Grafikkarte führte. Dadurch lief mein System lange ohne dedizierte Grafikkarte, man konnte das an den fehlenden Grafikkrachern bei meinen Spielebesprechungen letztes Jahr bemerken. Die vorher installierte 120GB große SSD wurde samt vieler anderer alten Hardwarekomponenten einem Verwandten gespendet, nur noch die 500GB Crucial MX 500 ist neben einer Backupfestplatte im System. Das ist angenehm überschaubar, 500GB werden mir aber langsam zu wenig und dürften bald durch eine M.2-NVMe-SSD ergänzt werden.
Der Monitor ist ein Acer CB242Y, 1080p@75Hz mit IPS-Panel. Heute ist er überteuert, zum Preis von damals war er eine gute Wahl, ich bin weiterhin zufrieden. Der Dell U2312HM von zuvor ist auf den Schreibtisch nebenan gewandert und funktioniert ohne neue Macken.
Bei den Peripheriegeräten hat sich viel getan. Die G80-3000-Cherrytastatur rastet zurzeit, ich schreibe mit der kleineren A-Jazz AK33 und habe mich an die gut gewöhnt. Meine Maus ist die Cherry MW 4500, die ich im November repariert habe, die vorherige CSL-Maus wurde ebenfalls repariert (simpler: Katzenhaare im Mausrad) aber wanderte auf einen anderen Schreibtisch. Kopfhörer benutze ich zwei: Primär den passiv isolierenden ATH-M50x, der Logitech-Vorgänger war komplett durch; wenn ich sprechen muss oder auf eine Lieferung warte wechsel ich zum Philips SHB 7000, der mir vor einigen Jahren geschenkt worden war. Ich spreche dann meistens in das Mikrofon aus dem t.bone MB 88U Dual Bundle.
Um den Wechsel zwischen Laptop und Rechner am Arbeitsende angenehmer zu machen benutze ich den USB-Switch Aten US224. Ein wichtiger Bestandteil meiner Heimarbeitsstrategie, damit die Peripherie komfortabel zu teilen, aber die Rechner zu trennen. Er funktioniert im Betrieb zuverlässig, nur direkt nach dem Einschalten muss er manchmal einmal hin- und hergeschaltet werden. Das Mikrofon läuft per USB auch über den Switch, der gerade aktive Kopfhörer dank dem Sharkoon DAC Pro S V2 ebenfalls – wobei mit dem DAC der M50x ein minimales Rauschen hat wenn gerade nichts abgespielt wird, was mich zum Glück bisher nicht stört.
Die Peripherie komplettiert weiterhin das gleiche Ikeazeug: Ein Markus-Bürostuhl (den damals in grauem Textil zu kaufen war richtig, haltbarer als die Kunstledervariante), die Linnmon-Adils-Günstigvariante eines Schreibtischs und hinter dem Monitor eine nicht mehr geführte Plastiktischleuchte. Neben dem Schreibtisch steht neuerdings ein Karton mit Zeug, keinen Stauraum zu haben ist der Nachteil des einfachen Tischs als Schreibtisch, aber was solls, das funktioniert.
Mein Telefon war zuvor ein Wileyfox Spark+, das aber mittlerweile keine Updates mehr bekommt. Ich benutze es noch als Google-Gerät zum Testen und für Apps, die den Playstore brauchen. Die Alternative hatte ich lange recherchiert und darüber geschrieben. Über ein leider schnell defektes LG G3 landete ich bei einem LG G5. Müsste ich wieder wechseln sollte sustaphones mir eine Übersicht verschaffen, wenn dann nicht sogar ein Linuxtelefon bereitsteht.
Wieder war ich unterwegs und brauchte dafür ein Notfallgerät. Das Touchpad schien mir dafür zu alt, mein Pinetab diente als Ersatz. Das funktionierte leidlich.
Software
Ich beschränke mich hier aufs grobe.
Der Arbeitslaptop läuft mit Ubuntu LTS 20.04.3. Als ich am ersten Arbeitstag schnell entscheiden musste, um kein Apple-Gerät aufgedrückt zu bekommen, erschien mir Ubuntu als die sicherste Wahl. Firefox, Chromium und Visual Studio Code samt Androidemulator ergeben die sehr simple professionelle Arbeitsumgebung.
Auf meinem eigenen Rechner bin ich bei Void geblieben, der Wechsel war damals ganz frisch. Dieser Distro eine Chance zu geben war im Nachhinein eine tolle Entscheidung, ich hatte null Ärger mit ihr. Der Desktop ist wie zuvor selbst zusammengestellt (icewm, conky, simdock, trayer), gute Software braucht keinen Wechsel. Firefox und Geany sind daher weiterhin die Hauptwerkzeuge, allerdings habe ich Trojitá mit Thunderbird ersetzt. Trojitá hätte nur wenige UI-Verbesserungen gebraucht um toll zu sein, aber die kamen die Jahre über einfach nicht.
Auf meinem LG G5 läuft LineageOS 18.1 ohne Playstore, dafür mit F-Droid. Tatsächlich ist das als Testgerät arbeitsrelevant. Ich habe inzwischen einige Apps mehr im regelmäßigen Einsatz, aber davon wiederum dient nichts der Arbeit, die werde ich in einem späteren Artikel auflisten.
Eine Umstellung in meinem Browser wirkt sich allerdings schon auf den FOSS- wie regulären Arbeitsalltag aus: Statt duckduckgo ist die Suchmaschine von Brave überall meine Standardsuchmaschine. Sie ist so viel besser, dass ich praktisch nie zu Google wechseln muss, der Unterschied zu vorher ist enorm.
Server
Meine Internetpräsenz ist auf mehrere Hoster und Server verteilt, die ich diesmal etwas detaillierter beschreiben will.
Dieser Blog lebt seit dem Wechsel von Scaleway auf der günstigsten Cloud-Compute-SSD-Instanz von vultr. Auf IPv4 zu verzichten drückt den Preis, Backups erhöhen ihn wieder, die letzte Rechnung war $3.57. Dass der Blog trotzdem per IPv4 erreichbar ist liegt an Cloudflare als kostenlosen Vermittler.
Mein Hardwareempfehler pc-kombo wird von Scaleway gehostet. DEV1-M ist für das Projekt derzeit überteuert – die absurden Grafikkartenpreise und -nichtverfügbarkeit machen mir den Spaß an dieser meiner ältesten eigenen Webanwendung momentan zunichte und die Seite auch nicht gerade zu einer Einnahmequelle. Ich sollte die Gelegenheit nutzen und den Hoster wechseln, allein mir fehlte selbst dazu bisher die Motivation.
Pipes dagegen wird kompetent und günstig von Hetzner gehostet. Hier gibt es keinen Änderungsbedarf. Ich würde pc-kombo hierhin umziehen, wenn ich nicht die Regel hätte zur Risikovermeidung jedem Projekt einen eigenen Hoster zu geben.
Die neueste Seite sustaphones ist eine statische Seite, die umsonst von netlify ausgeliefert wird. Ich wäre bei dem kostenlosen Angebot kritisch, wenn das nicht so gut funktionieren würde dass ich tatsächlich glaube, dass sich das als Werbung für die lohnt. Außerdem ist der gesamte Quellcode samt dem HTML meiner Seite auf Gitlab, sodass ein Wechsel kein Problem wäre.
Uberspace ist Hoster meiner Emails und dient mir gelegentlich als Entwicklungsumgebung, vor allem für Serendipity. Uberspace primär für Emails zu nutzen ist wahrscheinlich ungewöhnlich, war aber immer einwandfrei und ist empfehlenswert.
Ich habe noch zwei Heimserver am Laufen: Der uralte Pogoplug ist mit einer 5TB großen externen Festplatte das Borg-Backupziel (früher war er auch Heimat meiner Webseite fürs Musikabspielen), ein relativ neuer Raspberry Pi 4 Model B mit 4GB Arbeitsspeicher aktualisiert regelmäßig die Preise in der Datenbank von pc-kombo.
Soviel zur Arbeitsausstattung vom Hobby- und professionellem Arbeitsplatz. Ich glaube, dass jede der Änderung sinnvoll und gut motiviert war. Selbst wo das nicht so eindeutig war, war der Wechsel meist richtig – der neue Prozessor zum Beispiel war ein totaler Gelegenheitskauf, aber seine Grafikeinheit wurde später zum Glücksfall.
Diese Setup-Beschreibungsartikel sind nun schon eine Blogtradition, wer mehr davon lesen will findet ein paar aktuelle bei Thomas verlinkt. Weitere Artikel anderer Blogger sind auch immer gern gesehen.
Sustaphones mit mehr Roms und Daten zum Kopfhöreranschluss
Monday, 31. January 2022
Wohl weil ich letztens mit Freunden über die Seite sprach war ich motiviert, sustaphones ein paar Updates zu geben. Nichts grundlegendes, aber es gibt ein paar Verbesserungen:
- Mit PixelExperience und Havoc-OS werden nun zwei weitere Android-Varianten gelistet, neben LineageOS, /e/ und MokeeRom.
- Via PixelExperience kamen weitere Telefone auf die Seite (während für Havoc-OS die Dokumentation dafür zu wenige Daten liefert), insbesondere einige 2021 veröffentlichte.
- Zu allen Telefonen in der Datenbank habe ich manuell nachgetragen, ob ein Kopfhöreranschluss vorhanden ist oder nicht.
- Gesammelte Kleinigkeiten: Das Platzhaltericon ist mit einem schöneren ersetzt, ein fehlendes Icon wurde nachgetragen, die Sortierreihenfolge angepasst.
Das macht erstmal keinen groß sichtbaren Unterschied, außer dem handgebauten Platzhaltericon:
Aber zusammengenommen dürften die Änderungen die Seite etwas hilfreicher machen.
Mir hat das Arbeiten an der Seite diesmal wieder Spaß gemacht, größtenteils. Denn klar, für hunderte Telefone die Daten zum Kopfhöreranschluss zu prüfen macht erstmal wenig Freude, es ist nur danach angenehm das komplettere Datenset zu sehen. Doch wie die Seite gebaut wird gefällt mir immer noch: Jedes einzelne Android-Rom bekommt seinen eigenen Parser, der dadurch ziemlich simpel bleibt. Der Parser liest strukturierte Daten, die von den Projekten bereitgestellt werden, und schreibt das Ergebnis in eine gemeinsame YAML-Datei. Ein weiteres Skript ergänzt die Datei um Bildern und Batteriewechselanleitungen aus der ifixit-API. Schließlich erstellt ein letztes Skript das HTML der Seite, wobei es dafür zwei Templatedateien benutzt. Das alles ist in Ruby geschrieben und auf Gitlab nachvollziehbar.
Netlify hostet die statische Seite kostenlos und zieht sich das HTML komfortabel aus dem Git-Repo, nach jedem Push vollautomatisch. Alles zusammen sehe ich in diesem Entwicklungsmodell ein gutes Beispiel für die Vorteile statischer Seiten bei solchen datengetriebenen Anwendungsfällen.
Meine Motivation an der Seite zu arbeiten ist noch nicht ganz verraucht, falls jemand Vorschläge hat.
Die Trennung der Computersphären
Monday, 17. January 2022
Wohl weil ich derzeit zu Hause arbeite, hat sich bei mir eine strikte Trennung der verschiedenen Geräte etabliert.
Während der Arbeit ist der Computer aus und der Laptop an, wodurch die beiden Geräte sich einen Monitor teilen können und via einem USB-Hub auch Maus und Tastatur. Auf dem Laptop habe ich keinen Zugriff auf meine eigenen Mails, auf meine privaten Chatprogramme, Steam, den Firefox-Account oder meinen Github-Account. Eingerichtet ist dort nur was für die Arbeit gebraucht wird: Visual Studio Code, Thunderbird zeigt auf die fast nur für passive Benachrichtigungen genutzte Büroadresse, Microsoft Teams läuft im Browser, für Github habe ich einen eigenen Arbeitsaccount. Nur der Google-Account ist eine theoretische Brücke, wird aber nur für Youtube Music benutzt. Praktisch nichts kann mich so stören oder ablenken, Thunderbird ist meistens aus und bei Teams kann im Zweifel einfach das Tab zugemacht werden.
Vorteil eines guten kleinen Teams, dass ein solches Abtauchen bisher nie ein Problem, aber auch nur selten nötig war.
Nach der Arbeit ist der Laptop immer aus, oft der PC an. Auf dem PC habe ich keinen Zugriff auf meine Arbeitsaccounts, insbesondere nicht auf Github oder Teams. Es gibt also keine Versuchung mit der eigenen Hardware weiterzuarbeiten oder erreichbar zu sein. Erreichbar wäre ich über den PC auch nur per Mail, denn seit ich vor vielen Jahren ICQ ausgelassen habe und IRC wegfiel hat sich kein neues Chatprogramm eingenistet. Und das Emailprogramm (seit kürzerem auch hier wieder Thunderbird) ist meistens aus. Beides hilft, sich am PC nicht ablenken zu lassen, und sei es nur vom gerade laufenden Spiel.
Es bleibt das Telefon. Und klar: Hier kann man mich praktisch immer anrufen und erreichen, im Notfall dürfte das auch die Arbeit machen. Auf dem Telefon läuft Telegram, wodurch ich mit einigen wenigen Leuten regelmäßig Kontakt halte – aber das schöne ist, dass man das Gerät ja einfach weglegen kann. Während ich das hier schreibe weiß ich zum Beispiel gar nicht wo es liegt. So lässt sich auch das gut ausblenden, wenn es gerade nicht passt. Aber obwohl da wie beim PC nur private Accounts laufen, ist es doch nicht einfach eine weglegbare Dopplung des PCs; Insbesondere sind ganz bewusst Emails nicht eingerichtet. Dadurch sind sehr viele meiner Internetaktivitäten ausgeblendet, sei es alles auf Github, Kommentare hier im Blog, Kommentarantworten auf anderen Seiten oder Supportanfragen für Pipes.
Diese Trennung bedeutet auch, dass ich unterwegs ohne den PC von viel abgeschnitten bin, weil bei mir doch sehr viel über Emails läuft und das Telefon darauf gewollt keinen Zugriff hat. Als mich das letzten Monat länger betraf hatte ich deshalb das vorbereitete Pinetab dabei. Mit seiner Tastatur und mit postmarketOS bewährte sich das vielversprechende Konzept des Geräts, es kann wirklich kurzfristig den Linux-PC ersetzen. Nur kurzfristig, weil es einfach zu lahm ist. Aber es reichte so gerade für etwas Programmierung, etwas Designarbeit im Blog und für die Emails, wobei die mit einem echten Mailprogramm statt der Roundcube-Weboberfläche wahrscheinlich angenehmer gewesen wären.
Durch diese Aufstellung betreffen mich viele der Bedenken gegen das Arbeiten von daheim kaum. Die Trennung der Geräte hilft der Trennung im Kopf, wenn es schon kein eigenes Heimbüro nur für die Arbeit sein kann, was wohl psychisch noch idealer wäre. Ich habe auch wirklich den Eindruck, weiterhin ziemlich gut mit der Heimarbeit zurechtzukommen, wobei die absolut nicht übergriffigen Kollegen und Vorgesetzten da sicher auch ein großer Faktor sind.
FreeSync-Range unter Linux anpassen
Monday, 29. November 2021
Unter Windows lassen sich relativ einfach die FreeSync-Grenzwerte von Monitoren anpassen. Unter Linux geht das auch, aber es ist weniger einfach – und bei mir war es auch nicht erfolgreich. Trotzdem hier der Zusammenschrieb, für einen erneuten Versuch in der Zukunft.
Im Grunde kann man in großen Teilen dieser Anleitung folgen (die ich leider erst jetzt fand), aber ich musste zusätzlich mit dracut arbeiten um die neue Konfiguration beim Booten laden zu können.
Wie man FreeSync überhaupt aktiviert habe ich in einem früheren Artikel schonmal beschrieben.
Die Anpassung sollte harmlos sein, aber garantieren kann das niemand. Und selbst wenn sie nur nicht erfolgreich ist, kann nach den folgenden Änderungen der Monitor unter X auch ganz ausbleiben, sodass dann die Konfiguration in der Konsole zurückgestellt werden oder der Monitor solange an einen anderen Grafikkartenanschluss muss. Man sei sich dem bewusst.
EDID auslesen
Die EDID ist eine Datei mit den Metadaten des Monitors. In ihr steht auch die FreeSync-Konfiguration. Sie wird beim Starten des Grafiktreibers geladen. Normalerweise läuft das automatisch, aber wir können sie abfangen.
xbps-install read-edid sudo modprobe i2c-dev sudo get-edid > edid.bin
xbps-install ist der Paketmanager unter void, unter Ubuntu ersetzt man das mit apt install.
EDID anpassen
Die soeben erstellte edid.bin kann wxedid nun editieren. Bei mir war das Programm nicht in den Quellen. Daher musste ich manuell ein Release von SourceForge herunterladen, entpacken und kompilieren:
./configure make ./wxedid
Mit dem Programm lässt sich jetzt die edid.bin öffnen. Der für uns interessante Reiter ist "MRL: Monitor Range Limits". Der Eintrag min_vFreq ist die Untergrenze, max_vFreq die Obergrenze. Die jetzt editieren, danach die Datei neu exportieren.
Verschiebe diese neue Datei nun nach /lib/firmware/edid/new_edid.bin
Nur NVIDIA: xorg.conf anpassen
Die EDID lässt sich bei NVIDIA-Treibern per xorg.conf laden, wie das Arch-Wiki beschreibt. Falls noch nicht vorhanden, erstelle dir einen Screen-Konfigurationsblock, z.B. unter /usr/share/X11/xorg.conf.d/20-screen.conf:
Section "Screen"
Identifier "Screen0"
Device "nvidia" # könnte auch anders heißen
Option "CustomEDID" "$MONITOR:/lib/firmware/edid/new_edid.bin"
EndSection
$MONITOR muss noch mit der richtigen ID des Monitors ersetzt werden. Die findet sich per xrandr, war bei mir wie oben zu sehen also DisplayPort-1.
Das sollte es für NVIDIA-Nutzer auch schon gewesen sein. Da ich eine Grafikkarte von AMD benutze konnte ich das aber nicht richtig testen.
Der amdgpu-Treiber kennt CustomEDID aber nicht, deshalb da der folgende Ansatz.
Nur AMD: Die initramfs ergänzen
Es kann sein, dass es bei deinem System für diesen Schritt ausreichte die Datei nach /lib/firmware/edid/ zu verschieben.
Bei mir reichte das nicht, wohl weil die initramfs die EDID laden würde, sie aber auf diesen Ordner keinen Zugriff hat. Ich bekam dann später nach Setzen des Bootparameters diese Fehlermeldung:
*ERROR* Requesting EDID firmware new_edid.bin failed (err=-2)
Mit dracut ändert man das so:
sudo dracut -i /lib/firmware /lib/firmware --force
Der Befehl bläst die initramfs leider sehr auf und man müsste das regelmäßig machen, wenn ich herausfinde wie man das richtig konfiguriert und zielgerichtet nur die EDID-Datei hinzufügt wird dieser Artikel editiert. Aber zum Testen reicht es.
Allerdings benutzt nicht jede Distribution dracut. Dieser Launchpadbug beschreibt eine Lösung für Ubuntus initramfs-tools, was die meisten anderen Distributionen abdecken dürfte.
Nur AMD: Den Bootparameter setzen
Um die EDID dann auch wirklich zu laden setzt man in der /etc/default/grub den Parameter drm.edid_firmware:
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=4 … drm.edid_firmware=DP-2:edid/new_edid.bin"
DP-2 ist systemabhängig und folgt nicht der gleichen Nummerierung wie xrandr. Die richtige findet man mit
grep . /sys/class/drm/card-/status
Nicht vergessen die neue grub-Konfiguration auch anzuwenden:
sudo update-grub
Testen
Beim nächsten Neustart sollte der Treiber den Monitor nun gemäß der neuen EDID ansprechen. Zum Testen empfehle ich wieder VRRTest.
Für meinen Acer CB242Y hat die ganze Aktion nichts gebracht. Erhöhe ich die obere Grenze, wird alle paar Sekunden der Bildschirm schwarz. Senke ich die untere Grenze, wird der Bildschirm schwarz sobald die FPS unter 48 fallen.
Ich fand ein paar Kommentare von Nutzern, bei denen diese Freesync-Anpassung unter Windows ging, aber unter Linux nicht. Es kann durchaus sein, dass die anderen Treiber da mehr herausholen können, oder dass die unter Windows benutzte Software wie CRU beim Editieren der EDID noch weitere Tricks draufhat. Vielleicht geht da also später noch was, vielleicht wird es irgendwann auch komfortabler und der Treiber kann die Freesync-Range ohne den Umweg über die EDID anpassen.
