Fedora 23 standardmäßig ohne SSL3- und RC4-Support

Auf der Entwickler-Liste von Fedora wurde heute ein Änderungsvorschlag für Fedora 23 gepostet, der den Support für SSL3 und RC4 durch eine Änderung am crypto-policies Paket systemweit deaktivieren will. Begründet wird dies damit, das SSL3 und RC4 mittlerweile nicht mehr als sichere Verschlüsselungsalgorhytmen gelten.

Primär sind von dieser Änderung openssl und gnutls betroffen. Betreuer von Anwendungen, die Verschlüsselung nutzen, werden aufgerufen, sicherzustellen, das ihre Anwendungen auch weiterhin funktionieren und nicht ausschließlich SSL3 und/oder RC4 benötigen. Sollte dies jedoch der Fall sein, sollen Paketbetreuer entweder mit dem Upstream daran arbeiten, das Problem zu lösen, oder ausnahmsweise auf das crypto-policies Paket verzichten.

COPRs: Ein zweischneidiges Schwert

Als vor nicht all zu langer Zeit COPRs (Cool Other Peoples Repositores) Einzug in das Fedora Repository hielten, war die Freunde gros, das man endlich ein Pendant zu den PPAs aus dem Untuntu-Universum habe.

Inzwischen hat man jedoch immer öfter den Eindruck, das COPRs als eine Art Zwischenschicht zwischen Rawhide und Stable missbraucht werden. Als jüngstes Beispiel könnte man das mit dem Kernel 4.0 eingeführte Live-Patching nennen. Einerseits wird bekanntgegeben, das Live-Patching standardmäßig im Fedora-Kernel deaktiviert ist, im gleichen Atemzug wird jedoch auf ein use on your own risk COPR verwiesen, wo man Kernel mit aktiviertem Live-Patching bekommen kann.

COPRs sind durchaus nützlich und hilfreich, wenn es darum geht, Dritten Pakete zur Verfügung zu stellen, die (noch) nicht in den offiziellen Fedora Repositories enthalten ist oder um neuere Versionen der in Fedora enthaltenen Software zum Testen bereit zu stellen. Ich halte es jedoch falsch, COPRs für das Entwickeln und Testen neuer Features zu verwenden. Dafür war bislang Rawhide zuständig und so sollte es auch bleiben. Ansonsten war Fedora die längste Zeit die Distribution, die man sich installiert hat, wenn man möglichst nahe am Puls der Linux-Entwicklung sein wollte und wird immer mehr zu einem Debian auf rpm-basis.

Fedora 22: dnf ersetzt yum als Standard-Paketmanager

Mit dem Update auf Version 3.4.3-505 wird der langjährige Standard-Paketmanager yum offiziell als “deprecated” (veraltet) markiert und durch dnf als Standard-Paketmanager ersetzt. Weiterhin wird bei jedem Aufruf von yum ab dem Updater der folgende Hinweis angezeigt und der Aufruf anschließend als dnf weitergereicht:

Yum command has been deprecated, use dnf instead.
See ‘man dnf’ and ‘man yum2dnf’ for more information.
To transfer transaction metadata from yum to DNF, run ‘dnf migrate’
Redirecting to ‘/usr/bin/dnf ‘

Wer weiterhin yum nutzen möchte, muss anstatt yum nun yum-deprecated aufrufen. Um den Hinweis, das yum veraltet ist, kommt man dennoch nicht herum.

Linux is doch kein copy cat! – ein GTK-Theme Rant

Eigentlich bin ich ein Mensch, der nur ungern die standardmäßig verwendeten Themes von Gnome (adwaita) oder Xfce (greybird) nutzt, da ich meinen Desktop gerne etwas individueller haben möchte.

Allerdings ist mir im Moment ehrlich gesagt nur noch nach Heulen zumute, wenn ich so durch die Liste der Themes bei (gnome|xfce)-look.org oder DeviantArt blättere: Im Grunde gibt es dort momentan nur noch 3 Arten von Themes: Flat-Design, Windows-like und OSX-like.

Aus dem Grund möchte ich den Designern am liebsten nur noch so laut es geht ins Gesicht brüllen:

THIS IS LINUX AND NO F***ING WINDOWS, ANDROID OR OSX!!!111

Wenn ich möchte, das mein Desktop wie ein Windows oder OSX aussieht, dann installiere ich mir das Original und vergewaltige meinen Linux-Desktop nicht mit dem Versuch, das Look&Feel einer anderen Plattform zu imitieren! Und wenn ich Android-Optik haben möchte, dann greife ich zum Android-Smartphone oder -Tablet!

Ganz allgemein muss man aber feststellen, das subjektiv betrachtet die Kreativität der GTK-Theme-Designer seit GTK 3.0 beträchtlich nachgelassen hat und irgendwie sämtliche Themes gleich aussehen und sich – überspitzt formuliert – nur der Name des Autors ändert. Wo sind die farbenfrohen Themes aus den Zeiten von GTK 2 geblieben? GTK 3 Themes sind, wenn sie nicht gerade das Look&Feel anderer Plattformen imitieren, fast nur in schwarz oder dunklem Grau gehalten und sehen sich alle irgendwie sehr ähnlich. Fast so, als würde Designer B das Design von Designer A kopieren und nur noch ein wenig modifizieren, damit nicht sofort auffällt, das er kopiert hat.

Nicht minder frustrierend ist auch der Umstand, das wenn man mal ein ansehnliches GTK-Theme gefunden hat, dies meist nicht mehr gepflegt wird und mit aktuellen Versionen von GTK nicht mehr vernünftig – oder manchmal sogar gar nicht mehr – funktioniert.

Vielleicht ist es an der Zeit, Plattformen wie gnome-look.org und xfce-look.org (vorübergehend) abzuschalten, um diesem Trauerspiel endlich ein Ende zu bereiten …

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

Fedora 22: anderen Screenlocker mit xflock4 nutzen

Bitte beachtet auch die Anmerkungen zu den HowTos!

Das xflock4 Script aus dem Paket xfce4-session unterstützte bislang lediglich den xscreensaver als Screenlocker. Wer jedoch einen anderen Screenlocker (z.B. xlockmore oder light-locker) nutzen wollte, musste bislang auf das xflock4 Script verzichten.

Mit dem Update auf 4.12.1-3 kann man xflock4 über einen Eintrag in xfconf dazu bringen, einen anderen Screenlocker als xscreensaver zu verwenden. Dazu muss lediglich folgendes Kommando im Terminal ausgeführt werden:

xfconf-query -c xfce4-session -p /general/LockCommand -t string -n -s "xscreensaver-command -lock"

Wobei “xscreensaver-command -lock” durch den Aufruf des jeweiligen Screenlockers zu ersetzen ist.

Maximale Aufnahmedauer des Gnome-Screencasters erhöhen

Bitte beachtet auch die Anmerkungen zu den HowTos!

Die Gnome-Shell verfügt seit Version 3.2 über einen eingebauten Screencaster, der jedoch nur maximal 30 Sekunden lange Aufnahmen erlaubt.

Wer mehr möchte, muss dazu lediglich im Terminal oder dem Ausführen-Dialog (ALT+F2) folgenden Befehl ausführen

gsettings set org.gnome.settings-daemon.plugins.media-keys max-screencast-length value

Will man beispielsweise die maximale Aufnahmedauer auf 10 Minuten (mehr geht AFAIK nicht) verlängern, lautet der Befehl

gsettings set org.gnome.settings-daemon.plugins.media-keys max-screencast-length 600

Die Änderungen sind sofort wirksam.

Im Original von iddnna

Die Aufnahme des Screencasters wird mittles STRG+ALT+SHiFT+R gestartet und beendet. Das eine Aufnahme läuft, erkennt man an einem roten Punkt in der oberen rechten Ecke der Gnome-Shell.

Workaround: Google-Kalender mit Evolution 3.16 abonnieren

Bitte beachtet auch die Anmerkungen zu den HowTos!

Evolution Version 3.16 wird allem Anschein nach wohl nicht in der Lage sein, Google-Kalender direkt aus Evolution heraus zu abonnieren.

Es gibt jedoch einen relativ einfachen Workaround, um auch mit Evolution 3.16 Google-Kalender zu abonnieren:

  1. Man besorgt sich die Kalender-IDs aller Kalender, die man abonnieren möchte, aus der Google-Kalender Weboberfläche, indem man dort die Einstellungen öffnet, in den Reiter “Kalender” wechselt und dort die Details der jeweiligen Kalender aufruft.
  2. In den Details findet man die Kalender-ID im Bereich “Kalenderadresse” neben den Buttons für XML, ICAL und HTML.
  3. Nun wechselt man in Evolution in das Kalender-Modul und legt einen neuen CalDAV-Kalender an.
  4. Als URL für den Kalender gibt man https://www.google.com/calendar/dav/[Kalender-ID ]/events/ ein und als Benutzername den Google-Benutzernamen ohne @gmail.com Suffix

Die oben genannten Schritte 3 und 4 widerholt man für jeden Google-Kalender, den man mit Evoluton abonnieren möchte.