Die meisten Bilder, welche aus einer Digitalkamera kommen enthalten sogenannte EXIF-Informationen. Die Abkürzung EXIF steht dabei für Exchangeable Image File Format. In diesen Metadaten zum Bild können eine Reihe von Informationen enthalten sein, wie z.B. Datum und Uhrzeit, Koordinaten an welchen das Bild geschossen wurde, die Blendenzahl und viele weitere. Unter Umständen kann es gewünscht sein diese Informationen zu entfernen. Unter Linux, in diesem Fall Ubuntu, kann das mit dem ExifTool erledigt werden. Dazu muss dieses im ersten Schritt installiert werden:

apt install exiftool

Anschließend kann eine einzelne Datei mit dem Befehl:

exiftool -all= image.jpg

bearbeitet werden. Soll das Ganze rekursiv über mehrere Ordner passieren kann folgender Befehl genutzt werden:

cd folder/
find . -iname "*.jpg" -type f -exec exiftool -all= {} \;

Er durchsucht alle Verzeichnisse unterhalb des gewählten Verzeichnisses und entfernt, für jede Datei mit der Endung .jpg, die EXIF-Daten.

Ich freue mich, euch heute mein neustes Projekt vorzustellen, bei dem es wortwörtlich um neue Dinge geht: mit LatestVersionOf.com biete ich seit heute öffentlich eine Webseite an, mit der es möglich ist, an zentraler Stelle die aktuellen Versionsnummern von Software zu finden. Eine besondere Rolle spielt hierbei Open Source-Anwendungssoftware, die zum Teil bereits verzeichnet ist.

Die Motivation für das Projekt stammt aus meiner täglichen Arbeit: leider ist nicht jede Anwendung im Paketmanager verfügbar und das Zusammensuchen der jeweils aktuellsten Version stellt sich oftmals als sehr mühselig dar.

LatestVersionOf.com soll ein Portal werden, das Versionsupdates verschiedener Anwendungen aus unterschiedlichen Quellen ermittelt und an einer Stelle zusammenführt. So lassen sich einheitlich die Versionen von z.B. Firefox, Chrome, Thunderbird, MediaWiki, Ubuntu, dem Arch Linux-Installationsmedium, u.v.m. abrufen.

Ich stelle euch das Projekt zum frühstmöglichen Zeitpunkt als MVP zur Verfügung. Grundsätzlich ist das System nicht an Pakete gebunden, upstream tracking wäre als Idee allerdings möglich. Auch wäre eine Einbeziehung von Softwarebibliotheken denkbar. Ebenfalls ist eine Watchlist-Funktion sowie eine API bereits in Vorbereitung. Das Auftrennen bestimmter Versionsstränge („flavors“, wie z.B. 9.x, 10.x, etc.) ist technisch schon möglich, die dazugehörige Automatisierung ist noch in der Entwicklung.

Für Vorschläge weiterer Software für den Index könnt ihr dieses Formular nutzen. Besonders einfach ist es, wenn als URL ein GitHub-Repository angegeben werden kann.

Das Projekt ist momentan als Beta-Version in der Testphase, die für die nächsten Monate angelegt ist. Ich bin gespannt auf euer Feedback! Dazu einfach hier (konstruktiv ;)) kommentieren oder mir eine Mail schicken!

Wer als Versionsverwaltung Mercurial verwendet und diese nicht selbst hosten will nutzt vermutlich meist das Angebot von Bitbucket.

Auf dem offiziellen Blog wurde nun bekannt gegeben, dass in einigen Monaten die Unterstützung für Mercurial eingestellt wird. Bitbucket setzt dann wie andere Anbieter (z. B. Github oder Gitlab) nur noch auf Git.

Ab dem 01. Februar 2020 kann man bei Bitbucket keine Mercurial-Repositories anlegen. Ab dem 01. Juni 2020 ist dann endgültig Schluss und die vorhandenen Repositories werden gelöscht.

Wer also Projekte bei Bitbucket hostet, sollte bis spätestens 31. Mai seine Daten sichern und sich nach einer Alternative umsehen.

Ich vermute die Entscheidung von Bitbucket wird dazu führen, dass einige Projekte nun zu Git wechseln.

Wer weiterhin Mercurial nutzen will, kann sich https://www.mercurial-scm.org/wiki/MercurialHosting ansehen. Dort werden einige alternative Anbieter (die mich auf den ersten Blick alle nicht beigeistern) aufgeführt.

Ebenfalls werden dort Möglichkeiten zu selber hosten genannt. Hier finde ich vor allem Heptapod interessant. Hierbei handelt es sich um einen Fork von Gitlab der Mercurial unterstützt. Zudem sind die Entwickler von Gitlab dem Fork postiv gesinnt und unterstützen die Entwicklung. Laut den Entwicklern ist Heptapod allerdings noch in einem frühen Entwicklungsphase. Wer also Mercurial für wichtige Projekte nutzt, sollte daher noch abwarten.

Letztens flatterte mir in Friendica eine Empfehlung für ein VIM Tutorial von Daniel Miessler durch die Timeline. Das Tutorial fängt bei dem absoluten Neuling an und führt einen meines Erachtens gut durch die anfänglichen Stolpersteine.

Dann bin ich ein wenige neugierig geworden und habe mal geschaut, was er sonst noch so geschrieben hatte. Und tatsächlich sind da einige tolle Tutorials mit Schwerpunkt Linux und Netzwerk dabei, so dass die Seite in meine Bookmarkliste beziehungsweise in meinen selbst gehosteten RSS Reader (Tiny Tiny RSS) mit aufgenommen wurde.

Das Smartphone Betriebssystem mit dem denkbar Suchmaschinen-unfreundlichen Namen /e/ ist ein Android-basiertes Custom Rom mit dem Ziel Google zu ersetzen ohne den Anwender funktional in die Isolation zu treiben. Es integriert eine Vielzahl interessanter Open Source Projekte und ein paar Eigenentwicklungen, sowie dazugehörige Cloud-Dienste.

Im Rahmen meiner Android-Serie hatte ich LineageOS als Custom Rom empfohlen (siehe auch: Android ohne Google III - Custom Rom (LineageOS) aufspielen). LineageOS ist so etwas wie das Debian unter den Android-Roms. Es läuft auf sehr vielen Geräten und bietet eine solide Basis aber nach der Installation steht der Anwender mit einem ziemlich schmalen Betriebssystem da und muss darauf aufbauend sein individuelles App-Portfolio zusammen stellen. Das ist kein Hexenwerk aber bietet auch keim Potenzial nach oben, wie die Nutzerzahlen zeigen.

Hinter /e/ steht unter anderem Gaël Duval - ein Urgestein der Open Source Community.  Vor 20 Jahren kombinierte er Red Hat mit KDE und schuf dadurch Mandrake Linux. Der Open Source Welt ist er Treu geblieben, doch wie so viele widmet er sich nun anstelle klassischer Desktop-Themen der Entwicklung für mobile Endgeräte.

/e/ soll nicht nur einfach eine Custom Rom sein, es soll eine Google-befreite Android-Variante werden, die dennoch nicht auf Komfort verzichtet. Dazu kombiniert man eine von CyanogenMod/LineageOS abgespaltene Basis mit dem MicroG-Projekt, das sich an einer freien Implementierung der Play Services versucht. Hinzu kommen Forks einer Vielzahl von populären Open Source-Apps. Die Zusammenstellung kann dieser Seite entnommen werden. Das Portfolio runden perspektivisch zugehörige Dienste ab, ohne die auch freie Projekte nicht mehr auskommen (siehe: Purism startet Kampagne für Librem One).

Neben den Forks populärer Apps und ihrer gelungenen Zusammenstellung gibt es zwei substanzielle Eigenentwicklungen. Eine davon ist der Blizz Launcher samt Icon-Set, der optisch eine ziemlich Imitation von iOS ist. Letzteres muss man mögen aber Xiaomi und Huawei zeigen, dass man durch diese Richtung viele Anwender für sich gewinnen kann. Die zweite ist ein eigener App Store.

Je nach Gerät ist die Android-Basis relativ alt, die aktuellen Sicherheitspatches sind aber eingepflegt, weshalb das kein Sicherheitsrisiko ist. Die Apps sind dabei bei jeder Variante aktuell, wodurch man als Anwender von den unterschiedlichen Android-Versionen nicht soviel merkt.

Um Google wirklich zu ersetzen beabsichtigt /e/ einen eigenen zentralen Dienst zu betreiben. Momentan ist dieser Dienst aber zahlenden Unterstützern vorbehalten. Der Dienst kann aber, basierend auf der Nextcloud, eine ziemlich umfänglich Synchronisation von E-Mails, Kontakten, Kalender, Dateien, Notizen etc. bieten.

In einem kleinen Test lief /e/ bereits sehr stabil. Der App Store ist sogar ganz gut gefüllt, wobei die Herkunft der Apps nicht ganz klar ist. Eine schöne Funktion ist die Integration von Exodus, wodurch für Anwender der "Privacy-Impact" leicht ersichtlich ist.

Insgesamt ist /e/ ein spannendes Projekt. Die Idee Android von Google zu befreien aber ohne jenen asketischen Ansatz, der vielen anderen vergleichbaren Projekten eigen ist, hat etwas für sich. Das Ziel ist somit quasi nicht viel weniger als der Nachbau des proprietären Google-Universums mit freien Diensten und freier Software. Die Leistung von /e/ besteht darin dies klug zu bündeln und dem Anwender möglichst leicht zu machen. Damit widmet sich /e/ einem Problem, an dem ich mich hier im Blog bereits das ein oder andere Mal abgearbeitet habe (siehe: Warum Linux in einer vernetzten Welt einfach keinen Komfort bietet!).

Vermutlich sind solche Ansätze auf Android aufbauend etwas für Privatsphäre und Datenschutz zu entwickeln deutlich fruchtbarer, als langwierige Sonderwege, die mit hoher Wahrscheinlichkeit nie wirkliche Marktreife erringen (siehe: Purism Librem 5 - Bestenfalls eine Experimentalstudie).

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay

Wurde früher unter Debian oder Ubuntu ein Paket installiert, so wurde das Kommando apt-get dazu genutzt:

apt-get install mc

Seit Ubuntu 14.04 gibt es neben den Kommandos rund um apt-get, das Kommando apt. Ab Ubuntu 16.04 wurde offiziell empfohlen apt anstatt von apt-get und apt-cache zu nutzen. Da stellt sich natürlich die Frage wie sich die Kommandos voneinander unterscheiden? Bei den alten Kommandos musste für die Paketverwaltung mit apt-get und apt-cache gearbeitet werden, je nachdem welche Operation benötigt wurde. Die Installation wurde mit apt-get install vorgenommen. Für eine Suche über die Pakete wurde stattdessen apt-cache benötigt:

apt-cache search mc

Mit dem damals neu eingeführten Kommando apt gibt es nun ein einheitliches Interface für die Paketverwaltung:

apt install mc
apt search mc

Neben der Vereinheitlichung, bietet apt einige weitere Vorteile, so kann unter anderem der Fortschritt einer Operation angezeigt werden.

apt zeigt unter anderem den Fortschritt der Operation an

Im Grunde ist apt eine Zusammenführung der am häufigsten genutzten Kommandos zur Paketverwaltung unter einem Kommando. Bestimmte obskure Low-Level-Operationen, welche bei apt-get und apt-cache noch zu finden waren, wurden bei apt zugunsten der Benutzbarkeit weggelassen. Zusätzlich dazu sind die Standardeinstellungen von apt sinnvoller gesetzt.

Zu den häufigen Aufgaben eines Sysadmins gehört sicherlich die Suche nach der Nadel im Heuhaufen besser bekannt als Logfiles.
Seien es System Logs, Mail Logs oder Firewall Logs, meist gilt es eine Fehlermeldung zu finden oder andere Unstimmigkeiten zu entdecken.
Standardwerkzeuge sind da meist tail -f oder tailf, grep, cat, less und wie sie alle heißen. 

Logfile Navigator (lnav)

Einen weitaus einfacheren Umgang bietet lnav. Dank des Tools kann schnell mit Hilfe von Syntax Highlighting durch Massen an Log Files navigiert werden.
Tastaturbefehle ermöglichen zusätzlichen Komfort, aber zunächst muss das Tool installiert werden, da es nicht zu den vorinstallierten Paketen eines Servers gehört.

#Debian
sudo apt install lnav


#CentOS
sudo yum install lnav


#SuSE
sudo zypper install lnav

Nach der Installation lässt sich das Logfile Navigator einfach öffnen.

lnav

oder

journalctl -f | lnav

Der lnav Befehl öffnen standardmäßig Syslog (/var/log/syslog) .

Wer archivierte Logs einbinden möchte, der setzt hinter den gewünschten Pfad noch einen Stern.

lnav /var/log/mail.log*

Der Navigator unterstützt nahezu jedes Logformat und erlaubt nebenbei die Einbindung eigener Formate. Wie dies funktioniert ist hier beschrieben.

Natürlich lassen sich Logfiles auch kombinieren.

lnav /var/log/mail.log /var/log/syslog

Die Log Navigation

Neben der Einbindung der Log Archive hat lnav den großen Vorteil, dass es Hotkeys unterstützt.

Hiervon gibt es ebenfalls eine schöne Übersicht, allerdings möchte ich die "besten" hier sofort aufzeigen:

24 Stunden vor oder zurück

d oder Shift + d

Suche und Navigation

/gesuchter Begriff

Nächster Suchtreffer

n oder Shift + n 

Warnungen suchen

w oder Shift + w

Fehlermeldungen suchen

e oder Shift + e

(rot hervorgehoben)

Logzusammenfassung (Histogramm anzeigen)

Diese bietet einen guten Überblick über mögliche Fehlermeldungen und deren Häufigkeit.

i oder verlassen mit Shift + i

Innerhalb der Zusammenfassung kann ebenfalls zwischen den Zeiteinheiten navigiert werden

z oder Shift + z

Pretty Print View

Sollte der Überblick fehlen und eine etwas andere Aufteilung notwendig sein, bietet sich dieser Modus an.

p  oder Shift + p

Beenden

q

Fazit

Um die Suche nach Warnings und Errors zu verbessern setzt lnav an den richtigen Stellen die richtigen Funktionen und verkürzt damit den Weg zum Ziel ungemein.
Lediglich das Syntax Highlighting (blau auf schwarz) ist manchmal etwas unglücklich.

Diese Frage hat mich heute Morgen beschäftigt, als mich Gnome mit einer Notiz "wichtige Aktualisierungen sind verfügbar" (leider keinen Screenshot gemacht) darauf aufmerksam machte und mir die Wahl zwischen "nicht jetzt" und "Ja, aktualisieren" ließ.

Na klar, wollte ich das mal ausprobieren, also auf "Ja" geklickt.

Dann kam der Hinweis, das dazu der Rechner rebootet werden muss.

WTF? Das hat mich dermaßen geschockt, dass ich erneut den Screenhot vergaß.

Also habe ich gesagt, "OK".

Was dann kam hat mich doch sehr überrascht. Es wurde sofort der Shutdown eingeleitet auf halben Wege  wurden dann die Pakete installiert und danach fuhr der Rechner  weiter mit dem Reboot fort.

Jetzt gab es auf dem Desktop diese Nachricht.

Hiervon habe ich einen Screenshot gemacht.

Es war ja schon lange in der internen Diskussion bei Debian, über das Für und Wider von automatischen Installationen.

Aus Sicht eines einfachen, evtl. von Windows migrierten Anwenders vielleicht gar nicht die schlechteste Idee.

Abschalten oder einfach ignorieren, bis man es dann selber macht kann man es ja trotzdem.

Doch ich bin besonders verblüfft über die Art und Weise. Ist der Reboot nun obligatorisch? Hoffentlich nicht, das wäre dann wirklich eine Verschlechterung. Bisher war das meiner Meinung nach eins der wichtigsten Argumente Linux anstelle Windows für die tägliche Arbeit zu benutzen. Wenn ich sehe wie häufig Windows Systeme wegen einer Software Aktualisierung reboot werden müssen....

Ps: ich suche nochmal die Pakete raus, die aktualisiert wurden,  es war vermutlich etwas dabei, das einen Reboot erfordert.

Nachtrag: Ja, diese Pakete waren betroffen. U.a. der Kernel.

Start-Date: 2019-08-14  08:38:35
Commandline: packagekit role='update-packages'
Upgrade: libpangoft2-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangoft2-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), linux-libc-dev:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chrome-remote-desktop:amd64 (76.0.3809.21, 76.0.3809.117), libgs9:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-image-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), gir1.2-pango-1.0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium-sandbox:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), chromium-common:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), pango1.0-tools:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangoxft-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango1.0-dev:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangocairo-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangocairo-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), ghostscript:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-headers-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 
4.19.37-5+deb10u2), libgs9-common:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-kbuild-4.19:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
linux-headers-4.19.0-5-common:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), libpango-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1)
End-Date: 2019-08-14  08:39:21

Die alte Variante gefiel mir besser, es wurde einfach eine Marker Datei " /var/run/reboot-required" angelegt.

Bei einem Server ist es vermutlich immer noch so, aber auch so mancher Entwickler wird sich ärgern, wenn er durch ein leichtfertiges "Ja" seine gesamte Palette an gestarteten Programmen schwinden sieht und er alles wieder einzeln öffnen muss.

Nun Gut, das passiert nur ihm sicher nicht nochmal... 

Zum nachlesen 

https://anarc.at/blog/2016-12-22-debian-considering-automated-upgrades/

https://www.pro-linux.de/news/1/24312/debian-diskutiert-%C3%83%C2%BCber-automatische-aktualisierung-als-standard.html

Nachtrag 18.8.2019:

So, wieder wird mir von gnome eine notwendige Betriebssystem Aktualisierung angezeigt.

Auch hier blau hervorgehoben, im Hintergrund noch gerade erkennbar wird von Neustart geredet.

Diesmal ist kein Kernel Update und auch die Libs sehen für mich nicht so auss, als wäre ein Neustart notwendig.

Also kurzerhand in der Console apt update und full-upgrade gemacht.

Es wird kein /var/run/reboot-required  angelegt, also ist kein Reboot aus Sicht des Packagemanagers notwendig, dennoch wurde der Anwender von der Notwendigkeit, (siehe links) infomiert.

Erschwehrend kommt ja noch hinzu, dass man, wenn man ok gesagt hat ja den Neustart nicht mehr aufhälten kann. Das macht Windows besser (Oh Gott, dass ich das mal sage ..), denn dort wird installiert und man bekommt die Option den Neustart später zu machen.

Fazit für mich, ich inoriere die GUI Benachrichtigung und mache es weiterhin in der Console, wenn es mir passt.

Das Kommandzeilentool screen ist praktisch, da Prozesse, welche mittels screen gestartet wurden, auch nach dem Logout weiter laufen. Problematisch ist es, wenn ein Prozess ohne screen gestartet wurde und er nachträglich in screen überführt werden soll. Hierfür wird das Tool reptyr benötigt:

apt install reptyr

Mithilfe von reptyr ist es möglich eine Anwendung an ein neues Terminal zu binden. Um nun einen Prozess zu screen zu überführen, muss erst einmal eine neue screen-Instanz gestartet werden:

screen bash

Sobald die Instanz geöffnet wurde, kann der eigentliche Prozess neu zugewiesen werden:

reptyr PID

PID ist hierbei die Prozess-ID, welche sich mittels des ps-Kommandos ermitteln lässt. Alternativ kann dafür auch top oder htop genutzt werden. Damit wurde die Terminalsitzung und mit ihr der laufende Prozess in die screen-Sitzung überführt.

Vor einigen Wochen gab mein Homeserver endgültig den Dienst auf. Eine Reparatur ist zwar möglich aber da fast alle elementaren Bestandteile an die 10 Jahre alt sind und die Energieeffizienz bestenfalls durchwachsen ist habe ich mich für eine Neuanschaffung entschieden. Klassische Homeserver gibt es allerdings kaum noch, daher geht die Tendenz in Richtung NAS. Nur ist auch hier die Auswahl groß.

Mein Anforderungsprofil ist ziemlich gewöhnlich. Neben der obligatorischen Funktion als Datengrab und Sicherungsziel für meinen Mac (beides SMB) sollte das Gerät genug Leistungsreserven haben um den ein oder anderen Dienst - z. B. TT-RSS, Nextcloud oder Äquivalente - zu betreiben. Vom Speicherplatz reichen mir zwei Festplatten im RAID 1 Verbund. Problematisch ist eher das Budget, denn ohne Festplatten möchte ich nicht mehr als 250 - 300 € ausgeben.

Neben NAS-Eigenbaulösungen (die Gehäuse haben leider einen unterirdischen WAF) kommen noch proprietäre Lösungen von QNAP und Synology in Frage. Eigenbau-Lösungen befriedigen zwar den Tüftler in mir, aber freie Zeit hat man mit zunehmendem Alter leider immer weniger und die Testberichte für Synology lesen sich gut.

Konkret kämen wohl in Frage Synology DiskStation DS218 (ohne j, + oder play) oder QNAP Systems TS-231P2.

So richtig entschieden habe ich mich aber noch nicht, weil proprietäre Lösungen (wenn auch auf Linux-Basis) in einem Bereich in dem Linux so gut aufgestellt ist irgendwie einen schalen Beigeschmack haben.

Daher meine Frage: Was setzt ihr denn so zu Hause als NAS bzw. Homeserver ein?

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Android beherrscht den Smartphone-Bereich. Ausgelieferte Geräte sind aber fest mit zahlreichen Google-Diensten und weiteren proprietären Hersteller-Apps verbunden. Das Basissystem von Android ist allerdings Open Source und wird im so genannten Android Open Source Project (AOSP) zur Verfügung gestellt. Zusätzlich kann man das Smartphone auch rooten.

Das Android Smartphone zu rooten ist ein Schlagwort unter dem im Internet alles mögliche kursiert. Viele bezeichnen damit das Entsperren des Bootloaders oder die Verwendung einer Custom Rom. Beides ist aber problemlos ohne Root-Zugriff möglich und umgekehrt kann man auch eine Stock Rom eines Herstellers rooten.

Root-Rechte auf dem Smartphone sind - falsch eingesetzt - ein erhebliches Sicherheitsrisiko. Daher sollte man beim installieren einer Custom Rom wie LineageOS davon absehen automatisch und quasi nebenbei das System zu rooten. Erst wenn man wirklich vor dem Problem steht für eine Aktion oder eine App Root-Rechte zu benötigen sollte man dies machen. Es lässt sich jederzeit nachträglich vornehmen.

Dazu lädt man via LineageOS das passende Paket von AddonSU herunter. Wenn man sich nicht sicher ist kann man auf der Install-Seite des eigenen Geräts nachschauen welche Architektur richtig ist.

Anschließend bootet man in die Recovery wo unter Installation das Archiv im Verezichnisbaum gesucht, ausgewählt und installiert wird.

Nach einem Neustart kann man unter Einstellungen -> System -> Erweitert -> Entwickleroptionen den Root-Zugriff steuern. Zudem lässt sich überprüfen welche Apps Root-Zugriff haben.

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Android beherrscht den Smartphone-Bereich. Ausgelieferte Geräte sind aber fest mit zahlreichen Google-Diensten und weiteren proprietären Hersteller-Apps verbunden. Das Basissystem von Android ist allerdings Open Source und wird im so genannten Android Open Source Project (AOSP) zur Verfügung gestellt. Dieses besitzt aber keinen App Store, weshalb die Einbindung von F-Droid unumgänglich ist.

Das zentrale Element eines Smartphones ist eigentlich der App Store. Ohne diesen ist das Gerät eigentlich nur ein per Touchgesten bedienbares Featurephone. Genau aus diesem Grund hat Google seinen eigenen Store aus dem freien System ausgenommen und bündelt die Lizenzierung an Bedingungen. Hierüber verhindern sie konkurrierende Android-Ökosysteme anderer Hersteller, was zuletzt auch die EU-Kommission auf den Plan gerufen hat (siehe: Kommentar: Strafe gegen Google - Chancen für freiere Systeme).

Es gibt einige alternative App Stores für Linux. Unter dem Gesichtspunkt eines vertrauenswürdigen Systems bleibt aber eigentlich nur F-Droid. Dabei handelt es sich um einen Katalog freier Software für Android, der durch eine App mit den gleichen Funktionen wie ein normaler Store ausgeliefert wird. Das bedeutet über die F-Droid App lassen sich Apps installieren und aktualisieren, sowie neue Apps suchen.

F-Droid funktioniert dabei ähnlich wie viele Linux Distributionen. Die Entwickler der Apps stellen ihre Programme (in der Regel) nicht selbst in der den Store, sondern Maintainer sind für die Apps verantwortlich. Das bringt leider auch alle Nachteile mit sich, die man von Linux kennt. Insbesondere verzögerte Updates können bei manchen Paketen ein echtes Problem sein.

F-Droid ist ebenso wie der Play Store zudem das zentrale Verwaltungselement. Schwachstellen in der F-Droid-App selbst oder nicht erkannte Schwachstellen in den ausgelieferten Apps sind eine direkte Bedrohung für den Anwender.

Installation von F-Droid

Die Installation erfolgt direkt über den Browser von LineageOS. Dieser muss dazu kurzzeitig das Recht bekommen ungeprüft Apps zu installieren. Via Apps & Benachrichtigungen -> Erweitert -> Spezieller App-Zugriff kann man über die Schaltfläche Unbek. Apps installieren dem Browser als Quelle vertrauen.

Anschließend lädt man via F-Droid die APK Datei herunter und installiert diese.

Nun nimmt man dem Browser unbedingt und sofort wieder das Recht Apps zu installieren. Nach der Installation von F-Droid sollte nur der F-Droid Store selbst das Recht dazu haben.

Benutzung von F-Droid

F-Droid verhält sich wie ein normaler App Store, vergleichbar mit Google Play oder dem iOS App Store. Man kann Apps suchen, installieren und aktualisieren. Nach dem ersten Start richtet man via Optionen -> Paketquellen die verfügbaren Quellen ein.

Zusätzlich kann man festlegen ob lediglich WLAN genutzt oder auch der Mobilfunk-Traffic in Anspruch genommen werden darf. Hinzu kommen die Möglichkeit den Aktualisierungs-Intervall festzulegen, Benachrichtigungen zu erlauben und speziellere Funktionen wie den Download via Tor/Orbot. Die Standardeinstellungen sind hier bereits recht gut gewählt.

Wer bisher bereits viel mit freien Apps gearbeitet hat wird relativ schnell fündig werden. Die mitgelieferten Apps von LineageOS bieten eine gute Basis, die man eigentlich nur Ergänzen muss.

Ein paar kleine Tipps für einige Bereiche seien hier dennoch aufgelistet:

• Cloud: Nextcloud
• Browser: Tor Browser (leider noch nicht via F-Droid)
• E-Mail: K9 E-Mail
• Mobilität: Transportr
• Multimedia: VLC
• DAV-Synchronisation: DAVx
• Karten/Navigation: OsmAnd

Die Auswahl ist nicht sonderlich groß und einige wichtige Sachen fehlen. Neben den ganzen proprietären Apps sind dies z. B. auch Signal und momentan auch Tor. Hier muss man dann ggf. den Aufwand der manuellen Installation via APK-Datei auf sich nehmen.

Es gibt noch einige andere Stores, unter anderem mit der Möglichkeit quasi am offiziellen Weg vorbei sich bei Google Play zu bedienen (Yalp). Dies möchte ich hier aber nicht offiziell empfehlen, weil es rechtlich eine Grauzone ist und dem eingangs beabsichtigten Ziel ein vertrauenswürdiges System zu haben widerspricht. Wer pragmatischer in Richtung Alltagstauglichkeit gehen möchte ist mit einem iPhone vermutlich besser bedient, als mit einem Android System - gleich ob mit Google oder ohne.

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Android beherrscht den Smartphone-Bereich. Ausgelieferte Geräte sind aber fest mit zahlreichen Google-Diensten und weiteren proprietären Hersteller-Apps verbunden. Das Basissystem von Android ist allerdings Open Source und wird im so genannten Android Open Source Project (AOSP) zur Verfügung gestellt. Hier gibt es viel Auswahl, besonders populäre ist LineageOS.

Im Grunde genommen kann jeder auf Basis von AOSP ein eigenes Betriebssystem - genannt ROM - kreieren. Insbesondere in den Anfangsjahren von Android war das ein sehr volatiles Umfeld und Hypes kommen und gingen. In den letzten Jahren ist das Ökosystem stabiler geworden und mit LineageOS - hervorgegangen aus CyanogenMod - hat sich eine verbreitete und aktiv entwickelte Lösung abgesetzt. Natürlich gibt es immer noch viele andere Varianten, die teilweise mit findigen Extras auf sich aufmerksam machen, bei manchen Smartphones existieren zudem Sonderlösungen, aber meist ist LineageOS eine gute Wahl.

Obligatorisch weise ich zudem darauf hin, dass die folgende Anleitung von mir auf meinem Smartphone getestet wurde. Andere Hardware-Konstellationen und/oder Bedienfehler können das Gerät jedoch unter Umständen unbrauchbar machen. Ich übernehme daher keine Haftung wenn ihr die folgenden Schritte umsetzt.

Die Installation einer alternativen ROM führt zu einem Wipe (Zurücksetzen) des Systems. Sofern sich Daten auf dem Gerät befinden, sind diese vorab zu sichern.

Die Installation erfolgt via Recovery. Daher muss das Smartphone zuerst in die Recovery gebootet werden. Entweder per Modell-spezifischer Tastenkombination oder via ADB:

$ adb reboot recovery

In der TWRP Recovery kann man zuerst in den Einstellungen die deutsche Lokalisierung vornehmen. Anschließend ruft man die Schaltfläche Löschen auf. Dort wählt man zuerst Daten formatieren. Ist der Vorgang abgeschlossen ruft man Erweitertes löschen auf und löscht hier die Cache und System Partition.

Anschließend wählt man via Erweitert ADB Sideload. Hierdurch kann man das heruntergeladene LineageOS-System vom Desktopsystem an das via USB-Kabel angeschlossene Smartphone schicken.

$ adb sideload <dateiname.zip>

Ist der Sideload-Vorgang erfolgreich absolviert kann man das System via Neustart booten. Hier ist Geduld gefragt, da der erste Start je nach Hardware relativ lange dauern kann.

Anschließend begrüßt einen ein sehr schlankes AOSP im LineageOS-Gewand. Es sind keine dezidierten Google-Dienste vorinstalliert. Allerdings auch kein App Store und die vorinstallierten Apps decken gerade das notwendige Mindestmaß ab.

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Android beherrscht den Smartphone-Bereich. Ausgelieferte Geräte sind aber fest mit zahlreichen Google-Diensten und weiteren proprietären Hersteller-Apps verbunden. Das Basissystem von Android ist allerdings Open Source und wird im so genannten Android Open Source Project (AOSP) zur Verfügung gestellt. Zuerst benötigt man aber eine freie Recovery-Lösung

Voraussetzung um eine freie Recovery-Software aufzuspielen ist ein entsperrter Bootloader. Die Methoden dazu unterscheiden sie je nach Hersteller. Manche machen es einem leicht, manche zwingen einen zu dubiosen Lösungen. Im jeweiligen Forum von XDA Developers zum verwendeten Gerät wird man in der Regel fündig werden.

In diesem Zusammenhang sei allerdings darauf verwiesen, dass die Auswirkungen einer Entsperrung und der Verwendung eines alternativen Recovery-Systems auf Garantie und Gewährleistung immer noch nicht abschließend juristisch geklärt sind. Sollte man auf beides Wert legen empfehle ich von einem Fortfahren hier abzusehen.

Obligatorisch weise ich zudem darauf hin, dass die folgende Anleitung von mir auf meinem Smartphone getestet wurde. Andere Hardware-Konstellationen und/oder Bedienfehler können das Gerät jedoch unter Umständen unbrauchbar machen. Ich übernehme daher keine Haftung wenn ihr die folgenden Schritte umsetzt.

Die Installation einer alternativen Recovery-Software führt zu einem Wipe (Zurücksetzen) des Systems. Sofern sich Daten auf dem Gerät befinden, sind diese vorab zu sichern.

Meisten wird einem TWRP (Team Win Recovery Project) als freie Recovery Lösung empfohlen. Um diese aufzuspielen kann man entweder eine App installieren oder ADB (Android Debug Bridge) und Fastboot verwenden. TWRP empfiehlt zwar die offizielle App, aber ADB/Fastboot sind hilfreiche Lösungen um Android Smartphones zu verwalten, weshalb ich persönlich beides vorziehe.

Werkzeuge einrichten

Die Installation variiert je nach Betriebssystem. ADB und Fastboot sind in den Paketquellen vieler Distributionen enthalten und lassen sich daher unter Linux einfach installieren. Bei Debian, sowie Ubuntu und allen Derivaten geht dies via

$ sudo apt-get install adb fastboot

Windows-Nutzer müssen die Android-Tools bei Google herunterladen. Gleiches gilt für macOS-Anwender, die hier ebenfalls die Tools laden können. Bei beiden Systemen genügt es das Paket zu entpacken.

Im weiteren Verlauf genügt es für Linux-Anwender die Kommandos in einer Bash-Konsole zu verwenden, da sie systemweit zur Verfügung stehen. Windows- und macOS-Anwender müssen zuerst in der Shell in den entsprechenden Ordner navigieren.

Smartphone vorbereiten

In den Einstellungen müssen zuerst die Entwickleroptionen freigeschaltet werden. Dazu muss man 7 mal auf die Build-Nummer klicken. Diese findet man beiden meisten Hersteller-Roms in den Informationen Über das Telefon. Anschließend kann man die Entwickleroptionen in den Einstellungen aufruhen. Auch hier unterscheidet sich der Ort je nach Hersteller Rom aber befindet sich meist unterhalb von System. Hier aktiviert man Android bzw. USB Debugging.

Anschließend schließt man das Smartphone per USB-Kabel an den PC an. Das Smartphone fragt nun ab, ob der PC für USB-Debugging authorisiert werden soll, was man bestätigt.

Der folgende Befehl sollte nun das angeschlossene Smartphone zeigen:

$ adb devices

TWRP installieren

Nun bootet man das Smartphone in den Bootloader. Ein kleiner Hinweis für macOS-Anwender. Hier muss ein ./ vorangestellt werden, da ansonsten die Android Tools nicht gefunden werden. Der Befehl lautet dann z. B. $ ./adb reboot bootlader.

$ adb reboot bootloader

Anschließend startet das Smartphone in den Fastboot-Modus. Unten sollte mittig nun auch der Hinweis stehen, dass der Bootloader entsperrt ist.

Nun installiert man die Recovery-Lösung von TWRP. Diese muss dazu von der Homepage heruntergeladen werden. Im Beispiel befindet sich die Image-Datei im aktuell ausgewählten Shell-Pfad.

$ fastboot flash recovery twrp.img

Mittels folgendem Befehl rebootet man nun zurück in das zurücksetzte System.

$ fastboot reboot

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Android beherrscht den Smartphone-Bereich. Ausgelieferte Geräte sind aber fest mit zahlreichen Google-Diensten und weiteren proprietären Hersteller-Apps verbunden. Das Basissystem von Android ist allerdings Open Source und wird im so genannten Android Open Source Project (AOSP) zur Verfügung gestellt. Anwender haben dadurch die Möglichkeit ein freies System zu betreiben.

Eigentlich bin ich Android gegenüber eher kritisch eingestellt. Das System ist zwar in der Basis frei, aber die Entwicklung widerspricht dem wichtigen Community-Gedanken. Google wirft alle paar Monate der Community einfach eine mehr oder minder lauffähige neue Version vor die Füße. Die enge Anbindung an Google (siehe auch die Serie: Android - Keine sichere Alternative!) behindert die freie Weiterentwicklung von Android. Wie mächtig Google hier ist hat die jüngste Affäre um Huawei gezeigt (siehe: Google sperrt Huawei aus - Zum Zustand von Android). Wichtige Bestandteil für das was heute ein Smartphone ausmacht - vor allem das App-Ökosystem - hält Google in proprietären Diensten vor, weshalb AOSP-Systeme bessere Feature-Phones sind (siehe: Android ohne Google Play - Featurephone mit Touchscreen).

Normalerweise empfehle ich daher für den Alltag ein iPhone. Das System ist zwar hochgradig geschlossen, Apple positioniert sich aber eindeutig für Datenschutz und Privatsphäre. Außerdem gibt es lange Supportzeiträume für die Geräte. Daher sind iPhones ein guter Kompromiss zwischen Alltagstauglichkeit und Datenschutz. Die Probleme von Android sind nämlich nicht nur auf Google zurückzuführen, sondern es gibt ernste Probleme mit der Sicherheit des System und dem ausrollen von Sicherheitsupdates für alle Anwender. Wenn man sich die monatlichen Patches anschaut kann man einige neuralgische Punkt identifizieren, die permanent Sicherheitsprobleme verursachen.

Doch was wenn man für bestimmte Einsatzszenarien ein Gerät haben will, dem man wirklich vertraut? Apples iPhone kann dies aufgrund der Verzahnung mit Apple-Diensten und der proprietären Software nicht bieten. Andere freie Systeme gibt es faktisch nicht (siehe: Freie Mobilbetriebssysteme - Ein Trauerspiel). Es bleibt daher nur ein freies Android.

In der kommenden Serie möchte ich daher zeigen wie man ein Smartphone mit einer freien Recovery-Lösung wie TWRP versorgt und ein Custom Rom aufspielt. Hinzu kommen im Anschluss noch weitere notwendige Änderungen, da auf Custom Roms Google nur unzureichend aussperren.

Für einen solchen Einsatzzweck eignet sich eigentlich jedes Smartphone, das LineageOS in seiner unterstützten Liste führt. Für jedes Budget und die meisten Leistungsanforderungen dürfte da etwas dabei sein. Inoffizielle Portierungen auf XDA-Developers gibt es zwar auch für andere Geräte, aber wenn man sich für ein solches Unterfangen ein neues Gerät anschafft kann man sich diese Unsicherheit leicht ersparen.

Es gibt einige, die meinen, dass man bei Smartphones mit Fokus auf Datenschutz und Privatsphäre auf so genannte China-Phones, wie die von Xiaomi verzichten sollte. Dahinter steht ein grundlegendes Misstrauen gegen mögliche Backdoors aus Fernost. Sofern man mit der Stock Rom der Hersteller arbeiten möchte kann ich diese Sichtweise verstehen, da hier in der Vergangenheit immer mal wieder ungewollte Datenübertragungen berichtet wurde. Sofern man aber sowieso auf ein AOSP-Rom wechseln möchte ist das unreflektierte Panikmache. Natürlich gibt es das Risiko von Backdoors im Hardware- oder Firmware-Bereich, was leider auch bei AOSP erhalten bleibt. Es gibt aber kaum einen Hersteller von Smartphones, dem man hier bedingungslos vertrauen darf, da alle ihre Geräte in Ländern mit geringer Transparenz und Rechtsstaatlichkeit produzieren lassen. Hier sollte man sich also nicht von Gerüchten aus US-Geheimdienstkreisen wie beispielsweise im Fall Huawei verrückt machen lassen.

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Android beherrscht den Smartphone-Bereich. Ausgelieferte Geräte sind aber fest mit zahlreichen Google-Diensten und weiteren proprietären Hersteller-Apps verbunden. Das Basissystem von Android ist allerdings Open Source und wird im so genannten Android Open Source Project (AOSP) zur Verfügung gestellt. Anwender haben dadurch die Möglichkeit ein freies System zu betreiben.

Eigentlich bin ich Android gegenüber eher kritisch eingestellt. Das System ist zwar in der Basis frei, aber die Entwicklung widerspricht dem wichtigen Community-Gedanken. Google wirft alle paar Monate der Community einfach eine mehr oder minder lauffähige neue Version vor die Füße. Die enge Anbindung an Google (siehe auch die Serie: Android - Keine sichere Alternative!) behindert die freie Weiterentwicklung von Android. Wie mächtig Google hier ist hat die jüngste Affäre um Huawei gezeigt (siehe: Google sperrt Huawei aus - Zum Zustand von Android). Wichtige Bestandteil für das was heute ein Smartphone ausmacht - vor allem das App-Ökosystem - hält Google in proprietären Diensten vor, weshalb AOSP-Systeme bessere Feature-Phones sind (siehe: Android ohne Google Play - Featurephone mit Touchscreen).

Normalerweise empfehle ich daher für den Alltag ein iPhone. Das System ist zwar hochgradig geschlossen, Apple positioniert sich aber eindeutig für Datenschutz und Privatsphäre. Außerdem gibt es lange Supportzeiträume für die Geräte. Daher sind iPhones ein guter Kompromiss zwischen Alltagstauglichkeit und Datenschutz. Die Probleme von Android sind nämlich nicht nur auf Google zurückzuführen, sondern es gibt ernste Probleme mit der Sicherheit des System und dem ausrollen von Sicherheitsupdates für alle Anwender. Wenn man sich die monatlichen Patches anschaut kann man einige neuralgische Punkt identifizieren, die permanent Sicherheitsprobleme verursachen.

Doch was wenn man für bestimmte Einsatzszenarien ein Gerät haben will, dem man wirklich vertraut? Apples iPhone kann dies aufgrund der Verzahnung mit Apple-Diensten und der proprietären Software nicht bieten. Andere freie Systeme gibt es faktisch nicht (siehe: Freie Mobilbetriebssysteme - Ein Trauerspiel). Es bleibt daher nur ein freies Android.

In der kommenden Serie möchte ich daher zeigen wie man ein Smartphone mit einer freien Recovery-Lösung wie TWRP versorgt und ein Custom Rom aufspielt. Hinzu kommen im Anschluss noch weitere notwendige Änderungen, da auf Custom Roms Google nur unzureichend aussperren.

Für einen solchen Einsatzzweck eignet sich eigentlich jedes Smartphone, das LineageOS in seiner unterstützten Liste führt. Für jedes Budget und die meisten Leistungsanforderungen dürfte da etwas dabei sein. Inoffizielle Portierungen auf XDA-Developers gibt es zwar auch für andere Geräte, aber wenn man sich für ein solches Unterfangen ein neues Gerät anschafft kann man sich diese Unsicherheit leicht ersparen.

Es gibt einige, die meinen, dass man bei Smartphones mit Fokus auf Datenschutz und Privatsphäre auf so genannte China-Phones, wie die von Xiaomi verzichten sollte. Dahinter steht ein grundlegendes Misstrauen gegen mögliche Backdoors aus Fernost. Sofern man mit der Stock Rom der Hersteller arbeiten möchte kann ich diese Sichtweise verstehen, da hier in der Vergangenheit immer mal wieder ungewollte Datenübertragungen berichtet wurde. Sofern man aber sowieso auf ein AOSP-Rom wechseln möchte ist das unreflektierte Panikmache. Natürlich gibt es das Risiko von Backdoors im Hardware- oder Firmware-Bereich, was leider auch bei AOSP erhalten bleibt. Es gibt aber kaum einen Hersteller von Smartphones, dem man hier bedingungslos vertrauen darf, da alle ihre Geräte in Ländern mit geringer Transparenz und Rechtsstaatlichkeit produzieren lassen. Hier sollte man sich also nicht von Gerüchten aus US-Geheimdienstkreisen wie beispielsweise im Fall Huawei verrückt machen lassen.

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Mozilla hat mit Firefox 68.0.2 das zweite Update für Firefox 68 veröffentlicht.

Download Mozilla Firefox 68.0.2 für Windows, Apple macOS und Linux

Eine Folge der in Firefox 68 geschlossenen Sicherheitslücken ist, dass über das file://-Protokoll geladene lokale Dateien nicht länger auf andere Dateien im gleichen Verzeichnis zugreifen können. Mit Firefox 68.0.2 hebt Mozilla diese Einschränkung für lokal eingebundene Schriften auf. Diese Änderung betrifft ebenfalls die Android-Version mit dem Update auf Firefox 68.0.2 für Android.

Weiter hat Mozilla einen Fehler in der mit Firefox 68 eingeführten Neu-Implementierung der Adressleiste behoben, der dafür sorgte, dass Spezial-Zeichen, welche zum Filtern in der Adressleiste genutzt werden können (#, $, %, ^, *, ?, +, %), fälschlicherweise vom Ende von Suchbegriffen entfernt worden sind.

Ein weiterer Fehler, den Mozilla behoben hat, ist, dass manche Grafiken unter bestimmten Umständen beim Neuladen der Website nicht angezeigt worden sind. Dies hat unter anderem als iFrame eingebundene Karten von Google Maps betroffen.

Der Fehler in der Web-Version von Outlook, dass beim Ausdruck lediglich der Header und der Footer gedruckt worden sind, wurde ebenfalls behoben.

Schließlich wurde noch ein Fehler behoben, welcher dafür sorgte, dass externe Anwendungen, welche über einen benutzerdefinierten URI-Handler gestartet werden, nicht starteten. Dies betraf unter anderem Skype for Business.

Außerdem wurde eine Sicherheitslücke behoben.

Der Beitrag Mozilla veröffentlicht Firefox 68.0.2 erschien zuerst auf soeren-hentzschel.at.

Nach einer kurzen Sommerpause gibt es auf ITrig in unregelmäßigen Abständen wieder ein paar Artikel.

Network Security Toolkit 30

Als einer der wenigen Fedora Vertreter im Bereich der Sicherheitsdistributionen hat NST mit Version 30 eine neue Version des Network Security Toolkit aufgelegt.

Viele Funktionen lassen sich in NST über den Browser bedienen, das sogenannte NST WUI.

Die neueste Version des Web User Interfaces unterstützt neben bekannten Sicherheits- und Netzwerktools die Geolokalisierung von Fotos und Videos.

Eine Untersuchung von Daten wird dank des Exif Tool und den vorhandenen Metadaten mit dem NST Mapping Tools noch einfacher.

Der NST WUI Directory Browser wurde auf diese neuen Funktionalitäten ebenfalls angepasst.

Dazu kamen weitere Änderungen, welche im Changelog nachgelesen werden können.

Parrot Security 4.7 (Beta)

Kleine Meldung zwischendrin. Parrot arbeitet fleißig an Aktualisierungen und hat bereits die nächste Beta veröffentlicht.

BackBox 6.0

Eine weitere Distribution hat ihre Pakete aktualisiert. So arbeitet BackBox nun mit Kernel 4.18.

Dazu wurden die üblichen Updates gefahren, um am Ball zu bleiben.

Kali NetHunter App Store

Für den immer größeren mobilen Bereich stellt Kali Linux nun einen eigenen App Store für seine NetHunter Editionen bereit.

Mit dem letzten Update (2019.2) wurde die Unterstützung auf ganze 50 Geräte erweitert.

Der Store basiert auf dem bekannten F-Droid Store allerdings ohne Telemetrie und bietet Apps aus dem Securitybereich für Android Telefone an.

Natürlich handelt es sich um freie Apps, welche allerdings teilweise ein gerootetes Gerät voraussetzen.

Die Liste der angebotenen Android Anwendungen wächst stetig an:

• aLogcat - View system and app log
• bVNC Pro - Secure, open source VNC client
• ConnectBot - SSH and local shell client
• cSploit - The most complete and advanced IT security professional toolkit on Android
• DriveDroid - Boot your PC from ISO/IMG files stored on your phone
• Hacker's Keyboard - The ultimate virtual keyboard for hackers
• Hash Droid - Verify file integrity
• Hijacker - All-in-one WiFi cracking tools
• Intercepter-NG - Multifunctional network toolkit
• LTE Discovery - Powerful signal discovery and analysis tool
• NetHunter - NetHunter installer, updater, and interface for Kali Linux on Android
• NetHunter Store - NetHunter Store client
• NetHunter Terminal - Kali Linux command line shell
• NetHunter VNC - GUI desktop experience for Kali Linux on Android
• NetHunterStore Privileged Extension - Services to allow NetHunter Store to securely install and update apps
• Nexmon - Install a WiFi firmware that enables monitor mode and frame injection on support
• OONI Probe - Open Observatory of Network Interference (OONI)
• OpenVPN for Android - OpenVPN without root
• Orbot - Proxy with Tor
• PixelKnot - Hide Messages
• RF Analyzer - RF spectrum visualizer for HackRF/RTL-SDR
• Router Keygen - Recover your keys for your wifi network
• Rtl-sdr driver - Allows you to use I/Q packet source in your Android applications.
• Shodan - World's first search engine for Internet-connected devices
• SnoopSnitch - Check mobile network security
• SysLog - Capture log files
• USB Keyboard - Android device as USB keyboard/mouse
• Walrus - Use your existing contactless card cloning devices with your Android device
• WHID Injector - WHID Mobile Connector
• WiGLE WiFi Wardriving - Network observation, positioning, and display client

Welche der Anwendungen root Rechte benötigen müsst ihr den Beschreibungen entnehmen.

Manche Apps, wie zum Beispiel WiGLE WiFi Wardriving können auch klassisch über den Play Store bezogen werden, wenn gewünscht.

Übersicht 08/2019

Die Geolocation-API erlaubt es Webseiten, den Standort des Benutzers zu ermitteln – eine ausdrückliche Erlaubnis des Nutzers vorausgesetzt. Mit Firefox 70 verbessert Mozilla die Transparenz hinsichtlich einer erteilten Geoloaction-Berechtigung.

Die Geolocation-API zur Ermittlung des Standortes, nützlich zum Beispiel bei einem Kartendienst, erfordert zur Aktivierung die ausdrückliche Erlaubnis des Benutzers. Wurde die Berechtigung erteilt, ist diese bis zum Sitzungsende gültig. Dabei ist nicht mehr ersichtlich, dass die Berechtigung noch aktiv ist, und kann, zumindest wenn die Berechtigung nicht dauerhaft erteilt worden ist, auch nicht auf einfache Weise wieder entzogen werden, ohne den Browser neu zu starten.

Das ändert sich mit Firefox 70. Ab dann erscheint in der Adressleiste bei aktiver Geolocation-Berechtigung ein zusätzliches Symbol. Per Klick darauf sieht der Nutzer, wann die Website zuletzt Gebrauch von der Geolocation-API gemacht hat, und kann die Berechtigung mit einem weiteren Klick ganz einfach wieder entziehen.

Firefox 70 erscheint nach aktueller Planung am 22. Oktober 2019.

Der Beitrag Firefox 70 bekommt verbesserte Anzeige der Geolocation-Berechtigung erschien zuerst auf soeren-hentzschel.at.

Mittlerweile finden vier von fünf Anfragen von Firefox-Nutzern verschlüsselt statt. Dementsprechend plant Mozilla Änderungen in Firefox 70, welche die Darstellung von HTTP respektive HTTPS in der Adressleiste betreffen.

Die verschlüsselte Übertragung von Daten im Web gewinnt immer mehr an Bedeutung. Bereits über 79 Prozent aller von Firefox-Nutzern geladenen Webseiten werden über HTTPS anstelle von HTTP übertragen. Auch die unter anderem von Mozilla ins Leben gerufene Certificate Authority (CA) Let’s Encrypt, welche kostenlos Zertifikate für die Nutzung von HTTPS bereitstellt, trägt einen großen Anteil daran.

Damit ist ein Punkt gekommen, an welchem auch die vor Jahren eingeführten Standards hinsichtlich der Darstellung von HTTP und HTTPS in der Adressleiste von den Browserherstellern neu bewertet werden. Die Entwicklung geht allgemein weg von positiven Sicherheits-Indikatoren hin zu negativen Indikatoren für unsichere Seiten, da sichere Seiten mittlerweile die Norm sind. Für Firefox 70 stehen gleich mehrere Änderungen an.

Bisher zeigte Firefox für jede Seite, sowohl HTTP als auch HTTPS, ein „i“-Symbol in der Adressleiste an. Per Klick darauf gelangte man zu den Website-Berechtigungen sowie Anti-Tracking-Einstellungen. Im Falle von HTTPS wurde zusätzlich ein grünes Schloss angezeigt, über welches die gleichen Optionen zugänglich waren.

Mit Firefox 70 wird das „i“-Symbol für alle Seiten gestrichen. Zwar gibt es dann für sämtliche Seiten ein Schild-Icon in der Adressleiste, dieses ist jedoch kein Ersatz für das „i“-Icon, sondern beinhaltet die überarbeiteten Anti-Tracking-Einstellungen, an denen Mozilla ebenfalls für Firefox 70 arbeitet und ein eigenes Thema sind.

Seiten, welche nur über HTTP und nicht über HTTPS erreichbar sind, werden ab Firefox 70 mit einem durchgestrichenen Schloss und damit explizit als unsicher markiert. Bislang gab es eine solche Darstellung für HTTP-Seiten nur, wenn auf der Seite ein Passwort-Feld existierte.

Wem das nicht weit genug geht, der kann über about:config den Schalter security.insecure_connection_text.enabled auf true setzen – dann erscheint neben dem Icon zusätzlich noch der Text „Nicht sicher“. Diese Option existiert bereits seit Firefox 60 und bleibt auch in Firefox 70 standardmäßig abgeschaltet.

Das bisher grüne Schloss-Icon bei HTTPS-Seiten wird ab Firefox 70 grau und damit weniger auffallend. Wer weiterhin ein grünes Schloss haben möchte, kann über about:config den Schalter security.secure_connection_icon_color_gray auf false setzen.

Bei Extended-Validation-Zertifikaten zeigte Firefox bislang neben dem Schloss-Symbol den Namen des Zertifikats-Inhabers direkt in der Adressleiste an. Diese Information, dessen Nutzen umstritten ist, wird mit Firefox 70 aus der Adressleiste entfernt und stattdessen via Klick auf das Schloss-Symbol zugänglich gemacht. Hier kann das alte Verhalten wiederhergestellt werden, indem der Schalter security.identityblock.show_extended_validation in about:config auf true gesetzt wird.

Der Beitrag Firefox 70: Änderung der Darstellung von HTTP und HTTPS in Adressleiste erschien zuerst auf soeren-hentzschel.at.

Mit Firefox 70 führt Mozilla das bereits erwartete neue Firefox-Logo ein. Außerdem nennt Mozilla seinen Browser nicht länger Firefox Quantum, sondern ab sofort Firefox Browser.

Nachdem das neue Firefox-Logo weltweit als erstes bereits im Januar auf diesem Blog zu sehen war und im Juni dann offiziell von Mozilla vorgestellt worden ist, wird Mozilla das neue Branding mit Firefox 70 einführen. Die finale Version von Firefox 70 erscheint nach aktueller Planung am 22. Oktober 2019.

Teil des neuen Brandings ist neben einem neuen Logo und neuer Schriftart für die Wortmarke auch eine Änderung des Produktnamens. Seit der Veröffentlichung von Firefox 57 im November 2017 trägt Firefox den Beinamen Quantum. Firefox 57 stellte die größte Aktualisierung in der bisherigen Geschichte von Firefox dar und der Name Firefox Quantum stand symbolisch für den Quantensprung, den Firefox gemacht hat. Aus Firefox Quantum wird im Oktober Firefox Browser.

Für Nutzer einer Nightly-Version von Firefox ist die Änderung bereits seit heute aktiv.

Dass Mozilla hier von Firefox Browser und nicht einfach nur von Firefox spricht, ergibt viel Sinn in Anbetracht des wachsenden Produkt-Portfolios rund um die Marke Firefox, unter anderem mit Firefox Send, Firefox Monitor und Firefox Lockwise sowie weiteren Produkten in der Zukunft.

Der Beitrag Firefox 70: Aus Firefox Quantum wird Firefox Browser + Neues Logo erschien zuerst auf soeren-hentzschel.at.

Ich bin heute von Stretch auf Buster gewechselt, auf meinem Dektop fehlten jetzt die Icons. Default sind die nicht mehr eingeschaltet bei Gnome 3.30.

Ich habe die gnome-tweaks (in Gnome Sprech=Optimierungen) installiert, damit kann man das steuern.

Das Werkzeug Optimierungen starten und im Abschnitt Erweiterungen die Desktop Icons einschalten. 

Wenn das nicht geht weil das Feld inaktiv ist, dann fehlt sicherlich das Paket gnome-shell-extension-desktop-icons.

Nachinstallieren mit apt install gnome-shell-extension-desktop-icons  und dann läßt es sich einschalten. Schwupps sind die Icons wieder da

Taucht "Optimierungen" gar nicht nicht auf wenn man danach sucht, dann einfach gnome-tweaks installieren mit apt install gnome-tweaks. (oder mit einem anderen Debian Tool)

Ps: Kommentare beachten!

Ich liebe die Suchfunktionalität in Gnome 3, habe ich das schon erwähnt?

Einfach die Meta Taste drücken und anfangen zu tippen ... Einfacher geht es nicht.

Oder mit der Maus ins linke obere Eck fahren, das geht auch.

Hier mal ein thematisch etwas anderer Blogpost. Vor etwas über einem Jahr ließ ich mir eine Photovoltaik-Anlage auf dem Dach des Hauses montieren. Einige Tage nach der Montage ging die Anlage auch an das Stromnetz. Das ist heute auf dem Tag genau ein Jahr her. In diesem Blogpost zeige ich ein wenig, wie mäßig die Software ist, wie man selbst Herr über die Daten wird und wie weit die Schätzungen vom Ertrag von der Realität abweichen.

Die Photovoltaik-Anlage besteht aus 20 Modulen à 335W. Es hat somit eine Peak-Leistung von 6700 Wh. Theoretisch sollte also keine höhere Peak-Leistung bei Idealbedingungen möglich sein, in der Realität sah ich ein paar mal Peak-Leistungen, die darüber lagen.

(Smarter) Wechselrichter

Neben den Modulen, Gestellen, Kabeln und anderen Kleinigkeiten, besteht so eine Photovoltaik-Anlage noch aus einem Wechselrichter, der den Gleichstrom in Wechselstrom umwandelt. Konkret besitze ich einen Kostal PIKO 7.0. Viele der neueren Wechselrichter sind „smart“. Sie besitzen eine LAN-Buchse und kommen also mit Web-Interface und App daher, mit diversen Vor- und Nachteilen, was die Daten angeht, da man diese optional aus der Hand geben kann, was ich tue.

Die Qualität der Software ist allerdings optimierungsbedürftig. Der Wechselrichter erfasst einiges an Daten. Das umfasst unter anderem den aktuellen Stromverbrauch des Hauses, die Generatorleistung (Ertrag) der PV-Module, eine Eigenverbrauchsquote oder ein Einspeisung des Stroms in das öffentliche Netz. Der Wechselrichter sammelt diese Daten für ein paar Stunden und lädt sie in (un)regelmäßigen Abständen innerhalb eines Tages auf den Server vom Anbieter hoch. Mir ist bewusst, dass dadurch der Anbieter Daten hat, um zu sehen, wann etwa die Kaffeemaschine angeschaltet wird, oder wann gekocht wird.

Die hochgeladenen Daten können über die Web-Oberfläche von Kostal oder über die App eingesehen werden. Leider ist hier schon ein Problem da, denn manchmal verschluckt der Wechselrichter scheinbar die Daten und lädt diese nicht zuverlässig hoch. Das führt zu Lücken in den Graphen des Tages und es lässt sich keine zuverlässigen Auswertungen zu. Für den Monat Juli waren etwa an vier Tagen fast keine Daten hochgeladen worden, was die hinterlegte Statistik für die einzelnen Tage/Monat/Jahre verfälscht und unbrauchbar macht.

Die App kann nicht nur die Daten von den Servern laden und mittelmäßig darstellen, sondern auch Live-Daten anzeigen. Dazu muss sich das Handy aber im selben Netzwerk wie der Wechselrichter befinden. Dargestellt wird dann der aktuelle Ertrag der PV-Anlage, die aktuelle Einspeisung ins Netz, der aktuelle Verbrauch des Hauses und Füllstand und Lade/Entlade-Kapazität von einer Batterie. Da ich keine Batterie habe, ist die entsprechend immer bei 0.

Die Qualität der App war auch eher mittelmäßig. Häufig hat die App die Zugangsdaten vergessen und man musste sich diese immer wieder neu eintippen. Auch die grafische Darstellung war eher schlecht, da sich einige Zahlen in den Graphen überlappen, wenn das Smartphone im Hochformat verwendet wird. Prinzipiell praktisch ist hingegen die Möglichkeit pro Stunde, Tag, Woche, Monat und Jahr die Verbrauchs- und Ertragsdaten darstellen zu lassen. Aufgrund der sporadischen Aussetzer war dies mir allerdings auch nicht zufriedenstellend genug.

Neben dem Online-Portal und der App hat der Wechselrichter noch einen Webserver laufen, über den man einige Daten abrufen kann. Dies ist nur im lokalen Netz erreichbar und nutzt dieselbe Schnittstelle, wie die App.

Eigene Datenhaltung

Aufgrund der eher mäßigen Qualität der Software musste also eine eigene Datenhaltung her. Nicht, weil ich unbedingt genaue Daten brauche, sondern weil es geht und weil ich es kann.

Die zuvor angesprochene Web-Oberfläche des Wechselrichters sind lediglich ein paar einfache HTML-Seiten mit JavaScript. Um an die Daten des Wechselrichters zu kommen, musste also ein wenig „Reverse-Engineering“ durchgeführt werden. Das hab ich bewusst in Anführungsstrichen geschrieben, weil das, was ich getan hab, viel zu einfach ist, als es Reverse-Engineering zu nennen.

Der JavaScript Code sendet alle paar Sekunden HTTP-Anfragen an den Wechselrichter, in dem es lange IDs hinschickt und Antworten als Key-Value Paare zurückerhält. Aus den IDs und somit auch Keys der Antworten, lässt sich nicht aus Anhieb erkennen, was für ein Wert das ist. Mit ein wenig logisches Denken, kann man das allerdings sehr schnell mit den Werten aus der Web-Oberfläche verknüpfen. Dazu war auch ein Blick in den Netzwerk-Tab der Web-Konsole hilfreich. Kompliziert war das nicht, eher ein wenig nervige Handarbeit.

Um nun die aktuellen Daten auszulesen, habe ich ein Python-Skript geschrieben, welches anhand der IDs die Daten über die REST-Schnittstelle abruft und in eine PostgreSQL-Datenbank schreibt. Das Skript ist im GitHub-Repository svijee/kostal-dataexporter zu finden. Komplex ist das ganze nicht. Das Skript läuft bei mir innerhalb eines Docker Containers und schreibt es in die Datenbank. Das Skript ist nicht wirklich schön – aber es funktioniert!

Die Daten möchte ich natürlich auch noch visualisieren. Dazu habe ich (natürlich) Grafana im Einsatz, wofür ich ein Dashboard gebaut habe. Zum jetzigen Zeitpunkt hat es allerdings nicht die gleichen Features wie die App bzw. das Web-Portal von Kostal. Ich kann nämlich bislang nur die Daten von einem Tag darstellen und es findet noch keine praktisch-nutzbare Aggregierung der Daten über mehrere Tage, Wochen, Monate oder Jahre statt. Ich kann daher etwa nicht anschauen, wie viel Strom pro Tag oder Woche erzeugt wurde.

In dem Screenshot lässt sich einiges Interessantes herauslesen. Oben links ist der Graph für den Gesamtertrag der Anlage und unten links der Graph für die Einspeisung in das öffentliche Netz. Wie man daraus erkennen kann, läuft der untere Graph gegen eine Grenze bei fast 5 kW. Dies hängt damit zusammen, dass der Netzbetreiber (in meinem Fall Westnetz) für die EEG-Vergütung nur bis zu 70% der Peak-Leistung der Anlage annehmen müssen. Das entspricht bei meiner Anlage eine maximale Leistung bei der Einspeisung von 4690 W. Der Eigenverbrauch des Hauses wird da nicht mit eingerechnet, sodass alles über 70% Leistung reduziert wird, d.h. es eine künstliche Leistungsreduzierung stattfindet, sofern der Strom nicht selbst verwendet wird. Alles über 70% der Peak-Leistung ist somit kostenfreier Strom, da dieser sonst „verpufft“. Aus ökologischer Sicht ist diese 70% Regelung natürlich Unfug, da sauberer Strom künstlich reduziert wird, nur, damit der Netzbetreiber nicht alles an produzierten Strom ankaufen muss. Als PV-Anlagen Betreiber heißt das dann natürlich: Möglichst viel Strom tagsüber verbrauchen.

Zurück zum technischen! Die übrigen Daten, die auf dem Dashboard zu sehen sind, sind alles Daten, die direkt von der REST-Schnittstelle vom Wechselrichter kommen. Viel Magie passiert da also nicht.

Rechts sieht man noch zwei Graphen: den Stromverbrauch im Haus, sowie darunter pro Phase. Letzteres interessiert mich in der Praxis nicht wirklich. Aus dem Stromverbrauch im Haus lassen sich diverse Informationen auslesen. Man erkennt gut, wann der Herd an war und man erkennt häufig auch sehr gut, wenn die Personen im Haushalt aufstehen, da der angeschaltete Wasserkocher ebenfalls erkennbar ist. An Tagen wo keiner zu Hause ist, erkennt man auch sehr gut den laufenden Kühlschrank, der in regelmäßigen Abständen für eine gewisse Zeit kühlt und dann in den Standby wechselt. Für mich zeigte das deutlich, dass man aus diesen Metadaten einiges erkennen kann, was auch ein wesentlicher Kritikpunkt von smarten Stromzählern sind.

Ein weiterer Punkt, der aus dem Graphen zu erkennen ist, dass Nachts keine Erfassung des Stromverbrauchs erfolgt. Dies hängt damit zusammen, dass der Sensor, der den Stromverbrauch des Hauses misst, nur dann läuft, wenn Strom aus der Photovoltaik-Anlage bekommt. Der Hauptzweck des Sensors ist die Berechnung, wieviel Strom in das Netz eingespeist werden kann, wenn gleichzeitig Strom im Haus verbraucht wird. Dies hängt erneut mit der 70% Regelung zusammen. Kostal hält es jedenfalls nicht für notwendig, dass man den Sensor so nutzen kann, dass man 24h den Stromverbrauch im Haus messen kann. Um dies zu ermöglichen, bräuchte ich eine Batterie, die wiederum aktuell noch zu teuer ist.

Auswertung

Spannend war für mich die Auswertung der Daten nach einem Jahr. Die Firma, die mir die Photovoltaik-Anlage montiert hat, hat über ein Programm ausgerechnet, wie hoch die möglichen Erträge für meine Anlage ist. Das war keine einfache Excel-Tabelle (wie sie teilweise andere Firmen genutzt haben), sondern ein Programm, was diverse Faktoren einkalkuliert hat. Darunter die Sonnenstunden der letzten Jahre auf den Koordinaten, den Winkel der Anlage auf dem Dach und der Winkel zur Sonne und mögliche Schattierungen von Bäumen in der Nähe.

Relevant für die Amortisation ist sowohl der Strombedarf für einen selbst, als auch ein möglichst hoher Eigenverbrauch, da dann weniger Strom vom Stromanbieter bezogen werden muss, da dies deutlich teurer ist.

Unser Jahresverbrauch im Vorjahr lag bei uns bei etwa 3800 kWh bei einem 2,5 Personen Haushalt. Dies diente dann als Berechnungsgrundlage für den Amortisierungsplan. Folgende Leistungsdaten berechnete das Programm von der Firma:

• Ertrag der PV-Anlage: 6410 kWh

  • davon 1680 kWh Eigenverbrauch
  • davon 4730 kWh Netzeinspeisung

• Gesamtverbrauch: 3800 kWh

  • davon 1680 kWh durch PV
  • davon 2128 kWh durch Netz

Die Realität ein Jahr später sieht spannend aus:

• Ertrag der PV-Anlage: 7405 kWh (+995 kWh , +13,4%)
  • 1600 kWh Eigenverbrauch (-80 kWh, -5%)
  • 5805 kWh Einspeisung (+1075 kWh, +18,5%)

Der Gesamtverbrauch lag fast genau bei der Schätzung:

• Gesamtverbrauch: 3793 kWh (-8 kWh, -0,01%)
  • 1600 kWh durch PV (-80 kWh, -5%)
  • 2193 kWh durch Netz (+65 kWh, +3%)

Wie man sieht, sind die geschätzten Werte nahezu insignifikant höher oder niedriger als geschätzt, mit einer krassen Ausnahme: der Gesamtertrag der PV-Anlage und somit auch die Einspeisung in das öffentliche Netz. Da schien die Sonne wohl deutlich mehr als die Jahre zuvor.

Und hier noch ein paar Funfacts:

• Der Monat mit dem höchsten Ertrag war der Juni mit über 1000 kWh
  • Photovoltaik-Anlagen arbeiten besser, wenn es kühler ist. Der Juli war deutlich zu heiß, das sieht man deutlich an den Ertragsgraphen
• Der Tag mit dem höchsten Ertrag war der 15. Mai mit 46,4 kWh
  • Die Screenshots oben sind von dem Tag
• Der Tag mit dem geringsten Ertrag war der 16. Dezember mit 0,7 kWh
  • Das war einer der wenigen Tage mit 100% Eigenverbrauchsquote

Fazit

Rein finanziell lohnt sich so eine Photovoltaik-Anlage für mich. Aus technischer Sicht machte das schon viel Spaß sich damit näher auseinander zu setzen, und damit mein ich sowohl generell das Thema Photovoltaik, als auch die Erfassung, Auswertung und Visualisierung der Daten. Persönlich fehlt mir ja noch eine Batterie, um den Eigenverbrauch zu steigern. Dazu lag mir zwar auch ein Angebot vor, doch 33% Aufpreis bei einer längeren Amortisationsdauer von +50% war nicht wirklich sinnvoll. Da warte ich lieber auf hoffentlich günstigere Angebote in Zukunft für Batterien, da diese sich ja mit überschaubaren Aufwand nachrüsten lassen.

Bei jedem Betriebssystem gibt es Anwender, die aus irgendeinem Grund aufgehört haben ihre Betriebssysteme und/oder Programme zu aktualisieren. Eine Entscheidung, die nicht nur die Sicherheit beeinträchtigt, sondern eine ganze Kette an Folgeproblemen nach sich zieht. Am Ende schlägt man dann mit komischen Problemen in Supportforen auf, weil man in einer seltsamen Binnenlogik festsitzt.

Erfahrungsgemäß beginnt die Fehlentwicklung bei einem einzigen Programm. Entweder wird dieses nicht weiter entwickelt, das Lizenzmodell wird geändert oder man ist mit funktionalen Änderungen nicht einverstanden. Also beschließt man, dass man diesen Aktualisierung nicht machen möchte. Das kann auch mal mit einem ganzen Betriebssystemupdate so sein - siehe Windows Vista oder Windows 10 - ist aber in dieser Gestalt seltener.

Eine kluge Vorgehensweise besteht darin sofort nach einer Alternative zu suchen und die Migration vorzubereiten, so lange das alte Programm noch nicht zu lange aus der Unterstützung raus gefallen ist oder vielleicht sogar noch Legacy-Support genießt.

Eine schlechte Entscheidung ist es aber einfach auf der Version zu bleiben, die man gerade nutzt. Eine Entscheidung, die leider viel zu viele Anwender aus Bequemlichkeit wählen.

Diese Programmversion mag funktionieren und vielleicht macht sie auch noch das eine oder andere Betriebssystemupgrade mit, aber irgendwann kommt der Moment an dem das Programm mit einer neuen Version des verwendeten Systems nicht mehr funktioniert. Bei Linux und macOS dürfte das sogar relativ schnell passieren, bei Windows kann das mitunter Jahre dauern.

Also beschließt der nunmehr hartnäckige Verweigerer, dass er nun auch beim Betriebssystem auf Aktualisierungen verzichtet. Ein paar Jahre Legacy-Support gibt es ja für alle Systeme und dann sieht man weiter.

Nun kommt der Verweigerer in das Stadium in dem sich viele Programme nicht mehr aktualisieren lassen, weil die blöden Entwickler alte OS-Versionen nicht mehr unterstützen. Der Verweigerer friert also seine kompletten genutzten Versionen ein. Vielleicht sogar für viele Jahre.

Die Interoperabilität ist längst obsolet. Zugesandte Dateien lassen sich immer seltener reibungslos öffnen. Man klinkt sich zunehmend aus diesem Prozess aus oder beschwert sich gar über neumodische Formate. Browser werden meist sehr lange unterstützt und somit lässt sich das Internet mit obsoleten Betriebssystemversionen lange nutzen.

Doch irgendwann geht auch die verwendete Hardware kaputt und neue Hardware verlangt leidlich aktuelle Betriebssysteme. Auf diesem laufen aber alle alten Programme nicht und die alten Dateiversionen lassen sich nicht mehr reibungslos importieren.

Wutentbrannt schlägt der Verweigerer nun im Supportforum seiner Wahl auf. Dem Frust muss Luft gemacht werden.

Besser man endet nicht so.

Die richtige Entscheidung muss ganz am Anfang getroffen werden. Kein Programm wird ewig existiert, fortlaufende Migrationen sind Teil des Alltags. Daher sollte man drei Grundsätze beherzigen:

1. Man versucht seine Datenbestände kontinuierlich auf unterstützte Programme zu migrieren. In der Regel ist man zu dem jeweiligen Zeitpunkt nicht alleine und kann auf Unterstützung im Internet hoffen.
2. Sollte eine Migration absolut unmöglich sein, muss man das Programm vom restlichen System isolieren und ggf. in einer virtuellen Maschine betreiben. Dadurch verhindert man, dass dieses Problem auf die restlichen genutzten Programme ausstrahlt.
3. Archivierungen von Dateien nimmt man weiterhin nur in Dateiformaten vor, die für diesen Zweck entworfen wurden. PDF/A wäre hier ein geeignetes Beispiel. Keinesfalls nimmt man irgendwelche binären Formate - seien sie freie Software oder nicht.

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay 

Bei jedem Betriebssystem gibt es Anwender, die aus irgendeinem Grund aufgehört haben ihre Betriebssysteme und/oder Programme zu aktualisieren. Eine Entscheidung, die nicht nur die Sicherheit beeinträchtigt, sondern eine ganze Kette an Folgeproblemen nach sich zieht. Am Ende schlägt man dann mit komischen Problemen in Supportforen auf, weil man in einer seltsamen Binnenlogik festsitzt.

Erfahrungsgemäß beginnt die Fehlentwicklung bei einem einzigen Programm. Entweder wird dieses nicht weiter entwickelt, das Lizenzmodell wird geändert oder man ist mit funktionalen Änderungen nicht einverstanden. Also beschließt man, dass man diesen Aktualisierung nicht machen möchte. Das kann auch mal mit einem ganzen Betriebssystemupdate so sein - siehe Windows Vista oder Windows 10 - ist aber in dieser Gestalt seltener.

Eine kluge Vorgehensweise besteht darin sofort nach einer Alternative zu suchen und die Migration vorzubereiten, so lange das alte Programm noch nicht zu lange aus der Unterstützung raus gefallen ist oder vielleicht sogar noch Legacy-Support genießt.

Eine schlechte Entscheidung ist es aber einfach auf der Version zu bleiben, die man gerade nutzt. Eine Entscheidung, die leider viel zu viele Anwender aus Bequemlichkeit wählen.

Diese Programmversion mag funktionieren und vielleicht macht sie auch noch das eine oder andere Betriebssystemupgrade mit, aber irgendwann kommt der Moment an dem das Programm mit einer neuen Version des verwendeten Systems nicht mehr funktioniert. Bei Linux und macOS dürfte das sogar relativ schnell passieren, bei Windows kann das mitunter Jahre dauern.

Also beschließt der nunmehr hartnäckige Verweigerer, dass er nun auch beim Betriebssystem auf Aktualisierungen verzichtet. Ein paar Jahre Legacy-Support gibt es ja für alle Systeme und dann sieht man weiter.

Nun kommt der Verweigerer in das Stadium in dem sich viele Programme nicht mehr aktualisieren lassen, weil die blöden Entwickler alte OS-Versionen nicht mehr unterstützen. Der Verweigerer friert also seine kompletten genutzten Versionen ein. Vielleicht sogar für viele Jahre.

Die Interoperabilität ist längst obsolet. Zugesandte Dateien lassen sich immer seltener reibungslos öffnen. Man klinkt sich zunehmend aus diesem Prozess aus oder beschwert sich gar über neumodische Formate. Browser werden meist sehr lange unterstützt und somit lässt sich das Internet mit obsoleten Betriebssystemversionen lange nutzen.

Doch irgendwann geht auch die verwendete Hardware kaputt und neue Hardware verlangt leidlich aktuelle Betriebssysteme. Auf diesem laufen aber alle alten Programme nicht und die alten Dateiversionen lassen sich nicht mehr reibungslos importieren.

Wutentbrannt schlägt der Verweigerer nun im Supportforum seiner Wahl auf. Dem Frust muss Luft gemacht werden.

Besser man endet nicht so.

Die richtige Entscheidung muss ganz am Anfang getroffen werden. Kein Programm wird ewig existiert, fortlaufende Migrationen sind Teil des Alltags. Daher sollte man drei Grundsätze beherzigen:

1. Man versucht seine Datenbestände kontinuierlich auf unterstützte Programme zu migrieren. In der Regel ist man zu dem jeweiligen Zeitpunkt nicht alleine und kann auf Unterstützung im Internet hoffen.
2. Sollte eine Migration absolut unmöglich sein, muss man das Programm vom restlichen System isolieren und ggf. in einer virtuellen Maschine betreiben. Dadurch verhindert man, dass dieses Problem auf die restlichen genutzten Programme ausstrahlt.
3. Archivierungen von Dateien nimmt man weiterhin nur in Dateiformaten vor, die für diesen Zweck entworfen wurden. PDF/A wäre hier ein geeignetes Beispiel. Keinesfalls nimmt man irgendwelche binären Formate - seien sie freie Software oder nicht.

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay