Willkommen in Akaria

Vor allem vor einem _macOS_ -Update kann es vorkommen, dass auf den kleineren Speicherkonfigurationen eines _Macs_ der Speicher knapp wird. Neben dem manuellen Ausmisten helfen hierbei auch Tools wie mac-cleanup-py. Das Tool kann über Homebrew installiert werden: brew install mac-cleanup-py Nach der Installation kann das Werkzeug über: sudo mac-cleanup aus dem _Terminal_ heraus angestartet werden. Beim ersten Aufruf können die Module für die Bereinigung aktiviert werden. Später kann dies mittels: mac-cleanup -c wiederholt werden. Soll die Bereinigung ohne nachfragen durchgeführt werden kann der Parameter _-f_ mit angehangen werden: sudo mac-cleanup -f Das Tool selbst ist freie Software unter der _Apache License_ in Version 2.

Wenn von einer Sekunde auf die andere das Internet über die _FRITZ!Box_ nicht mehr funktioniert, lohnt es sich ein Blick in die DNS-Konfiguration. Dazu ist ein kleiner Aufruf von _dig_ im _Terminal_ nötig: dig example.org Die Ausgabe zeigte dann das der DNS-Service auf der _FRITZ!Box_ nicht mehr so arbeitete, wie er sollte. ;; WARNING: recursion requested but not available Um auszuschließen, das es sich nicht um ein generelles Problem handelt, kann _dig_ anschließend noch einmal mit einem manuell gesetzten DNS-Server aufgerufen werden: dig @1.1.1.1 example.org Liefert dieser Aufruf eine DNS-Auflösung, so ist die Ursache höchstwahrscheinlich in der _FRITZ!Box_ zu finden. Hier lohnt es sich nach einem Login die DNS-Einstellungen unter _Internet_ ⇾ _Zugangsdaten_ ⇾ _DNS-Server_ aufzurufen. Die DNS-Einstellungen der FRITZ!Box Dort hilft es in vielen Fällen den Punkt _Verschlüsselte Namensauflösung im Internet (DNS over TLS)_ zu deaktivieren. Meist kann die Einstellung anschließend, nachdem sie einmalig übernommen wurde, wieder aktiviert werden. In anderen Fällen muss sie komplett deaktiviert werden, damit die DNS-Auflösung wieder funktioniert.

Willkommen in Akaria

Willkommen in Akaria

Für _Ubuntu_ -Rechner habe ich es mir seit vielen Jahren angewöhnt ein Skript _upgrade.sh_ zu erzeugen, welches installierte Pakete auf den aktuellen Stand bringt: #!/bin/bash apt autoremove -y && apt autoclean -y && apt update && apt full-upgrade -y && apt autoremove -y && apt autoclean -y snap refresh Bei _apt_ wird _autoremove_ und _autoclean_ vor und nach dem Upgrade aufgerufen, um bei Systemen mit wenig Speicherplatz für möglichst viel freien Platz zu sorgen. Technisch unspektakulär, aber eine zuverlässige kleine Routine, die die Systempflege deutlich erleichtert.

Unter Umständen kann es passieren das sich unter _macOS_ in der Menüleiste ein Icon für die _Eingabequellen_ findet. Damit dieses wieder deaktiviert werden kann, müssen im ersten Schritt die _Einstellungen_ geöffnet werden. Dort sollte dann der Punkt _Tastatur_ aktiviert werden. Die Einstellungen für die Eingabequellen Im _Tastatur_ -Tab muss anschließend unter _Texteingabe_ ⇾ _Eingabequellen_ auf den _Bearbeiten_ -Button gedrückt werden. Dort findet sich dann die eigentliche Einstellung mit der Bezeichnung _Eingabequellen in der Menüleiste_ anzeigen. Sobald diese deaktiviert wurde, verschwindet das Icon aus der Menüleiste.

Bei der _ELV Fibonacci-Uhr_ handelt es sich um einen Bausatz für eine Fibonacci-Uhr. Diese kann über serielle Terminal-Befehle gesteuert werden. Auf der offiziellen Webseite werden allerdings nur Möglichkeiten angeboten das Ganze über Windows zu bewerkstelligen. Die ELV Fibonacci-Uhr Damit es unter _Linux_ funktioniert, müssen ein paar kleinere Hürden genommen werden. In dem Gerät steckt ein _CP210x_ -Chip für die serielle Kommunikation. Allerdings wird dieser auf Anhieb unter _Linux_ nicht erkannt. Ein Aufruf von: dmesg | tail -n 20 zeigt folgendes: [ 99.803450] usb 1-1: new full-speed USB device number 7 using xhci_hcd [ 99.928828] usb 1-1: New USB device found, idVendor=18ef, idProduct=e037, bcdDevice= 1.00 [ 99.928865] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 99.928883] usb 1-1: Product: Fibonacci-Clock FC1 [ 99.928898] usb 1-1: Manufacturer: ELV [ 99.928911] usb 1-1: SerialNumber: 162b12d76ceeec11bd1331f90f611c40 Allerdings taucht kein Gerät unter _/dev/tty*_ auf. _lsusb_ zeigt ebenfalls, dass ein USB-Gerät entdeckt wurde: Bus 001 Device 007: ID 18ef:e037 ELV Elektronik AG Fibonacci-Clock FC1 Damit das Gerät nun über das serielle Interface angesprochen werden kann, wird im ersten Schritt der Treiber in den Kernel geladen: modprobe cp210x Danach wird temporär ein neues Gerät erstellt: echo 18ef e037 | sudo tee /sys/bus/usb-serial/drivers/cp210x/new_id Nun kann sich über _Screen_ (alternativ kann auch _Picocom_ genutzt werden) mit dem Gerät verbunden werden: screen /dev/ttyUSB0 115200 Zum Test kann dort das Kommando _v_ abgesetzt werden. Kommandos wie das Zeitkommando (_T12:01:01_) sollten am besten am Stück eingefügt werden, da sie sonst automatisch als _t_ -Kommando erkannt werden, welches die Zeit nur anzeigt.

In den neueren Versionen von _Spotlight_ unter _macOS_ besteht die Möglichkeit Suchanfragen an _Apple_ zu übertragen, um der Firma bei der Verbesserung der Suchfunktion zu helfen. Auch wenn dort eine Anonymisierung vorgenommen werden soll, trägt dieses Verhalten doch einen schalen Beigeschmack. Die Spotlight-Einstellungen Um dies zu deaktivieren, müssen im ersten Schritt die _Einstellungen_ geöffnet werden. Dort sollten dann die _Einstellungen_ für _Spotlight_ selektiert und dort der Punkt _Apple beim Verbessern der Suche helfen_ deaktiviert werden. Anschließend werden keine Suchanfragen mehr an _Apple_ übertragen.

Für die Welten in _Minecraft_ existieren eine Reihe von Lösungen, um diese als Karte zu rendern. Bis vor einiger Zeit nutze ich Mapcrafter als Renderer. Allerdings wurde dieser nicht mehr weiter gepflegt, sodass es mit neueren _Minecraft_ -Versionen zu Darstellungsfehlern und ähnlichen Problemen kommt. Eine Alternative kann in einem solchen Fall BlueMap sein. BlueMap mit einer Map Während _Mapcrafter_ die Daten der _Minecraft_ -Welt nutzte, um die Karten mit Leaflet anzuzeigen, integriert sich _BlueMap_ in Server wie _Paper_ als Plugin. Die 3D-Ansicht in der BlueMap Nach der Installation und entsprechender Konfiguration kann _BlueMap_ anschließend im Browser genutzt werden. Das Rendering findet hierbei im _Minecraft_ -Serverprozess statt, sodass die Karte immer aktuell ist.

Für den _Raspberry Pi_ existieren eine Reihe von offiziellen Kameramodulen. Softwareseitig existieren mit den _rpicam-apps_ , eine Reihe von Werkzeugen um diese zu testen. Dazu müssen diese im ersten Schritt installiert werden: apt install rpicam-apps Anschließend kann auf den Desktop-Varianten von _Raspberry OS_ _rpicam-hello_ gestartet werden. Dieses öffnet eine Vorschau, so das die Kamera überprüft und ihr Bild in Augenschein genommen werden kann. Daneben existieren weitere Tools, welche ebenfalls aus diesem Paket stammen. So kann mittels: rpicam-jpeg --output test.jpg ein Bild mit der Kamera aufgenommen und als Bilddatei gespeichert werden. Auch die Aufzeichnung von Video ist möglich, z.B. über _rpicam-vid_.

Für eine Installation nutzte ich einen _Raspberry Pi 5_. Neben einigen Problemen mit der thermischen Belastbarkeit zeigte sich noch ein anderes interessantes Verhalten, welches mit der Stromversorgung zusammenhing. Versorgt würde der _Raspberry Pi_ über ein USB-Kabel, welches an einem Industrienetzteil angeschlossen war. Besagte Installation Am Rechner selbst waren einige USB-Geräte angeschlossen, welche sporadisch ausfielen und wieder neu starteten. Normalerweise würde der _Raspberry Pi_ die Spannung per _Power Delivery_ mit dem Netzteil aushandeln. Schlägt dies fehl, kann es zu beschreibendem Verhalten kommen, da der Strom für die USB-Geräte auf 600 mA limitiert wird. Um dieses Problem bei einem ausreichend dimensionierten Netzteil zu umgehen, kann der Parameter _usb_max_current_enable_ gesetzt werden. Dazu muss im ersten Schritt die entsprechende Konfiguration bearbeitet werden: nano /boot/firmware/config Dort wird nun der Parameter (im Bereich _all_) auf den Wert 1 gesetzt: usb_max_current_enable=1 Nach einem Neustart sollte das Verhalten verschwinden, solange die neue Limitierung (etwa 1,6 Ampere) nicht überschritten wird.

Bei Waschmaschinen von LG kann es durchaus passieren, das diese ein WLAN aufspannen. Genutzt wird dies z.B. für die hauseigene _LG ThinQ-App_. Allerdings kann dieses WLAN auch wieder deaktiviert werden, auch wenn diese Funktionalität etwas versteckt ist. Das WLAN ist abgeschaltet Dazu muss die Maschine angeschaltet werden. Anschließend kann durch einen längeren Druck auf _Zeitverzögerung_ und _Schleudern_ die Netzwerkverbindung deaktiviert und wieder aktiviert werden. Nach etwa drei Sekunden erscheint eine Statusmeldung, die den aktuellen Status anzeigt.

Unendliche Mannigfaltigkeit in unendlicher Kombination. Frei nach diesem Grundprinzip der vulkanischen Philosophie könnte der geneigte Nutzer auch die Vielfalt der Dateimanager betrachten. Neben den mit den Betriebssystemen mitgelieferten Dateimanagern, wie dem Explorer unter _Windows_ oder dem Finder unter _macOS_ , existieren viele weitere Dateimanager, mit teils recht unterschiedlichen Herangehensweisen. Eine Klasse von Dateimanagern stellen die orthodoxen Dateimanager, auch Zwei-Panel-Datei-Manager genannt, dar. Diese nutzen ein Konzept, welches insbesondere dann seine Vorteile ausspielt, wenn viel und oft mit Dateien gearbeitet wird und eine flexible Arbeitsweise gewünscht ist. Mit ihrer charakteristischen Zwei-Panel-Architektur und tastaturzentrierten Bedienung bieten sie eine Effizienz, die moderne grafische Dateimanager selten erreichen. **Definition** Orthodoxe Dateimanager verdanken ihre Bezeichnung nicht einer religiösen Konnotation, sondern ihrer Treue zu den etablierten Designprinzipien des _Norton Commander_ , welcher erstmals 1986 erschien. Der Begriff _Orthodox File Manager_ (OFM) wurde durch Nikolai Bezroukov 1996 geprägt und bezeichnet die standardisierte Implementierung der Zwei-Panel-Philosophie: > I introduced the term „orthodox file managers“ in 1996 (see OFM Bulletin 1998) … Das zentrale Element eines orthodoxen Dateimanagers sind zwei symmetrische Verzeichnisfenster (Panels), die es ermöglichen, Dateien direkt zwischen Quell- und Zielverzeichnis zu verwalten. Eines der beiden Panels ist aktiv (Quelle), das andere passiv (Ziel). Sämtliche Befehle beziehen sich auf dieses Verhältnis. OFMs bieten einen einheitlichen Funktionsumfang: Kopieren, Verschieben, Löschen und Umbenennen über klar strukturierte Menüs und vordefinierte Shortcuts. Die vollständige Tastaturbedienung steht im Vordergrund und erlaubt es, sämtliche Operationen ohne Maus durchzuführen. Die Belegung entspricht auch heute noch größtenteils denen des _Norton Commanders_ : F1: Hilfe F2: Benutzermenü F3: Datei betrachten F4: Datei bearbeiten F5: Kopieren F6: Verschieben/Umbenennen F7: Verzeichnis erstellen F8: Löschen F9: Menüleiste aktivieren F10: Beenden Tab: Zwischen Panels wechseln Einfügen: Dateien markieren Auch Archivformate wie ZIP oder TAR werden meist direkt unterstützt, oft so, als wären sie normale Verzeichnisse. Hierbei ist die Rede von virtuellen Dateisystemen. Diese abstrahieren verschiedene Speicherquellen, Archive, FTP-Server oder Cloud-Speicher und binden sie transparent als Verzeichnisse ein. Ergänzt wird dieser Ansatz durch integrierte Dateibetrachter und Editoren, sodass viele Aufgaben innerhalb des Dateimanagers, ohne einen Rückgriff auf andere Anwendungen, erledigt werden können. Orthodoxe Dateimanager sind eng mit der nativen Shell des Systems verbunden. Pfade und Befehle lassen sich direkt, innerhalb des Dateimanagers, an die Kommandozeile übergeben. Trotz der Standardisierung der Kommandos und des generellen Aussehens ist die Anpassbarkeit ein weiteres Merkmal orthodoxer Dateimanager. Tastenkombinationen, Menüstrukturen und das Erscheinungsbild lassen sich in vielen Fällen an persönliche Bedürfnisse anpassen. **Spezifikationen** _Nikolai Bezroukov_ prägte nicht nur den Begriff des orthodoxen Dateimanagers, sondern überführte diese Philosophie in einige Spezifikationen. Die OFM-Spezifikation von 1999 hatte das Ziel, diese Philosophie zu standardisieren. Sie legt Grundfunktionen und Interaktionsmuster fest, um eine langfristig tragfähige Basis für Entwickler und Anwender zu schaffen. Nach dem ursprünglichen OFM-Standard von 1999 wurde im Jahr 2004 eine Erweiterung veröffentlicht. Ziel war es, neben dem fest etablierten Grundkonzept auch fortgeschrittene Funktionen wie Filter, benutzerdefinierte Sortierung und Archivverwaltung zu normieren. Die letzte Erweiterung stammt aus dem Jahr 2012. Zu den wesentlichen Erweiterungen zählen flexible Panel-Größen, erweiterte Skriptintegration mit Variablenzugriff sowie die Vorbereitung auf Funktionen wie Tabs und Plugin-gesteuerte Dateiansichten. Um übermäßige Komplexität zu vermeiden, wurden nur Features aufgenommen, die sich in mindestens einem Jahr realer Nutzung bewährt hatten. Seitdem wurde die Spezifikation nicht weiter überarbeitet. Dennoch lieferte sie wichtige Impulse und eine Orientierung für die Praxis. **Geschichte** Einer der ersten Dateimanager mit textbasierter, aber visuell strukturierter Oberfläche war PathMinder von _Albert Nurick_ und _Brittain Fraley_. Dieser erschien im Jahr 1984. Einen Monat nach der Veröffentlichung erschien mit _DualView_ ebenfalls ein textbasierter Dateimanager. Mit XTree erschien 1985 ein weiterer Vertreter, welcher ähnlich wie _PathMinder_ eine Art Baumstruktur darstellte. Der De-facto-Standard der orthodoxen Dateimanager wurde 1986 mit dem _Norton Commander_ definiert, der durch geschicktes Marketing und technische Verfeinerung stilbildend wirkte. Gestartet wurde die Arbeit am _Norton Commander_ von _John Socha_ im Jahr 1986. Zu dieser Zeit trug das Projekt den Namen Visual DOS bzw. VDOS: > I started work on what became known as the Norton Commander in the fall of 1984 while I was still a graduate student in Applied Physics at Cornell University. The first versions were entirely in assembly language, but that was too time-consuming, so I soon switched to a blend of C and assembly language at a time when most „real programmers“ wouldn’t touch C. > > > At the time I called it Visual DOS, with the abbreviation of VDOS instead of the usual two-letter abbreviations used at the time. _Norton Commander_ 1.0 erschien im Mai 1986 und definierte die Grundprinzipien, die bis heute Gültigkeit haben. Auch bot er erstmals einen integrierten Viewer und Editor, wodurch komplette Workflows ohne Anwendungswechsel möglich wurden. Die Version 3.0 von 1989 gilt als Höhepunkt der DOS-Ära mit Hypertext-Hilfe und dem legendären Sternenhimmel-Bildschirmschoner. Inspiriert vom _Norton Commander_ erschienen ab Ende der 1980er-Jahre weitere orthodoxe Dateimanager wie der Volkov Commander oder der DOS Navigator. In der Unix- bzw. Linux-Welt entstand 1994 mit dem Midnight Commander, von _Miguel de Icaza_ , einer der bekanntesten orthodoxen Dateimanager. Auch für Systeme wie OS/2 wurden orthodoxe Dateimanager entwickelt, wenngleich diese heute nur noch eine geringe Nutzerschaft aufweisen. **Vom Terminal zur GUI** Neben den textbasierten orthodoxen Dateimanagern entstanden mit dem Aufkommen von _Windows_ auch grafische Umsetzungen dieses Konzepts. Hier sind Entwicklungen wie der _Windows Commander_ (1993), welcher später zum _Total Commander_ wurde, sowie die Umsetzung des _Norton Commander für Windows_ (1998) zu nennen. Unter Linux entstanden grafische OFMs, wie der _GNOME-Commander_ und _Krusader_. **OFMs im Einzelporträt** Heutzutage werden eine Vielfalt von orthodoxen Dateimanagern für unterschiedliche Systeme aktiv entwickelt und vorangetrieben. Neben den hier vorgestellten orthodoxen Dateimanagern existieren unzählige weitere – von kleineren Prototypen bis zu ausgewachsenen kommerziellen Varianten. Grundsätzlich müssen zwei Formen unterschieden werden. Die klassischen auf einer Terminal UI (TUI) basierten Dateimanager und die auf einer grafischen UI (GUI) basierten Dateimanager. **TUI-basierte Implementationen** Zu den TUI-basierten Implementationen würde aus heutiger Sicht auch der Norton Commander gehören. Selbst im Zeitalter grafischer Systeme und Bildschirmauflösungen jenseits der 4K haben solche Dateimanager nach wie vor ihre Berechtigung. Sei es auf der Nutzung im Terminal oder auf entfernten Rechnern per SSH. **Far Manager** Der Far Manager wurde 1996 von _Eugene Roshal_ , seines Zeichens Schöpfer des RAR-Formats, entwickelt. Seit 2007 ist er freie Software unter der modifizierten BSD-Lizenz und wird aktiv entwickelt. Er ist ein textbasierter orthodoxer Dateimanager für _Windows_ , der die Tradition des _Norton Commanders_ in die moderne _Windows_ -Ära überträgt. Der Far Manager erinnert an den Norton Commander Die Zwei-Panel-Struktur wird durch eine Kommandozeile am unteren Rand ergänzt, die eine direkte Ausführung der Befehle ermöglicht. Dabei wird eine Art Autovervollständigung geboten. Die Oberfläche unterstützt verschiedene Farbschemata und kann detailliert angepasst werden. Moderne Features wie Drag & Drop innerhalb des Dateimanagers werden, trotz der Konsolennatur, unterstützt. Daneben verfügt der _Far Manager_ über einen integrierten Text-Editor sowie einen Viewer. Auch die Unterstützung für Archiv-Formate und deren Einbindung ist gegeben. Mit seinem umfangreichen Plugin-System und der Fokussierung auf Effizienz richtet er sich an erfahrene Anwender. Verfügbar ist der Dateimanager für Windows, jeweils in einer x64 und einer ARM64-Version. Es existiert auch eine Linux-Portierung des Managers. **Midnight Commander** Der Midnight Commander gilt auf dem Terminal unter Unix- und Linux-Systemen als Standard-OFM. Erstmalig veröffentlicht wurde er im Jahre 1994 durch Miguel de Icaza, welcher später das GNOME-Projekt mitbegründete. Der Midnight Commander unter macOS Als GNU-Software unter der GPL in Version 3 veröffentlicht, läuft er in Textterminals und bietet seine volle Funktionalität sowohl lokal als auch über SSH-Verbindungen. Seine Entwicklung kam mehrere Jahre zum Erliegen, aber seit 2009 wurde er mit der Version 4.6.2 wieder aktiv weiterentwickelt. Die VFS-Implementierung unterstützt SSH, SFTP, FTP und zahlreiche Archivformate. Für die direkte Arbeit mit Dateien steht ein eingebauter Texteditor zur Verfügung. Er bietet unter anderem Syntax-Highlighting für viele Programmiersprachen. Ergänzt wird der Editor durch einen Viewer, der Text- und Binärdateien unterstützt. Die integrierte Suchfunktion hilft beim Auffinden von Dateien im Verzeichnisbaum. Die Farbgebung ist anpassbar, und verschiedene Skins stehen zur Verfügung. Trotz der text-basierten Natur bietet der _Midnight Commander_ eine Maus-Unterstützung in modernen Terminal-Emulatoren. Unter _Linux_ -Systemen kann der _Midnight Commander_ über den Paketmanager installiert werden. Für _macOS_ gilt das Gleiche, etwa über Homebrew. Daneben existiert mit mcwin32 eine Windows-Portierung des Dateimanagers. **GUI-basierte Implementationen** Neben den terminal-basierten Implementationen existiert eine große Auswahl an GUI-basierten Implementationen des OFM-Paradigmas. **Linux** In der Linux-Welt existierten einige historische OFMs, wie der Tux Commander, emelFM2 oder Sunflower, welche mittlerweile mehr oder weniger inaktiv sind. Gleichzeitig existieren dort aktiv weiterentwickelte orthodoxe Dateimanager. **GNOME Commander** Der GNOME Commander wurde ursprünglich 2001 vorgestellt und richtet sich an Nutzer der GNOME-Desktop-Umgebung. Die Anwendung ist in C++ geschrieben und nutzt GTK für die grafische Oberfläche. Interessant ist dass mittlerweile eine Reimplementation in Rust vorgenommen wird. GNOME Commander unter Ubuntu GNOME Commander integriert sich gut in GTK-basierte Desktop-Umgebungen. Standardmäßig glänzt er in einem _Norton Commander_ -Blau. Der Dateimanager ist eng in die GNOME-Desktopumgebung integriert und nutzt das zugrunde liegende GIO-Framework als Abstraktionsschicht für Dateien und andere Ressourcen. Der Archivzugriff ist im _GNOME Commander_ nicht so komfortabel gelöst wie in anderen orthodoxen Dateimanagern, da sie hier auf externe Tools verlassen wird und keine Integration in ein virtuelles Dateisystem erfolgt. Daneben bietet der Dateimanager Unterstützung für erweiterte Dateiattribute, darunter Eigentümer, Benutzergruppen, Zugriffsrechte und Zeitstempel. Ein Lesezeichen- und Favoritensystem erlaubt es, häufig genutzte Pfade als Schnellzugriffe zu speichern und wieder aufzurufen. Weiterhin unterstützt der Dateimanager entfernte Verbindungen, was den Zugriff auf SSH-, SFTP-, FTP-, SMB-, sowie WebDAV-Server ermöglicht. Das Projekt ist unter der GPL in Version 2 lizenziert und wird aktiv auf GitLab gepflegt. Installiert werden kann der GNOME Commander über den jeweiligen Paketmanager der Linux-Distribution. **Krusader** _Krusader_ wurde im Jahr 2000 vorgestellt und bietet eine moderne, grafische Interpretation der orthodoxen Dateimanager-Philosophie. Die Oberfläche integriert sich nahtlos in KDE und nutzt dessen Design-Sprache. Tabs, Toolbars und Kontextmenüs sind vollständig anpassbar. Krusader unter Ubuntu Die C++-Implementierung nutzt KDE-Frameworks, was den Zugriff auf verschiedenste Dateisysteme und Ressourcen ermöglicht. Dadurch lassen sich Netzwerkpfade und Archive wie reguläre Ordner behandeln. Die Archiv-Unterstützung ist dank der KDE-Bibliotheken sehr breit aufgestellt: _Krusader_ kann mit nahezu allen gängigen Archivformaten umgehen, darunter ZIP, RAR, 7Z und TAR. Die Archive lassen sich direkt durchsuchen und bei Bedarf entpacken oder erstellen. Die Suchfunktion erlaubt nicht nur das schnelle Auffinden von Dateien, sondern auch die inhaltsbasierte Suche. Zur Vorschau von Dateien nutzt _Krusader_ den einen kombinierten Viewer und Editor. Für Dateivergleiche steht eine eingebaute Synchronisationsfunktion mit grafischer Oberfläche zur Verfügung, die Unterschiede zwischen Verzeichnissen übersichtlich darstellt und verschiedene Synchronisationsmodi anbietet. Andere Funktionen wie die Mehrfachumbennenung werden über externe Werkzeuge wie _KRename_ realisiert. _Krusader_ ist unter der GPL lizenziert und kann über den Paketmanager installiert oder alternativ bezogen werden. **macOS** Auch für das macOS stehen eine Reihe von orthodoxen Dateimanagern zur Verfügung, darunter auch solche, die besonderen Wert auf eine gelungene Integration in das System legen. **Commander One** Commander One wurde 2015 von _Eltima Software_ (jetzt _Electronic Team_) veröffentlicht und ist ein orthodoxer Dateimanager für macOS. Er kombiniert die klassische Zwei-Panel-Struktur mit einer modernen Cocoa-Oberfläche. Die Zwei-Panel-Ansicht ist zentrales Element, ergänzt durch Toolbar, Pfadleiste und Dateidetails. Der Dateimanager unterstützt macOS-Finder-Tags, Quick Look und bietet native Hotkey-Unterstützung. Die Anwendung wurde in _Swift_ entwickelt und ist sowohl in einer kostenlosen Grundversion als auch in einer kostenpflichtigen Pro-Variante mit erweiterten Funktionen erhältlich. Commander One Klassische OFM-Funktionstasten werden weitgehend unterstützt, ebenso wie Drag & Drop und Kontextmenüs im Stil des _macOS_ -Finders. Auch die einfache Möglichkeit versteckte Dateien anzuzeigen ist positiv hervorzuheben. In der Pro-Version wartet Commander One mit erweiterten Archivfunktionen auf. Archive in Formaten wie ZIP, RAR, 7z oder TAR lassen sich nicht nur extrahieren, sondern auch direkt erstellen. Hinzu kommt eine leistungsfähige Cloud-Integration, die unter anderem Google Drive, Dropbox, OneDrive, Amazon S3 und WebDAV unterstützt. Auch Apples _iCloud_ ist sinnvoll eingebunden. Für den Zugriff auf entfernte Server bietet Commander One integrierte Clients für FTP, SFTP und SCP. Ein eingebautes Terminal-Fenster ermöglicht den direkten Zugriff auf die Shell, ohne die Anwendung zu verlassen. Allerdings muss hier berücksichtigt werden, dass es Unterschiede zwischen der Version aus dem App Store und der von der Webseite des Herstellers gibt. Aufgrund der Sandbox-Beschränkungen sind einige Funktionen nur in der Version des Herstellers verfügbar. Dazu zählen z. B. das Beenden von Prozessen, das Mounten von iOS-Geräten und das Ignorieren der System-Einstellungen für die Funktionstasten. Neben dem Bezug über den _App Store_ kann _Commander One_ auch direkt über die Webseite des Herstellers bezogen werden. **Marta** _Marta_ ist ein moderner und minimalistisch gestalteter Zwei-Panel-Dateimanager für _macOS_ , der 2017 als Indie-Projekt von _Yan Zhulanow_ vorgestellt wurde. Geschrieben in _Swift_ und vollständig nativ, vereint Marta orthodoxe Bedienphilosophie mit der Ästhetik und Performance moderner Apple-Systeme. Marta Das Zwei-Panel-Layout steht im Fokus, unterstützt durch eine konfigurierbare Statusleiste und eine leistungsfähige Kommandozeile. Klassische OFM-Funktionstasten werden weitgehend unterstützt. Ein modular aufgebautes Plugin-System, das derzeit auf Lua-Basis entwickelt wird, erlaubt die individuelle Erweiterung der Funktionalität. Daneben existiert seit der ersten Version eine Swift-API. Bereits integriert ist eine Unterstützung für Archivformate wie ZIP, TAR, RAR und 7z, die sich direkt als virtuelle Verzeichnisse öffnen lassen. Für den komfortablen Zugriff auf häufig verwendete Pfade stehen Favoriten sowie eine durchsuchbare Verlaufsfunktion zur Verfügung. Ein integriertes Terminal ist vorhanden und kann optional angezeigt bzw. versteckt werden. Die Konfiguration erfolgt über Marco-Dateien, ein für Marta entwickeltes Format, dass die Konfiguration allerdings unnötig umständlich erscheinen lässt. Die Software ist kostenlos, wird aktiv weiterentwickelt und kann über die offizielle Webseite oder Homebrew bezogen werden. **Nimble Commander** _Nimble Commander_ ist ein weiterer ressourcenschonender und klassisch orientierter Zwei-Panel-Dateimanager für macOS. Die Anwendung wurde in Objective-C++ entwickelt und ist nativ für macOS geschrieben. Nimble Commander Im Zentrum steht ein übersichtliches Zwei-Fenster-Layout, das _Terminal_ -Fenster ist nicht in dieses integriert, sondern kann über das „View“-Menü als Overlay aktiviert werden. Daneben stehen Funktionen zur Dateiverwaltung wie Suchen, Umbenennen oder die Arbeit mit Archiven zur Verfügung. _Nimble Commander_ unterstützt viele Archivformate, darunter ZIP, TAR, GZ, BZ2 und weitere Formate. Auch ermöglicht der _Nimble Commander_ es, in den Admin-Modus zu wechseln und mit entsprechenden Rechten zu arbeiten. Die Konfiguration bietet zahlreiche Anpassungsmöglichkeiten, von Tastenkürzeln über Dateitypen bis hin zum Erscheinungsbild. _Nimble Commander_ ist unter der GPL in Version 3 lizenziert, damit freie Software, und kann über die offizielle Webseite, den App Store oder Homebrew bezogen werden. **Windows** Nachdem DOS über Jahre hinweg als bevorzugte Plattform orthodoxer Dateimanager gedient hatte, erfolgte mit dem Aufstieg grafischer Betriebssysteme eine allmähliche Migration dieser Gattung in die Windows-Welt – meist als Neuentwicklungen mit vertrautem Bedienkonzept. **Altap Salamander** Der _Altap Salamander_ wurde ursprünglich 1997 unter dem Namen _Servant Salamander_ von _Petr Šolín_ und _Pavel Schreib_ veröffentlicht und zählt zu den ältesten grafischen orthodoxen Dateimanagern für Windows. Entwickelt in Tschechien, bot das Programm von Beginn an eine schlanke, schnelle Alternative zum Windows Explorer. Der Altap Salamander unter Windows _Altap Salamander_ kombiniert klassische Zwei-Panel-Ansicht mit einer aufgeräumten und funktionalen Benutzeroberfläche. Die integrierte Archivunterstützung erlaubt den direkten Zugriff auf Formate wie ZIP, RAR, ISO oder CAB. Mit eingebauten Clients für FTP, FTPS, SFTP und SCP können Dateioperationen auch im Netzwerk durchgeführt werden. Werkzeuge zur Dateiverwaltung runden das Paket ab. Dazu gehören Funktionen zum Verzeichnisvergleich, zur Datei-Synchronisation sowie zur Berechnung und Prüfung von Prüfsummen und die Suche. Ein interner Viewer unterstützt die Anzeige im Text- und Binärmodus, während der genutzte Editor sich frei konfigurieren lässt. Durch das Plugin-System lässt sich der Funktionsumfang erweitern. Während der Dateimanager lange Zeit als Shareware vertrieben wurde, wurde er nach dem Kauf von Altap durch Fine zu freier Software. Die freigegebene Variante, genannt _Open Salamander_ , findet sich auf GitHub und ist unter GPL in Version 2 lizenziert. Derzeit ist keine aktive Weiterentwicklung erkennbar, was darauf hindeutet, dass das Projekt momentan pausiert. Technisch gesehen ist die Anwendung ein Kind seiner Zeit: eine reine WinAPI-Anwendung, ohne moderne C++-Paradigmen wie RAII, _Smart Pointers_ oder STL; dafür mit reichlich tschechischen Kommentaren im Code. Bezogen werden kann der _Altap Salamander_ über die offizielle Seite des Herstellers. **FreeCommander XE** _FreeCommander XE_ ist ein orthodoxer Dateimanager für Windows, der seit den frühen 2000er-Jahren entwickelt wird. Die Anwendung wurde von Marek Jasinski initiiert und richtet sich an Nutzer, die ein flexibles, Zwei-Panel-basiertes Werkzeug für Dateiverwaltung unter Windows suchen. FreeCommander XE _FreeCommander XE_ wurde in _Delphi_ entwickelt und läuft nativ unter _Windows_. Das Programm wird aktiv weiterentwickelt und ist sowohl als kostenlose Version als auch in einer Donator-Version verfügbar. Diese Donator-Version scheint aktuell die 64-Bit Version zu umfassen. Die Oberfläche orientiert sich an klassischen Prinzipien orthodoxer Dateimanager, wurde aber mit modernen Windows-Elementen angereichert. Zwei horizontal oder vertikal teilbare Panels bilden das zentrale Layout. Tabs, anpassbare Toolbars und farbige Dateiansichten sorgen für Übersichtlichkeit. Eine eingebaute Kommandozeile, Kontextmenüs und Drag & Drop sind ebenso vorhanden wie Einstellungen zur Nutzeranpassung. Für die Organisation und den Abgleich von Dateien steht ein integriertes Tool für Dateivergleich und Verzeichnis-Synchronisation zur Verfügung. Die Archivunterstützung umfasst gängige Formate wie ZIP, RAR, CAB und 7z. Der Zugriff erfolgt je nach Format direkt oder über externe Anwendungen. Die Netzwerkfunktionen ermöglichen den Zugriff auf Netzwerkpfade, UNC-Freigaben sowie FTP- und SFTP-Server. Ein interner Viewer erlaubt die Anzeige und Bearbeitung von Texten, Bildern und Daten. Als Editor wird eine externe Anwendung konfiguriert. Ein Batch-Umbenennungstool mit Unterstützung für reguläre Ausdrücke ermöglicht das gleichzeitige Umbenennen vieler Dateien. Die Anwendung ist Freeware und kann über die offizielle Webseite bezogen werden. **Total Commander** 1993, ursprünglich als Windows Commander gestartet, musste _Christian Ghisler_ das Programm nach einer Aufforderung von Microsoft aus markenrechtlichen Gründen umbenennen. Total Commander gilt als einer der bekanntesten orthodoxen Dateimanagern für Windows. Total Commander Die Oberfläche von Total Commander ist funktional und anpassbar. Die klassische Zwei-Panel-Ansicht lässt sich durch verschiedene Ansichtsmodi ergänzen, von einfachen Dateilisten bis zu detaillierten Spaltenansichten. Die Symbolleisten sind vollständig konfigurierbar, und Nutzer können praktisch jeden Aspekt der Oberfläche ihren Bedürfnissen anpassen. Die integrierte Archiv-Unterstützung erlaubt den direkten Zugriff auf Formate wie ZIP, RAR, 7Z, TAR, GZ und viele weitere. Ein FTP/SFTP-Client ist ebenfalls integriert und unterstützt neben klassischem FTP auch FTPS, SFTP und WebDAV. Verbindungen können gespeichert, organisiert und über Bookmarks schnell aufgerufen werden. Die Such- und Filterfunktionen bieten Unterstützung für reguläre Ausdrücke, Volltextsuche im Dateiinhalt und einen integrierten Duplikat-Finder. Zusätzlich erlauben Schnellfilter das sofortige Eingrenzen angezeigter Dateien in Echtzeit. Ein integriertes Synchronisationswerkzeug unterstützt verschiedene Abgleichmodi, darunter bidirektionale und asymmetrische Synchronisation, während das Multi-Rename-Tool Funktionen zum gleichzeitigen Umbenennen von mehreren Dateien bietet. Mit dem integrieren Viewer können Textdatei bis zu 8192 Petabyte betrachtet werden. Auch Bilder und Multimedia-Inhalte können direkt angezeigt werden. _Total Commander_ verfügt über ein umfangreiches Plugin-System, das verschiedene Plugin-Typen unterscheidet. Packer-Plugins (WCX) erweitern die Unterstützung für Archivformate. Dateisystem-Plugins (WFX) ermöglichen den Zugriff auf alternative Datenquellen außerhalb des regulären Dateisystems, etwa auf FTP-Server, WebDAV, Cloudspeicher, die _Windows_ -Registry oder laufende Prozesse. Diese Ressourcen erscheinen innerhalb des Dateimanagers wie normale Verzeichnisse. Lister-Plugins (WLX) ermöglichen die Anzeige spezieller Dateiformate im internen Betrachter, z. B. für Multimedia-, Office- oder CAD-Dateien. Inhalts-Plugins (WDX) stellen zusätzliche Dateieigenschaften bereit, die z. B. in benutzerdefinierten Spalten angezeigt oder für Such- und Filterfunktionen verwendet werden können. Bezogen werden kann _Total Commander_ über die offizielle Webseite. Dort kann ebenfalls eine Lizenz erworben werden. **Plattformübergreifend OFMs** Neben den bisher vorgestellten orthodoxen Dateimanagern, die meist auf ein einzelnes Betriebssystem beschränkt sind, existieren auch plattformübergreifende Lösungen. **Double Commander** Double Commander, dessen erste Version 2006 erschien, versteht sich als plattformübergreifende Lösung eines orthodoxen Dateimanagers. Die in _Object Pascal_ geschriebene Anwendung bietet native Binaries für Linux, macOS und Windows. Double Commander unter macOS Die Bedienelemente sind größer und klarer als bei vielen Konkurrenten, was der Benutzerfreundlichkeit zugutekommt, allerdings auch als klobig empfunden werden kann. Tabs ermöglichen das Arbeiten mit mehreren Verzeichnissen pro Panel. Die Oberfläche ist anpassbar, vom Farbschemata über Symbolleisten hin zu Tastenkombinationen. Die Archiv-Unterstützung umfasst eine breite Palette von Formaten wie ZIP, 7Z oder TAR. Die erweiterte Suchfunktion erlaubt nicht nur Dateinamen- und Pfadsuche, sondern auch die Nutzung von regulären Ausdrücken sowie die Suche im Dateiinhalt. Eine integrierte Synchronisationsfunktion mit grafischer Darstellung erleichtert das Vergleichen und Angleichen von Verzeichnissen. Abgerundet wird der Funktionsumfang durch einen integrierten Viewer, der Texte, Bilder und Dateien anzeigen kann. Der Dateimanager nutzt die Total Commander Plugin-API, sodass _Total Commander_ -Plugins unter Windows auch im _Double Commander_ genutzt werden können. Der Double Commander ist unter der GPL in Version 2 lizenziert und kann über die offizielle Seite bezogen werden. **muCommander** muCommander ist ein plattformunabhängiger, Java-basierter orthodoxer Dateimanager, der 2002 veröffentlicht wurde. Er setzt auf ein klassisches Zwei-Panel-Layout und ist besonders für Nutzer interessant, die einen leichtgewichtigen Dateimanager auf unterschiedlichen Betriebssystemen wie Windows, Linux, macOS oder BSD nutzen möchten. muCommander unter macOS Zwei Panels stehen im Fokus, ergänzt durch eine Shell, Pfadleisten, Toolbar, Statusanzeigen und ein Menüband. Das Design lässt sich über verschiedene Styles konfigurieren, ist aber nicht auf native Optik ausgelegt. Der Funktionsumfang umfasst integrierte Unterstützung für zahlreiche Netzwerkprotokolle wie FTP, SFTP, SMB, HTTP, Amazon S3 und Bonjour. Auch Archivformate wie ZIP, TAR, GZip und BZip2 werden unterstützt und lassen sich direkt wie normale Verzeichnisse durchsuchen. Praktische Funktionen wie Favoriten und eine Verlaufsansicht erleichtern den Zugriff auf häufig verwendete oder zuletzt besuchte Pfade. Der integrierte Dateibetrachter erlaubt die Vorschau von Text-, Binär- und Bilddateien. Das Programm ist unter der GPL lizenziert und wird aktiv als Open-Source-Projekt gepflegt. Es kann über die offizielle Webseite, oder je nach System über den Paketmanager bezogen werden. **Mobile Adaptierung** Neben orthodoxen Dateimanagern für Desktop-Systeme existieren auch Lösungen für mobile Systeme, allem voran Android. Allerdings sind solche Dateimanager unter _Android_ und _iOS_ eher selten, da diese Plattformen restriktiver im Umgang mit dem Dateisystemzugriff und Benutzeroberflächenparadigmen sind. So existiert eine Umsetzung des _Total Commander_ für Android, welche als Freeware vertrieben wird. Der Total Commander unter Android Ein weiterer mobiler Vertreter findet sich mit dem Ghost Commander, welcher ebenfalls das OFM-Paradigma implementiert, dies allerdings noch konsequenter umsetzt. Ghost Commander _iOS_ -Beschränkungen verhindern echte orthodoxe Implementierungen. App-Sandboxing und File-System-Zugriffsbeschränkungen machen die charakteristischen Features nur schwer umsetzbar. Daneben stellt sich im mobilen Bereich die Frage nach der Sinnhaftigkeit solcher Implementierungen, da die Vorteile wie eine schnelle Bedienung über die Tastatur, wenn überhaupt, nur in bestimmten Setups zum Tragen kommen. **Fazit** Orthodoxe Dateimanager repräsentieren ein Konzept, das sich über fast vier Jahrzehnte bewährt hat. Ihre Effizienz, Konsistenz und Erweiterbarkeit machen sie zu unverzichtbaren Werkzeugen für Power-User, Entwickler und Systemadministratoren. Die Philosophie der tastaturorientierten, effizienten Dateiverwaltung bleibt relevant für all jene, die täglich mit großen Mengen von Dateien arbeiten müssen. Besonders interessant ist, dass trotz des Alters dieses Konzepts die Entwicklung sehr aktiv ist. Heutige Implementierungen werden kontinuierlich weiterentwickelt und an aktuelle Bedürfnisse angepasst. Diese Einheitlichkeit im Bedienkonzept, bedingt durch die informelle Standardisierung, sorgt dafür, dass Nutzer beim Wechsel zwischen verschiedenen orthodoxen Dateimanagern kaum Einarbeitungszeit benötigen. Welcher orthodoxe Dateimanager für wen geeignet ist, ist eine Frage der persönlichen Präferenz. Hier kann nach Betriebssystem vorselektiert werden und auch die Frage, ob es freie Software oder auch ein kommerzielles Produkt sein darf, entscheidet. Gemeinsam haben alle hier vorgestellten Dateimanager eine gewisse Basisfunktionalität. Die Differenzierung der einzelnen Dateimanager fängt meist erst bei den komplexen Features an. Während z. B. der _Total Commander_ mit vielen Funktionalitäten glänzt und über ein reichhaltiges Pluginangebot verfügt, kann er für einige Nutzer altgebacken oder überladen wirken. Nicht alle orthodoxen Dateimanager sind in die eigene Landessprache übersetzt, sodass auch dies ein Entscheidungskriterium sein kann. Unter Linux bieten sich je nach gewählter Desktop-Umgebung der _GNOME Commander_ oder _Krusader_ an, während _macOS_ mit _Commander One_ , _Marta_ und dem _Nimble Commander_ über gut integrierte Dateimanager verfügt. Auch für _Windows_ -Nutzer stehen mehrere orthodoxe Dateimanager zur Verfügung, die nativ auf dem System laufen. Wer betriebssystemübergreifend unterwegs ist, kann auf Multiplattform-Manager wie den _Double Commander_ oder den _muCommander_ zurückgreifen. Je nach individuellen Anforderungen kann auch die Nutzung terminalbasierter Varianten wie des _Far Managers_ oder des _Midnight Commander_ eine sinnvolle Alternative darstellen. Welche Lösung am besten passt, lässt sich meist erst im praktischen Einsatz beurteilen; eine individuelle Erprobung ist daher unerlässlich. Zusammenfassend lässt sich sagen, dass orthodoxe Dateimanager ein effizientes Arbeiten mit vielen Dateien und komplexen Verzeichnisstrukturen ermöglichen; ganz ohne den Umweg über mausgesteuerte Bedienkonzepte. Dies spart Zeit, schont die Nerven und steigert die Produktivität. _Dieser Artikel erschienursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden._

Wer auf einem _Raspberry Pi_ ein Kiosk-System einrichten möchte, kann hierfür mit dem Raspberry OS Lite beginnen. Dort sollte über einen Aufruf von _raspi-config_ der _Autologin_ aktiviert werden (_System Options_ -> _S6 Auto Login_). Im nächsten Schritt wird der _Wayland Compositor_ _Sway_ installiert: apt install sway xwayland Nach der Installation wird im lokalen Nutzer, welcher für den Kiosk-Modus benutzt werden soll, eine Konfiguration-Datei angelegt: mkdir -p ~/.config/sway/ nano ~/.config/sway/config Diese wird mit folgender Konfiguration befüllt: # Sway kiosk configuration for Raspberry Pi + Raspberry Pi Touch Display 2 # Configure sway default_border none default_floating_border none # Set and transform output output DSI-2 transform 90 # Execute application exec_always sh -c '/home/seeseekey/testapp' Die Konfiguration sorgt dafür das _Sway_ rahmenlos arbeitet und der Bildschirm des _Raspberry Touch 2 Display_ um 90 Grad gedreht wird. Im letzten Schritt wird in der Konfiguration eine Applikation gestartet. Für Debugzwecke können daneben bei Bedarf noch folgende Zeilen hinzugefügt werden: # Debug (write outputs and tree into file) exec_always sh -c 'sleep 4 && swaymsg -t get_outputs > /tmp/outputs.json' exec_always sh -c 'sleep 4 && swaymsg -t get_tree > /tmp/tree.json' Zwar ist mit dieser Konfiguration das Display gedreht, aber die Eingaben werden noch in der ursprünglichen Rotation übermittelt. Hierzu muss im ersten Schritt mittels _libinput-tools_ das Gerät ermittelt werden: apt install libinput-tools libinput list-devices Nachdem das Touchscreen-Gerät ermittelt wurde, kann der Name des Gerätes genutzt werden, um eine _udev_ -Regel zu definieren: nano /etc/udev/rules.d/99-touch-rotation.rules Dort wird die Rotation ebenfalls um 90 Grad gedreht: ATTRS{name}=="11-005d Goodix Capacitive TouchScreen", ENV{LIBINPUT_CALIBRATION_MATRIX}="0 1 0 -1 0 1" Nachdem diese Konfiguration hinterlegt sind, wird eine lokale _systemd_ -Unit erstellt: mkdir -p ~/.config/systemd/user nano ~/.config/systemd/user/sway.service Diese wird mit folgendem Inhalt befüllt: [Unit] Description=Sway After=graphical-session.target Requires=graphical-session.target [Service] ExecStart=/usr/bin/sway Restart=always Environment=XDG_RUNTIME_DIR=/run/user/%U [Install] WantedBy=default.target Anschließend kann die _systemd_ -Unit aktiviert werden. systemctl --user enable sway Nun kann der _Raspberry Pi_ neugestartet werden. Im Idealfall startet das System führt den Login durch und startet die Applikation. Sollte es hier Probleme geben, kann es an bestimmten Bibliotheken wie _libxi6_ liegen, welche noch nachinstalliert werden müssen.

Unter _Rust_ ist das crosscompilen, also das Erstellen von Binaries für andere Architekturen relativ einfach. Im Falle des _Raspberry Pi 5_ , muss als Erstes die passende Zielarchitektur installiert werden: rustup target add aarch64-unknown-linux-gnu Da _Rusts_ Standardbibliothek _std_ auf C-Bibliotheken wie _libc_ aufbaut, muss gegen das Zielsystem gelinkt werden; in diesem Fall das _Linux_ auf dem _Raspberry Pi_. Dafür wird die entsprechende _Toolchain_ benötigt: brew tap messense/macos-cross-toolchains brew install aarch64-unknown-linux-gnu Nun muss das bestehende _Rust_ -Projekt noch modifiziert werden. Dazu muss eine _Cargo_ -Konfiguration unter _.cargo/config.toml_ erstellt werden: [target.aarch64-unknown-linux-gnu] linker = "aarch64-linux-gnu-gcc" Anschließend kann das Release erzeugt werden: cargo build --release --target aarch64-unknown-linux-gnu Nach dem Buildprozess findet sich das Kompilat im Ordner _target/aarch64-unknown-linux-gnu/release/_ und kann auf dem _Raspberry Pi_ ausgeführt werden.

Neben der Online-Nutzung von OpenStreetMap-Karten können diese auch gedruckt genutzt werden. Hierfür existieren eine Reihe von Diensten, welche es einem ermöglichen entsprechende Karten zu erstellen und sie anschließend als Datei für den Druck bereitzustellen. Einer dieser Dienste ist MyOSMatic, bei welchem es sich um einen Fork des MapOSMatic-Projektes handelt. MyOSMatic Nach der Auswahl eines Gebietes bzw. der Suche nach einem bestimmten Ort kann ein gewünschtes Layout gewählt und anschließend der Stil und etwaige Overlays festgelegt werden. Am Ende des Prozesses wird eine fertige Karte bereitgestellt, die anschließend heruntergeladen werden kann. Zu finden ist der Dienst unter print.get-map.org.

In der IT-Welt gibt es zahlreiche Fälle, in denen Platzhalterwerte für Dokumentationen, Tests und Simulationen benötigt werden. Diese Werte sollen realistisch erscheinen, dürfen aber nicht zu echten, existierenden Daten führen. Auch über die IT-Welt hinaus werden solche Werte hier und da verwendet, sei es in Film und Fernsehen, in Spielen oder anderen Medien. Natürlich können sich solche Beispielwerte einfach ausgedacht werden. Bei zugeteilten Ressourcen, wie Domains, Telefonnummern oder IP-Adressen kann dies allerdings zu Problemen führen. Der Missbrauch echter Domains oder IP-Adressen kann dort zu technischen Problemen, Datenschutzverletzungen oder rechtlichen Konsequenzen führen. In diesem Artikel werden die Hintergründe, die technischen Standards und die Best Practices im Umgang mit solchen Ressourcen, wie Beispieldomains, IP-Adressen und anderen reservierten Werten behandelt. **Nutzung** Im ersten Moment stellt sich vielleicht die Frage, wo solche Beispieldaten bzw. Ressourcen benötigt werden. In Dokumentationen und Handbüchern oder auch Anleitungen für unterschiedlichste Netzwerkgeräte oder Software werde Dinge wie IP-Adressen oder URLs gezeigt. Wünschenswert ist es, bei solchen Beispielen keine echten Ressourcen zu involvieren. In der Softwareentwicklung und beim Testen von Anwendungen setzen Entwickler gezielt Beispiel-Adressen ein. Diese Praxis dient dazu, sicherzustellen, dass Quellcode-Beispiele und Testumgebungen niemals versehentlich mit Produktivressourcen interagieren. So kommen in Unit-Tests oder Konfigurationsdateien oft Dummy-Domains wie example.org oder _test.example_ zum Einsatz. Auch IP-Adressen werden bewusst gewählt, um reale Systeme nicht zu beeinflussen. Das Gleiche gilt für Telefonnummern, wer hier auf einer Visitenkartenvorlage eine Nummer zeigt, möchte sicherstellen, dass diese nicht genutzt wird oder Unbeteiligte belästigt werden. In Produktdemos oder Marketingmaterial befinden sich oft Platzhalter. Etwa Screenshots einer CRM-Software zeigen _Max Mustermann – +1 555 0176_ als Kontakt, um realistische Daten vorzuführen, ohne echte Personen und Nummern preiszugeben. Oder ein Cloud-Anbieter demonstriert eine Konsole mit einem fiktiven Server _server.example.com_ und der IP _203.0.113.42_ , um die Oberfläche exemplarisch darzustellen. In der Systemadministration werden separate Testumgebungen mit Dummy-Daten betrieben. Beispielsweise könnte ein E-Mail-System auf einer internen Domain _test.example_ laufen, damit Test-E-Mails nicht in die Außenwelt gelangen. Datenbanken in Staging-Systemen enthalten Telefonnummern aus einem Pool von Beispielnummern, damit keine versehentlichen SMS oder Anrufe an echte Kunden herausgehen. In all diesen Fällen dienen die Beispielwerte dazu, realitätsnahe Situationen nachzustellen, ohne reale Adressen, Telefonnummern oder weitere zugeteilten Ressourcen zu benutzen. Dadurch können Lernende, Entwickler oder Nutzer gefahrlos experimentieren und die Beispiele nachvollziehen, ohne unbeabsichtigte Seiteneffekte in der realen Welt. **Unberechtigte Nutzung reservierter Ressourcen** Oft jedoch werden solche reservierten Ressourcen verwendet, ohne auf deren Verfügbarkeit zu achten. Ein Beispiel für eine solche Nutzung ist die E-Mail-Adresse *protected email*, welche insbesondere vor einigen Jahren gerne und häufig als Absender-Adresse für Newsletter oder Support-E-Mails verwendet wurde. Mit dem notwendigen Kleingeld kann auch *protected email* als E-Mail-Adresse genutzt werden Derjenige der die Kontrolle über die Domain noreply.com ausübt, kann diese dazu nutzen, E-Mails, welche auf solchen E-Mail-Adressen auflaufen zu empfangen und damit potenziell missbräuchlich nutzen. Eine fiktive und doch reale Domain aus dem Spiel „Do Not Feed the Monkeys“ Auch in anderen Medien, wie Spielen, sind immer wieder Domains zu finden, welche im besten Fall dem Spieleproduzenten gehören, im schlimmsten Fall aber andere Eigentümer haben. Die Domain steht zum Verkauf Was auf den ersten Blick harmlos erscheint, kann zu Problemen und ernsthaften Konsequenzen führen. **Risiken und Nebenwirkungen** Zu den Risiken und Nebenwirkungen der Verwendung solcher Ressourcen, welche nicht im Eigentum liegen, oder für den Beispielgebrauch vorgesehen sind, zählen unter anderem juristische Konsequenzen. Die unberechtigte Nutzung einer existierenden Telefonnummer oder IP-Adresse oder Domain kann zu rechtlichen Problemen führen. Leser oder Anwender können der Versuchung erliegen, eine beispielhafte Telefonnummer anzurufen oder eine Kreditkarten-Testnummer als reale Nummer zu verwenden. Das geschieht öfter als gemeinhin angenommen, z. B. mit amerikanischen Sozialversicherungsnummern. 1938 verwendete ein Geldbörsenhersteller, die _E. H. Ferree Company_ , für Werbezwecke die echte Social Security Number der Sekretärin des Vizepräsidenten, _Hilda Schrader Whitcher_ , auf einer Musterkarte, die in jede verkaufte Brieftasche eingelegt wurde. Trotz Aufdrucken wie _Specimen_ und rotem Druck hielten viele Käufer die Karte für echt und übernahmen die Nummer als ihre eigene. Zum Höhepunkt im Jahr 1943 nutzten über 5.700 Menschen diese Nummer. Insgesamt haben sie über 40.000 Menschen genutzt. Selbst 1977 benutzten noch zwölf Personen diese Sozialversicherungsnummer. Die _Social Security Administration_ musste die Nummer für ungültig erklären und breit kommunizieren, dass sie nicht verwendet werden darf. _Whitcher_ selbst wurde wegen des Vorfalls sogar vom FBI befragt, empfand den ganzen Trubel aber eher als Ärgernis. Neben diesem Vorfall gab es immer wieder ähnliche Vorfälle auch mit anderen gefälschten oder illustrativen Sozialversicherungsnummern — unter anderem veröffentlichte das _Social Security Board_ selbst 1940 ein Heft mit einer Fantasienummer (_219-09-9999_), die später ebenfalls von echten Personen beansprucht wurde. In der IT verhindern reservierte Adressen, dass Testsoftware Schaden anrichtet. Ohne Beispieladressen könnte es passieren, dass ein Entwickler, natürlich nur zum Test, hart kodierte IP-Adressen oder Domains einbaut, die zufällig jemandem gehören. Im schlimmsten Fall sendet eine solche Software dann Daten an Unbefugte oder beeinträchtigt fremde Systeme. Mit Beispiel-IPs wie _192.0.2.42_ sind solche Kollisionen absichtlich ausgeschlossen. Auch werden potenzielle Konflikte mit künftigen echten Zuweisungen vermieden – ein wichtiger Grund, der auch in der RFC 2606 genannt wird. Niemand muss befürchten, dass etwa die Domain _example.com_ nächstes Jahr von einer Firma registriert oder gekauft wird und plötzlich von bestehender Nutzung real angesprochen wird. Die Domain ist fest als reserviert vorgesehen und dadurch, besser als gewöhnliche Domains, abgesichert. Insgesamt sind Risiken vorhanden, die von möglichen Belästigungen Unbeteiligter über potenzielle Datenlecks bis hin zu rechtlichen Fragen reichen. Daher gilt: Real existierende Telefonnummern, Domains oder IP-Adressen haben in Publikationen und Tests nichts verloren, sofern sie nicht ausdrücklich zur Demonstration ausgewählt und genehmigt wurden und sich idealerweise im Eigentum des Nutzers befinden. **Domains** Wer eine Domain als Beispiel nutzen möchte, sollte im einfachsten Fall darauf achten, dass diese Domain im eigenen Besitz und entsprechende Kontrolle über die Domain vorhanden ist. Dann wäre es kein Problem, eine E-Mail-Adresse wie _ *protected email*_ zu nutzen. Werden Domains allerdings nur als Beispiel benötigt, so kann sich mit einer Beispiel-Domain wie _example.com_ beholfen werden. Solche Beispieldomains werden in einer Reihe von RFCs, wie der RFC 2606, definiert. Die Domain example.com ist als Beispieldomain verfügbar Dort sind die Domains _example.com_ , _example.net_ und _example.org_ als Beispiel-Domains definiert. In Dokumentation und Beispielen sollten solche Domains verwendet werden, anstatt auf beliebte echte Domains wie _yourdomain.com_ , _noreply.com_ oder im deutschsprachigen Raum auf _beispiel.de_ zu verweisen. beispiel.de versteht sich als Beispiel-Domain Auch wenn sich die Domain _beispiel.de_ als Beispiel-Domain versteht, so trägt sie doch keinen offiziellen Status und sollte deshalb nicht als Beispiel für eine solche in Betracht gezogen werden. Beispiel.de steht ebenfalls zum Verkauf So steht die Domain mittlerweile zum Verkauf und kann in Zukunft eine andere Nutzung erfahren, die mit dem Beispielzweck nicht übereinstimmt. Vor allem in TV und Film wurden in der Vergangenheit auch gerne Domains mit ungültigen Top-Level-Domains wie z. B. der _.web_ -Domain verwendet. So tauchte im _James-Bond_ -Film _Skyfall_ die Webadresse _www.868000.web_ auf, während im Film _Next Day Air_ die Domain _www.nda.web_ auftauchte. Das wird spätestens zu einem Problem, wenn die Top-Level-Domain _.web_ in Zukunft eventuell angeboten wird. Ein vergleichbarer Fall ereignete sich 2024 bei AVM mit der Domain fritz.box. Neben diesen konkreten Domains sind spezielle Top-Level-Domains für Beispiele reserviert. Diese sind in der RFC 2606 definiert worden. Hierzu gehören die Endungen _.test_ , _.example_ , _.invalid_ und _.localhost_. Die Top-Level-Domain _.test_ wird für Tests von aktuellem oder neuem DNS-bezogenem Code empfohlen, während _.example_ bevorzugt in Dokumentationen oder als Beispiel verwendet werden sollte. Die Top-Level-Domain _.invalid_ ist für solche Domains vorgesehen, die als sicher ungültig erkannt werden sollen. Zudem wurde die TLD _.localhost_ traditionell in DNS-Implementierungen statisch definiert, um einen A-Record auf die Loopback-IP-Adresse zu verweisen. Sie ist ausschließlich für diesen Zweck reserviert, da jede andere Nutzung mit weitverbreitetem Code in Konflikt geraten würde, der von dieser spezifischen Verwendung ausgeht. **IP-Adressen** Auch bei IP-Adressen kann die Nutzung falscher Beispiele zu Problemen führen. In Film und Fernsehen sind manchmal interessante Kombinationen wie _138.168.212.473_ zu sehen, bei welcher es sich um eine ungültige IP-Adresse handelt. Auch die Nutzung bekannter IP-Adressen, wie der _8.8.8.8_ des Google Public DNS-Services, sollte nicht als Beispiel-IP-Adresse eingesetzt werden. Besser und sicherer ist es hier dafür speziell vorgesehene Bereiche für Dokumentationszwecke zu nutzen. Definiert werden diese für IPv4-Adressen in der RFC 5737. Dabei sind mehrere Bereiche vorgesehen: 192.0.2.0/24 198.51.100.0/24 203.0.113.0/24 Die Blöcke tragen hierbei die Namen TEST-NET-1 (_192.0.2.0/24_), TEST-NET-2 (_198.51.100.0/24_) und TEST-NET-3 (_203.0.113.0/24_). Gemäß der RFC sollen diese Blöcke von Adressen nicht im Internet auftauchen und in Netzwerken sollten diese Adressblöcke in die Liste der nicht routingfähigen Adressräume aufgenommen werden. Damit gehören diese Adressbereiche nicht zu realen Netzwerken und können sicher in Handbüchern, Dokumentationen und Beispielen verwendet werden. Natürlich könnten in der Theorie auch andere Bereiche genutzt werden, wie einer der privaten Adressbereiche wie _192.168.0.0/16_. Somit wäre eine IP-Adresse wie _192.168.1.1_ auf den ersten Blick unbedenklich. Allerdings werden diese IP-Adressen in internen Netzen produktiv genutzt und fallen damit als Beispiele in vielen Fällen weg. Für besagte Dokumentationszwecke sind somit die oben genannten TEST-NET-Adressen vorzuziehen, weil sie global eindeutig als Beispieladressen kenntlich sind und nicht mit realen Netzen kollidieren. Für IPv6 wurde ebenfalls ein Bereich bzw. ein Präfix für Dokumentationszwecke vorgegeben. Definiert ist dieses Präfix in der RFC 3849. Der für Dokumentationszwecke reservierte /32-Bereich lautet: 2001:0DB8::/32. Jede IPv6-Adresse, die mit 2001:DB8 beginnt, ist somit als fiktiv für Dokumentations- und ähnliche Zwecke ausgewiesen. Zusätzlich existiert für spezielle Protokoll-Demonstrationen ein reservierter IPv4-Multicast-Adressbereich mit dem Namen MCAST-TEST-NET (_233.252.0.0/24_), der in RFC 5771 definiert ist. Dieser Bereich ist für Demonstrations- und Beispielzwecke vorgesehen, doch im Alltag sind hauptsächlich die oben genannten Adressbereiche relevant. **Telefonnummern** Eine weitere zugeteilte Ressource sind Telefonnummern. Welche Folgen die unbedachte Verwendung realer Nummern haben kann, zeigt der Song _Skandal im Sperrbezirk_ der Spider Murphy Gang. Dort heißt es im Songtext: > Ja, Rosi hat ein Telefon > Auch ich hab ihre Nummer schon > Unter zwounddreißig sechzehn acht > Herrscht Konjunktur die ganze Nacht Die dort besungene Telefonnummer _32 16 8_ sollte angeblich einer älteren Dame gehören, allerdings erzählte der Sänger Günther Sigl in einem Interview eine andere Geschichte dazu: > Richtig, 32168 war auf einmal die berühmteste Telefonnummer Deutschlands. In München hatten wir die Nummer gecheckt, die gab’s da damals nicht. In anderen Städten aber schon. Einige Jugendliche haben sich da einen Spaß gemacht, angerufen und blöd dahergeredet. Naja, wir haben damals einige Rufnummernänderungen bezahlt und zahlreiche Blumensträuße als Entschuldigung quer durch Deutschland geschickt. Seit 2006 ist der Rufnummernblock _(0)89 32168 000_ bis _(0)89 32168 999_ der _Telefónica_ zugewiesen. Statt echter Nummern können zu diesem Zweck reservierte Bereiche, sogenannte _Drama Numbers_ , genutzt werden. Im deutschen Raum sind diese über die Amtsblatt-Mitteilung 148/2021 definiert. In der Amtsblatt-Mitteilung wurden für einige Ortsnetze im Festnetz bestimmte Nummernbereiche zur freien Verwendung definiert: Berlin: (0)30 23125 000 bis 999 Frankfurt am Main: (0)69 90009 000 bis 999 Hamburg: (0)40 66969 000 bis 999 Köln: (0)221 4710 000 bis 999 München: (0)89 99998 000 bis 999 Wer diese Nummern anruft, wird per Ansage erfahren, dass die Rufnummer nicht erreichbar ist. Interessierte haben die Möglichkeit, dies selbst zu testen, da dies der Zweck der reservierten Nummern ist. Somit können diese Nummern gefahrlos in Medienproduktionen oder als Beispiel genutzt werden. Neben Festnetznummern sind auch eine Reihe von Mobilfunknummern in den deutschen Netzen freigegeben: (0)152 28817386 (0)152 28895456 (0)152 54599371 (0)171 39200 00 bis 99 (0)172 9925904 (0)172 9968532 (0)172 9973185 (0)172 9973186 (0)172 9980752 (0)174 9091317 (0)174 9464308 (0)176 040690 00 bis 99 Die Rufnummern des Blockes _(0)171 39200 00_ bis _99_ gehören hierbei der _Deutschen Telekom_ , die des Blockes _(0)176 040690 00_ bis _99_ zu _Telefónica_ , während die restlichen Nummern im _Vodafone_ -Netz liegen. **Internationale Telefonnummern** Ähnlich wie in Deutschland existieren auch international spezielle Rufnummernblöcke für Beispielzwecke. Zu den bekanntesten Nummern zählen sicherlich die Telefonnummern aus dem amerikanischen Raum, die mit der Ziffernfolge _555_ beginnen. In Nordamerika ist seit den 1960er Jahren die Vorwahl _555_ für fiktive Nummern gebräuchlich. Telefongesellschaften und Filmstudios einigten sich darauf, diese Vorwahl in Fernsehen und Film zu nutzen. Tatsächlich sind die nur Nummern _555-0100_ bis _555-0199_ für rein fiktive Zwecke reserviert – wenn solche Nummern im Film gewählt werden, ist sichergestellt, dass kein tatsächlicher Anschluss existiert. Definiert sind diese Nummern im _555 NXX Line Number Reference Document_ (ATIS-0300115). Dort heißt es: > With the sunset of the 555 NXX Assignment Guidelines, a block of one hundred (100) 555 line numbers will remain reserved as fictitious, non-working numbers for use by the entertainment and advertising industries. These specific numbers are 555-01XX, i.e., numbers between and including 555-0100 and 555-0199. In der Kinofassung von _Bruce Allmächtig_ (im Origial: _Bruce Almighty_), wurde die Nummer von Gott als _776-2323_ angegeben. In _Buffalo_ , wo der Film spielte, war die Nummer nicht belegt, aber in vielen anderen Vorwahlbereichen existierte die Nummer. So wurde sie für die DVD, HD-DVD und Bluray-Fassungen schließlich in _555_ geändert. Aktivieren Sie JavaScript um das Video zu sehen. Video-Link: https://www.youtube.com/watch?v=mbZibNULsxI Auch in britischen Produktionen kamen häufig Telefonnummern zum Einsatz, die sich nur bedingt als Beispiele eignen. Sehr bekannt ist sicherlich die „neue“ Notrufnummern. Anstatt der _999_ soll in der Welt von _IT Crowd_ nur noch die Nummer _0118 999 881 999 119 725 3_ gewählt werden. Aktivieren Sie JavaScript um das Video zu sehen. Video-Link: https://www.youtube.com/watch?v=HWc3WY3fuZU Der Sketch spielt auf eine wahre Gegebenheit an: Im Jahr 2003 hatte Großbritannien sein traditionelles Auskunftssystem umgestellt, bei dem früher einfach die 192 gewählt wurde, um eine Telefonnummer zu erfragen. Nach der Liberalisierung mussten Anrufer stattdessen eine der neuen, kommerziellen 118-Nummern wählen, wobei insbesondere die leicht einprägsame _118 118_ , auch aufgrund einer allgegenwärtigen Werbekampagne, schnell Berühmtheit erlangte. Zwar existiert der Bereichscode _0118_ , aber der Rufnummernblock beginnend mit der _999_ wird nicht weitergeleitet, sodass zumindest keine Gefahr bestand, hier wirklich jemand zu erreichen. Allerdings existieren auch in Großbritannien entsprechende Nummern für die Nutzung in fiktivem Kontext. Diese wurde zuletzt 2019, von der britischen Medienaufsicht, dem _Office of Communications_ , veröffentlicht. So könnte das _Torchwood-Institut_ in _Cardiff_ , vielleicht die Telefonnummer _029/20180000_ nutzen. Daneben existieren in vielen anderen Ländern wie Australien, Irland, Südkorea, Schweden oder Frankreich Regelungen und Freigaben für jeweils auf die Länder zugeschnittene Drama Numbers. **Weitere zugeteilte Ressourcen** Neben den genannten Anwendungsfällen, wie Telefonnummern, Domains und IP-Adressen, gibt es weitere Ressourcen, für die gegebenenfalls Beispiele und Testdaten benötigt werden. Für Kreditkarten wird z. B. von VISA die Testkreditkartennummer _4111 1111 1111 1111_ bereitgestellt. Dies ist auch für viele andere Kreditkarten der Fall, hängt aber in der konkreten Ausprägung auch vom jeweiligen Zahlungsdienstleister ab. Gültig sind diese Nummern, dann meist nur in den jeweiligen Testsystemen der Dienstleister. Auch für Kontonummern, wie IBANs existieren entsprechende Testnummern, welche genutzt werden können. **Best Practices** In der Praxis ist es ratsam, Beispiele klar als solche zu kennzeichnen, um Missverständnisse zu vermeiden. Dies kann durch Kommentare im Quellcode, Fußnoten in Dokumentationen oder spezielle Formatierungen geschehen. Dokumentationen sollten klar kennzeichnen, dass verwendete Werte nur Beispiele sind. In Software sollte sichergestellt werden, dass Testwerte nicht versehentlich in Produktionsumgebungen gelangen. Wenn die existierenden Beispieldaten nicht ausreichen, kann in bestimmten Fällen nachgeholfen werden – beispielsweise durch die Nutzung von Subdomains: api.example.com blog.example.com shop.example.com So bleibt die Beispielhaftigkeit gewahrt. Auch bieten die Beispiel-Top-Level-Domains die Möglichkeit viele Testdaten zu generieren z. B. _shop.example_ , _system.example_. Softwareentwickler sollten Mechanismen implementieren, die verhindern, dass echte Daten versehentlich in Testumgebungen verwendet werden. Skripte und Produktionscode können etwa prüfen, ob eine verwendete IP-Adresse oder Domain tatsächlich für Tests vorgesehen ist. Auch der umgekehrte Fall gilt. In Produktivsystemen können auch Prüfungen eingebaut werden, ob in Feldern wie Telefonnummern oder Domains nur Beispielwerte eingegeben und diesen dann abgelehnt werden. Daneben sollte man darauf verzichten, für Beispiele Templates aus echten Daten zu erstellen. Es mag verlockend sein, z. B. einen echten Konfigurationsausschnitt aus einem System als Grundlage für eine Dokumentation zu nutzen. Hier besteht jedoch immer die Gefahr, einen Wert zu übersehen und reale Details abzubilden. Besser ist, von Anfang an eine künstliche Beispielumgebung aufzusetzen. So sollte ein Demo-Account mit Beispielnamen und -kontakten verwendet werden, statt eines echten Accounts. Bei der Nutzung in Produktivumgebungen, wie als E-Mail-Absender, sollten die eigenen Domains genutzt werden. So kann sichergestellt werden, dass auch Rückläufer für _noreply_ -Adressen nicht ins Leere laufen oder unbeabsichtigt Dritte erreichen. **Fazit** Beispiel ist nicht gleich Beispiel. Bei der Nutzung von Beispielen in Dokumentationen, anderen Texten, Medien oder Applikationen sollte Vorsicht geboten sein. Handelt es sich um Beispiele, oder fiktive Werte, so sollten dafür vorgesehenen Varianten, wie z.B. _Drama Numbers_ , verwendet werden. Durch die Nutzung von Beispiel-IP-Adressen wird vermieden, dass Beispiel-Skripte, Konfigurationen oder Tutorien ungewollt fremde Rechner scannen oder ansprechen. Auch wenn ein Nutzer einen in einer Anleitung gezeigten Befehl kopiert, sind diese Adressen harmlos, da sie ins Leere führen oder nur lokale Wirkung haben. Von inoffiziellen Beispieldomains wie _beispiel.de_ sollte abgeraten werden, da hier keine Kontrolle darüber besteht, wie lange sie noch ihrer Funktion als Beispiel entspricht. Bei den hierfür offiziell reservierten Ressourcen kann hingegen von einer gewissen Kontinuität ausgegangen werden. Beispieldomains, reservierte IP-Adressen und _Drama Numbers_ sind essenziell für sichere und verständliche Dokumentationen sowie Testumgebungen. Durch die Verwendung standardisierter Werte können Fehler vermieden, Datenschutzrisiken minimiert und die Konsistenz in technischen Dokumentationen gewährleistet werden. Die Einhaltung der entsprechenden RFCs und Best Practices hilft, Missverständnisse und missbräuchliche Nutzungen zu vermeiden. _Dieser Artikel erschienursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden._

Die Screenshots, welche mit der _Switch 2_ , erstellt werden können, werden entweder im internen Speicher oder auf der _microSD-Express_ -Karte gespeichert. Da _microSD-Express_ -Reader relativ kostspielig sind, stellt sich die Frage wie die Screenshots auf den Rechner kopiert werden können. Neben der Möglichkeit die Daten automatisch hochzuladen und in der offiziellen _Nintendo Switch_ -App einzeln zu speichern, kann die _Switch 2_ selbst als _microSD-Express_ -Reader genutzt werden. Über MTP werden die Daten transferiert Dazu muss die _Switch 2_ über den unteren USB-C-Port mit dem Rechner verbunden werden. Anschließend sollten in der _Switch 2_ die _Systemeinstellungen_ unter dem Punkt _Datenverwaltung_ aufgerufen werden. Dort findet sich der Unterpunkt _Screenshots und Videos verwalten_ und dort wiederum der Punkt _Per USB-Verbindung auf einen PC kopieren_. _Die Switch 2_ ermöglicht es anschließend die Daten über das MTP-Protokoll zu kopieren.

Wie andere Rechner auch, verfügen auch _Dell_ -Laptops über Funktionstasten, meist F1 bis F12. In den letzten Jahren wurden diese dann mit einer zweiten Belegung (z. B. die Einstellung der Bildschirmhelligkeit) versehen. Irgendwann wurde seitens der Hersteller dazu übergegangen diese Zweitbelegung zur Primärbelegung zu machen. Dies führte allerdings zu dem Problem, dass die Funktionstasten nur noch mit einem zusätzlichen Druck der _Fn_ -Taste erreichbar waren. Die Funktionstasten sind meist mit einer zweiten Belegung versehen Um das wieder zu ändern, kann eine Einstellung im BIOS getätigt werden. Während des laufenden Betriebs kann diese Funktionalität allerdings auch über die Tastenkombination _Fn_ + _Esc_ umgeschaltet werden. Damit wechselt die Primärbelegung zu den Funktionstasten und umgekehrt.

Wenn unter _macOS_ der _Papierkorb_ entleert wird, so wird dies mit einem Fortschritt angezeigt. Unter Umständen kann es passieren, das selbst nach Stunden die Entleerung des _Papierkorbes_ nicht voranschreitet. In einem solchen Fall kann es hilfreich sein, manuell nachzuhelfen. Über das Kontextmenü kann Sofort löschen ausgewählt werden Im geöffneten _Papierkorb_ findet sich im Kontextmenü der Punkt _Sofort löschen_ , mit dem sich einzelne Ordner und Dateien aus dem _Papierkorb_ löschen lassen. Damit lässt sich der _Papierkorb_ manuell entleeren. Anschließend kann der _Papierkorb_ wieder über die normale Funktionalität geleert werden.

Wer die integrierte _Kalender_ -App unter _macOS_ nutzt, wird feststellen das dort keine Kalenderwochen angezeigt werden. Allerdings verfügt die App durchaus eine Unterstützung für die Anzeige dieser. In den Einstellungen können die Kalenderwochen aktiviert werden Aktiviert werden kann die Darstellung der Kalenderwochen in den _Einstellungen_ unter _Erweitert_. Dort findet sich der Punkt _Wochenzahlen einblenden_. Wird dieser aktiviert, werden anschließend die Kalenderwochen mit im Kalender angezeigt.

Im Rahmen digitaler Souveränität ist das Hosten auf _GitHub_ eine zwiespältige Sache. Während die zugrundeliegenden Werkzeuge wie _Git_ frei verfügbar sind, trifft dies auf Plattformen wie _GitHub_ nicht zu. Allerdings existieren auch Alternativen, wie Codeberg. Dabei handelt es sich um eine gemeinnützige, community-getriebene Plattform für die Entwicklung und das Hosting von Open-Source-Softwareprojekten. Betrieben wird sie vom eingetragenen Verein _Codeberg e.V._ mit Sitz in Berlin. Die Plattform bietet eine datenschutzfreundliche Alternative zu kommerziellen Diensten wie _GitHub_ und richtet sich an Entwickler:innen, die Wert auf Transparenz, Offenheit und digitale Souveränität legen. Die Plattform Codeberg Nun ist ein vollständiger Wechsel für viele Nutzer nicht unbedingt immer möglich. Eine Alternative ist dann unter Umständen die Nutzung zweier Plattformen wie _GitHub_ und _Codeberg_ und eine entsprechende Spiegelung. Die der _Codeberg_ zugrundeliegende Plattform Forgejo beherrscht die Spiegelung von Repositories. Allerdings ist dieses Feature auf der Plattform mit Absicht deaktiviert. Wer eine solche Synchronisation nutzen möchte, ist damit auf weitere Werkzeuge angewiesen. Eines dieser Werkzeuge ist Gickup. Nach der Installation: brew install gickup sollte eine Konfigurationsdatei mit dem Namen _conf.yml_ angelegt werden. Eine Minimalkonfiguration könnte folgendermaßen aussehen: source: github: - token: topsecret-github-token includeorgs: - Entitaet - seeseekey wiki: true issues: true destination: gitea: - url: https://codeberg.org/ token: topsecret-codeberg-token createorg: true mirror: enabled: true Diese Konfiguration stellt sicher, dass nur gewünschte Organisationen synchronisiert werden und dass Repositories von Organisationen, als solche in _Codeberg_ angelegt werden. Die Token müssen auf _GitHub_ und _Codeberg_ angelegt werden und anschließend in der Konfiguration hinterlegt werden. Für _GitHub_ wird dieses Token in den Einstellungen erzeugt. Hier sollte ein _Classic_ -Token erzeugt werden und die Rechte für _repo_ sollten zugewiesen werden. Für GitHub werden die repo-Berechtigungen benötigt Unter _Codeberg_ wird das neue Token ebenfalls in den Einstellungen unter Anwendungen angelegt. Das Token für Codeberg wird erzeugt Nachdem die Token in der Konfiguration hinterlegt worden sind, kann der Prozess mittels _gickup_ gestartet werden: 2025-05-20T21:18:50+02:00 INF Reading conf.yml file=conf.yml 2025-05-20T21:18:50+02:00 INF Configuration loaded destinations=1 pairs=1 sources=1 2025-05-20T21:18:50+02:00 INF Backup run starting 2025-05-20T21:18:50+02:00 INF grabbing my repositories stage=github url=https://github.com 2025-05-20T21:19:20+02:00 INF starting backup for https://github.com/Entitaet/autoxylophon.git stage=backup 2025-05-20T21:19:20+02:00 INF mirroring autoxylophon to https://codeberg.org/ stage=gitea url=https://codeberg.org/ 2025-05-20T21:19:21+02:00 INF already up-to-date stage=gitea url=https://github.com/Entitaet/autoxylophon.git Je nach Größe der eigenen Repositories kann die Spiegelung einige Minuten in Anspruch nehmen. Ist eine Aktualisierung gewünscht, so kann der Prozess einfach erneut angestoßen werden. Neben dieser Möglichkeit existieren weitere Möglichkeiten, um eine Spiegelung von Repositories zu _Codeberg_ zu realisieren.

Wer RSS-Reader nutzt weiß vollständige Feeds zu schätzen. So sollte auch diese Webseite vollständige Feeds ausliefern, allerdings tat sie das seit einiger Zeit nicht mehr. Die _Einstellungen_ unter _WordPress_ zeigten, das eigentlich alles in Ordnung sein müsste. Die Feed-Einstellungen unter WordPress Auf der Suche nach der Ursache geriet schlussendlich das Plugin _The SEO Framework_ in den Fokus. The SEO Framework – Fast, Automated, Effortless. Price: Free In den Einstellungen dieses Plugins fanden sich die Optionen _Feed-Einträge in Textauszüge umwandeln_ und _Link zur Quelle unter Feed-Einträge hinzufügen_. Diese waren standardmäßig gesetzt und sorgten dafür das die Feeds der _WordPress_ -Installation gekürzt wurden. Nach der Deaktivierung der Optionen funktionierten auch die Feeds wieder im Volltext.

Bedingt durch die Kürzungen der US-Regierung, war es in den letzten Wochen durchaus denkbar, dass die CVE-Liste, mangels monetärer Mittel, ihre Arbeit hätte einstellen müssen. Das veranlasste die _Agentur der Europäischen Union für Cybersicherheit_ (ENISA), ihre eigene Schwachstellen-Datenbank, die _European Vulnerability Database_ (EUVD), früher vorzustellen. Neben der offiziellen Seite, wird auch eine API bereitgestellt. Das Webinterface der EUVD Mehrere spezialisierte Endpunkte stehen innerhalb der API zur Verfügung: _/api/lastvulnerabilities_ , _/api/exploitedvulnerabilities_ und _/api/criticalvulnerabilities_ liefern jeweils bis zu acht aktuelle Einträge. Über _/api/vulnerabilities_ lassen sich Schwachstellen detailliert nach Kriterien wie Score, EPSS-Wert, Veröffentlichungszeitraum, Hersteller oder Produktname filtern. Weitere Routen ermöglichen den Zugriff auf konkrete Einträge per ENISA-ID oder geben zugehörige Advisories aus. Die erstellte OpenAPI-Spezifikation Die Dokumentation der API ist allerdings eher rudimentär und nicht wirklich strukturiert gehalten, so werden z.B. die _Response_ -Objekte nirgendwo definiert. Da ich die API in _Rust_ nutzen wollte, führte dies zur Entwicklung des _Crates_ euvd. Passend dazu habe ich eine OpenAPI-Spezifikation erstellt, welche die API möglichst vollumfänglich abbildet. Damit können auch Clients abseits von _Rust_ für die EUVD-API erzeugt werden. Der Content-Type ist text/plain Die API selbst enthält noch einige Merkwürdigkeiten bzw. Inkonsistenzen. Dies fängt damit an, das JSON-Objekte zurückgegeben werden: { "id": "cisco-sa-ata19x-multi-RDTEqRsy", "description": "Cisco ATA 190 Series Analog Telephone Adapter Firmware Vulnerabilities", "summary": "Multiple vulnerabilities in Cisco ATA 190 Series Analog Telephone Adapter firmware, both on-premises and multiplatform, could allow a remote attacker to delete or change the configuration, execute commands as the root user, conduct a cross-site scripting (XSS) attack against a user of the interface, view passwords, conduct a cross-site request forgery (CSRF) attack, or reboot the device.\r\n\r\nFor more information about these vulnerabilities, see the Details [\"#details\"] section of this advisory.\r\n\r\nCisco has released firmware updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities. However, there is a mitigation that addresses some of these vulnerabilities for Cisco ATA 191 on-premises firmware only.\r\n\r\n", "datePublished": "Oct 16, 2024, 4:00:00 PM", ... } Der _Content-Type_ seitens der API wird allerdings als _text/plain;charset=UTF-8_ definiert und entsprechend zurückgegeben. Dies führte unter anderem bei der Client-Generation zu Problemen, da der Text nicht standardmäßig in die bereitgestellten JSON-Objekte konvertiert wurde. In den API-Objekten selbst wird mit _Camel case_ gearbeitet, allerdings existieren aus Ausnahmen, wie die _enisa_id_ , welche als _Snake case_ geschrieben wird und die API an einigen Stellen etwas inkonsistent wirken lässt. "enisa_id": "EUVD-2024-45012\n", "assigner": "mitre", "epss": 0.05, "enisaIdProduct": [ ... An anderen Punkten wird wieder die Schreibweise in _Camel case_ genutzt, wie z.B. beim _enisaIdProduct_ -Feld. Auch eine Versionierung ist nicht zu erkennen, was die Frage nach dem genauen Updateprocedere der API aufwirft. In Bezug auf digitale Souveränität fällt zudem auf, dass die API bei _Azure_ gehostet wird, wie ein _whois_ zeigt: % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.arin.net inetnum: 20.0.0.0 - 20.255.255.255 organisation: Administered by ARIN status: LEGACY whois: whois.arin.net changed: 1994-10 source: IANA # whois.arin.net NetRange: 20.33.0.0 - 20.128.255.255 CIDR: 20.64.0.0/10, 20.128.0.0/16, 20.40.0.0/13, 20.34.0.0/15, 20.36.0.0/14, 20.33.0.0/16, 20.48.0.0/12 NetName: MSFT NetHandle: NET-20-33-0-0-1 Parent: NET20 (NET-20-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Microsoft Corporation (MSFT) RegDate: 2017-10-18 Updated: 2021-12-14 Ref: https://rdap.arin.net/registry/ip/20.33.0.0 Dies lässt strategische Autonomie vermissen, wenn solche Dienste auf einer Infrastruktur betrieben werden, welche unter ausländischer Rechtshoheit steht. Um die API bzw. den _Client_ in _Rust_ zu nutzen, muss im ersten Schritt das _Crate_ ins eigene Projekt eingebunden werden: cargo add euvd Anschließend können die einzelnen Ressourcen aufgerufen werden: use euvd::apis::configuration::Configuration; use euvd::apis::default_api; async fn get_last_vulnerabilities() { // Preparation let config = Configuration::default(); let result = default_api::get_last_vulnerabilities(&config).await; // Print result if successful if let Ok(response) = &result { println!("Response received:"); for vuln in response { println!("• ID: {:?}, Description: {:?}", vuln.id, vuln.description); } } // Asserts assert!(result.is_ok(), "API call failed: {:?}", result.err()); } Weitere Beispiele zur Nutzung der API finden sich im Integrationstest.