Open Source macht ein System noch nicht sicher. Dazu gehört heute viel mehr. Die Maßnahmenkette reicht von Updates bis hin zum sogenannten verifizierten Boot. Ein kleiner Überblick über den Unterschied von GrapheneOS zu anderen Projekten.

XDA Developers ist voll von tollen quelloffenen Projekten, die trotzdem Geräte produzieren, die so unsicher sind, dass man vermutlich mit einem China-Smartphone samt Herstellersoftware sicherer unterwegs ist.

Drei Faktoren heben hier GrapheneOS von anderen AftermarketOS („Custom ROMs“) ab.

1. Updates für Firmware und Kernel
2. Verified Boot
3. Notwendige Hardware-Eigenschaften
4. Open Source & Hardening

GrapheneOS – Maßnahmen für mehr Sicherheit

1. Updates für Firmware und Kernel

Android in der AOSP-Variante (Android Open Source Project) steht unter einer freien Lizenz und kann von jedem verwendet und adaptiert werden. Das gilt aber nur für das Betriebssystem und nicht für den Linux-Kernel und die Firmware. Diese Bestandteile variieren von Gerät zu Gerät. So nutzt mein Google Pixel 6 z. B. den Linux-Kernel in Version 5.10, während mein Samsung Galaxy S10 den Linux-Kernel in Version 4.14 verwendet. Beides wird sich voraussichtlich über die gesamte Nutzungszeit nicht ändern.

Der Grund dafür ist die Treiberversorgung. Im Gegensatz zu Linux auf dem Desktop ist ein Großteil der Treiber nicht im sogenannten Mainline-Kernel und deshalb kann der Kernel nicht beliebig aktualisiert werden. Das stellt auch die Hersteller vor Probleme, wie immer wieder gebrochene Updateversprechen zeigen. So lange das Gerät noch herstellerseitig unterstützt wird, ist das nur ein beschränktes Problem. Die Entwickler alternativer Betriebssysteme können dann die Updates des Herstellers für die freie Variante übernehmen. In dem Moment, in dem der Hersteller den Support einstellt, gibt es keine Updates für den Kernel mehr. Mithin die wichtigste Komponente des Systems. Auf diesen dann zusehend marode werdenden Kern kann man noch einige Zeit neue AOSP-Versionen aufsetzen, aber die Sicherheitslücken nehmen naturgemäß zu.

Deutlich problematischer ist hier die Versorgung mit der sogenannten Firmware. In der Szene gern mit Baseband, Radio, Modem etc. umschrieben. Auch hier gibt es Sicherheitsaktualisierungen, aber diese können in der Regel nicht über Updates von z. B. LineageOS eingespielt werden. Bei Samsung muss der Besitzer dies – so er nicht das Samsung Stock Android nutzt – über Software wie Odin oder Heimdall im Downloadmodus erledigen. Die Wahrscheinlichkeit, sein Gerät damit unbrauchbar (soft bricked oder noch schlimmer hard bricked) ist gar nicht so unwahrscheinlich. Entsprechend machen das die meisten Nutzer von AftermarketOS-Systemen nicht oder zumindest nicht regelmäßig.

Für das notorische Problem der kurzen Hardwareunterstützung im Android-Ökosystem bietet somit auch GrapheneOS keinen Ausweg. Deshalb unterstützt man nur wenige Geräte (die Google Pixel-Serie) und diese auch nur so lange, wie Google upstream noch Support für die Geräte bietet. Die von Google angekündigten 5 Jahre für das Google Pixel 6 lassen hier aber hoffen, da GrapheneOS dies hoffentlich übernehmen wird.

2. Verified Boot

Die Wahl auf die Pixel-Geräte von Google fiel sicher nicht, weil Google allseitig so beliebt ist, sondern weil die Pixel-Geräte offiziell die Installation anderer Betriebssysteme erlauben.

Dazu muss man sich vergegenwärtigen wie bei anderen Geräten AftermarketOS aufgespielt werden: Immer muss der Bootloader mit komplizierten Methoden über Klammergriffe oder Herstellercodes, manchmal sogar über Maßnahmen an der Grenze zum „Hacking“ (also über z. B. das Ausnutzen von Fehlern) geöffnet werden. Dieser lässt sich anschließend auch nicht mehr schließen. Dadurch lässt sich nicht nur jederzeit ein anderer Betriebssystem installieren, die „Verified Boot„-Kette lässt sich auch nicht mehr gewährleisten. Durch diesen wird sichergestellt, dass das ausgeführte System aus einer vertrauenswürdigen Quelle stammt und nicht manipuliert wurde. Der Rollback-Schutz verhindert zudem, dass ein Exploit sich dauerhaft im System einnistet.

Geräte ohne „Verified Boot“ sind per Definition einfach nicht sicher. Der Datenschutz hinsichtlich Datenabfluss im Betrieb mag vielleicht besser als bei einem Stock Android sein (was aber auch wieder von Konfiguration und genutzten Apps abhängt), aber die Sicherheit ist massiv viel schlechter. Vor allem wenn man an Szenarien denkt, bei denen Angreifer physischen Zugang zum Gerät haben.

Bei GrapheneOS kann und sollte der Bootloader nach der Installation wieder geschlossen werden. Die vollständige Vertrauenskette beim Start ist anschließend wieder intakt.

3. Notwendige Hardware-Eigenschaften

Aktuelle Versionen von Android, Kernel, Firmware und eine verifizierte Vertrauenskette beim Start sind wichtige Aspekte. Zusätzlich kommen weitere Faktoren hinzu. Auf modernen Smartphones werden immer sensiblere Informationen gespeichert. Ganz besonders brisant sind biometrische Daten für Fingerabdruck oder Gesichtserkennung.

Apple hat hier vor einigen Jahren mit dem Secure Enclave Maßstäbe gesetzt, indem man begonnen hat, solche Daten auch hardwareseitig separiert auf dem Gerät zu speichern. Google nennt seine Lösung Titan Sicherheitschip. Beim Pixel 6 kommt der weiterentwickelte Titan M2 zum Einsatz. (Dieser basiert übrigens auf RISC-V wie die Szene interessiert zur Kenntnis nahm)

Der Titan M2 dient unter anderem dazu, dort biometrische Daten zu speichern. Zusätzlich können Apps via Android-API dort private Schlüssel hinterlegen. Der Titan M2 soll eine Extraktion dieser Daten erfolgreich verhindern.

Wegen fehlender entsprechender Sicherheitsmaßnahmen hatte ich z. B. von der Verwendung von Fingerabdrucksystemen bei herkömmlichen Linux-Systemen abgeraten.

4. Open Source & Hardening

Last, but not least: GrapheneOS ist Open Source. Die Entwickler bauen direkt auf AOSP auf und übernehmen Android damit nicht mittelbar über ein drittes Projekt, wie dies in der Szene oft der Fall ist. Es gibt zudem keine proprietären Bestandteile und keine Google-Dienste in der Standardinstallation.

Hinzu kommen zahlreiche Eigenentwicklungen wie der Chromium-Fork Vanadium als Browser, ein eigener PDF-Viewer, eine eigene Kamera-App und zahlreiche Modifikationen für die Sicherheit („Hardening“). Momentan experimentiert man mit sogenannten „Sandboxed Play Services“, was ein interessanter Ansatz für jene sein könnte, die partout nicht auf Google-Dienste verzichten können.

Wer von einem LineageOS-System umsteigt, wird den Unterschied sofort sehen.

Alternativen

Die möglichen Alternativen zu GrapheneOS sind sehr überschaubar. Eine Möglichkeit ist CalxyOS, das eine ähnliche Zielsetzung wie GrapheneOS verfolgt. (Einen ausführlichen Test von CalxyOS kann man bei Golem lesen) Das erkennt man nicht zuletzt an der nahezu identischen Geräteauswahl beider Systeme. Es gibt halt nicht viel Android-Hardware, das diese Vorgaben erfüllt. Die meisten der oben genannten Punkte treffen deshalb auch auf CalyxOS zu.

CalyxOS versucht es dem Anwender ein bisschen leichter zu machen und integriert daher ein paar mehr Funktionen als GrapheneOS in den Standardumfang bzw. erlaubt es dem Anwender diese leicht einzurichten. CalyxOS könnte daher vor allem jene interessieren, die ein paar mehr Kompromisse eingehen müssen. CalyxOS könnte zudem interessant sein, wenn man ein sicheres Android für Familienmitglieder sucht.

Aus meiner persönlichen Sicht sind einige der Funktionen fraglich und werfen einen Schatten auf das Projekt. Dazu gehört nicht nur microG (weil man damit eben doch Google ins System holt), sondern auch die Bewerbung von VPN (weil VPN nichts mit Anonymität zu tun hat), der massenhaften Leitung von Daten über Tor oder Cloudflare-DNS. Das ist aber klagen auf extrem hohen Niveau!

Außer GrapheneOS oder CalyxOS gibt es allerdings nicht viel. Herkömmliche Linux-Systeme, auch solche von Purism, haben viele der Sicherheitsfunktionen, die in den letzten Jahren Standard im Mobilbereich geworden sind, nicht implementiert. Das gilt ebenso für halbfreie Systeme wie Sailfish OS. Sie können also bestenfalls in einer Liga mit LineageOS spielen. Weitere Informationen dazu im ersten Teil der Serie.

Zwei große Defizite

Das erste Defizit liegt in der Geräteauswahl. So gut sie auch begründet ist und so wenig Alternativen es auch gibt, der Ansatz Google Geld für ein Gerät zu überweisen, um anschließend Google mittels eines anderen Systems zu entkommen, verdeutlicht die ganze Schizophrenie der technischen Gegenwart. Für viele – auch für mich – war und ist dies ein großes Hindernis, aber vielleicht der Preis, den man momentan bezahlen muss.

GrapheneOS ist letztlich von der Entwicklung bei Google (Hardware-Support durch Upstream) und AOSP abhängig. Ohne Android gäbe es auch kein GrapheneOS. Ob die AOSP-Community stark genug wäre, das System zu pflegen oder weiterzuentwickeln, wenn Google eines Tages beispielsweise zu Fuchsia wechseln sollte, steht in den Sternen. Es ist somit eine Freiheit von Googles Gnaden.

Der Artikel GrapheneOS – Viele Maßnahmen für die Sicherheit erschien zuerst auf [Mer]Curius

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Manchmal möchte man ein Lied oder eine Playlist abspielen, die man nicht lokal in der mpd-Datenbank hat. Häufig findet man diese Lieder dann bei youtube. Da ich über meinen mpd mittels snapcast Musik gleichzeitig in mehreren Räumen abspielen kann möchte ich natürlich mpd auch für youtube nutzen.

Dazu habe ich mir ein kleines script geschrieben, welches das Lied oder die Playliste mit mpd abspielt.

Vorraussetzungen um das script nutzen zu können sind mpc und yt-dlp oder youtube-dl.

#! /bin/bash

# mpdpipe
# Copyright (C) 2021 Martin Dosch 
# 
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.

ytdl=$(command -v yt-dlp)
if [[ -z "$ytdl" ]]
then
	ytdl=$(command -v youtube-dl)
	if [[ -z "$ytdl" ]]
	then
		echo "No youtube-dl found."
		exit
	fi
fi

mpc=$(command -v mpc)
if [[ -z "$mpc" ]]
then
	echo "No mpc found."
	exit
fi

get_song_url () {
	url=$("$ytdl" -qgf bestaudio "$1")
}

check_url () {
	regex='(https?|ftp|file)://[-A-Za-z0-9\+&@#/%?=~_|!:,.;]*[-A-Za-z0-9\+&@#/%=~_|]'
	if [[ ! $1 =~ $regex ]]
	then
		echo "$1 is not a valid URL."
		exit
	fi
}

show_help () {
	basename=$(command -v basename)
	if [[ -z "$basename" ]]
	then
		program="$0"
	else
		program=$($basename "$0")
	fi
	echo "Usage:"
	echo "$program url"
	echo "$program mpd_host url"
	exit
}

case $# in
	1)
		if [ "$1" = "help" ] || [ "$1" = "--help" ]
		then
			show_help
		fi
		if ! $mpc -q
		then
			echo "Couldn't connect to mpd."
			exit
		fi
		mpc_command="$mpc"
		input="$1"
		;;
	2)
		if ! $mpc -qh "$1"
		then
			echo "Couldn't connect to mpd at $1."
			exit
		fi
		mpc_command="$mpc -h $1"
		input="$2"
		;;
	*)
		echo "Invalid input."
		show_help
		;;
esac

check_url "$input"

$mpc_command clear
firstrun=1

for link in $("$ytdl" --flat-playlist --no-warnings -qg "$input")
do
	get_song_url "$link"
	if [ -n "$url" ]
	then
		$mpc_command add "$url"
		if [ $firstrun -eq 1 ]
		then
			$mpc_command play
			firstrun=0
		fi
	fi
done

Ich werde das script hier aktuell halten, aber für den Fall, dass ich es doch mal vergesse: Ich habe es auch auf salsa.debian.org veröffentlicht.

#! /bin/bash

# mpdpipe
# Copyright (C) 2021 Martin Dosch 
# 
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .

ytdl=$(command -v yt-dlp)
if [[ -z "$ytdl" ]]
then
	ytdl=$(command -v youtube-dl)
	if [[ -z "$ytdl" ]]
	then
		echo "No youtube-dl found."
		exit
	fi
fi

mpc=$(command -v mpc)
if [[ -z "$mpc" ]]
then
	echo "No mpc found."
	exit
fi

get_song_url () {
	url=$("$ytdl" -qgf bestaudio "$1")
}

check_url () {
	regex='(https?|ftp|file)://[-A-Za-z0-9\+&@#/%?=~_|!:,.;]*[-A-Za-z0-9\+&@#/%=~_|]'
	if [[ ! $1 =~ $regex ]]
	then
		echo "$1 is not a valid URL."
		exit
	fi
}

show_help () {
	basename=$(command -v basename)
	if [[ -z "$basename" ]]
	then
		program="$0"
	else
		program=$($basename "$0")
	fi
	echo "Usage:"
	echo "$program url"
	echo "$program mpd_host url"
	exit
}

case $# in
	1)
		if [ "$1" = "help" ] || [ "$1" = "--help" ]
		then
			show_help
		fi
		if ! $mpc -q
		then
			echo "Couldn't connect to mpd."
			exit
		fi
		mpc_command="$mpc"
		input="$1"
		;;
	2)
		if ! $mpc -qh "$1"
		then
			echo "Couldn't connect to mpd at $1."
			exit
		fi
		mpc_command="$mpc -h $1"
		input="$2"
		;;
	*)
		echo "Invalid input."
		show_help
		;;
esac

check_url "$input"

$mpc_command clear
firstrun=1

for link in $("$ytdl" --flat-playlist --no-warnings -qg "$input")
do
	get_song_url "$link"
	if [ -n "$url" ]
	then
		$mpc_command add "$url"
		if [ $firstrun -eq 1 ]
		then
			$mpc_command play
			firstrun=0
		fi
	fi
done

GrapheneOS ist ein Custom ROM, aber nicht irgendeines. Die Entwickler behaupten ein besonders sicheres Custom ROM auszuliefern und bieten dieses auch nur für Hardware an, die besondere Sicherheitsstandards erfüllt. Doch könnte man nicht was anderes verwenden?

Vor Kurzem berichtete ich bereits von meinem Plan, GrapheneOS einzusetzen. Nachdem nun die ersten experimentellen Builds für das Google Pixel 6 zur Verfügung stehen, möchte ich die Serie zu GrapheneOS beginnen. Zuerst ist daher die Frage zu klären, warum man kein anderes ROM oder Betriebssystem nehmen kann. Es gibt schließlich zahlreiche proprietäre und quelloffene Systeme.

Wenn Herstellersoftware, dann Apple

Man sollte sich nichts vormachen, jede Modifikation am Betriebssystem, selbst wenn es so professionell dokumentiert ist wie GrapheneOS, bedeutet für die meisten Menschen einen zu großen Aufwand. Hier fehlt die Zeit, das Interesse, die Kenntnisse oder eine Kombination aus allem.

Wenn man keine Modifikation am System vornehmen möchte, jenseits der Veränderung irgendwelcher Einstellungen oder Installation von Apps, dann empfehle ich nach wie vor iPhones. Diese sind nicht perfekt, es fließen immer noch Daten an Apple ab und man ist von den Entscheidungen in Cupertino abhängig, aber man bekommt ein ganz passables Datenschutzniveau und die Geräte sind sehr sicher. Die extrem geschlossene Plattform hat eben auch Vorteile und nicht nur Nachteile.

Der Vorteil von Apples iOS ist somit lediglich relativ und liegt vor allem daran, wie schlecht Android in der Variante ist, wie wir es bei auslieferten Geräten vorfinden (genannt Stock Android). Stock Android bedeutet in der Regel nicht nur massiven Datenabfluss an Google, sondern auch an mindestens einen weiteren Hersteller. Angesichts der gegenwärtigen Marktanteile sogar oft ein chinesischer Anbieter und damit an ein Unternehmen, das zwangsläufiger Teil des größten, restriktivsten und immer übergriffigeren Überwachungsstaates der Welt ist. Hinzu kommen ungelöste Probleme bei der Updateversorgung, strukturelle Probleme im System etc. pp. Stock Android ist der Traum für jeden Produzenten von bösartiger Software – vom gewöhnlichen Kriminellen bis hin zu staatlichen Akteuren.

Warum nicht LineageOS, Murena (/e/) oder eine andere ROM?

Der Datenschutz macht es somit unumgänglich sich von Stock Android und den proprietären Google-Bestandteilen von Android zu lösen. Das ist nur leider gar nicht so einfach. Ist man bereit, ein alternatives System (eine sogenannte Custom ROM) zu installieren, gibt es zahlreiche Alternativen. Es waren früher mal mehr, aber noch immer gibt es – abhängig vom jeweiligen Gerät – ein paar verschiedene Systeme zur Auswahl. Leider sind diese allesamt nicht nur positiv, vor allem wenn man den Sicherheitsaspekt in den Vordergrund stellt.

Alle diese Custom ROMs basieren auf dem Android Open Source Project (AOSP) und passen dieses an. Eine Zusammenstellung der wichtigsten Begriffe habe ich hier mal erstellt. Die bekannteste Variante ist immer noch LineageOS und dieses bildet auch die Basis für viele andere ROMs. Nur sehr wenige ROMs basieren direkt auf AOSP. Hier ist wichtig sich zu vergegenwärtigen, dass die Modder-Szene nicht automatisch an Datenschutz und Sicherheit interessiert ist. Die Verbindung beider Interessengruppen ist eher ein Zweckbündnis. Vieles von dem, was auf XDA Developers so passiert (fehlende Offenlegung des Codes, Rooten, Bootloader öffnen, Software aus zweifelhaften Quellen via Downloadlink zu einem Filehoster beziehen) widerspricht Datenschutz und Sicherheit.

Das hat verschiedene Probleme zur Folge. Solche, die LineageOS-spezifisch sind und die sich durch die meisten ROMs ziehen und negative Auswirkungen auf die Sicherheit durch die Nutzung eines Custom ROM allgemein.

Die LineageOS-spezifischen Probleme sind mannigfaltig und sowohl technischer als auch organisatorischer Natur. Das Projekt hat – zählt man CyanongenMod dazu – eine lange Entwicklungsgeschichte hinter sich und passt AOSP seit vielen Jahren mit vielfältigen Erweiterungen an. Dabei hat man einige hartnäckige Probleme und Bugs ins System getragen, die man nicht beheben kann oder möchte. XDA Developers ist voll von entsprechenden Berichten über hartnäckige Neustart-Probleme und vieles andere. Hier kann man betroffen sein, muss aber nicht. Das ist auch abhängig vom Gerät. Hinzu kommt eine dünne Entwicklerdecke, die das Mehraugenprinzip als zentrales Sicherheitsprinzip von Open Source unterminiert. Schaut man sich die Änderungen im Code an, stößt man oft auf Commits, bei denen ein und derselbe Entwickler die Änderung vorgenommen, den Review durchgeführt und die Verifizierung abgenommen hat. Vor allem im Bereich der Geräteunterstützung ist das keine Seltenheit. Je kleiner das ROM, desto größer das Problem.

Hinzu kommen Probleme, die jenseits der Möglichkeiten von LineageOS & Co sind. Updates beziehen sich immer nur auf AOSP. Firmware und Kernel müssen vom Hersteller aktualisiert werden. Stellt der Hersteller den Support ein, ist es mit Kernel-Updates nicht mehr weit. Firmware-Updates müssen zudem am System vorbei vorgenommen werden. Das ist keineswegs trivial und passiert deshalb oft nicht. Angesichts der zentralen Bedeutung von Firmware, können dadurch Geräte scheunentorgroße Sicherheitslücken aufweisen. Naturgemäß muss man zudem seinen Bootloader öffnen und ein Custom Recovery installieren. Das System wird dadurch für einen Angreifer unsicherer als ein Stock Android (zur Erinnerung: Datenschutz ungleich Sicherheit).

Das gilt auch für das aktuell sehr populäre Murena (zuvor /e/) und andere LineageOS-Abkömmlinge und sorgt letztlich für den Ausschluss nahezu aller Custom ROMs.

Eine Alternative wäre lediglich CalyxOS, das eine ähnliche Zielsetzung wie GrapheneOS verfolgt, es dem Anwender aber etwas leichter machen soll. CalyxOS ist vor allem für jene Anwender von Interesse, die auf microG wert legen, was mir aber nicht auf das Gerät kommt.

Und Linux? Wann steht das endlich zur Verfügung?

Seitdem ich mich mit Smartphones befasse warte ich auf ein „richtiges“ Linux für Smartphones. Es ist so traurig, aber die Zustandsbeschreibung, die ich 2018 schrieb, gilt eigentlich immer noch.

Linux scheitert mobil daran, dass dort alle negativen Eigenschaften der Community zum tragen kommen und keine der positiven. Zersplitterte Projekte ohne wirtschaftliche Perspektive basteln nebeneinander her und anstelle die neue Geräteklasse zu nutzen, um überholte Strukturen abzulösen, übertragt man die alten Pfadabhängigkeiten des Desktop-Ökosystems auf die mobilen Geräte. Zahlungskräftige Sponsoren fehlen zudem fast vollständig und somit ist Linux im Mobilbereich ein interessantes Beispiel dafür, was passiert, wenn die so oft schutzartig vorgebrachte Ehrenamtlichkeit der Entwicklung tatsächlich mal eintritt: Nicht viel!

Anstelle hier wenigstens aufzuholen, verliert man ganz im Gegenteil immer stärker den Anschluss. Möglicherweise ist man hier bereits endgültig abgehängt, da wird sich substanziell aller Voraussicht nach nichts mehr ändern. Und selbst wenn da noch was kommt, erfüllt es zwar das Kriterium Open Source, aber hinsichtlich elementarer Sicherheitsfunktionen, die sich in den letzten Jahren auf diversen Plattformen eingebürgert haben, hinkt man technisch weit hinterher. Wie eben der Desktop auch.

Diese Problembeschreibung gilt auch für Systeme wie Sailfish OS, das im Gegensatz zu AOSP nicht mal komplett quelloffen ist und bei dem sich die Entwicklerfirma Jolla zudem inzwischen in fragwürdiger finanzieller Abhängigkeit von Russland befindet. Damit ist das absolut keine Option.

Zusammenfassung und Ausblick

Diese Zustandsbeschreibung ist für langjährige Leser dieses Blogs sicher nicht neu, sondern zieht sich durch meine Artikel zu dem Thema. Dazu erhalte ich Widerspruch und interessante Kommentare. In einem jener Kommentare legte man mir GrapheneOS nahe, das viele der Schwächen von Custom ROMs umgeht und ein besonders sicheres System liefert. Ein Überblick über GrapheneOS folgt im nächsten Teil der Serie.

Der Artikel GrapheneOS – Warum kein anderes System? erschien zuerst auf [Mer]Curius

Viele Datenschützer nutzen Android Custom ROMs, um der Überwachung durch Hersteller zu entgehen. Leider fehlen diese einige heute übliche Funktionen wie Push Dienste. Deshalb empfehlen viele gerne microG. Ein Fehler?

Ich persönlich benötige diese Dienste nicht und nutze deshalb kein microG. Die Frage, welchen Mehrwert für Privatsphäre und Datenschutz microG bietet, hatte ich hier aber auch schon gestellt.

microG bewirbt das eigene Produkt wie folgt auf der Webseite:

Although most microG components are far from complete, users are amazed by the results. Free software users got extended application support, privacy-caring users can reduce or monitor data that is sent to Google and especially older phones can expect some battery life improvements. microG is not only used on real devices, but also replaces Google tools in test emulators and is even used in virtual mobile infrastructure.

microG, abgerufen am 04.12.2021 (Hervorhebung durch den Autor)

Die Gleichsetzung von Open Source mit positiven Effekten für Privatsphäre und Datenschutz als Werbestrategie ist hier mal wieder ein beliebtes, aber gefährliches Mittel.

Denn der Mehrwert für Privatsphäre und Datenschutz ist nicht besonders positiv. Das ist jedenfalls die Meinung der GrapheneOS-Entwickler, wie man im September in einem Thread auf Twitter darlegte:

Da viele Leser hier Twitter nicht nutzen möchte, fasse ich die Kernaussagen knapp zusammen:

• microG ist keine Open Source Implementierung, der App Dienste, da die darauf zugreifenden Apps weiterhin proprietäre Google-Bibliotheken nutzen.
• microG ist somit nur ein Open Source Zwischenhändler zwischen proprietären Bibliotheken und proprietären Diensten. Das bietet keinen Mehrwert für Privatsphäre und Sicherheit.
• Sie sind faktisch sogar unsicherer als die proprietäre Play Service-Implementierung, weil das API Sicherheitsmodell nicht richtig umgesetzt ist und Techniken wie Pinning nicht implementiert sind.
• Die Nutzung von microG erfordert die Umgehung von Sicherheitsprüfungen und Play Services Signaturen.
• Die Verwendung von microG kann nur durch eine invasiven Eingriff in das Betriebssystem erfolgen und setzt umfassenden Zugriff auf privilegierte APIs und spezielle SELinux-Richtlinien vorraus.

Meiner Meinung nach trifft damit auf microG die Bezeichnung „Snake oil/Schlangenöl“ zu. Die meisten kennen das bestimmt aus dem Kontext von Antiviren-Programmen. Es handelt sich per Definition um ein völlig wirkungsloses „Wundermittel“, das anstelle zu helfen sogar unerwünschte Nebenwirkungen haben kann. Genau das scheint nach Aussage der GrapheneOS-Entwickler, deren Expertise klar sein dürfte, auf microG zutreffen.

Bei GrapheneOS arbeitet man stattdessen an sogenannten „Sandboxed Play Services„. Letztlich scheint das eine sinnvollere Variante zu sein. Entweder man kann auf Google-Technologien verzichten oder nicht. Wenn man sie benötigt, hilft auch keine vorgeblich freie Reimplementierung in Open Source, da man Bibliotheken in den Apps und die proprietäre Serversoftware bei Google trotzdem nicht kontrolliert. Man verschafft sich damit bestenfalls die Illusion von Datenschutz und vielleicht ist das sogar kontraproduktiv für die Sicherheit des Geräts.

Der Artikel Ist microG nichts anderes als Schlangenöl? erschien zuerst auf [Mer]Curius

Im Blog schreibe ich regelmäßig über unterschiedliche Betriebssysteme und versuche gerne den normalen Nutzer im Blick zu behalten. In der Community kursieren dazu manchmal komische Vorstellungen. Deshalb man ein Blick auf die Fakten.

Nicht nur beim Thema Betriebssysteme gibt es bei vielen „gefühlte Wahrheiten“, die sich aus dem persönlichen Nutzungsverhalten und dem, was man so in seinem Umfeld sieht, ergibt. In der Linux-Community kursieren da manchmal lustige Annahmen, wenn einige behaupten, Linux müsste doch bestimmt 10 % Marktanteil haben oder mobil wären Custom ROMs eine relevante Größe. Solche verzerrten Wahrnehmungen gibt es aber natürlich auch in anderen Communitys.

Eine Möglichkeit an Zahlen zu kommen, bietet Statista. Dabei handelt es sich um ein deutsches Unternehmen, das Daten zu vielen verschiedenen Themen zusammen trägt und aufbereitet. Einige Informationen sind kostenlos, für andere benötigt man eine kostenpflichtige Lizenz. Wer hier als Mitarbeiter oder Student Angehöriger einer Universität ist, kann mal schauen, ob es dafür eine Campuslizenz gibt.

Die Zahlen sind nicht perfekt, sondern werden unter anderem über Millionen Page Views erhoben und aus Lizenzgründen kann ich die genauen Zahlen und Grafiken hier im Blog nicht übernehmen, aber möchte mal eine Trends verdeutlichen und mit Zahlen aus anderen Quellen anreichern, um mal eine gemeinsame Diskussionsgrundlage herzustellen.

Desktopsysteme

Alle Hersteller arbeiten an konvergenten Systemen und Desktop und Smartphone / Tablet nähern sich sukzessiv an, aber noch macht es Sinn, in Desktop- und Mobilbetriebssystem zu trennen.

Am Desktop hält Microsoft mit Windows knapp 75 % des weltweiten Marktanteils, gefolgt von macOS mit ca. 15 % und dann erst Linux mit knapp über 2 % (Statista). Deutschland ist da erstaunlich nahe an den weltweiten Werten (Statista), anders als beispielsweise die USA. Dort hält Windows nur noch knapp 60 %, dafür kommt macOS auf fast 25-30% und Googles ChromeOS kommt hier auf ca. 8 %. Linux hat weniger als 2 % und ist sogar leicht rückläufig (Statista), wobei man das bei so kleinen Marktanteilen sicher schwer zu erheben ist.

Alles Humbug? Mit Steam erhebt eine weitere Stelle umfassend Daten und da sieht das sogar noch besser für Windows aus. Zuletzt kam Microsofts Betriebssystem auf knapp 96 % und macOS kommt auf lediglich 2,70 % und Linux nur auf 1,16 %.

Bei Statista kann man die Erhebung kritisieren, bei Steam den Fokus auf Gamer mit ihrer Präferenz für Windows. Man kann aber auch einfach konstatieren, dass Linux in keiner mir bekannten Erhebung auf mehr als 2-4 % kommt und dieser Marktanteil konstant bis rückläufig ist.

Mobile Geräte

Der Markt an mobilen Betriebssystemen war mal sehr vielfältig. 2010 tummelten sich dort zwar schon iOS und Android, aber daneben gab es noch BlackBerry, Windows Phone, Nokia Symbian und andere Nischensysteme. Das war eigentlich ein idealer Zustand. Heute gibt es hingegen nur noch Apples iOS und Googles Android.

Die Verteilung ist je nach Land aber sehr unterschiedlich. Da spielt vermutlich die unterschiedliche Kaufkraft und unterschiedliche Traditionen eine Rolle. In den USA ist der Markt z. B. fast 50/50 zwischen iOS und Android geteilt, während in Spanien Android komplett dominant ist (Statista). Deutschland nimmt da eine Zwischenposition ein, verzeichnet aber tendenziell einen steigenden Marktanteil für iOS (Statista).

Innerhalb von Android hat Google nach wie vor Probleme mit der Updateverteilung. Ein substanzieller Teil der Nutzer hängt auf älteren Android-Versionen, selbst das jetzt schon wieder veraltete Android 11 kommt erst auf knapp 1/3 Marktanteil (Statista). Custom ROMs spielen dabei überhaupt keine Rolle. Die bekannteste und größte Custom ROM LineageOS hat laut eigenen Angaben 1.865.014 aktive Gerät (Stand 04.12.2021). Zum Vergleich: Pro Quartal werden weltweit knapp 300 Mio. Smartphones verkauft (Statista).

Andere Systeme wie SailfishOS oder die Linux-Systeme (wenn man Android nicht dazu zählt) spielen keine messbare Rolle.

Schlussfolgerungen

Warum diese Zahlenorgie? Manchmal gibt es in Communitys eine verzerrte Binnenwahrnehmung und je kleiner die Community, desto eher entsteht eine geschlossene Blase. Daraus folgen dann bei manchen „gefühlte Wahrheiten“.

Die Marktanteile zeigen, dass Linux nicht sonderlich erfolgreich (Desktop) oder gar nicht existent (Mobil) ist. Viele Linux-Anwender werden das nicht mal als Manko wahrnehmen. Apple geling es hingegen seinen Marktanteil langsam aber stetig zu steigern, das Beispiel ChromeOS in den USA zeigt übrigens, dass die Marktanteile nicht so fest gefügt sind, wie manche es als Grund für den ausblenden Erfolg von Linux anführen. Das sagt übrigens nichts über den Erfolg von Open Source, denn freie Software kommt auch bei Windows oder macOS eine herausragende Bedeutung zu. Nicht umsonst widmen Projekte wie KDE der Windows Plattform mehr Aufmerksamkeit.

Diese Zahlen sollte man aber im Hinterkopf haben, wenn man sich über den Erfahrungsraum und Erwartungshorizont normaler Nutzer Gedanken macht und sich überlegt, wo man diese beispielsweise bei den Themen Datenschutz oder Privatsphäre abholen muss.

Der Artikel Betriebssysteme – Verbreitung und Marktanteile erschien zuerst auf [Mer]Curius

Fr, 3. Dezember 2021, Niklas

Bereits Mitte Mai haben wir berichtet, dass das freie Betriebssystem Haiku auf die RISC-V CPU Architektur portiert wurde. Seitdem wurde noch viel daran gearbeitet. Zum Beispiel wurde das System auf echter Hardware getestet, dazu bekam der Entwickler ein HiFive Unmatched RISC-V Mainboard von der Haiku Inc. zur Verfügung gestellt.

Die Änderungen dazu hat der verantwortliche Entwickler zunächst in einem eigenen Fork des Haiku Quellcodes vorgenommen. In der Zwischenzeit wurden viele Stellen im Code optimiert und er wurde in den Master Branch von Haiku selbst übernommen. Das bedeutet, dass die Nightly Builds jetzt funktionsfähig sind und ausprobiert werden können.

Man sollte dabei im Hinterkopf behalten, dass zunächst nur die x86 Architektur voll unterstützt wird, RISC-V zählt weiterhin als experimentell. Auch sind noch keine Paket-Repositorys für die RISC-V Variante vorhanden, sodass alle Pakete selbst über den Haikuporter und das Haikuports Quellcode-Repository kompiliert werden müssen.

Wer das Experiment trotzdem wagen möchte, kann Haiku jetzt auf RISC-V ausprobieren. Als echte Hardware wird bislang nur das HiFive Unmatched unterstützt. Wer dieses nicht besitzt, kann auch mittels QEMU auf einem ganz normalen x86 Computer ein RISC-V System emulieren. Und so funktioniert es:

HiFive Unmatched:

• Anforderungen:
  • HiFive Unmatched Mainboard
  • Eine AMD Radeon Grafikkarte, die von Haikus radeon_hd Treiber unterstützt wird
  • Eine SD-Karte, die als u-boot uefi bios vorbereitet wurde
  • Haiku RISC-V Nightly Build auf einem USB-Stick
• Vorgehensweise:
  • SD-Karte in das HiFive Unmatched einstecken
  • USB-Stick in das HiFive Unmatched einstecken
  • Das HiFive Unmatched einschalten
  • Ein Desktop sollte innerhalb von einer bis zwei Minuten erscheinen

Serielles Debugging: Sollte es hierbei Probleme geben, kann ein Micro-USB-Kabel mit dem HiFive Unmatched verbunden werden. Dadurch sieht man serielles Output während des Bootvorgangs. (minicom, 115200 8N1, no flow control)

QEMU:

• Anforderungen:
  • QEMU 6.0.0 oder neuer
  • Haiku RISC-V Nightly Build
  • u-boot binary für QEMU riscv64

Haiku kann mit dem folgenden Befehl in QEMU gestartet werden:

qemu-system-riscv64 -M virt -m 1G -device ati-vga -kernel u-boot.bin \
    -drive file=haiku-mmc.image,format=raw,if=virtio \
    -usb -device usb-ehci,id=echi -device usb-kbd -device usb-tablet

Serielles Output kann auf unter view → serial0 angeschaut werden.
Der Haiku Desktop erscheint auf view → ati-vga. Achtung: Eine Boot-Animation gibt es nicht. Hier erscheint erst etwas, wenn der Bootvorgang abgeschlossen ist.

Vorsicht vor Bugs: Es gibt einige bekannte Probleme mit RISC-V in Verbindung mit QEMU. Wenn der Bildschirm über längere Zeit schwarz bleibt, sollte man es einfach noch einmal versuchen. Relevante Bugs: #17379 und #17380

RISC-V ist Haikus erster funktionierender Port auf eine andere CPU Architektur. Es ist für das Projekt eine grosse Chance, die Hardwareunterstützung zu erweitern. Viel Arbeit ist allerdings noch zu tun. So kann Haiku auf RISC-V beispielsweise aktuell nur einen einzigen CPU Kern nutzen.

Auch interessant: In letzter Zeit wird wieder vermehrt an den Portierungen auf ARM gearbeitet, sowohl an 32Bit als auch 64Bit. Diese Ports sind noch lange nicht so weit wie RISC-V und sind zum aktuellen Zeitpunkt nicht nutzbar, aber in ein paar Monaten könnten die ersten funktionierenden Builds für Experimentierfreudige bereitstehen.

Quelle: https://www.haiku-os.org/blog/kallisti5/2021-11-07_booting_our_risc-v_images/

Do, 2. Dezember 2021, Lioh Möller

Das Manjaro Linux ARM Entwicklerteam hat eine erste Beta-Version für das PinePhone Pro vorgestellt. Dabei kommt der auf GNOME basierende Desktop Phosh in Version 0.14 zum Einsatz, die darunterliegenden GNOME Komponenten basieren auf Version 41.1 der Desktopumgebung.

Im Gegensatz zur Version für das reguläre PinePhone, basieren die Abbilder für das PinePhone Pro auf dem Linux Kernel 5.16-rc.

Darüber hinaus wurde systemd 249.7 und Mesa 21.2.5 integriert. Das Anti-Spam-System erlaubt es ungewünschte Anrufe zu unterdrücken.

Download: https://github.com/manjaro-pinephone/phosh/releases

Do, 2. Dezember 2021, Ralf Hersel

NixOS 21.11 trägt den Namen "Porcupine" und erscheint sechs Monate nach der Veröffentlichung von NixOS 21.05 "Okapi". Es enthält eine Menge Neuheiten, angefangen bei der GNOME 41.1 Desktop-Umgebung für die GNOME-Edition, über Wayland-Unterstützung für die KDE Plasma 5.23 Edition bis hin zur Version 6 des Pantheon-Desktops von elementary OS.

Wer mehr über diese spezielle GNU/Linux-Distribution erfahren möchte, dem empfehlen wir unsere vierteilige Serie zu NixOS.

Diese Version enthält Nix 2.3.16 als Standard-Paketmanager, stellt das iptables-Dienstprogramm auf das nf_tables-Backend um, aktualisiert das Hadoop-Modul und -Paket auf Hadoop 3 als Standard mit neuen Diensten wie JournalNode, ZKFS und HTTPFS und verbessert die LXD-Unterstützung, um Images direkt aus Konfigurationen zu erstellen.

Eine weitere interessante Änderung in NixOS 21.11 ist die Unterstützung für die Ausführung von Aktivierungsskripten während eines nixos-rebuild dry-activate und die Erkennung der Trockenaktivierung durch das Auslesen der Variable $NIXOS_ACTION.

"Damit können Aktivierungsskripte ausgeben, was sie ändern würden, wenn die Aktivierung wirklich ausgeführt würde. Das users/modules-Aktivierungsskript unterstützt dies und gibt einen Teil seiner Aktionen aus", erklären die Entwickler.

In dieser Version sind standardmässig PHP 8.0, Python 3.9, systemd 249, GNU Bash 5, OpenSSH 8.8p1, kops 1.21.1, PostgreSQL 13, spark 3, kubernetes-helm 3.7.0 und ORY Kratos 0.8.0 Alpha 3 enthalten. Unter der Haube wird NixOS 21.11 von der Linux 5.10 LTS Kernel-Serie angetrieben (Linux 5.10.81 ist der Standard-Kernel).

Zu guter Letzt bringt NixOS 21.11 zahlreiche neue Dienste mit, darunter btrbk für die Sicherung von btrfs-Subvolumes, clipcat X11-Clipboard-Manager, PeerTube, eine freie und dezentrale Alternative zu Video-Hosting-Plattformen, Hockeypuck OpenPGP-Schlüsselserver und viele andere, die man in den Release Notes findet.

NixOS 21.11 kann als GNOME- oder KDE-Plasma-Live- und installierbare ISO-Images sowie ein Minimal-ISO-Image ab sofort von der Webseite des Projekts heruntergeladen werden. Während die GNOME- und KDE-Plasma-ISOs nur 64-Bit-Systeme unterstützen, kann das Minimal-Image auch auf 32-Bit-Rechnern installiert werden.

Quelle: https://9to5linux.com/nixos-21-11-porcupine-released-with-gnome-41-kde-plasma-on-wayland

Mi, 1. Dezember 2021, @65536@troet.cafe

Im letzten Teil unserer Artikelserie zu NixOS fassen wir zusammen, für wen NixOS geeignet ist und für wen möglicherweise auch eher nicht. Die ersten drei Teile befassen sich unter anderem mit den Grundlagen eines deklarativen Betriebssystems, der Installation und Konfiguration von NixOS sowie den Besonderheiten der Paketverwaltung.

NixOS könnte gut geeignet sein für diejenigen, die…

• gerne sehr detaillierte Kontrolle über ihr System haben möchten.
• ein sauberes System haben möchten, auf dem früher getätigte Einstellungen nicht vergessen werden können und später zu Problemen führen, weil sie zentral und deklarativ gesetzt werden. Wer wie ich den deklarativen, anti-imperativen Ansatz auf die Spitze treiben will, kann sogar die Dateisystemwurzel bei jedem Neustart leeren und neu deklarativ generieren lassen, beispielsweise indem sie als tmpfs eingerichtet wird.
• ein besonders zuverlässiges System haben wollen. Der Nix-Paketmanager verhindert prinzipbedingt, Konflikte von Paketen sehr gut.
• viel herumexperimentieren möchten, ohne ihr System in Probleme zu manövrieren. Mit nix-shell lassen sich Programme ausprobieren, ohne sie zu installieren. Ich bin mehrmals zwischen Gnome und KDE gewechselt, indem ich einfach die Zeilen zur Desktopumgebung und dem Displaymanager in configuration.nix austauschte. Ein sudo nixos-rebuild boot und einen Reboot später landete ich ohne jegliche Fehler oder weitere Umstände im anderen Displaymanger und in der anderen Desktopumgebung. Nicht einmal die in Gnome und KDE jeweils integrierten Anwendungen müllten die andere zu. Auch auf das Rollback trifft das tadellos zu.
• Anwendungsprogramme benutzerweise installierbar haben möchten. Jeder Benutzer kann mit nix-env selbst Software installieren, ohne dabei Administratorrechte zu benötigen. Die Software steht dann nur dem einen Nutzer zur Verfügung.
• mehrere Rechner möglichst identisch konfigurieren wollen, indem dieselbe Konfigurationsdatei auf alle Rechner angewandt wird.
• zukünftig neue Rechner mit derselben Software und Einstellungen einrichten wollen wie ihren derzeitigen. Anstatt entweder sämtliche installierte Software herauszufinden und nachzuinstallieren oder ein Systemimage komplett zu klonen und damit auf eine frische Linuxinstanz zu verzichten, kann schon bei der Installation einfach die bisherige Konfiguration eingefügt und nur ggf. die hardwarespezifischen Zeilen aus der automatisch generierten Konfiguration übernehmen.

NixOS ist möglicherweise weniger geeignet für diejenigen, die…

• lieber mit GUI-Werkzeugen arbeiten als mit Konfigurationsdateien und Befehlen. In der Alltagsbenutzung wird man zwar weitestgehend ohne Kommandozeile auskommen, aber für die Installation und Teile der Konfiguration ist sie nötig.
• zum allerersten Mal Linux nutzen. In dem Fall ist es allerdings unwahrscheinlich, dass man ausgerechnet NixOS ins Auge gefasst hat.
• den imperativen Ansatz bevorzugen. Er ist zwar zu grossen Teilen auch mit NixOS möglich, empfohlen ist hier aber deklarative Vorgehensweise.
• nicht die Motivation haben, sich die bei NixOS neu zu lernenden Dinge anzueignen. Die Lernhürde ist nicht zu unterschätzen, aber andererseits auch nicht immens und definitiv lohnend. Nach einem knappen Jahr des Linux-Kennenlernens mit Debian wechselte ich zu NixOS und brauchte dann 10-20 Abendstunden, um mich mit den Eigenheiten von NixOS zurechtzufinden. Seitdem möchte ich das deklarative Konzept nicht mehr missen, und lerne immer mehr tolle Optionen kennen.
• sehr wenig Speicherplatz haben.

Ein paar der Alternativen zu NixOS sind:

• Fedora Silverblue: Diese sehr benutzerfreundliche Distribution ist immutable, es sind also, wie übrigens auch bei NixOS, die meisten Systemdateien im Betrieb unabänderbar. Neue Anwendungen sind als Flatpak zu beziehen; die selten nötigen Änderungen am Basissystem erfordern bei Silverblue sogar immer einen Neustart. Die Ähnlichkeiten zu NixOS sind die integrierten Rollbacks-Bootoptionen und die hohe Zuverlässigkeit durch Sauberhaltung des Systems. Die Immutabilität bei NixOS ist weniger strikt als bei Silverblue, letzteres hat aber keine zentrale deklarative Konfiguration. Statt der nix-shell ist hier das Werkzeug toolbx zum Nutzen nicht ins System integrierter Software verfügbar.
• Fedora Kinoite: Der jüngere Bruder von Fedora Silverblue nutzt KDE Plasma statt Gnome.
• GNU Guix System: Von NixOS inspiriert, setzt diese besonders auf freie Software fokussierte Distribution die gleichen Konzepte mit eigenen Implementierungen und Werkzeugen um. Ausserdem setzt es statt systemd GNU Daemon Shepherd als sein Init-System ein. Diese Distribution wird auch von der FSF empfohlen.

Ein paar Fun Facts. Schon gewusst, dass…

• NixOS eine Variante für Mobilgeräte hat? Leider werden recht wenige Geräte unterstützt.
• die Softwarerepositories von Nix sowohl zu den grössten als auch aktuellsten der Linuxwelt gehören?
• der Nix-Paketmanager auch auf vielen anderen Distributionen, und sogar auf Apples MacOS installierbar ist? Das bringt diesen zwar nicht die Reproduzierbarkeit und Konfigurierbarkeit von NixOS, aber zumindest nix-env, nix-shell etc.

Links:

https://nixos.org/
https://silverblue.fedoraproject.org/
https://kinoite.fedoraproject.org/
https://guix.gnu.org/
https://mobile.nixos.org/
https://repology.org/

Im Februar 2020 wurde schon angekündigt, dass OpenSSH die Unterstützung von ssh-rsa auslaufen lässt. Umgesetzt wurde dies in Version 8.8, die vor gut einem Monat veröffentlicht wurde.

Leider unterstützt nicht jedes System moderne HostKeyAlgorithms. Ein solches Beispiel konnte ich die Tage z. B. bei einem Switch beobachten konnte. Hier erscheint folgender Fehler:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

In so einem Fall kann man ausnahmsweise doch noch ssh-rsa erlauben und das geht entweder per Option im ssh-Aufruf:

ssh -o HostKeyAlgorithms=+ssh-rsa 192.168.1.1

oder man trägt es in die ~/.ssh/config dauerhaft ein:

Host XYZ
    HostName 192.168.1.1
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Di, 30. November 2021, Lioh Möller

Die Bedienung eines Computers oder Mobiltelefons überfordert oftmals ältere Menschen. Insbesondere, wenn sie zuvor nie in Kontakt damit gewesen sind. Dennoch möchten sie die Verbindung mit den Enkelkindern aufrechterhalten und Mails schreiben oder eine Recherche im Internet durchführen. Die französische Firma Ordissimo SA, welche bis 2018 unter dem Namen Substantiel geführt wurde, hat sich dem Thema bereits zu Beginn der Nullerjahre angenommen. Ziel war es den ersten Computer für alle Informatik-Anfänger zu entwickeln. Im Jahre 2005 wurde dann das erste Ordissimo-Modell veröffentlicht. Ein auf dem Linux-Betriebssystem basierender Computer mit einer angepassten Benutzeroberfläche. Seither hat sich viel getan und bereits in 2013 konnte das 50'000te Ordissimo-Gerät verkauft werden.

Das Bedienkonzept ist dabei einzigartig gestaltet und ermöglicht einen schnellen Zugriff auf die wichtigsten Funktionen. Als Technologie kommt bis dato ein angepasster Enlightenment Desktop zum Einsatz. Bekannte Applikationen wie Thunderbird, Firefox oder LibreOffice wurden mit einem vereinfachten User-Interface versehen und der eigens entwickelte Dateimanager ermöglicht einen einfachen Zugriff auf Dokumente, Bilder, Datenträger und mehr.

Auch die Druckereinrichtung ist, sofern das Modell unterstützt wird, in wenigen Schritten vollzogen. Die Ordissimo Hardware zeichnet sich darüber hinaus durch eine Tastatur aus, welche keine doppelt belegten Tasten verwendet.

Zwar stand ein Grossteil der zum Einsatz kommenden Software-Komponenten seit jeher unter einer Freien Lizenz zur Verfügung, die Distribution selbst war allerdings nur im Bundle mit einem Ordissimo-Computer erhältlich.

Ein Projekt aus Italien mit dem Namen Debianissimo versucht seit einigen Jahren diese Lücke zu schliessen und stellt eine installierbare Distribution mit allen Ordissimo Komponenten zur Verfügung.

Die Live-Medien starten dabei zunächst in eine Shell und erst mithilfe von startx lässt sich die Desktopumgebung laden.

Dabei ist im Live-Modus nur ein Bruchteil der Software verfügbar und so empfiehlt sich eine Installation, wobei mindestens 64GB Diskspeicher vorausgesetzt wird. Das enthaltene Installationsprogramm steht bisher nur in italienischer Sprache zur Verfügung. Nach dem ersten Start des Installers führt dieser eine Aktualisierung durch und muss daraufhin erneut aufgerufen werden. Während der Installation wird lediglich die Festplatte ausgewählt. Alle zuvor vorhandenen Daten werden dabei gelöscht.

Sobald das System erfolgreich installiert wurde, startet es nach einem Neustart automatisch in die Grafische Oberfläche. Es empfiehlt sich zunächst im Bereich Einstellungen eine Aktualisierung durchzuführen. Dazu ist ein erneuter Neustart notwendig. Ein Grossteil des auf Debian 9 basierenden Betriebssystems wird read-only gemounted, es lässt daher standardmässig nur bedingt Veränderungen zu. Durch einen remount im beschreibbaren Modus, lässt sich dies temporär ändern.

Wie eingangs erwähnt verfügen nahezu alle Applikationen über eine vereinfachte Oberfläche, die eine einfache Nutzung auch für Computer-Einsteiger ermöglicht.

Das Panel am unteren Bildschirmrand bietet einen schnellen Zugriff auf die wichtigsten Funktionen, sowie einige Bedienelemente wie beispielsweise + und - zum Vergrössern des Bildschirminhaltes. Das Pfeilsymbol macht eine zuvor gemachte Änderung rückgängig (Undo).

Die Distribution eignet sich für alle, die das Ordissimo-Betriebssystem auf einem Standard-PC nutzen möchten. Wer eine Investition nicht scheut, findet im Online-Shop des Original-Herstellers eine breite Auswahl an Hardware.

Quelle: https://debianissimo.it
Download: https://debianissimo.it/cdn/isos/debianissimo-sr2018.iso