Fedora 18: Menüs in LibreOffice sehr klein und kaum lesbar

Wer nach dem Upgrade auf Fedora 18 die Menüs in LibreOffice kaum noch lesen kann, da die Schriftgröße extrem klein ist, sollte überprüfen, ob auf seinem System das freetype-freeworld Paket installiert ist:

rpm -qa freetype-freeworld

Falls das Paket installiert ist, führt bis zu Beseitigung dieses Bugs kein Weg um die Deinstallation des Paketes mittels

su -c'yum remove freetype-freeworld'

und einen anschließenden Neustart der Desktopumgebung herum.

Steht „tmp on tmpfs“ auf der Kippe?

Momentan sieht es so aus, als ob das für Fedora 18 geplante Feature „tmp on tmpfs„, welches ein tmpfs als /tmp mounten soll, auf der Kippe steht.

Ausgehend von einer Mail Richhard W.M. Jones an die Entwicklerliste, in der er sich nach dem korrekten Vorgehen, um ein vom FESCO akzeptierten Feature rückgängig machen zu lassen erkundigt, haben sich auch andere Entwickler gemeldet, die dem Feature kritisch gegenüber stehen und eher Nach- als Vorteile darin sehen.

So wird unter anderem bemängelt, das bei Umsetzung des Features die Größe von /tmp von der Größe des Arbeitsspeichers und nicht mehr von der Größe der Festplatte(n) abhängt. Aber auch die angeblichen Performance-gewinne werden angezweifelt.

Im Verlauf der Diskussion innerhalb des entsprechenden FESCO-Tickets führt Richard W.M. Jones das Argument ins Feld, das Debian eine entsprechende Änderung bereits nach kurzer Zeit wieder rückgängig gemacht hat und das Ubuntu aufgrund dessen diese bereits geplante Änderung nicht vornehmen wird.

Lennard Poettering führt für das Feature die kaum existente Anzahl an Bugreports ins Feld, was von Kevin Kofler jedoch mit den Worten

Filing bugs assumes the feature is fixable in the first place. This one is not.

(Fehlerberichte bedeuten zunächst einmal, das ein Feature reparierbar ist. Dieses ist es nicht).

zurückgewiesen wird.

Letztendlich muss FESCO über die Zukunft von „tmp on tmpfs“ entscheiden, aber so wie es momentan aussieht, würde eine Rolle rückwärts bei diesem Thema wohl niemanden ernsthaft überraschen, da die Contra-Argumente momentan zu überwiegen scheinen.

Adios prefdm

Das bislang von Fedora genutzte Script prefdm, über welches der jeweils installierte DisplayManager gestartet wird, wird mit Fedora 18 in Rente geschickt werden.

Die Aufgabe, den DisplayManager zu starten, wird ab Fedora 18 stattdessen Systemd übernehmen. Dazu wird jeder der momentan 7 in Fedora vorhandenen DisplayManager ein Service-File mitbringen, über das Systemd diesen startet. Darüber hinaus sollen die DisplayManager ab Fedora 18 fest auf vt1 verknüpft werden und nicht, wie bislang, das erste freie virtuelle Terminal zugewiesen bekommen.

Durch diese Änderungen versprechen sich Lennart Poettering und Christoph Wickert unter anderem, ein einfacheres Handling der DisplayManager, was auch die spätere Aufnahme weiterer DisplayManager vereinheitlichen soll. Darüber hinaus wird der momentan Fedora-exklusive Weg, DisplayManager über prefdm zu handlen, aufgegeben.

Fedora 18 bekommt „offline“ Updates

Ein weiteres, für Fedora 18 akzeptiertes Feature sind die „offline“ Updates. Wobei offline in diesem Fall bedeutet, das die Updates in einer kontrollierten, minimalen Umgebung und nicht wie bislang im laufenden Betrieb installiert werden. Durch diese Maßnahme sollen unter anderem Probleme beim Update von Bibliotheken verhindert werden, wenn Anwendungen oder Dienste, die diese Bibliotheken nutzen, während des Updates ausgeführt werden.

Diese Probleme sollen beim offline Update dadurch vermieden werden, das die Updates im Hintergrund heruntergeladen werden und anschließend der Benutzer informiert wird und das System in einen speziellen Update-Modus booten kann, in dem die Updates installiert werden. Eine Installation von Updates im laufenden Betrieb mit yum oder anderen Kommandozeilentools soll auch weiterhin möglich sein.

Microsoft hilft Fedora bei UEFI Secure Boot

Die Fedora-Entwickler überlegen momentan anscheinend, den Signierdienst von Microsoft zu nutzen, um Fedora 18 auch auf Geräten mit aktiviertem Secure Boot installieren zu können.

Dies geht zumindest aus einem Blogpost von Matthew Garett hervor. Laut dem Blogpost wurden auch andere Optionen, wie beispielsweise das Versenden des Fedora Schlüssels an alle in Frage kommenden Hardwarehersteller, überlegt, aber letztendlich als unpraktikabel wieder verworfen.