Mo, 7. Februar 2022, Ulf Bartholomäus

Bei SuSE Linux und dem darauf basierenden openSUSE Community Projekt handelt es sich um eines der ältesten Linux Distributionen überhaupt. Sie war wegen ihrer deutschen Wurzeln und insbesondere für die gute Unterstützung der deutschen Sprache sehr bekannt. SuSE war für viele ältere Linux Nutzer die erste benutzte Linux Distribution.

SuSE Linux Enterprise ist vor allen für kommerziellen Einsatz gedacht. Das davon abgeleitete openSUSE Linux Community Projekt, gibt es in zwei Varianten. Dem auf klassischen Release-Zyklus basierenden openSUSE LEAP, das demnächst in der neuen Version 15.4 veröffentlicht wird und eher einer LTS (Long Term Support) Distribution ähnelt, sowie seit etwa 10 Jahren openSUSE Tumbleweed. Welches mittlerweile ein Aushängeschild des openSUSE Projektes geworden ist. Anstelle klassischer Versionsnummern und periodischer Updates wird ein Rolling-Release-System genutzt. Updates finden kontinuierlich statt, vorherige Stände des Betriebssystems werden als „Snapshots“ gesichert. Die Mehrheit der openSUSE Anwender nutzen laut regelmäßig durchgeführten Umfragen mittlerweile Tumbleweed als Desktop Distribution.

Dabei wird nach der Factory First Policy vorgegangen, bei der alle Pakete zunächst nach Factory releast werden, bevor sie in eine Distribution aufgenommen werden können. Aus Factory wird täglich ein Snapshot gezogen und einem automatisierten Testprogramm unterzogen. Bei erfolgreichem Test wird der Snapshot publiziert. Anders als bei anderen Distributionen ist Tumbleweed somit ein getestetes Rolling Release, was der Stabilität sehr entgegenkommt.

Aussage des  Tumbleweed Portals: "Das Projekt tut dies für Nutzer, die die jeweils neueste stabile Software haben wollen." Deshalb ist Tumbleweed auch nach meinen jahrelangen Erfahrungen besonders für die ambitionierten Einsteiger geeignet.

In meiner LUG verwenden es einige Einsteiger seit Jahren, ohne damit nennenswerte Probleme zu haben. Dabei ist insbesondere die sehr gute und aktuelle KDE/Plasma sowie nahtlose Integration für viele Tumbleweed Nutzer das ausschlaggebende Argument für die Nutzung.

Installation

Das Herunterladen des ISO Images und das anschliessende (optionale aber empfehlenswerte) Überprüfen dessen, ist sehr gut und in deutscher Sprache beschrieben. Auch wird neben der Installation von DVD die Installation mit dem gleichen ISO auf einen USB-Stick unterstützt. Das Brennen könnte einfacher nicht sein, da sogar ein eigenes Programm, dass sich SUSE Studio ImageWriter nennt, dazu angeboten wird. Ist das ISO dann auf der DVD oder USB-Stick geschrieben, kommt eigentlich wie bei allen anderen Linux Distributionen auch der schwierigste Schritt. Nämlich den eigenen PC oder Notebook zu überreden, dass er von dem Installationsmedium startet. Hat man diese Hürde genommen, die leider nicht von Linux beeinflusst werden kann, sondern nur vom verwendeten PC-Hersteller abhängt, erscheint der Bootbildschirm. Hier kann man direkt die Sprache auf Deutsch umschalten oder erst nach dem Starten der Installation. Egal wie, die komplette Installation wird in sehr guten Deutsch geführt und sogar die optionale Hilfe ist komplett in Deutsch vorhanden.

Eigentlich kann man danach nicht mehr viel falsch machen, weil die meisten Einstellungen intuitiv zu tätigen sind. Auch sind immer wieder gute Tipps in der Hilfe gut beschrieben.

Mein Tipp, ist gleich KDE/Plasma als Desktop zu wählen, da dieser besonders gut in openSUSE integriert ist und die "deutsch" - "deutsche" Partnerschaft zwischen beiden eine lange Tradition hat. Ich kenne keine andere Distribution, die so hervorragend in die KDE/Plasma Desktop Welt integriert.

Selbst komplexe Aufgaben, wie ein verschlüsseltes System lassen sich mit dem geführten und mit sinnvollen Hilfetexten versehenen Installations-Programm auch für Einsteiger ohne Probleme durchführen.

Ist das System fertig zusammengestellt, kann man sich alle Einstellungen noch mal in Ruhe anschauen und bei Bedarf noch mal einfach ändern. Anschliessend braucht man nur noch mit "Installieren" alles laufen lassen, bis der Anmeldebildschirm nach dem ersten Starten erscheint.

Durch die eigentlich immer etwa 1 Monat verzögert verfügbaren aktuellen Kernel, ist auch aktuelle Hardware insbesondere bei Notebooks wichtig, bestmöglich unterstützt. Sollte es doch mal mit dem einen oder anderen Feature klemmen, kann man sicher sein, dass sich das Problem nach einigen Updates in der Regel von alleine löst. Auch das nur mit wenig Verzögerung gegenüber dem offiziellen KDE/Plasma Releases verfügbare, aber immer gut integrierte und adaptierte Desktop und Anwendungen, sind so in keiner anderen Distribution zu finden.

Einführung

Direkt nach dem ersten Start wird man mit dem "Ahoi" Fenster begrüsst. Dieser bietet direkt den Einstieg in einige sehr gute und vor allem auch fast durchgängig deutsche Einführung. Überall werden auch immer mehrere Wege zur Lösung angeboten, sodass man den für sich bevorzugten aussuchen kann.

Vollständigkeit

Insbesondere nach Aktivieren der zusätzlichen Community Repositories, kann einfach über YaST auf fast alles zugreifen, was irgendwie als Linux Programm angeboten wird. Falls doch mal was fehlt, aktiviert man im KDE/Plasma Anwendungsmanager "Discover" einfach Flatpack und bekommt standardmäßig alle auf Flathub angebotenen Programme dazu.

Stabilität

Dadurch die Factory First Policy und den vorherigen automatischen Tests der Software vor der Verteilung über die Tumbleweed Repositories, kommt es eigentlich nicht zu nennenswerten Problemen mit der Stabilität. Sollte dann doch mal der Fall der Fälle auftreten, bietet Tumbleweed zahlreiche Möglichkeiten an trotzdem mit dem System zu arbeiten. Standard mässig werden immer der aktuelle und der zuletzt verwendete Kernel in den erweiterten Optionen angeboten, zusätzlich kann jeder von ihnen im Recovery Modus gestartet werden. Wird BTRFS verwendet, werden noch sehr intelligent Snapshots angefertigt, die dann im nur-lese Modus gestartet werden kann. Kommt man mit den vorherigen Massnahmen nicht weiter, löst das Aktualisieren via bootbarem ISO das Problem sehr zuverlässig.

Vorkonfiguration

Tumbleweed ist nach dem Start komplett benutzbar konfiguriert und auch die wichtigsten Anwendungen sind vorhanden.  Möchte man auch exotische und geschützte Codecs verwenden oder die aktuellsten nVidia Grafiktreiber, kann man das durch einfaches geführtes hinzufügen von Community Repositories wie Packman erledigen. Auf dem schon erwähnten Tumbleweed Portal gibt es auch eine fast noch einfachere Anleitung via Textkonsole und einfachen kopieren und einfügen.

Update-Prozess

Der ist ganz einfach, ihn gibt es in dem Sinn ja nicht. Die täglichen manchmal bis zu hundert Pakete fixen nicht nur Fehler oder lösen kritische Sicherheitsprobleme kurz nach Bekanntwerden. Auch neue Programme und Funktionen kommen immer wieder in mehr oder weniger kleinen Schritten hinzu. Das ist sehr angenehm, da es dadurch im schlimmsten Fall nur ein paar Tage dauert, bis ein Problem einer SW gelöst und durch die fortlaufenden Updates gelöst wird.

Bewertung

Kriterium	Bewertung (max. 5)
Installation	🏆️🏆️🏆️🏆️
Einführung	🏆️🏆️🏆️🏆️🏆️
Vollständigkeit	🏆️🏆️🏆️🏆️
Stabilität	🏆️🏆️🏆️🏆️
Vorkonfiguration	🏆️🏆️🏆️🏆️🏆️ (KDE Version)
Update-Prozess	🏆️🏆️🏆️🏆️
Summe	26

Fazit

openSUSE Tumbleweed KDE/Plasma eignet sich sehr gut für Linux-Einsteiger, vor allem wenn sehr neue Hardware verwendet werden soll. Als Desktopoberfläche empfiehlt sich KDE, was man auch daran erkennen kann, dass es bei der Desktop Auswahl an erster Stelle steht. Das System ist im Standardumfang gut konfiguriert und die wichtigsten Anwendungen sind vorinstalliert. Eine Installation von weiteren Applikationen ist auch für Erstanwender ohne weiteres möglich, wobei bei KDE Discover die erste Wahl sein sollte. Mit YaST steht eine extrem leistungsfähige und benutzerfreundliche Möglichkeit zur Verfügung, das System sehr weitgehend und komfortabel anzupassen. Dabei ist insbesondere die einfache Installation von Hardware wie Druckern, Scannern und Multifunktionsgeräten via YaST sehr gut gelöst.

Download: https://get.opensuse.org/de/tumbleweed/

Mo, 7. Februar 2022, Lioh Möller

Die aus Mandriva Linux heraus entstandene Distribution OpenMandriva wurde in der Version Lx 4.3 veröffentlicht (OMLx 4.3). Eine Besonderheit stellt die Verwendung des LLVM Compilers dar, was nach Aussagen des Projektes zu einer Performance-Steigerung führt.

Wie bereits in der Vorgängerversion lässt sich mit dem Hilfsprogramm om-feeling-like das Erscheinungsbild der Standard-Desktopoberfläche anpassen und von anderen Betriebssystemen her bekannte Paradigmen nachbilden.

Der Willkommensassistent OM-Welcome wurde für die nun vorliegende Version weiter verbessert und ermöglicht Einsteigern einen schnellen Zugang zur Distribution.

Ein Port für die 64-bit ARM Architektur steht offiziell zur Verfügung. Damit einhergehend werden installierbare Images für PinebookPro, Raspberry Pi 4B und 3B+, Rock Pi 4A, 4B und 4C, Synquacer, Cubox Pulse und generische UEFI-kompatible aarch64 Geräte angeboten.

LibreOffice ist in Version 7.3.0.3 enthalten sowie Krita 5.0.2, Digikam 7.5, SMPlayer 21.10.0, VLC 3.0.16 und der Falkon Webbrowser 3.2.

PipeWire ist standardmässig aktiviert, bei Bedarf ist allerdings weiterhin ein Wechsel auf PulseAudio möglich.

Als Standardkernel kommt Version 5.16.7 zum Einsatz und der KDE Plasma Desktop wird in Version 5.23.5 ausgeliefert.

Quelle: https://www.openmandriva.org/en/news/article/openmandriva-lx-4-3-released

Mit den Heizthermostaten von Homematic IP lassen sich die Heizkörper minutengenau zeitsteuern. In der Zentrale, in meinem Falle die Homematic CCU3, lassen sich Zeitprofile für jedes Heizthermostat hinterlegen. Die ganze Woche lässt sich damit detailliert planen. Es ist offensichtlich, dass nicht jede Woche eine Kopie der vorherigen Woche ist. Manchmal arbeitet man die ganze Woche von Zuhause aus, manchmal ist man im Urlaub. Damit ergibt sich auch, dass die Räume anders geheizt werden müssen.

Die Homematic CCU3 ermöglicht es, bis zu drei verschiedene Wochenprogramme anzulegen. Die Frage ist nun, wie kann man komfortabel zwischen diesen Wochenprogrammen wechseln? Diesem Thema widme ich diesen Artikel.

Automatisierung ftw!

Der Grundgedanke eines Smart Homes ist natürlich, dass es „smart“ ist, also eigenständig Entscheidungen trifft. In meinem konkreten Fall könnte das bedeuten, dass meine Heizungssteuerung automatisch erkennt, wann mein Wochenprogramm sich ändern müsste. Mit entsprechenden Bewegungsmeldern ist das sicherlich möglich, wenn auch relativ aufwendig und kostspielig.

Ich habe mich dafür entschieden, eine übergeordnete Steuerung zu verwenden, den Home Assistant. Die Homematic CCU3 tritt dort nur als Client auf. Das ist insofern eine ganz gute Idee, als dass sich Home Assistant über eine App steuern lässt. Das ist komfortabel und zukunftssicher, dank einer engagierten Community im Hintergrund.

Einbindung von Homematic CCU3 in Home Assistant

Der Home Assistant und die Homematic CCU3 lassen sich glücklicherweise sehr einfach miteinander verbinden. Einzig ein Eintrag in der configuration.yaml von Home Assistant ist notwendig. Im Beispielcode sind die Passwörter in eine secrets-Datei ausgelagert.

# Homematic
homematic:
  interfaces:
    ip:
      host: 192.168.1.123
      port: 2010
      resolvenames: json
      username: !secret homematic_user
      password: !secret homematic_pw
    groups:
      host: 192.168.1.123
      port: 9292
      resolvenames: json
      username: !secret homematic_user
      password: !secret homematic_pw
      path: /groups
  hosts:
    ccu3:
      host: 192.168.1.123
      username: !secret homematic_user
      password: !secret homematic_pw

Damit man das Wochenprogramm umschalten kann, braucht es einen Service, den wir folgendermaßen zusammensetzen.

1. Man erstellt auf einem Dashboard einen neuen Button.
2. Bei den Einstellungen des Buttons wechselt man in die Code-Ansicht und gibt dort folgendes ein.

Address ist die Serialnummer des Gerätes, Value ist das Wochenprofil.

type: button
tap_action:
  action: call-service
  service: homematic.set_device_value
  service_data:
    address: 000a1d8991xxxx
    channel: 1
    param: ACTIVE_PROFILE
    value: '2'
    value_type: int
  target: {}
entity: climate.000a1d8991xxxx
icon: mdi:bed-outline
name: Kein Besucher im Gästezimmer

Um das Wochenprofil auf einen anderen Wert zu stellen, dupliziert man die Kachel und ändert die „Value“. Leider habe ich nicht herausgefunden, wie man den aktuellen Wert für das Wochenprofil ausliest. Mit dieser Info könnte man einen einzelnen Button verwenden und diesen togglen.

The post Homematic IP: Wochenprogramm via Home Assistant wechseln first appeared on bejonet - Linux | Smart Home | Technik.

Die Linux-Community kannte Shitstorms schon bevor es den Begriff gab und Desktopwars sind legendär. Heute hat man diese harten Auseinandersetzungen auf eine neue Stufe gehoben, indem man die Diskussion verweigert. Mit Folgen für die Meinungsbildung.

Wenn man irgendwo (die Betonung liegt auf irgendwo, es muss eben nicht in diesem kleinen Blog passieren) eine Kritik an Linux formuliert, entsteht immer ein ähnlicher Schlagabtausch. Ich werde das hier mal exemplarisch aufschreiben, um bei Bedarf immer wieder darauf verlinken zu können, weil ich es ehrlich gesagt leid bin, dieselben Pseudoargumente immer wieder zu lesen.

Um das Ganze etwas plastischer zu machen, beschreibe ich das an einem konkreten Beispiel. Diese Kritik könnte wie folgt lauten:

Wayland ist unter Linux noch nicht alltagstauglich, weil es insgesamt an Entwicklern fehlt, diese Entwickler sich weiterhin über viele Projekte verteilen, die Parallelentwicklungen betreiben und nicht alle der Migration die gleiche Bedeutung beimessen.

Ich nehme für diesen Blogbeitrag mit Absicht Wayland, weil ich keine Nebendiskussion auslösen möchte und ich Wayland noch für verhältnismäßig wenig umstritten halte. Das kann man aber für jede Entiwcklungsdiskussion der letzten 10 Jahre nachzeichnen – von ext4 bis systemd. Das ist eine im wesentlichen auf Fakten beruhende Kritik. Für Windows könnte man so etwas auch formulieren:

Windows beinhaltet aus Gründen der Abwärtskompatibilität viele alte Bestandteile, die die Entwicklung bremsen. Microsoft wird diese aus Rücksichtnahme auf seine Business-Kunden aber niemals zugunsten des Gesamtfortschritts aufgegeben.

Ich bin mir nicht mal sicher, ob in einer Diskussion zu so einer Windows-Meldung überhaupt nennenswerte Kommentare kämen. Die Schwächen von Windows sind auch seinen Befürwortern bekannt. Kaum jemand glaubt hier für Microsoft argumentativ in die Bresche springen zu müssen. Man weiß schließlich, was man an Windows hat. Bei Linux käme aber sofort Widerspruch, weil für viele in der Community Kritik sofort abgeblockt werden muss. Kritik ist für sie Verrat an der Wahrheit. Weil das je nach Faktenlage schwer ist, kommen Standardargumente zum Einsatz, um die Diskussion auf Nebenschauplätze abzulenken oder abzuwürgen.

10 Standardargumente sind besonders verbreitet:

1. Linux ist kostenlos. Das kannst du nicht mit ChromeOS vergleichen.
2. Linux lebt vom Mitmachen, wo ist dein Beitrag? Hast du schon Code zu Wayland beigesteuert?
3. Keinen Entwickler interessiert, dein Kommentar hier im Forum / Blog / Kommentarbereich.
4. Man kann Linux-Entwickler halt nicht zwingen, woran sie sich beteiligten, weil die alle ehrenamtlich mitarbeiten. Manche wollen halt lieber für X.org entwickeln.
5. Du musst Linux doch nicht nutzen. Such dir doch eine Alternative, die dir mehr gefällt.
6. Linux lebt von seinen Alternativen. Das war schon immer so und ist gut. Du hast dadurch einfach die Wahl zwischen X.org und Wayland.
7. Du verwendest den Begriff Linux völlig falsch. Linux ist nur der Kernel. Wovon du sprichst ist die Distribution und da müssen wir erst mal definieren ob Wayland so ähnlich wie X11 ist und ob du nicht eigentlich von Android sprichst.
8. Wayland widerspricht aber der UNIX-Philosophie. Alternativ: Wayland widerspricht dem KISS-Prinzip
9. Früher konnten Entwickler noch besser entwickeln, deshalb ist X11/X.org heute so gut und Wayland macht alles falsch.
10. Bei mir gibt es keine Probleme! Alternativ: Ich brauche Wayland nicht.

Diese Standardargumente kann man angepasst in jede Diskussion schmeißen und ich bin mir sicher, dass die meisten Leser einiges davon wieder erkennen. Vermutlich könnte man über Jahre jede Diskussion auf jeder Linux-Plattform mit diesen 10 Bausteinen bestreiten. Manche dieser Argumente haben verwandte Vorläufer-Argumente aus anderen Kontexten wie „Dann geh dich nach drüben!“, manche sind für sich genommen nicht falsch, sondern nur ihre Verwendung erzeugt fatale Mechanismen und manche Argumente werden gerne wiederholt, sind aber einfach nicht richtig.

Kann uns das nicht egal sein? Nein! Niemand steht morgens auf und sagt: Wayland finde ich blöd. Wir bilden uns unsere Meinung über neue Entwicklungen in einem diskursiven Prozess. Einige experimentieren mit den neuen Werkzeugen und schildern ihre Eindrücke, andere argumentieren eher theoretisch und manche folgen dem Prozess lediglich und bilden sich ihre Ansicht passiv.

Dabei ist es durchaus wichtig festzuhalten, dass dieser Prozess sich nicht nur auf die Entwickler beschränkt, sondern der diskursive Meinungsbildungsprozess zwischen Entwickler- und Anwendergemeinschaft insgesamt entsteht. Die Linux-Geschichte ist voll von guten und weniger guten Entwicklungen, die sich nicht durchsetzen konnten, weil die Anwender sich der Entwicklung verweigerten. Die beste Idee, fehlerfrei umgesetzt, kann nicht erfolgreich sein, wenn die Mehrheit konsequent dagegen ist. Dadurch entstehen dann Dynamiken, die sich nicht rational erklären lassen. Zum Beispiel ist es inzwischen egal was Mozilla mit Firefox macht, die Mehrheit ist immer dagegen und das schlägt sich in den Nutzungszahlen wider.

Am Ende entsteht eine Mehrheitsmeinung, der sich die meisten anschließen und abweichende Minderheitsmeinungen, die entweder verworfen werden, langfristig doch noch Einzug halten, oder in einer Spaltung münden.

Wenn der diskursive Prozess gestört ist, weil keine Diskussion mehr möglich ist, da jede Argumentation mit Standardargumenten entführt oder mit Falschinformationen abgelenkt wird, hat das Auswirkungen auf die Bereitschaft, diese neuen Entwicklungen zu adaptieren, weil die meisten nicht wissen, wie sie die Entwicklung einordnen sollen.. So entstehen dann fiktive Aussagen wie: „Wayland habe ich noch nicht getestet, aber ich habe gelesen, dass es UNIX-Prinzipien bricht, weil die Netzwerktranspararenz nicht mehr besteht und das finde ich blöd. Außerdem ist X.org toll, weil damals konnten die noch effizient entwickeln.„

Der Artikel Standardargumente bei Kritik an Linux und die Folgen dieser Diskussionsunfähigkeit erschien zuerst auf [Mer]Curius

Wer glaubt schon auf dem Desktop die Qual der Wahl zu haben beim Thema Verschlüsselung, der könnte sich im vielfältigen Angebot für Cloud-Verschlüsselung endgültig verirren. Bei der Auswahl hilft es, sich von den genutzten Betriebssystemen leiten zu lassen.

Denn nur wenige Verschlüsselungslösungen adressieren auch konsequent alle Betriebssysteme. Die folgende Tabelle bietet eine grobe Orientierung:

Was für eine Lösung für einen infrage kommt, hängt somit stark von den genutzten Betriebssystemen ab. Insbesondere wenn man im mobilen Bereich Apps für iOS oder Android benötigt, lichtet sich das Feld enorm.

Nicht gelistet ist EncFS, von dem man dringend Abstand nehmen sollte. EncFS war zu seiner Zeit wertvoll, aber konnte die im Audit zutage getretenen Probleme nie substanziell ausräumen. Ich halte es für grob fahrlässig von vielen Distributionen diese unsichere und ungepflegte Software weiterhin in den Paketquellen vorrätig zu halten, obwohl die Community mit z. B. securefs oder gocryptfs gute indirekte Nachfolger hervorgebracht hat.

Ich persönlich rate daher immer zu Cryptomator, weil es einen hohen Funktionsumfang mit einer guten Bedienung verbindet und die Anwendung Open Source ist. Über die kostenpflichtigen Apps für iOS und Android haben die Entwickler ein faires Modell umgesetzt, um dem Dilemma der Kostenlos-Kultur in der Open Source-Community zu entkommen.

Grundsätzlich ist es je nach Bandbreite und/oder Fähigkeiten des Speicherdienstes auch möglich, containerbasierte Verschlüsselungslösungen wie VeraCrypt oder LUKS in der Cloud einzusetzen. Dafür sind sie aber nicht gemacht und ich würde das nicht pauschal empfehlen.

Weiterführende Informationen:

• Cryptomator
• Boxcryptor
• SimpleumSafe
• Plasma Vault (grafische Oberfläche für CryFS)
• SiriKali (grafische Oberfläche für CryFS, securefs, gocryptfs)
• zuluCrypt (grafische Oberfläche für verschiedene Lösungen)

Der Artikel Welche Verschlüsselung für die Cloud nehmen? Von Boxcryptor bis securefs erschien zuerst auf [Mer]Curius

Yabridge habe ich schon länger im Gebrauch und will nun endlich auch mal einen Artikel darüber schreiben, nachdem ich schon ein kleines Tutorial dazu gemacht habe. Wie man so schön auf deutsch sagen würde „Die Installation von YaBridge ist ein Gehirnloser (nobrainer)“  … manchmal vermisse ich die schlechten Übersetzungsprogramme.
 
Kurze Übersicht, was gemacht werden muss:

1. Installation von Wine „Staging branch“
2. Download Yabridge in ein bestimmtes Verzeichnis
3. Konfiguration von Yabridge, setzen der Plugin Pfade & yabridgectl sync ausführen
4. Fertig

 
Schritt für Schritt Anleitung mit vielen Erklärungen, um zu verstehen, was passiert und was dahinter steckt.
 

1. Installation von Wine „Staging branch“

Die „Staging branch“ ist quasi der neuste und heißeste Shit. Bleeding Edge! Es sind zwar die neusten Features mit drin, aber dafür kann man schon mal eben den einen oder anderen Bug rein bekommen. Insgesamt ist dieser Beta Entwicklungszweig aber auch sorgfältig gepflegt, so dass das zum Glück nicht häufig vorkommt. Hat man einen funktionierenden Stand könnte man den auch „einfrieren“ (apt pinning).
 

Generell IMMER der Anleitung auf der WineHQ Seite folgen!

Aktuell für Kubuntu 21.10 sieht das so aus

sudo dpkg --add-architecture i386

wget -nc https://dl.winehq.org/wine-builds/winehq.key
sudo apt-key add winehq.key

Für (K)Ubuntu 21.10

sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ impish main'

sudo apt update
sudo apt install --install-recommends winehq-staging

 
Dann gibt es noch 2 sehr wichtige Hinweise auf der WineHQ Webseite (Datum dieses Artikels)

WineHQ enthält derzeit keine Pakete für wine-gecko oder wine-mono. Wenn Sie ein neues Wine-Präfix erstellen, werden Sie gefragt, ob Sie diese Komponenten herunterladen möchten. Für beste Kompatibilität wird empfohlen, hier auf Ja zu klicken. Wenn der Download bei Ihnen nicht funktioniert, folgen Sie bitte den Anweisungen auf den Gecko- und Mono-Wiki-Seiten, um die Komponenten manuell zu installieren.

Beginnend mit Wine 5.7 haben die WineHQ Ubuntu-Pakete eine optionale debconf-Einstellung, um CAP_NET_RAW zu aktivieren, damit Anwendungen, die rohe IP-Pakete senden und empfangen müssen, dies tun können. Dies ist standardmäßig deaktiviert, da es ein potentielles Sicherheitsrisiko darstellt und die meisten Anwendungen diese Fähigkeit nicht benötigen. Benutzer von Anwendungen, die dies benötigen, können CAP_NET_RAW nach der Installation von Wine aktivieren, indem siedpkg-reconfigure wine-<branch>-amd64 wine-<branch> wine-<branch>-i386und beantworten Sie die drei Fragen mit Ja. (Ersetzen Sie devel, staging oder stable durch <branch> im obigen Befehl). Also sieht der Vefehl folgendermaßen ausdpkg-reconfigure wine-devel-amd64 wine-devel wine-devel-i386

Um die Darstellung anzupassen nutzt man das Tool winecfg. Unter Grafik kann man die DPI einstellen, so dass alles etwas größer ist z.B. 120 oder 150 DPI bei hochauflösenden Bildschirmen. Einfach in einer Konsole winecfg eintippen und Enter drücken.

Sollten irgendwelche Schriftarten oder ähnliches fehlen, können diese einfach mit dem tool winetricks nachinstalliert werden. Das Tool winetricks muss extra installiert werden und sollte mit größter Vorsicht und nur in Ausnahmefällen genutzt werden, da man sich mit diversen „Tipps & Tricks“ aus dem Internet schnell mal die Konfiguration zerschießen kann.Für die Schriftarten wäre es dann folgender Befehl notwendig winetricks -q corefonts

2 Download Yabridge in ein bestimmtes Verzeichnis

Von Robberts YaBridge Software Repository die letzte Version von Yabridge runterladen und zwar von der „Release“ Seite https://github.com/robbert-vdh/yabridge/releases . Das Paket das mit „-ubuntu-18.04.tar.gz“ endet ist AUSSCHLIESSLICH für (K)Ubuntu Versionen ÄLTER bis 18.04 gedacht. Für neuere Versionen einfach das Paket z.B. yabridge-3.8.1.tar.gz runter laden . Zum Zeitpunkt, wenn du das installierst, kann das natürlich eine neuere Version sein.

1. Download von https://github.com/robbert-vdh/yabridge/releases
2. Auspacken und in das Verzeichnis ~/.local/share (also dein Home Verzeichnis) kopieren. So dass als Ergebnis das Verzeichnis ~/.local/share/yabridge/ mit den entsprechend darin befindlichen Dateien existiert.
3. In einer Konsole in das Verzeichnis wechseln cd ~/.local/share/yabridge/
4. Die Pluginpfade hinzufügen ( mit ./yabridgectl add ), in denen sich normalerweise die installierten Plugins befinden. Wenn noch keine Plugins installiert sind, existieren auch oft die Pfade nicht!
   Typische Pfade sind:

"$HOME/.wine/drive_c/Program Files/Steinberg/Vstplugins/"
"$HOME/.wine/drive_c/Program Files/Vstplugins/"
"$HOME/.wine/drive_c/Program Files/Common Files/VST2"
"$HOME/.wine/drive_c/Program Files/Common Files/VST3"

Schau nach welche Pfade bei dir existieren (nach der Plugin Installation) und dann füge sie mit dem Befehl (im yabridge Verzeichnis) ./yabridgectl add DEINPFAD hinzu z.B. ./yabridgectl add "$HOME/.wine/drive_c/Program Files/Steinberg/Vstplugins/"

Mit ./yabridgectl list kannst du dir alle eingepflegten Pfade anzeigen lassen

und mit ./yabridgectl rm PFADNAME kannst du einen Pfad wieder aus der Konfiguration entfernen.

Mit ./yabridgectl status siehst du alle erkannten und unterstützten Plugins

Installierte Plugins hinzufügen
Jedes Mal, wenn ein neues Windows Plugin installiert wurde öffnest du eine Konsole, wechselst in das yabridge Verzeichnis cd ~./conf/share/yabridge und führst folgenden Befehl aus

./yabridgectl sync

Fertig

In der letzten Zeile der Ausgabe solltest du einen Hinweis lesen können, dass ein neues Plugin erkannt und hinzugefügt wurde (added new). Um es dann aber doch noch genau zu überprüfen und eine Liste aller Plugins zu sehen, rufe einfach folgenden Befehl auf

./yabridgectl status

Abschließend musst du vermutlich nur noch in der DAW die entsprechenden Pfade für die Plugins angeben und du kannst loslegen. Wenn du wieder mal neue Plugins installiert hast, dann einfach:

Prüfen, wird(wurde) das Plugin in einen der bekannten Pfade installiert?
Wenn ja, dann Konsole öffnen, ./yabridgectl sync ausführen. Fertig
Wenn nein, Pfad mit ./yabridgectl add PFAD hinzufügen und danach ./yabridgectl sync ausführen. Fertig.

 
Das gilt alles für 64 Bit Plugins. Für 32Bit muss bei Wine noch noch etwas angepasst werden, dann geht das auch. Aber das vielleicht in einem anderen Artikel.
 

The post Plugins – Windows VSTs 32/64 Bit mit YaBridge | Linux first appeared on Dem hoergen Blog.

Jede Woche werden für das vielfältige Linux-Ökosystem schwere und weniger schwere Sicherheitslücken entdeckt. Dafür stellen alle Distributionen zeitnah Patches bereit, damit ihre Anwender weiter sichere Systeme haben. Die Frage ist nur, wie zeitnah diese Updates erfolgen.

Die letzten Tage ging eine Lücke in Samba durch die Presse. Dabei handelt es sich um eine Nachbildung von Windows-Netzwerkdiensten, die nahezu jede Linux-Distribution vorinstalliert hat. Der Fehler ist im vfs_fruit Modul. Apple-Anwender kennen das vermutlich als Voraussetzung, um Time Machine-Backups auf einem Linux-Server ablegen zu können (damit habe ich mich hier im Blog schon häufig befasst). Die Lücke ist als kritisch eingestuft und unter CVE-2021-44142 registriert.

Alle mir bekannten Distributionen rollten geschwind Patches aus. Ubuntu, SUSE, Red Hat – die Patches waren in der Regel schon auf meinem System, bevor ich die entsprechende Meldung gelesen hatte. Nur bei Debian passiert mal wieder seit Tagen nichts.

Chromium hinkt auch schon wieder hinterher und beim Überfliegen der aktuellen Sicherheitsprobleme fielen mir gleich ein paar Pakete auf, für die ich auf meinen openSUSE Leap-Systemen bereits seit Tagen Updates habe (z. B. Expat), wobei die fairerweise nicht sonderlich kritisch sind. Genauso bei MariaDB, aber da macht openSUSE es sich ja auch leicht und rollt – total verrückt ich weiß – einfach die offiziellen Minor-Versionen von Upstream aus.

Ich mag Debian nicht sonderlich, das dürfte bekannt sein. Den Vorwurf nehme ich hier daher gleich vorweg. Wobei das nicht immer so war, sondern sich erst während der abstoßenden Auseinandersetzung um systemd so entwickelt hat. An Versionen wie Debian Lenny erinnere ich mich gerne zurück.

Zwei Punkte verwundern mich nur:

1. Woher hat Debian seinen Ruf als sicheres Betriebssystem? Sie bieten bestenfalls Durchschnitt an, wenn man sich die Reaktionsgeschwindigkeit auf Probleme ansieht.
2. Warum nimmt das in der Debian-Community überhaupt niemand wahr? Ich habe keine einzige ernsthafte Diskussion dazu gefunden.

Beispielsweise könnte man ja darüber diskutieren, wie hoch der Preis sein darf, den man bereit ist zu bezahlen, um Versionen absolut versionsstabil zu halten. Welche Pakete möchte man dafür noch opfern, wie viel Verzögerung bei Sicherheitsupdates findet man vertretbar für dieses Ziel. Priorisiert man Sachen wie reproduzierbare Builds höher als Sicherheit? Das wären interessante Punkte für eine Policy.

Vielleicht passiert das intern, vielleicht ist man intern aber auch zu sehr mit Personalpolitik beschäftigt, um sich solcher Sachen anzunehmen.

Der Artikel Sicherheitsupdates bei Debian – Wie viel Verzögerung ist normal? erschien zuerst auf [Mer]Curius

Die Frage welche Verschlüsselungslösung nun die Richtige für jemanden ist erreicht mich oft. Gerade bei Linux ist die Situation unübersichtlich, aber auch bei Windows und macOS gibt es Alternativen. Ein kleiner Leitfaden durchs Labyrinth.

Lösungen zur Verschlüsselung gibt es zahlreiche. Von Vollverschlüsselung über Benutzerdatenverschlüsselung bis hin zur Verschlüsselung einzelner Verzeichnisse ist alles möglich. Dann auch noch jeweils unterschiedlich für jedes Betriebssystem. Wer soll sich da noch auskennen. Daher ein paar kleine Leitfäden, wie man zu seiner passenden Verschlüsselung gibt.

Externe Festplatten

Weiterführende Informationen

• LUKS für externe Festplatten
• Externe Festplatten verschlüsseln unter macOS
• Externe Festplatten verschlüsseln mit BitLocker To Go
• VeraCrypt für systemübergreifende Verschlüsselung

Linux

Weiterführende Informationen

• LUKS für Betriebssystemverschlüsselung
• eCryptFS für Benutzerdatenverschlüsselung
• systemd-homed für Benutzerdatenverschlüsselung
• Plasma Vault für einzelne Verzeichnisse
• SiriKali für einzelne Verzeichnisse

macOS

Weiterführende Informationen

• macOS mit FileVault verschlüsseln
• Verzeichnisse mit SimpleumSafe verschlüsseln
• VeraCrypt für systemübergreifende Verschlüsselung

Windows

Weiterführende Informationen

• Windows mit BitLocker verschlüsseln
• VeraCrypt für systemübergreifende Verschlüsselung

Schlussbemerkung

Egal welche Lösung man nutzt, irgendeine sollte man verwenden, denn die Standardmechanismen der Betriebssysteme für den Desktop lassen sich leicht aushebeln. Im Zweifelsfall ist die Vollverschlüsselung mit der jeweiligen in das Betriebssystem integrierten Methode vorzuziehen.

Im mobilen Bereich unter Android und iOS ist die Situation zum Glück viel besser. Hier braucht es kleine solchen Leitfäden, denn die Systeme verschlüsseln standardmäßig und sicher die Daten auf den Geräten.

Der Artikel Welche Verschlüsselung soll ich wählen? Von eCryptFS bis VeraCrypt erschien zuerst auf [Mer]Curius

Fr, 4. Februar 2022, Lioh Möller

Im Hintergrund liefen die Arbeiten bereits seit vielen Monaten, um zeitnah zur Veröffentlichung von Slackware 15.0 eine aktualisierte Ausgabe des Linux-Kurses bereitstellen zu können.

Neben der vielen Änderungen, die Slackware selbst mitbringt, wird im Kurs nun auch eine Installation mit UEFI beschrieben.

Wie üblich steht der gesamte Quelltext unter einer CC-BY-SA Lizenz und ist im Git-Repository verfügbar.

Viel Spass an alle Slackware Interessierten und Linux-Neulinge. Wir freuen uns über Rückmeldungen und Fehlerkorrekturen.

Quelle: https://linuxkurs.ch

Das Heizsystem ist für viele der erste Einstieg in das Thema „Smart Home„. So ist es auch bei mir. Viele meiner Heizkörper laufen mittlerweile mit Heizthermostaten von Homematic. Zusammen mit der übergeordneten Software Home Assistant ist jetzt meine Menge möglich in meinen vier Wänden. Das Wandthermostat von Homematic ist sogar in der Lage, die relative Luftfeuchtigkeit zu messen. Das ist schon sehr nützlich und kann für weitere Auswertungen verwendet werden. In meinem Fall interessiere ich mich allerdings für die absolute Luftfeuchtigkeit, die sich von der relativen Luftfeuchtigkeit unterscheidet. Glücklicherweise lassen sich die beiden Werte ineinander umrechnen, und das Wandthermostat liefert auch alle notwendigen Messwerte dafür.

Unterschied zwischen relativer und absoluter Luftfeuchtigkeit

Mir als ausgebildeten Thermodynamiker liegt es natürlich am Herzen, dass man den Unterschied zwischen relativer und absoluter Luftfeuchtigkeit kennt. Der Unterschied liegt eigentlich auf der Hand und lässt sich schon anhand der Einheiten gut unterscheiden.

Die relative Luftfeuchtigkeit wird in Prozent angegeben. Die Luft ist ein Gemisch aus Gasen, ein Teil davon kann Wasserdampf sein. Wie viel das maximal ist, hängt von der Temperatur der Luft ab: je kälter es ist, desto weniger Wasserdampf kann dampfförmig in der Luft vorkommen. Sollte dieser Wert überschritten werden, bildet sich Nebel. Die relative Luftfeuchtigkeit gibt an, bis zu welchem Grad die Luft bereits mit Wasserdampf gesättigt ist. Sind die 100% erreicht, kondensiert alles zusätzliche Wasser und es wird neblig. Etwas thermodynamischer ausgedrückt, klingt die Definition so: Die relative Luftfeuchtigkeit gibt den Partialdruck des Wasserdampfs relativ zum Maximalwert bei aktueller Temperatur an.

Die absolute Luftfeuchtigkeit hingegen wird in g/m³ angegeben (andere Einheiten sind möglich). Bildlich kann man es sich so vorstellen, dass in einem Kubikmeter Luft die angegebene Menge Wasserdampf vorhanden ist.

Warum sollte man die absolute Luftfeuchtigkeit wissen wollen?

Eine typische Textaufgabe in Thermodynamik 1 könnte lauten: Im Wohnzimmer herrschen 22 °C und 40 % Luftfeuchtigkeit. Außen hat es 8 °C und 80 % Luftfeuchtigkeit. Steigt oder fällt die Luftfeuchtigkeit im Wohnzimmer, wenn man das Fenster öffnet?

Eine andere Fragestellung lässt sich ebenfalls darüber beantworten: Im Wohnzimmer herrschen 22 °C und 20 % Luftfeuchtigkeit. Das Raumvolumen beträgt 75 m³. Wie viele Kilogramm Wasser muss man verdunsten lassen, um auf 50 % Luftfeuchtigkeit zu kommen?

Wenn ihr es wisst, könnt ihr das gerne in den Kommentaren hinterlassen

Die Physik dahinter

Es sind zwei wichtige Formeln miteinander kombiniert. Die eine Formel, Antoine-Gleichung, berechnet den Sättigungsdampfdruck der Luft bei vorgegebener Temperatur. Die zweite Formel, die ideale Gasgleichung, berechnet daraus die absolute Feuchtigkeit. Die Temperatur und relative Feuchtigkeit werden vom Wandthermostat zur Verfügung gestellt.

Die Berechnung in Home Assistant

In Home Assistant legt man sich für diese Berechnung einen neuen Sensor an. Das geschieht über Templates. Dieser Sensor existiert nur softwareseitig und sein Messwert wird berechnet, nicht direkt gemessen. Ich habe das beispielsweise umgesetzt, indem ich in die configuration.yaml folgende Zeile ergänzt habe:

sensor: !include sensor.yaml

Mittels des folgenden Befehls habe ich besagte Datei erstellt und ihr den folgenden Inhalt gegeben.

$ touch sensor.yaml
$ nano sensor.yaml

- platform: template
  sensors:
    absolute_humidity:
	friendly_name: "Absolute Feuchte"
	unit_of_measurement: "g/m^3"
	icon_template: mdi:water-percent-alert
	value_template: "{{ 1000*e**(19.016-(4064.95/(float(states('sensor.wandthermostat_wohnzimmer_eg_actual_temperature'))+236.25)))*100/(461.66*(float(states('sensor.wandthermostat_wohnzimmer_eg_actual_temperature'))+273.15)) * float(states('sensor.wandthermostat_wohnzimmer_eg_humidity'))/100 | float }}"

In Home Assistant wird dieser Sensor in der Liste der Entitys angezeigt. Das Template hat sozusagen den neuen Sensor ins System integriert.

The post Home Assistant: Absolute Luftfeuchtigkeit berechnen first appeared on bejonet - Linux | Smart Home | Technik.

Fr, 4. Februar 2022, Ralf Hersel

Zum Abschluss unserer Serie 'Einsteigerlinux', werfe ich noch einen Blick auf eine der beliebtesten GNU/Linux-Distributionen des letzten Jahrzehnts: Ubuntu 22.04 LTS. Bisher habe ich einen Bogen um das Canonical-Produkt gemacht, weil Ubuntu zu viele Eigenwege geht und damit immer gescheitert ist (TV, Smartphone, MIR, Unity, Snap). Dennoch muss man Canonical zugutehalten, dass sie den Begriff 'Einsteigerlinux' massgeblich geprägt und gefördert haben. Ich selbst habe 15 Jahre lang ausschliesslich Ubuntu auf meinen Rechnern verwendet.

Da die kommende Ubuntu-Version zurzeit erst in der Beta-Version vorliegt, ist dieser Test etwas unfair. Dem habe ich Rechnung getragen, indem ich die Punktevergabe etwas angehoben habe. Canonical bietet mit der neusten LTS-Version eine Unterstützung bis April 2027 an und setzt auf den Kernel 5.15. Ubuntu wird mit Gnome Shell 42 erscheinen aber überwiegend Gnome 41 Core Apps bringen, die noch auf GTK3 basieren.

1. Installation

Die ISO-Datei von 'Jammy Jellyfish' ist 3.3 GB gross und kann hier heruntergeladen werden. Nach dem Booten muss man die Sprache auswählen und zwischen einem Live-Boot und der direkten Installation auswählen. Ich entscheide mich für die Installation. Zuerst wählt man das Tastaturlayout, wobei man aufpassen muss, das richtige Land zu wählen. Das Schweizer-Layout befindet sich nicht unter 'Deutschland', sondern unter 'Schweiz', was ungewöhnlich ist. Im nächsten Schritt wählt man zwischen 'normaler' und 'minimaler' Installation aus und kann Software von Drittanbietern mitinstallieren lassen. Nach den üblichen Einstellungen zur Partitionierung und der Zeitzone, gibt man Name und Passwort ein. Eine Besonderheit ist die Möglichkeit, die Unterstützung für 'Active Directory' auszuwählen.

Nun beginnt die eigentliche Installation. Meiner Meinung nach gibt es keine Unterschiede zur letzten Version 21.10; das Hintergrundbild wurde noch nicht auf 'Jammy Jellyfish' angepasst. Während der Installation wird eine Slideshow gezeigt, die wichtige Informationen über die Ubuntu-Distribution bietet. Der Vorgang dauert etwas länger als bei den anderen Distro-Tests, was an den Drittquellen liegen könnte. Fazit: absolut Einsteiger-freundlich: 4 Punkte.

2. Einführung

Nach dem Abschluss der Installation wird man zum Neustart aufgefordert. Dieser hat bei mir nicht funktioniert; nach dem Login-Screen geschah nichts mehr. Beim zweiten Versuch habe ich von Wayland auf X-Org umgeschaltet, was von Erfolg gekrönt war. Das muss nichts heissen und liegt wahrscheinlich an meiner Testumgebung (Ubuntu 20.04, VM: Boxes). So sieht Ubuntu direkt nach der Installation aus:

Ubuntu bleibt dem Unity-Stil treu, indem eine Dash am linken Rand angeboten wird. Die Ersteinrichtung beginnt mit den Online-Konten, was für mich keine ideale Begrüssung ist. Schlimmer wird es im zweiten Schritt, bei dem die Übertragung von Telemetrie-Daten standardmässig ausgewählt ist. Zum Glück sind im dritten Schritt der Einführung, die Ortungsdienste ausgeschaltet. Im letzten Schritt wird die Anwendung 'Software' für die Installation von Anwendungen angepriesen. Danach wartet die Aktualisierungsverwaltung mit einem ersten Update auf dich.

Fazit: Das machen andere Distros besser. Bei Ubuntu wird man nicht herzlich willkommen geheissen: 2 Punkte.

3. Vollständigkeit

Ubuntu 22.04 (daily build) kommt mit diesen wesentlichen Anwendungen daher:

• Kernel 5.15
• GNOME 41.3
• LibreOffice 7.2.5.2
• Firefox 96.0.3
• Thunderbird 91.5.1
• Rhythmbox 3.4.4
• Dateien 41.1 (Nautilus)
• Shotwell 0.30.14

Die GNOME-Optimierung (Tweak-Tool) ist nicht installiert. Auch die 'Erweiterungen' zur Verwaltung der GNOME-Shell Extentions sind nicht installiert. Ubuntu-eigene Werkzeuge zur Konfiguration des Desktops sucht man auch vergebens.

Zur Installation von weiteren Anwendungen setzt Canonical auf 'Ubuntu Software', vermutlich eine Adaption von 'GNOME Software'. Diese grafische Oberfläche für den Debian-Paketmanager 'apt' ist eine Zumutung. Nicht nur, dass das Werkzeug sehr langsam startet, es dauert auch ewig, bis das Portfolio an Apps angezeigt wird. Da ich diese Lahmheit auch schon beim Test von Fedora-Silverblue festgestellt habe, laste ich das nicht zwingend Canonical an, sondern behaupte, dass 'GNOME Software' einer der zähsten Paketmanager.

Eine Suche in diesem App-Center fördert in erster Linie Snap-Pakete zutage, zum Beispiel für Gimp oder Inkscape. Fatal finde ich die Tatsache, dass einer der wichtigsten Anwendungen, nämlich der Webbrowser Firefox als Snap-Paket installiert ist. Jeder, der bereits mit Snaps gearbeitet hat, weiss, dass diese sehr langsam starten. Der Ubuntu-Firefox braucht sagenhafte 10 Sekunden für den Start; normal sind 1-2 Sekunden. Hinzukommt, dass nach der Installation der GNOME-Extentions, Ubuntu den 'Native Host-Connector' (sudo apt-get install chrome-gnome-shell) nicht vorinstalliert hat, was Anfänger vor ein unlösbares Problem stellt, wenn sie ihren Desktop anpassen möchten.

Fazit: 2 Punkte

4. Stabilität

Hier muss ich nicht viel schreiben oder testen (zumal ich eine Beta-Version anschaue). Ubuntu 22.04 ist eine Long-Term-Support Version, basiert auf Debian und gehört damit zu den Stabilsten: 5 Punkte.

5. Vorkonfiguration

Als Thema verwendet Ubuntu 'Adwaita/Yaru' mit einer hellen Darstellung, wobei dies nicht konsequent angewendet wird: Shotwell erscheint mit einem dunklen Thema. Auch das System-Thema kommt mit dunkler Färbung (Kalender, System-Tray, Benachrichtigungen). Das Erscheinungsbild ist nicht konsistent.

In den GNOME-Einstellungen gibt es die Möglichkeit, zwischen einem hellen und dunklem Thema umzuschalten. Wählt man das dunkle Thema, wird der Gesamteindruck konsistenter. Dennoch fällt auf, dass die Window-Dekorations zwischen hell und dunkeln schwanken:

Schauen wir erneut auf den Paketmanager. Natürlich kann man 'synaptic' installieren oder 'apt' im Terminal verwenden. Da wir Einsteigerlinuxe testen, ist das keine Option. Canonicals Paketmanager 'Ubuntu Software' ist eine Zumutung von vorne bis hinten. Auf der Suche nach den Einstellungen, um die Repositories auszuwählen, stiess ich nur auf die Option 'Anmelden', welche ich nicht geklickt habe. Auch über die Optionen der Aktualisierungsverwaltung hat man keine benutzerfreundlichen Einstellungen, um z.B. Snap-Pakete gegen Flatpak-Pakete auszutauschen.

Fazit: 3 Punkte.

6. Update-Prozess

Die Aktualisierungsverwaltung war schon immer eine Stärke von Ubuntu. Man kann auswählen, wie oft auf Aktualisierungen geprüft werden soll und ob das System die Änderungen direkt herunterlädt.

Der Update-Prozess funktioniert gut und hält sich angenehm zurück. Wer möchte, kann sich die Einzelheiten der laufenden Aktualisierung anschauen. Aber auch hier sieht man wieder Schwächen beim Theming.

Fazit: Läuft unaufdringlich und zuverlässig. Ich beobachte jedoch Inkonsistenzen zwischen den Einstellungen und der Update-Häufigkeit: 4 Punkte.

Bewertung

Kriterium	Bewertung (max. 5)
Installation	🏆️🏆️🏆️🏆️
Einführung	🏆️🏆️
Vollständigkeit	🏆️🏆️
Stabilität	🏆️🏆️🏆️🏆️🏆️
Vorkonfiguration	🏆️🏆️🏆️
Update-Prozess	🏆️🏆️🏆️🏆️
Summe	20+5 = 25

Fazit

Was 2004 mit 'Warty Warthog' begann, hat in den letzten 18 Jahren den Weg für Linux auf dem Desktop geebnet, und hat insbesondere Umsteigern und Anfängern einen Anlaufpunkt für ihren Einstieg in die wunderbare GNU/Linux-Welt gegeben. Für Hunderttausende von Schülern, Neugierige und Homeoffice-Geplagte ist und war Ubuntu die erste Wahl, um aus dem proprietären Sumpf zu entkommen.

Wer über so viele Jahre ein solides Produkt auf den Schultern von Debian, GNOME und der Community abliefert, hat Dank für die Wertschöpfung verdient. Insbesondere, wenn diese Leistung durch das Kapital einer Privatperson finanziert wurde.

Die Geschichte lehrt, dass nach dem Hochmut der Fall kommt. Canonical war mutig und hat viele Versuche zur Differenzierung unternommen, hat Ideen entwickelt und Projekte gestartet. Leider war keiner dieser Vorstösse erfolgreich, sondern hat eher dazu geführt, nicht mehr am gemeinsamen Strang der grossen GNU/Linux-Community mitzuziehen.

Heute ist Canonical eine erfolgreiche Firma, die Gewinn für Mark Shuttleworth abwirft. Er hat es wahrlich verdient. Erfolg geht meist Hand in Hand mit der Summe an USPs (unique selling proposition). Durch diese Abgrenzung hat sich Ubuntu nach und nach aus dem Zirkel der bevorzugten Distributionen ausgeschlossen. Heute wählen Einsteiger eher MX-Linux, Linux-Mint, Pop!_OS, Manjaro, ElementaryOS, Zorin oder die Originale aus: Debian, Red Hat, OpenSUSE, Arch-Linux und die darauf aufbauenden Derivate.

Lange Rede, kurzer Sinn: Weil ich eine Beta-Version getestet habe, gebe ich 5 Zusatzpunkte, womit Ubuntu 22.04 LTS (daily) bei 25 Punkten landet.

Fr, 4. Februar 2022, Lioh Möller

Fünf Jahre sind vergangen, seit der letzten stabilen Veröffentlichung der ältesten, noch aktiven Linux Distribution der Welt. Doch still geworden ist es um das Projekt eigentlich nie. Der primär zur Entwicklung der Distribution gedachte -current Zweig konnte sich zu einem beliebten Rolling-Release etablieren, der nicht nur bei Linux-Enthusiasten beliebt ist.

Die nun vorliegende Version 15.0 bringt erwartungsgemäss eine Vielzahl von Verbesserungen und Neuerungen mit sich. Die Kerndistribution enthält aktuell 1590 Pakete, was einer Steigerung von 19% im Vergleich zu Version 14.2 entspricht. Damit stieg die Grösse aller komprimierten Pakete von 2.4 GB auf 3 GB an und erstmals wird für eine vollständige Installation 16 GB Festplattenplatz oder mehr empfohlen.

Slackware 15.0 liefert den Kernel in Version 5.15.19 mit Preemption aus. Eine Installation auf NVMe Disks wird unterstützt und die UEFI Integration wurde weiter verbessert.

Im Gegensatz zu den meisten aktuell verfügbaren Linux-Distributionen bietet Slackware weiterhin einen Zweig für 32bit Prozessoren an.

Mit dem neu enthaltenen make_world.sh Script ist es möglich, die vorliegende Version vollständig aus dem Quellcode zu übersetzen. elogind ersetzt ConsoleKit2 und bietet die Möglichkeit der Integration moderner Desktop-Umgebungen, die Teilaspekte von systemd voraussetzen.

FFmpeg und Lame wurden hinzugefügt, sowie SDL2, speex, opus und fluidsynth. Postfix ersetzt Sendmail als Standardmailserver, wobei letzteres weiterhin im ./extra Repository verfügbar ist. Ergänzt wird dies durch Dovecot als IMAP Server.

Qt4 wurde durch Qt5 ersetzt und KDE Plasma 5.23.5 integriert. Ergänzt wird dies durch die Calligra Office Suite, Krita, Digikam, KMymoney dem Falkon Webbrowser und Kyle als LaTeX Editor.

Xfce ist in der aktuellen Version 4.16 enthalten.

Mit Wayland 1.20.0 steht ein alternativer Displayserver zur Verfügung, wobei X.Org in Version 1.20.14 weiterhin als Standard eingesetzt wird.

Neben Pulseaudio steht erstmalig PipeWire zur Verfügung, und ein einfaches Script zum Wechsel des Backends wurde integriert.

Changelog: http://www.slackware.com/changelog/stable.php?cpu=x86_64
Download Slackware 15.0 ISO x86_64: https://mirrors.slackware.com/slackware/slackware-iso/slackware64-15.0-iso/
Blogpost alienBOB: https://alien.slackbook.org/blog/slackware-15-0-has-been-released-on-2022-02-02/
inoffizielle Slackware 15.0 Live DVD: https://slackware.nl/slackware/slackware-live/slackware64-15.0-live/

Viele Distributionen wie Ubuntu, Debian, Fedora oder Arch Linux setzen inzwischen verpflichtend oder optional auf Benutzeraccounts mit erweiterten Rechte anstelle eines umfassenden root-Accounts. Auch mit openSUSE lässt sich so etwas umsetzen.

Ich arbeite mit einem ziemlich speziellen openSUSE-System. Ich habe das System sehr genau auf meine Bedürfnisse angepasst und ausgehend von einer minimalen Installation aufgebaut (das ist kein Arch-Spezifikum, auch wenn die Arch-Nutzer das manchmal glauben). Das System betreibe ich gänzlich ohne YaST und seit Neuestem mit systemd-homed.

Um das System besser an meine Bedürfnisse anzupassen, nutze ich zudem sudo anstelle eines root Accounts. Das ist bei openSUSE standardmäßig nicht vorgesehen, aber openSUSE ist eine sehr flexible und wenig dogmatische Distribution. Es erfordert aber einige Änderungen am System.

openSUSE auf sudo umstellen

Sudo einrichten

Zuerst muss man sudo installieren und konfigurieren:

# zypper in sudo

Anschließend ist sudo zu konfigurieren.

# EDITOR=nano visudo 

Zuerst entfernt man die SUSE-Standardkonfiguration, nach der sudo mit dem root-Account ausgeführt wird. Dazu müssen zwei Zeilen auskommentiert werden. Dazu setzt man ein # vor die Zeile. Das Ergebnis muss wie folgt aussehen:

#Defaults targetpw   # ask for the password of the target user i.e. root
#ALL   ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!

Der Eintrag für die Gruppe wheel muss aktiv geschaltet werden (dazu das # vor der Zeile entfernen). Das Ergebnis muss wie folgt aussehen:

# Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL

Um grafische Programme mit sudo starten zu können sind zudem in folgender Zeile am Ende folgende zwei Ergänzungen zu machen. Die … stehen für die vielen Variablen dazwischen.

Defaults env_keep = "LANG ... DISPLAY XAUTHORITY"

Danach fügt man den Benutzeraccount, der mittels sudo erweiterte Rechte erhalten können soll, der Gruppe wheel hinzu. Bei einem herkömmlichen Benutzer geht das mit folgendem Befehl.

# usermod -aG wheel <benutzername>

Bei einem systemd-homed-Benutzer ist der Befehl anders:

# homectl update <benutzername> -G wheel

Hierbei unbedingt beachten, dass immer alle Gruppe genannt werden müssen, weil alle Gruppenmitgliedschaften überschrieben werden. Die Ausgabe könnte also wie folgt lauten:

# homectl update gheim -G vboxusers,users,wheel

Danach muss der Benutzer einmal ab- und wieder angemeldet werden. In der Konsole ist zu überprüfen, ob man mittels sudo entsprechende Befehle ausführen kann. Beispielsweise:

$ sudo zypper dup

Grafische Programme ohne root-Passwort starten

Manche Programme fragen beim Start das root-Kennwort ab. Beispielsweise YaST oder Programme wie der KDE-Partitionmanager. Unter KDE kann man das mit folgendem Befehl anpassen. Dazu wird eine entsprechende Konfiguration des Benutzers in ~/.config angepasst.

$ kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo

Root deaktivieren

Nun benötigt man den root-Account nicht mehr und kann ihn deaktivieren:

$ sudo passwd -l root

Sollte man ihn wieder benötigen, kann man ihn mit folgendem Befehl aktivieren:

$ sudo passwd -u root

Tipps & Tricks

Natürlich geht openSUSE in vielen Konfigurationen von der Existenz eines root-Accounts aus. Beispielsweise kann man keinen Drucker einrichten oder ändern, weil der Account mit sudo-Rechten nicht akzeptiert wird. Das lässt sich mit einer Änderung in der Datei /etc/cups/cups-files.conf ändern:

$ sudo nano /etc/cups/cups-files.conf

Hier ist folgender Eintrag zu suchen und wie folgt um die Gruppe wheel zu ergänzen:

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup wheel root

Benötigt man all das? Nein sicher nicht. Aber eine der Stärken von Linux ist, dass man sein System so einrichten kann, wie man es nutzen möchte. Mit diesem und anderen Artikeln möchte ich zeigen, wie mächtig openSUSE ist und dass es mindestens so flexibel und individuell konfiguriert werden kann, wie z. B. Arch Linux.

Der Artikel openSUSE mit sudo und ohne root Account erschien zuerst auf [Mer]Curius

Do, 3. Februar 2022, Lioh Möller

Die ersten Versionen der SUSE Linux Distribution gingen als das deutsche Slackware über den Ladentisch. Und das wortwörtlich, denn die Distribution wurde in erster Linie über den Buch- und Versandhandel vertrieben. Durch YaST (Yet another Setup Tool) sollte die Einrichtung und Verwaltung des Systems deutlich vereinfacht werden, doch insbesondere Version 1 von YaST wurde von vielen Anwendern eher gefürchtet als geliebt. In einer riesigen Konfigurationsdatei konnten nahezu alle Aspekte des Systems eingestellt werden. Manuelle Änderungen wurden dabei oftmals nach einem erneuten Aufruf der Applikation überschrieben und das Zusammenführen von Konfigurationsvariablen funktionierte entweder gar nicht oder nur sehr bedingt.

Mit der Einführung von YaST 2 und der einhergehenden Modularisierung besserte sich dies. Weiterhin war S.u.S.E. Linux primär als sogenannte Boxed-Version, also in einer Kartonschachtel mit ausführlichem Handbuch erhältlich.

Mit der zunehmenden Verfügbarkeit schneller Internetverbindungen im Heimbereich und der Einführung von openSUSE als Community Projekt, änderte sich dies. Dabei wurde openSUSE zunächst als eine Distributionsspielart angeboten, erst später erfolgte eine Aufteilung in die Zweige Leap und Tumbleweed. Letzteres richtet sich primär an Entwickler und Technikinteressierte und wird im Rolling-Release-Modell ausgeliefert. Leap wurde mit der aktuellen Version 15.3 mit dem kostenpflichtigen Enterprise-Produkt SLE (SUSE Linux Enterprise) harmonisiert und nutzt seither identische Pakete im Basisumfang des Systems.

Für den folgenden Test auf Einsteigertauglichkeit kommt openSUSE Leap 15.4 Alpha zum Einsatz.

1. Installation

Das angebotene DVD-Installationsmedium startet direkt in das Installationsprogramm. Zu Beginn lässt sich die Sprache und das Tastaturlayout auswählen.

Über ein Testfeld kann die gewählte Tastaturbelegung überprüft werden. Daraufhin besteht die Möglichkeit Online-Paketquellen einzubinden, was bei einer bestehenden Internetverbindung empfohlen wird, da so während der Installation bereits Aktualisierungen installiert werden können.

Bereits an dieser Stelle wird die Nähe zum kommerziellen Ableger deutlich. Die vorausgewählten Repositories können beibehalten oder bei Bedarf ergänzt werden.

Lange Zeit war KDE Plasma bei openSUSE als Desktopumgebung vorausgewählt. Nach Kritik aus der Community wird es weiterhin zuerst angeboten, es erfolgt allerdings keine automatische Vorauswahl. Wir entscheiden uns dennoch für die Variante mit der Plasma-Desktopoberfläche.

Ein Verzicht auf eine Desktop-Vorauswahl ist aus Community-Perspektive gerechtfertigt und richtig, kann allerdings eine Hürde darstellen.

Standardmässig kommt seit einiger Zeit Btrfs als Dateisystem zum Einsatz. Dieses bietet die Möglichkeit Snapshots, beispielsweise vor einer Systemaktualisierung zu erstellen und im Fehlerfalle auf die letzte funktionierende Vorgängerversion zurückzukehren. Nachteilhaft wirkt sich die erhöhte Komplexität aus, was sich im Alltag allerdings nicht bemerkbar macht. Eine Festplattenverschlüsselung lässt sich mithilfe des Installationsprogramms ebenfalls einfach einrichten.

Während der Erstellung des Benutzerkontos wird standardmässig eine automatische Anmeldung am System vorausgewählt. Bei Bedarf lässt sich der entsprechende Punkt deaktivieren.

Sofern dem Benutzer keine Systemadministratoren-Rechte vergeben werden, kann im Folgenden ein separates Root-Passwort definiert werden.

Abschliessend wird eine Übersicht der konfigurierten Optionen angezeigt, in der weitere Anpassungen durchgeführt werden können. Bis zu diesem Zeitpunkt wurden noch keine Veränderungen am Zielsystem vorgenommen und erst ein Klick auf Installieren sowie eine weitere Bestätigung führt die eigentliche Installation aus.

2. Einführung

Nach dem ersten Start des Systems und der Anmeldung an der KDE Plasma Oberfläche, wird ein Willkommensassistent angezeigt, der interessierte Anwender über die wichtigsten Aspekte des Systems informiert. Dabei wird auf die Installation von zusätzlichen Anwendungen und unfreien Komponenten ebenso eingegangen, wie auf die grundlegende Bedienung des Plasma Desktops.

3. Vollständigkeit

Neben Standardanwendungen wie Firefox werden unter anderem LibreOffice und die KOffice-Suite sowie der Multimedia-Player VLC mitgeliefert. Erweitern lässt sich der Softwareumfang auf einfache Weise über die YaST Paketverwaltung oder die eigens dafür eingerichtete Webseite software.opensuse.org. Dabei kommen sogenannte 1-Klick-Installationsassistenten zum Einsatz, welche nach dem Öffnen automatisch YaST starten, über das sich die Installation des gewünschten Paketes auslösen lässt.

Für Kurzweil sorgt eine Auswahl an Spielen aus der KDE Games Sammlung.

4. Stabilität

Obwohl bei unseren Tests die Alpha Version des kommenden openSUSE Leap Releases 15.4 zum Einsatz kam, erwies sich das System auch im längeren Betrieb als äusserst zuverlässig und stabil.

5. Vorkonfiguration

Das Erscheinungsbild ist durchgängig, angefangen beim Bootloader über den Splash-Screen bis zum Anmeldebildschirm und die eigentliche Desktopumgebung. Alle wichtigen Aspekte des Systems lassen sich über YaST auf einfache Weise konfigurieren. Der integrierte Assistent führt Einsteiger in die wichtigsten Bereiche des Systems ein. Die Softwareauswahl ist vollständig und lässt sich bei Bedarf ohne grossen Aufwand erweitern. Bei Bedarf lassen sich auch proprietäre Codecs mittels 1-Klick-Installer einbinden.

Insbesondere die voreingestellte Firewall, welche auf firewalld basiert, sorgt für ein zusätzliches Mass an Sicherheit auf dem Desktop.

6. Update-Prozess

Anstehende Systemaktualisierungen werden dem Nutzer über einen Hinweis im Systemabschnitt der Taskleiste angezeigt. Alternativ kann direkt die Online-Aktualisierung in YaST aufgerufen werden. Ein Wechsel auf eine neue Distributionsversion lässt sich online oder über die entsprechenden Installationsmedien durchführen.

Bewertung

Kriterium	Bewertung (max. 5)
Installation	🏆️🏆️🏆️🏆️
Einführung	🏆️🏆️🏆️🏆️🏆️
Vollständigkeit	🏆️🏆️🏆️🏆️
Stabilität	🏆️🏆️🏆️🏆️🏆️
Vorkonfiguration	🏆️🏆️🏆️🏆️🏆️
Update-Prozess	🏆️🏆️🏆️🏆️🏆️
Summe	28

Fazit

openSUSE in der Leap Version eignet sich sehr gut für Linux-Einsteiger. Lediglich die Wahl der zu verwendenden Desktopoberfläche kann zu einer Unschlüssigkeit führen. Das System ist im Standardumfang vollständig, aber nicht überladen. Eine Installation von weiteren Applikationen ist auch für Erstanwender ohne weiteres möglich.

Download: https://get.opensuse.org/leap/

Gelegentlich hat Ubuntu bzw. Linux einfach Fehler, bei denen man denkt: Das darf nicht passieren! Das verhindert die Alltagstauglichkeit! Gestern war es mal wieder soweit.

So beschleicht mich das Gefühl, Ubuntu hat eine eingebaute Lebenserwartung. Mehr als 5 Jahre und zwei LTS-Upgrades sind wohl nicht drin. Ich berichtete kürzlich ja schon mal über einen vollgelaufenen Paket-Cache in einem System. Am Wochenende machte dann das andere Kubuntu-System Probleme mit demselben Fehler. Also reagierte ich natürlich selbstsicher und der Anwender und ich spielten die dort geschilderte „Lösung“ durch. Sache geklärt! Leider nicht, wie sich gestern herausstellte, denn das Problem trat ein paar Tage später erneut auf. Daher nun doch, nachdem wir erfolgreich auf der grafischen Oberfläche waren, einen Blick mit AnyDesk auf das System geworfen.

Das Problem war mit einem schnellen Blick auf die Ausgabe von dpkg -l gefunden. 25 installierte Kernel plus die zugehörigen Extra-Module und Header. Irgendwann war dann halt mal „voll“. Aber es ist immer gut einen älteren Kernel in Reserve zu haben, oder zwei, oder drei, oder fünfundzwanzig.

Dieses „Kernel-Problem“ ist bekanntermaßen exklusiv für Ubuntu und kein allgemeines Linux-Problem. Trotzdem meinte ich, dass das irgendwann in der Vergangenheit mal gelöst worden war. Dem scheint nicht so zu sein oder die Änderung wurde bei den Upgrades nicht nachvollzogen. Per Autoremove wurden die Kernel jedenfalls nicht zur Entfernung vorgeschlagen, es war also kein Problem der Anwendung oder Systempflege.

• Erster Befund: Solche Probleme dürfen einfach nicht passieren, das muss durch eine bessere Standardkonfiguration abgefangen werden.
• Zweiter Befund: Schön, dass wir über den Speicherbedarf von Snaps reden. Die Paketverwaltung funktioniert schließlich perfekt.
• Dritter Befund: Upgrades bleiben eine Sollbruchstelle von Linux. Selbst wenn nahezu keine Veränderungen am System vorgenommen wurden, ist nach mehreren Upgrades unklar welchen Zustand die Konfiguration widerspiegelt und welche Änderungen übernommen wurden.

Die Systeme werden in jedem Fall im Frühjahr nicht mehr aktualisiert. Wer weiß, was da noch so tief in den Systemeinstellungen durch die Upgrades nicht auf dem aktuellen Stand ist. Vermutlich werden sie stattdessen im Sommer auf openSUSE Leap 15.4 umgestellt. Nicht, dass dort alles perfekt wäre, aber die SLE-Basis ist qualitativ schon sehr gut und die Upgrade-Routine nicht so eine Blackbox wie bei Ubuntu.

Den Anwendern ist der Unterbau egal, so lange sie einen KDE Plasma-Desktop auf einer Linux-Basis haben. Denn überzeugte Linux-Anwender sind sie in den letzten Jahren geworden und das ist doch immerhin mal positiv.

Der Artikel Ubuntu – Fehler, die nicht existieren dürften Teil II erschien zuerst auf [Mer]Curius

Mi, 2. Februar 2022, Lioh Möller

Bei Trisquel handelt es sich um eine GNU/Linux Distribution, welche vollständig auf Freier Software basiert. Dabei kommt der Linux-libre Kernel zum Einsatz, welcher keine sogenannten Binary Blobs enthält. Letztere kommen in der Regel in der Form von Firmware bei der Nutzung bestimmter Hardwarekomponenten zum Einsatz, beispielsweise bei WLAN-Adaptern.

Damit ist Trisquel eine der wenigen Distributionen, die den Richtlinien für Freie GNU/Linux-Verteilungen der Free Software Foundation entspricht. Mit dem Verzicht einher, geht eine schlechtere Hardwareunterstützung, da sich viele Geräte ohne die proprietären Firmwarebestandteile nicht betreiben lassen.

Nun liegt Trisquel in Version 10.0 (Codename Nabia) vor, welches auf Ubuntu 20.04 basiert.

Üblicherweise werden unterschiedliche Ausprägungen der Distribution angeboten. Die Standardvariante Trisquel nutzt Mate in Version 1.24 als Desktopumgebung. Alternativ steht mit Triskel eine Option mit dem KDE Plasma Desktop in Version v5.68 zur Verfügung. Trisquel mini ist mit LXDE in Version v0.99.2 deutlich ressourcensparender. Die Netzwerkmedien erlauben eine angepasste Installation, beispielsweise als Serverbetriebssystem.

Standardmässig wird der GNU Linux-libre 5.4 verwendet, alternativ werden die Kernelversionen 5.8 und 5.13 angeboten.

Bei Abrowser handelt es sich um ein Firefox Derivat ohne unfreie Bestandteile, welches darüber hinaus einen besseren Schutz der Privatsphäre bietet. Trisquel Nabia liefert den Browser in Version 96.0 aus.

Ähnlich verhält es sich mit dem Thunderbird Pendant Icedove, welches in Version 91.5.0 mitgeliefert wird. LibreOffice ist in Version 7.1.7 enthalten und der VLC Video Player in Version 3.0.9.2.

Trisquel 10.0 wird erstmals auch für die armhf Architektur angeboten, wobei noch keine Unterstützung für spezifische Single Board Computer angeboten wird. In Zukunft soll auch eine Nutzung auf 64-bit ARM und PowerPC möglich sein.

Darüber hinaus fanden viele Arbeiten im Bereich der Modernisierung der Infrastruktur des Projektes statt, was zu einer Beschleunigung zukünftiger Entwicklungen und zu einer verbesserten Einbindung der Community führen soll.

Quelle: https://trisquel.info/en/trisquel-10-nabia-release-announcement

Mi, 2. Februar 2022, Caos

Als eine der Ergänzungen zu dem Artikel „Olden but golden: Aktuelle Linux-Distributionen für 32-Bit“ möchte ich noch auf die Distribution Crunchbang++ hinweisen.
Sowohl das bereits im o.g. Artikel erwähnte Bunsenlabs als auch Crunchbang++ sind Community-Nachfolgeprojekte der Distribution Crunchbang #!, dessen Entwicklung 2015 aus Zeitgründen eingestellt wurde. Das Hauptziel des Crunchbang-Projekts war es, eine stabile Distribution zu entwickeln, die das bestmögliche Openbox-Erlebnis out-of-the-box bieten sollte.
An diese Devise knüpfen beide an, und so eignen sich auch beide hervorragend für ältere Hardware.

Das aktuellste Bunsenlabs basiert auf Debian 10 Buster, der Unterbau von Crunchbang++ ist dagegen bereits Debian 11 Bullseye, es baut also auf dem neuesten stabilen Debian-Zweig auf und geniesst damit Unterstützung bis 2025.
Auch Crunchbang++ stellt noch ein non-pae i868-Image bereit, ist also auch für 32-Bit-Geräte, deren Prozessor die Erweiterung PAE (Physical Adress Extension) nicht unterstützt, geeignet. Es bietet sich damit als schlanke Alternative an, die auch sehr alten Geräten wieder neues Leben einhauchen kann.

Software
Das System begrüsst mit einem 12-teiligen Post-Installations-Script „cbpp-welcome“, das Systemupdate/ -upgrade, Printer- und Java-Support sowie „packages used for developing software“ wie u.a. SSH und LAMP Stack beinhaltet.
Es ist bereits einiges an Software vorinstalliert. Neben schlanken Anwendungen wie Filemanager Thunar, Abiword, Gnumeric, Xfburn, Atril pdf-Viewer, Viewnior Image Viewer sind auch GIMP, VLC und Firefox ESR dabei. LibreOffice und Chromium lassen sich per Anwendungsmenü direkt nachinstallieren.
Alles Weitere lässt sich über apt aus den Debian-Paket-Quellen oder über Synaptic installieren. Deutsche Sprachpakete müssen manuell nachinstalliert werden.

Geringe Systemanforderungen
Die Hardwarevoraussetzungen sind mit 512 MB RAM als sehr niedrig angegeben. Der Window-Manager Openbox ist leichtgewichtig und daher sehr schnell.
Das Design von Crunchbang++ ist nochmals minimalistischer im Vergleich zu Bunsenlabs. Als Wallpaper werden neben dem voreinstellten schwarzen Hintergrund noch verschiedene Varianten in Dunkelgrau und Anthrazit angeboten, ein frisches Steingrau steht dagegen nicht bereit.

Live-System und Installation
Das System lässt sich nicht aus dem Live-System heraus installieren. Beim Booten besteht die Auswahl zwischen Live-Modus und Installation. Name und Kennwort für die Live-Session lauten „live“.

Quellen:
https://crunchbangplusplus.org/
LinuxWelt 2/2022, S. 11: Crunchbang++ 11.1
https://crunchbang.org/about/
https://www.bunsenlabs.org/

Di, 1. Februar 2022, Ralf Hersel

Während die neue Version 6.1 von Elementary OS gerade erst erschienen ist, arbeitet das Team bereits an der nächsten grossen Version Elementary OS 7, die im Laufe des Jahres erscheinen wird. Cassidy James Blaede, Mitbegründer und CXO von Elementary, spricht in einem aktuellen Blogbeitrag über einige der Funktionen und Verbesserungen, die in der Version 7 enthalten sein werden.

Elementary OS 7 wird auf Ubuntu 22.04 LTS (Jammy Jellyfish) aufbauen. Die Tatsache, dass es auf einer Ubuntu LTS-Serie basiert, bedeutet, dass die nächste grosse Elementary OS-Version auch für mehrere Jahre mit kleineren Punkt-Releases unterstützt werden kann.

Während Canonical beschlossen hat, GTK4-Anwendungen in Ubuntu 22.04 LTS so weit wie möglich zu vermeiden, planen die Entwickler von Elementary das Gegenteil und versprechen, dass Version 7 nativ mit GTK4 ausgeliefert wird. Darüber hinaus soll auch die libadwaita Bibliothek übernommen werden, die u.a. ein dunkles Thema für die meisten GTK4-Anwendungen ermöglicht. Elementar-OS 7 verspricht auch eine verbesserte Energieverwaltung und Akku-Einstellungsfunktionen, mit denen man das System für den Energiesparmodus, den ausgeglichenen Modus oder den Leistungsmodus konfigurieren kann, zusammen mit einem neuen Abschnitt über den Akkustatus für Laptop-Nutzer.

Zwei weitere wichtige Änderungen könnten mit dem nächsten Major Release auf elementary OS zukommen, nämlich automatische Updates im AppCenter und eine komplett überarbeitete Musik-App, die von Grund auf in GTK4 geschrieben wurde. Zudem wird eine "OS-Upgrade"-Funktion für Elementary OS 7 in Erwägung gezogen, die es den Nutzern ermöglichen würde, zwischen den Hauptversionen zu wechseln, ohne ein neues ISO-Image herunterladen zu müssen; diese Funktion befindet sich jedoch noch in einem sehr frühen Stadium und wird möglicherweise nicht in der endgültigen Version enthalten sein.

Die Daily Builds von Elementary OS 7 sind jetzt über die Early-Access-Initiative des Projekts erhältlich. Das endgültige Veröffentlichungsdatum und der Codename werden noch bekannt gegeben.

Quelle: https://blog.elementary.io/updates-for-january-2022/

Di, 1. Februar 2022, Ralf Hersel

Während die neue Version 6.1 von Elementary OS gerade erst erschienen ist, arbeitet das Team bereits an der nächsten grossen Version Elementary OS 7, die im Laufe des Jahres erscheinen wird. Cassidy James Blaede, Mitbegründer und CXO von Elementary, spricht in einem aktuellen Blogbeitrag über einige der Funktionen und Verbesserungen, die in der Version 7 enthalten sein werden.

Elementary OS 7 wird auf Ubuntu 22.04 LTS (Jammy Jellyfish) aufbauen. Die Tatsache, dass es auf einer Ubuntu LTS-Serie basiert, bedeutet, dass die nächste grosse Elementary OS-Version auch für mehrere Jahre mit kleineren Punkt-Releases unterstützt werden kann.

Während Canonical beschlossen hat, GTK4-Anwendungen in Ubuntu 22.04 LTS so weit wie möglich zu vermeiden, planen die Entwickler von Elementary das Gegenteil und versprechen, dass Version 7 nativ mit GTK4 ausgeliefert wird. Darüber hinaus soll auch die libadwaita Bibliothek übernommen werden, die u.a. ein dunkles Thema für die meisten GTK4-Anwendungen ermöglicht. Elementar-OS 7 verspricht auch eine verbesserte Energieverwaltung und Akku-Einstellungsfunktionen, mit denen man das System für den Energiesparmodus, den ausgeglichenen Modus oder den Leistungsmodus konfigurieren kann, zusammen mit einem neuen Abschnitt über den Akkustatus für Laptop-Nutzer.

Zwei weitere wichtige Änderungen könnten mit dem nächsten Major Release auf elementary OS zukommen, nämlich automatische Updates im AppCenter und eine komplett überarbeitete Musik-App, die von Grund auf in GTK4 geschrieben wurde. Zudem wird eine "OS-Upgrade"-Funktion für Elementary OS 7 in Erwägung gezogen, die es den Nutzern ermöglichen würde, zwischen den Hauptversionen zu wechseln, ohne ein neues ISO-Image herunterladen zu müssen; diese Funktion befindet sich jedoch noch in einem sehr frühen Stadium und wird möglicherweise nicht in der endgültigen Version enthalten sein.

Die Daily Builds von Elementary OS 7 sind jetzt über die Early-Access-Initiative des Projekts erhältlich. Das endgültige Veröffentlichungsdatum und der Codename werden noch bekannt gegeben.

Quelle: https://blog.elementary.io/updates-for-january-2022/

Mo, 31. Januar 2022, Lioh Möller

Die nun vorliegende Version des Raspberry Pi OS vom 28.01.2022 beinhaltet eine Vielzahl von Fehlerkorrekturen und Verbesserung. Raspberry Pi OS basiert auf Debian GNU/Linux 11 "Bullseye" und enthält ein CLI-Konfigurationsprogramm namens raspi-config sowie das grafisches Pendant rc_gui. Letzteres ermöglicht jetzt die Einstellung der Bildschirmauflösungen für VNC-Verbindungen. Darüber hinaus wird der Mutter Compositor automatisch deaktiviert, sobald eine VNC Verbindung auf das System aufgebaut wurde. Mittels raspi-config lässt sich Compositing steuern und der Legacy Kameramodus aktivieren. Auch hierüber kann die Bildschirmauflösung für VNC Verbindungen konfiguriert werden, was insbesondere für Szenarien interessant sein dürfte, bei denen kein direkt an den Raspberry Pi angeschlossener Bildschirm zum Einsatz kommt.

Die Taskleiste LXPanel der eingesetzte LXDE-basierten PIXEL-Desktopumgebung wurde ebenfalls aktualisiert. Der Einstellungsdialog zur Konfiguration des Erscheinungsbildes wurde durch eine neue Menüoption ersetzt, die es dem Benutzer ermöglicht, die allgemeinen Erscheinungsbildeinstellungen des Systems zu öffnen.

Das Programm lxinput zur grafischen Konfiguration von Tastatur und Maus, liest die aktuelle Mausbeschleunigung direkt über xinput aus und verwendet neu Geräte-IDs anstelle von Namen, um besser mit Geräteänderungen umgehen zu können.

ARandR zur grafischen Konfiguration der Bildschirmauflösung ist mit den neuen Touchscreen-Treibern in Raspberry Pi OS kompatibel. xrdp wurde aus der kommenden Debian GNU/Linux 12 "Bookworm" Version zurückportiert und dem Lite-Image wurden mehrere neue Werkzeuge hinzugefügt (MKVToolNix, udisks2, 7z und zip). Das Desktop-Image enthält neu GNOME-Keyring.

Bei der aktuellen Version des Raspberry Pi OS kommt der Linux-Kernel 5.10.92 zum Einsatz.

Release Notes: https://downloads.raspberrypi.org/raspios_armhf/release_notes.txt

Mit Common Voice stellt Mozilla den weltweit größten öffentlichen Datensatz menschlicher Stimmen bereit – kostenlos und für jeden nutzbar. Nun hat Mozilla Version 8.0 seines nun noch einmal 30 Prozent größeren Datensatzes veröffentlicht, inklusive elf weiterer Sprachen.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im Jahr 2017 das Projekt Common Voice gestartet. Mit Common Voice bietet Mozilla eine kostenlose Alternative an, zu der jeder beitragen kann und die jedem zur Verfügung steht. Damit möchte Mozilla Innovation und Wettbewerb in der Sprachtechnologie auf Basis von Maschinenlernen fördern.

Im vergangenen Jahr hat Mozilla Common Voice Investitionen von Nvidia, der Bill & Melinda Gates Foundation, der Deutschen Gesellschaft für Internationale Zusammenarbeit (GIZ) und dem britischen Außenministerium in Gesamthöhe von knapp fünf Millionen Dollar erhalten.

Mit dem nun veröffentlichten Common Voice Corpus 8.0 umfasst die Menge der aufgenommenen Sprachdaten jetzt mehr als 18.000 Stunden gegenüber den noch knapp unter 14.000 Stunden der im August 2021 veröffentlichten Version 7.0. Mit elf zusätzlichen Sprachen deckt Mozilla Common Voice jetzt außerdem insgesamt 87 Sprachen ab.

Zum Download der Mozilla Common Voice Datensätze

Der Beitrag Mozilla veröffentlicht Common Voice Corpus 8.0 erschien zuerst auf soeren-hentzschel.at.

Gestern erschien auf Linuxnews ein Bericht über die Lage von Open Source in München. In den Kommentaren ging es dann mal wieder nur um LiMux. Das Projekt ist seit 2017 tot. Hat mal jemand in den Kalender geschaut?

Werfen wir mal einen kurzen Blick auf die Eckdaten. Anlass für LiMux war die Ablösung von Windows NT 4 und entsprechende Studien im Jahr 2003. Heutige Studienanfänger waren da oft noch nicht geboren. Drei Jahre später rollte man die erste Desktopinstallation mit Debian und KDE 3 aus. Spätestens ab 2012/2013 kommt das Projekt in schweres Fahrwasser. Auch knapp 10 Jahre nach dem Start ist man weit von einer vollständigen Umsetzung entfernt. 2015 ist das Ende des Projekts bereits absehbar und 2017 zieht die Münchner Stadtverwaltung offiziell den Stecker und leitet die Re-Migration auf Microsoft-Lösungen ein.

Das kam keineswegs überraschend, denn LiMux hatte Probleme. Ich hatte mich bereits zwei Jahre vor Projektende hier im Blog damit beschäftigt und versucht zusammenzutragen, wie eigentlich die Basis von LiMux aussieht und was es für Probleme gibt. Erstaunlich finde ich seitdem, wie hartnäckig diese Probleme in der Berichterstattung ignoriert wurden und werden. Diese Gemengelage aus Projektteam, Interessenvertretern, Linux-Community, parteiischer Berichterstattung und der Unwillen oder die Unfähigkeit, andere Perspektiven einzunehmen, sind vermutlich der Hauptgrund für die bis heute verzerrte Wahrnehmung.

Doch wie dem auch sei, wir reden hier über Ereignisse, die also 5 bis 19 Jahre her sind. Damals gab es keine Smartphones, eine deutlich weniger IT-gestützt arbeitende Verwaltung und wir fangen besser gar nicht von den indirekten Pandemie-Folgen wie verstärktes Homeoffice etc. an.

Projekte scheitern. Wer noch nie ein Projekt beerdigen musste, hat noch nie in Projekten gearbeitet oder macht sich etwas vor. Manche Projekte scheitern in einem großen Knall, manche schleifen sich langsam aus, bis irgendjemanden den Stecker zieht, bei manchen verändern sich die Rahmenbedingungen so sehr, dass das Projekt überflüssig wurde. Meistens ist es eine ungünstige Verkettung von Umständen und Fehlentscheidungen, gepaart mit mangelhafter Kommunikation (was viel zu oft unterschätzt wird). Läuft die Dynamik erst mal gegen ein Projekt, kann man es meist nicht mehr retten. Dann heißt es zwei Schritte zurückmachen, Fehleranalyse durchführen und vielleicht in ein paar Jahren einen neuen Anlauf unternehmen.

LiMux war eine große Chance. München erwog sehr früh eine Open Source-Umstellung und war seiner Zeit weit voraus, dazu muss man sich nur die Jahreszahlen anschauen. LiMux bot somit die Chance, ein Leichtturmprojekt zu werden, aus dem – egal wie es ausgeht – viele Lehren gezogen werden könnten.

LiMux endete als absoluter Flop – und das in zweierlei Hinsicht. Es war ein Flop für Linux in der Verwaltung. Hätte LiMux Erfolg gehabt, hätte es möglicherweise ausgestrahlt auf andere Bereiche und wir wären heute nicht so abhängig von Microsoft. Ein ehemaliger SPD-Kanzlerkandidat würde hierzu sagen „hätte, hätte, Fahrradkette“. LiMux war aber auch ein Flop im Bereich der Evaluation. Das gescheiterte Projekt bot eigentlich die Gelegenheit für Open Source-Interessensverter und die Linux-Community aus Problemen zu lernen. 2017 waren neue Anläufe wie „Public Money, Public Code“ schließlich bereits in der Pipeline.

Folgende Fragen für eine tiefergehende Beschäftigung fallen mir da spontan ein. Grob geordnet von abstrakteren Punkten bis zu konkreteren Fragen:

• Wie kommuniziert man ein solches Projekt, um alle relevanten Stakeholder mitzunehmen?
• Wie muss das Vergaberecht angepasst werden, um Open Source in der Verwaltung zu stärken.
• Wie können durch Ausbildung und Personalentwicklung die Grundlagen für solche Projekte in der Verwaltung gelegt werden?
• Wie muss die IT-Abteilung einer Kommune oder eines Bundeslandes strukturiert sein, um solche Projekte erfolgreich durchzusetzen. Was muss hier zentral und was kann dezentral entschieden werden?
• Ist es klug gleich eine vollständige Migration anzustreben oder sollte man nicht mit Programmen und einzelnen Verfahren beginnen und ganz am Schluss möglicherweise das Betriebssystem angehen.
• Ist es sinnvoll mit dem Kostenargument zu werben oder ist Open Source am Ende nicht preiswerter als proprietäre Software.
• Ist es zielführend auf professionellen externen Support wie ihn z. B. SUSE oder Red Hat bieten können zu verzichten.
• Gibt es genug Dienstleister im Linux-Segment in Deutschland um bei Bedarf Service einzukaufen?
• Ist es sinnvoll eine eigene Distribution zu entwickeln?
• Ist die Entwicklung rund um den Linux-Desktop möglicherweise zu volatil für einen Einsatz in eher statischen Umgebungen.
• Hat der Linux-Desktop wirklich die geeigneten Tools um ohne „Turnschuhprinzip“ auf tausenden Rechnern einer Verwaltung zu laufen?
• Ist OpenOffice/LibreOffice wirklich eine adäquate Grundlage für Fachverfahren oder sollte man lieber eine andere Lösung nehmen bzw. entwickeln lassen.
• Gibt es geeignete Groupware-Lösungen auf dem Niveau von Exchange/Outlook?
• Ist es klug die Bedarfe von Verwaltungsangestellten immer einfach als unqualifiziert abzutun?
• Welchen Schulungsbedarf erzeugt man, wenn man nicht auf privates Windows-Vorwissen vertrauen kann?

Diese Liste ließe sich beliebig fortführen. Nicht alle diese Punkte müssen negativ ausfallen, aber Evaluationen bringen meist komplexe Befunde heraus und benennen selten einseitig Schuldige. Die Regierungskoalition in München hatte daran kein Interesse, nachdem sie die gewünschte Abkehr von LiMux erreicht hatte. Zumal man entsprechende Berichte ja vorgelegt hatte. Diese wurden halt nur von der Linux-Community als parteiisch abgelehnt.

Die LiMux-Befürworter haben sich dann aber auch lieber in einseitigen Schuldzuweisungen in Richtung Bürgermeister ergangen und sich auf den Standpunkt gestellt, dass es keine sachbezogenen Gründe gab bzw. diese immer außerhalb ihrer Zuständigkeit gesehen. Von Interessenvertretungen wie z. B. der FSFE kam auch nichts dergleichen. Das Ergebnis sieht man ja wieder in den Kommentaren auf Linuxnews. Dort liest man die seit langem bekannten „Erklärungen“. Da geht es dann um eine verlagerte Microsoft-Zentrale, einen Bürgermeister, dem man entweder Korruption oder Unfähigkeit unterstellt, Abteilungsleiter, die gegen die IT gearbeitet haben (wo wir übrigens wieder bei Kommunikation wären, denn wie kam es dazu?) und andere Rechtfertigungen.

Unbestritten ist, dass es am Ende an politischer Rückendeckung für das Projekt fehlte. Dennoch wäre bei einer erfolgreichen und abgeschlossenen Migration kein Bürgermeister binnen 2 Jahren in der Lage gewesen, eine vollständige Rückabwicklung eines Projekts einzuleiten. Dieses argumentative Spannungsfeld konnten die LiMux-Befürworter nie logisch auflösen.

Dadurch endete das Projekt als doppelter Flop. Es scheiterte nicht nur, es wurden auch keine Lehren aus dem Projekt gezogen, weil alle Beteiligten mit Gesichtswahrung beschäftigt waren und dafür eilfertige Unterstützung in der Berichterstattung erhielten.

Die Chance, aus dem LiMux-Scheitern zu lernen, ist nun endgültig vertan. Mehr als 10 Jahre im argumentativen „Schützengraben“ dürften jede rationale Analyse unmöglich machen. Jetzt ist es an der Zeit, in die Zukunft zu schauen. LiMux ist seit 5 Jahren offiziell erledigt und faktisch seit 10 Jahren angezählt. Ewig vergangenen Projekten nachzuhängen bringt niemandem etwas. Zukunft heißt momentan zuerst Schleswig-Holstein und dann der „souveräne Arbeitsplatz“ des Bundes. Beide Projekte konnten leider nicht direkt aus den LiMux-Fehlern lernen. In Schleswig-Holstein geht man dennoch zum Glück vieles anders an, aber die Entwicklung ist hier auch noch ziemlich offen. Der „souveräne Arbeitsplatz“ von Bundes und Ländern ist gegenwärtig noch ein reichlich nebulöses Unterfangen und deshalb lässt sich dazu wenig sagen.

Wenn eine Gemeinschaft sich lieber in fragwürdigen Erklärungen ohne Beweise ergeht, als Probleme zu evaluieren, ist das nächste Scheitern bereits vorprogrammiert. Auch in Schleswig-Holsten wird es Wahlen geben, Minister werden ihre Ämter tauschen, Karrieren werden weiter vorangetrieben und politische Unterstützung kann sich verschieben. Da sind keine dunklen Mächte am Werk, sondern das ist politische Normalität. Wenn ein Projekt dann nicht stabil läuft, eine breite Unterstützung genießt und bestenfalls bereits fast alternativlos ist, dann kann auch hier schnell das Licht ausgehen.

Das wäre dann das Ende von Open Source / Linux in der Verwaltung. Zwei gescheiterte Projekte dürften alle weiteren derartigen Vorhaben abwürgen. Hoffen wir mal, dass es nicht so kommt.

Der Artikel LiMux – Ewige Phantomschmerzen? erschien zuerst auf [Mer]Curius

Fr, 28. Januar 2022, Lioh Möller

Die Entwicklung der kommenden openSUSE Leap Version 15.4 ist bereits im vollen Gange und die Arbeiten verlaufen aktuell planmässig. Aufgrund der Harmonisierung der Leap Distribution mit dem kommerziellen SUSE Linux Enterprise (SLE) ist allerdings eine stärkere Abstimmung zwischen den Projekten notwendig.

Der verantwortliche Release Manager Luboš Kocman konnte jedoch bereits einige Details zu den geplanten Versionen der Desktopumgebungen Plasma und GNOME bekannt gegeben. KDE Plasma soll in der LTS Version 5.24 ausgeliefert werden, welche sich aktuell noch in der Beta-Phase befindet.

Entsprechende Pakete sollen in Kürze in openSUSE Tumbleweed zur Verfügung stehen.

Es wird aktuell davon ausgegangen, dass GNOME in Version 41 enthalten sein wird. Alle zu aktualisierenden Versionen der enthaltenen Desktopumgebungen und Windowmanager werden auf einer eigens dafür eingerichteten Seite dokumentiert.

So soll beispielsweise Enlightenment ebenfalls in einer aktuellen Version 0.25.x ausgeliefert werden.

Quelle: https://news.opensuse.org/2022/01/27/release-manager-gives-update-on-de/