Mal etwas aus der Dachbodenkiste. Wenn ein shell/bash script nicht das tut, was man von ihm erwartet gibt es zwei nette Techniken um das Problem zu lösen:
sh -x <scriptname>
das ist der xtrace mode, bei dem jedes Kommando auf stderr mit einem vorangestelltem + ausgegeben wird, bevor es ausgeführt wird. Damit kann man in einem sich bis zur Problemstelle vorwärtsdebuggen.
sh -n <scriptname>
das ist der noexec mode, welcher die Kommandos liest aber nicht ausführt. Damit lässt sich der Syntax vorab prüfen.
Das Synchronisieren von Digital Audio Workstation Einstellungen zweier Macs ist alles andere als einfach. Es ist ein Fortschritt, dass GarageBand und Logic Pro X einen gemeinsamen Datenstand benutzen, die Dokumentation wie das technisch passiert ist allerdings mangelhaft. weswegen hier ein bisschen Licht in das Dunkel gebracht werden soll.
Diesmal kurz und knackig. Linux auf einen neueren Mac? Ohne viel Abstriche läuft es auf eine Virtualisierungslösung hinaus. Und wer mit dem Linux noch produktiv sein will, wird zu Parallels greifen müssen…
sel4 hat eine extrem kleine TCB (trusted computing base), die zudem Fehlerfreiheit garantiert. Desweiteren soll eine WCET (Worst Case Execution Time) Analyse vorhanden sein, die darauf schließen lässt, dass seL4 harte Echtzeitfähigkeit besitzt, was ihn mit den anderen Fähigkeiten besonders für zertifizierungspflichtige Branchen prädestiniert.
Der, auf meinen statischen Seiten vorhandene Überblick über Linux Real-Time Systeme wurde mit einem seL4 Abschnitt erweitert.
Wer auf macOS 10.15 – alias Catalina – in der Audio-Midi-Setup Applikation des Betriebssytems unter dem Punkt MIDI-Studio einblenden eine neue MIDI Configuration anlegen will, wird sich wahrscheinlich mit folgendem Fenster auseinandersetzen müssen, dass leider ewig in diesem Zustand verharrt.
Fensteransicht, nach dem Anwählen einer neuen Konfiguration
Der Fehler scheint eine Abhängigkeit zu der gewählten Systemsprache zu haben.
Der Workaround ist nämlich, temporär in den SystemsettingsEnglish als Primärsprache anzuwählen, den Rechner neu zu starten, den Menüpunkt nun in einer englisch-sprachigen Umgebung zu starten und die Aktion durchzuführen, was anstandslos klappt. Danach kann man wieder zu Deutsch als Primärsprache wechseln.
Ein schneller Blick in das Alphabet der griechischen Buchstaben während einer technischen Lektüre, beförderte mich erneut in die Tiefen des PDF Unterbaus. Der Reihe nach…
UPDATED: Ursprünglich befasste sich dieser Artikel nur mit einem Fehler der auf VirtualBox auftrat. Da er aber mit der Virtualisierungssoftware Parallels in der gleichen Form auftritt, wurde er überarbeitet und mit einer genauerer Analyse versehen.
Um ganze Verzeichnisbäume zwischen verschiedenen Rechnern zu synchronisieren, ist das Kommandozeilentool rsync erste Wahl.
Schwieriger wird die Situation, wenn nicht nur klassische Computerplattformen, sondern auch mobile Plattformen – Handys & Tabletts – synchronisiert werden sollen. Dort ist eine Installation von rsync schwierig bis unmöglich. Zumal das Enkodierungsproblem der Dateinamen, siehe u.a. http://www.instruyete.org/?p=677 dort noch ausgeprägter auftritt.
Eine einfache Lösung ist die Benutzung kommerzieller Cloudanbieter. Dort begibt man sich aber in Abhängigkeit des Cloudanbieters, mit all den verbundenen Nachteilen, was Datenschutz und Plattformunterstützung betrifft.
Die bessere Alternative sind selber betriebene Dienste, wie die hier in diesem Artikel vorgestellte Lösung von Synology – Synology Drive
diskutiert. Dennoch ist das Problem immer noch existent und kann derzeit nur dadurch behoben werden, dass man bei 2 snap packages auf den candidate channel wechselt.
Nachdem ja erst kürzlich festgestellt wurde, dass snap packages NFS shares die autofs nutzen nicht erkennt und somit mit Dateien in diesen Verzeichnissen nicht arbeiten kann, muss man als zweiten großen Nachteil erwähnen, dass alle lokale Konfigurationen inkompatibel zur LSB innerhalb des Unterordners ~/snap gespeichert werden.
Falls man dann das snap package jemals durch ein nicht-snap package ersetzt wird das erneuerte Programm, bspw. unterhalb von:
~/.config ~/.local
nichts vorfinden und mit einer leeren Userkonfiguration starten.
Je mehr man sich mit snap packages beschäftigt, je offensichtlicher tritt zutage, dass snap packages zwar mit den Nachteilen der klassischen SW Repositories (ppa) aufräumten, aber dafür mindestens ebenso gewichtige neue Nachteile – die der Containerisierung und Abgrenzung – einführten. Der fehlende Zugriff auf NFS ist und bleibt ein NOGO!
Da ist es schon mehr als interessant, dass ich zufällig auf der Suche nach einer aktuellen SW Version des Raw Converters rawtherapee war, die mir als AppImage auf der Produkthomepage angeboten wurde.
Ein AppImage ist eine einzige Datei, die das Program, die Resourcen und alle Abhängigkeiten beinhaltet. Man kopiert sie in auf den lokalen Rechner (bevorzugt dort, wo die $PATH Umgebung schon Programme erwartet, bspw.
/usr/local/bin ~/bin
und führt sie aus. Das Konzept scheint den Apps auf macOS zu ähneln, auch wenn es dort technisch gesehen ein Dateiordner ist, der im Finder als singuläre Datei angezeigt wird.
Was sofort bleibt ist die Frage der Linux Desktop Integration. Diese wird beim Programmstart (Klick im Dateibrowser oder Konsolenaufruf) folgendermaßen beantwortet:
Dialog for integrating AppImage into Linux Desktop
Der Programmstart überprüft diese und stellt sie ggf. sicher – clever! Was noch bleibt ist die Frage der Deinstallation. Das AppImage löschen ist kein Problem, was passiert aber mit der existierenden Desktop Integration? Diese muss mit einem Kommandobefehl erfolgen, der im Beispiel des Programs rawtherapee folgendermaßen aussieht:
