Die Aprilscherze in LineageOS halten traditionell im ersten April-Build eines jeden Geräts Einzug in das Custom ROM. Dadurch trudeln sie etwas später ein, der „Oha!“ Moment dürfte dafür umso größer sein.
Auch dieses Jahr hat man sich mit den LOSCoins wieder viel Mühe gegeben. Nach dem Start erscheint direkt eine Benachrichtigung über das Vorhandensein einer möglichen Softwarefälschung. Um Missbrauch zu vermeiden, werden fortan angeblich LOSCoins generiert. Ha! 😀
Der letzte große Wurf in Punkto Theme fand letztmals im Jahre 2014 statt. Auch heute noch basiert das im Blog genutzte Theme auf Twenty Fourteen, einem direkt von WordPress.org stammenden Hauptheme, das vollständig reponsive ist und damit eines der Hauptkriterien erfüllt. Die neueren WordPress-Themes finde ich durchaus schick, aber noch konnte ich mich für kein gänzlich anderes erwärmen. Das mag sich dann aber irgendwann in Zukunft ändern, bis dahin habe ich aber vor einigen Monaten bereits einige Änderungen im Hintergrund ohne größere Erwähnung am momentan genutzten Theme vorgenommen: Auslagerung in ein Child Theme, CSS-Änderungen, Wechsel auf eine andere Schrift sowie ein neues Logo. Letzteres habe ich dabei erstmals mit Inkscape erstellt. Ein Grafikkünstler werde ich vermutlich zwar nicht mehr, aber ich konnte damit fürs erste halbwegs leben 😀
In der vergangenen Nacht habe ich nun noch einmal einen Blick auf die Änderungen geworfen und einige Kanten beseitigt: die Linkfarben habe ich etwas kräftiger gestaltet (diese waren zum Teil deutlich zu hell und nicht angenehm zu lesen), neue CSS-Farbverläufe in einigen Seitenbereichen eingefügt, einige weitere kleinere Details angepasst und es gibt einmal mehr ein neues Logo. In den letzten Wochen ist mir der kostenlose Gravit Designer ins Auge gesprungen (leider nicht Open Source wie Inkscape, aber trotzdem ein tolles Tool), damit lassen sich schicke Logos basteln. Die Bedienung ist für Fireworks-Umsteiger deutlich bequemer als sie es mit Inkscape vermutlich je sein wird. Das nun eingebundene Logo ist das Ergebnis der Bemühungen in der letzten Nacht 😀
Mit den nun vorgenommen Anpassungen sind die Hauptkritikpunkte am aktuellen Theme hoffentlich beseitigt, möge das Theme für die kommenden Monate weiterhin seine Dienste leisten 🙂
Schon in der Vergangenheit gab es im freien Editor Notepad++ das ein oder andere Easter Egg. Mit der gestern veröffentlichten Version 7.5.6 kam ein ganz offizielles hinzu – der Hinweis befand sich sogar in der Veröffentlichungsnachricht: „And help us to relay a message from outer space: type „Space Invaders“, select it, then hit F1.“
Der bitte um Weiterverbeitung komme ich natürlich gerne nach 😉 So sieht die Nachricht aus dem Weltraum aus:
Auch wenn es einige Alternativen zur gewöhnlichen Bash unter Linux gibt, zählt sie auch heute noch zu den beliebtesten Shells. Auch ich selbst nutze sie auf meinem Server noch rege. Die Z shell (zsh) sieht zwar ebenso vielversprechend aus, aber das ist ein Thema für ein anderes mal.
Unbegrenzte History
Kommen wir zurück zur Bash: etwas, dass ich lange vermisst habe, war die Größe der History so festzulegen, dass diese nicht begrenzt ist. Oftmals gibt es dann doch den einen Befehl, der nützlicherweise noch in der History schlummern könnte, wenn er nicht schon dem Größenlimit zum Opfer gefallen wäre. Festlegen lässt sich die Historygröße grundsätzlich über die beiden Variablen HISTSIZE sowie HISTFILESIZE. HISTSIZE legt dabei die maximale Anzahl von Befehlen bzw. Zeilen fest, die in der History im Hauptspeicher während einer Sitzung festgehalten bleiben. HISTFILESIZE legt dagegen die maximale Anzahl von Befehlen bzw. Zeilen in der Historydatei fest, die gespeichert bzw. beim Start der Bash geladen werden. Wichtig ist also, beide Werte entsprechend anzupassen. Bis zur Bash Version 4.3 gab es AFAIK keine Möglichkeit, beide Werte auf „unlimitiert“ zu setzen, sodass lediglich ein möglichst hoher Wert eine Alternative darstellte. Seit Version 4.3 führt ein Wert kleiner 0 zu einer unbegrenzten Größenfestlegung. Dazu sind folgende beiden Einträge in die Bashkonfiguration aufzunehmen:
HISTFILESIZE=-1
HISTSIZE=-1
History mit Zeitangaben
Doch auch wenn nun verwendete Befehle weit in der Vergangenheit nachgeschlagen werden können, bleibt manchmal die Frage offen, zu welchem Zeitpunkt ein Befehl ausgeführt wurde. Über HISTTIMEFORMAT lässt sich das Historyformat entsprechend anpassen, sodass die History künftig um eine Zeitangabe erweitert wird. Ein mögliches Format kann beispielsweise so aussehen:
HISTTIMEFORMAT=“[%d.%m.%y] %T „
Dies resultiert in Historyeinträgen im folgenden Schema: 536 [12.02.18] 00:13:56 ls -lha
.bashrc vs .bash_profile Bleibt noch die Frage offen, in welche der beiden Dateien die neuen Kofigurationszeilen aufzunehmen sind. Grundsätzlich lassen sich die Einträge in beide Dateien eintragen, sie werden allerdings zu unterschiedlichen Zeitpunkten Verwendung finden. Die .bashrc wird bei jedem Öffnen eines interaktiven Terminals automatisch geladen, während die .bash_profile beim Öffnen einer Login-Shell geladen wird. Um auf der sicheren Seite zu sein, müssten die Einträge also in beiden Dateien vorgenommen werden. Bei einem Server, der ohnehin grundsätzlich über SSH angesteuert wird, lässt sich die .bashrc aber auch automatisch mit der .bash_profile ausführen. Dazu ist lediglich folgendes kleine Snippet in die .bash_profile einzutragen:
Mit dem vor wenigen Tagen veröffentlichten Office Update für Mac werden nach 20 Jahren erstmals wieder alle Plattformen aus einer gemeinsamen Codebasis bedient. Dadurch lassen sich künftig Features, die zuerst in einer Plattform integriert werden, zeitnaher auf anderen Plattformen ausbreiten. Um dies zu bewerkstelligen, besitzt jede Plattform entsprechende Updatemechanismen. Diese unterscheiden sich sich grundsätzlich – so auch bei der Windows und Mac Variante.
Microsoft Office für Windows hält zwei verschiedene Wege für die Installation und Updates parat. Zum einen existiert der Weg über die MSI-basierte Installation. Diese stellte bis Office 2010 die gängige Methode zur Installation von Office dar. Auf diesem Weg werden die Office Updates über Windows Updates eingespielt – also ganz klassisch.
Seit Office 2013 gibt es mit Click-to-Run (Klick-und-Los) eine neue standardmäßige Variante. Hierbei wird die Office Installation auf den Computer gestreamt, sodass die Anwendungen bereits während der Installation genutzt werden können. Dabei wird die Office Installation über App-V virtualisiert und die einzelnen Office Anwendungen in verschiedene Module aufgeteilt. Die Office Updates werden hier über einen eigenen Mechanismus direkt aus Office heraus vorgenommen. Dadurch, dass nur veränderte Module einer Anwendung ausgetauscht werden müssen, ist ein Update in der Click-to-Run Variante deutlich schneller als über die MSI-basierte Installation via Windows Update.
Microsoft Office für Mac nutzt mit Microsoft AutoUpdate (MAU) einen eigenen Mechanismus für Updates. Die Updategröße richtet sich dabei nach dem Alter der zu aktualisierenden Office-Instanz. Liegt diese schon einige Versionen zurück, kommt ein Komplettupgrade zum Tragen, das vom Umfang einer Neuinstallation gleicht. Liegt die Office-Instanz eine oder mehrere, aber noch nicht deutlich mehr Versionen zurück, kann auf Delta-Updates zurückgegriffen werden. Diese enthalten nur die Änderungen für einige wenige zurückliegende Versionen. Sie fällt im Vergleich zum Komplettupgrade deutlich kleiner aus und spart etwa 77 Prozent der Größe ein. Mit der nächsten Microsoft AutoUpdate Version (MAU 4.0, noch nicht veröffentlicht) werden zudem Ultrathin Updates (Binary-based Updates) Einzug halten. Diese sparen nochmals deutlich an Umfang ein: der Unterschied zu einem Delta Update beträgt in einem Beispiel mehr als 90% – sie dürften aber vermutlich nur von der letzten Version aus möglich sein. Wer also öfter aktualisiert, profitiert von kleineren Updategrößen – bislang und auch künftig.
Bleibt festzustellen, dass trotz der gemeinsamen Codebasis weiterhin unterschiedliche Updatemechanismen zum Tragen kommen, die jeweilige Plattformeigenheiten berücksichtigen.
Es existieren verschiedene Möglichkeiten, externe Linux Netzwerklaufwerke unter Windows einzubinden. Zuhause im LAN hat sich Samba, das auf SMB/CIFS setzt, bewährt. Auch über LAN-Grenzen hinweg lässt sich Samba nutzen, allerdings möchte ich Samba ungerne auf einer dedizierten Maschine – die für andere Dienste genutzt wird – rein für diesen Zweck betreiben. Aus diesem Grund habe ich in der Vergangenheit nach passenden Tools gesucht, die eine Einbindung über das SSHFS erlauben. Neben einigen kostenpflichtigen Lösungen (Mountain Duck, ExpanDrive, NetDrive, u.a.) bin ich damals auch auf Dokan und win-sshfs gestoßen. Die Dokan Library stellt dabei den Unterbau bereit, der die Einbindung von virtuellen Dateisystemen unter Windows ermöglicht. Über win-sshfs lässt sich dann das SSHFS über eine GUI einbinden. Beide Tools sind Open Source und auf GitHub zuhause. Dokan wird sehr aktiv weiterentwickelt, dies trifft auf win-sshfs leider – trotz Forks – nicht mehr zu. Die aktuelle Version ist dabei leider nicht mehr mit Dokan kompatibel, auch ein Workaround aus dem Issue Tracker hat bei mir keine Abhilfe gebracht. Also ging die Tage die Suche erneut los. Neben einem Blick auf die kommerziellen Lösungen bin ich durch Zufall auch auf ein noch relativ neues Projekt gestoßen: Winfsp. Winfsp ist dabei quasi das Äquivalent zu Dokan, zur Einbindung des SSHFS existiert mit sshfs-win eine Zusatzlösung vom gleichen Autor. Auch diese beiden Tools sind Open Source. Die Einbindung eines SSHFS nach der Installation beider Tools geschiet direkt über die gewohnte „Netzwerklaufwerk verbinden“ Oberfläche im Windows Explorer. Lediglich der Pfad sieht etwas anders aus:
Momentan werden SSH Keys zur Authentifizierung noch nicht nativ unterstützt, über Umwege scheint dies aber möglich zu sein.
Genauere Erfahrungswerte zu Winfsp/sshfs-win kann ich abschließend ich noch nicht mitteilen, allerdings laufen erste Tests unter Windows 10 x64 1709 bislang vielversprechend.
Spontan, spontaner, Zeit für einen neuen Podcast! 🙂 Nach 10 Jahren ist es heute doch tatsächlich geschehen: es ist noch einmal ein Podcast entstanden. Die Themenliste hat sich ebenso zufällig ergeben. Feedback zum Podcast und den Themen sowie mögliche Themenvorschläge für einen eventuellen nächsten Podcast (wenn es ihn denn geben sollte) sind erwünscht 🙂
Inhalt:
– 00:09: Einleitung: erster Podcast nach 10 Jahren
– 01:35: Aktuelles zum theXME.de Theme
– 02:43: Gesehene Filme: La La Land & Emoji
– 04:58: Mein Spotify Musikjahr 2017
– 08:02: Alexa (die leider etwas leise ist, sorry!)
– 10:24: Let’s Encrypt
– 11:28: Ende des AOL Instant Messengers
– 13:35: Ausleitende Worte & ein Witz von Alexa
In der vergangenen Woche hat Mozilla mit Firefox 57 „Quantum“ die neuste Version seines Webbrowsers in die Welt entlassen. Häufige Versionswechsel sind wir mittlerweile gewohnt, doch mit dem neusten Ableger hat sich dann doch etwas mehr als sonst getan. Der neuste Fuchs präsentiert sich runderneuert und legt Altlasten wie das bisherige Addon-System vollständig ab. Das so ein großer Eingriff nicht ohne entsprechende Nutzerrückmeldungen über die Bühne gehen würde, war klar. Ich verstehe einerseits die Endnutzer, die teilweise auf langgenutzte Addons (vorläufig) verzichten müssen. Und ebenso Addon-Entwickler, die aufgrund von fehlenden WebExtension-API’s bisherige Erweiterungen nicht ohne weiteres portieren können – hoffentlich zeigt sich Mozilla in diesem Punkt auch in Zukunft offen und reagiert auf entsprechende Wünsche.
Auf der anderen Seite fühlt sich der neue Fuchs auch etwas moderner an. Natürlich lässt sich über das neue Design trefflich streiten. Unter dem Strich gefällt es mir aber sehr, insbesondere das dunkle Theme hat es mir angetan. Dabei nutze ich dunkle Themes ansonsten eigentlich recht selten. Weitreichende Themes, die Auswirkungen auf den Firefox-Aufbau hatten, habe ich ohnehin seit Jahren nicht mehr eingesetzt, deshalb fällt mir der Wechsel auch relativ einfach. Personas haben mir hierfür in der Vergangenheit ausgereicht.
Auf den ersten Blick fühlt sich der neue Firefox schneller an, allerdings ist das nur ein subjektiver Eindruck . Die Zeit wird sicherlich einen genaueren Eindruck vermitteln.
Um nochmals auf den Punkt Addons zurückzukommen: auch ich musste einen Blick auf meine bislang eingesetzten Addons werfen, nicht alle sind im aktuellen Zustand in eine WebExtension portiert worden. Nach etwas Recherche bin ich dann (vorübergehend) auf folgende Alternativen gewechselt:
Flagfox (wird noch angepasst) => Country Flags & IP Whois
SixOrNot (wird laut Autor vermutlich nicht mehr angepasst) => IPvFoo
Die restlichen Erweiterungen waren entweder bereits kompatibel oder ich habe diese direkt beim Aufräumen entsorgt. Auch wenn nicht alle Erweiterungen bereits den gleichen Umfang wie die alten Addons aufweisen, so lässt es sich mit der neuen Sammlung vorerst leben.
Der „harte“ Wechsel ist also ohne größere Probleme geschafft. Einen Grund für einen Umstieg auf Chrome sehe ich weiterhin nicht, ich mag meinen Fuchs! 🙂 Und etwas Konkurrenz tut dem Web auch sicherlich künftig gut. Denn Vielfalt bereichert bekanntlich das Leben. In diesem Sinne: gutes Browsing! 😀
JMAP – Java..? Auch wenn es mit jmap ein gleichnamiges Java-Werkzeug gibt, handelt es sich bei JMAP trotz Namensgleichheit (aber anderer Schreibweise) um eine neue Protokollspezifikation: der JSON Meta Application Protocol Specification (JMAP).
Bis vor wenigen Tagen hätten sich über meinem Kopf auch noch viele Fragezeichen hervorgetan, wäre mir da nicht ein Roundcube Issue Eintrag auf GitHub über den Weg gelaufen.
Das Konzept von JMAP hört sich interessant an: die Ablösung von IMAP und SMTP (auf Clientseite, Mailserver <-> Mailserver bleibt unberührt) mit dem Ziel, Schwachstellen von IMAP zu optimieren und die Erweiterbarkeit (z.B. durch die Möglichkeit der Synchronisation von Kontakten und Kalendern) sicherzustellen.
Die Entwicklung wurde von FastMail angestoßen und wird mittlerweile in der IETF offen fortgesetzt. Noch stehen einige Punkte auf der Milestone-Liste – bis das Protokoll also in der praktischen Anwendung anzutreffen ist, dürfte noch etwas Zeit vergehen. Dennoch ist die Entwicklung eines derartigen Alternativprotokolls zu einem gefühlt jahrhundertaltem etablierten Protokoll spannend.
Mit dem Monitoring-Tool Munin und dem ssl_ Plugin lassen sich Restlaufzeiten von SSL Zertifikaten auf einfache Weise überwachen. Insbesondere bei Zertifikaten mit kurzen Laufzeiten (u.a. Lets Encrypt) kann das ganz nützlich sein. Nach dem Download des Plugins muss nur eine Verknüpfung für die zu überwachende Domain angelegt werden, z.B.:
Wenn man nun in der munin.conf wie folgt noch die gewünschten Werte für Warnung und Critical hinterlegt, lässt sich damit im Handumdrehen eine simple E-Mail Benachrichtigung einrichten, die bei einem anstehenden Ablauf des Zertifikats aktiv wird (in diesem Beispiel, sobald 20 (Warning) bzw. 10 Tage (Critical) Restlaufzeit erreicht werden).
