Flash-Player für Linux wird de facto eingestellt

Wie Phoronix berichtet, wird Adobe sein Flash-Plugin nach Version 11.2 auf die PPAPI umstellen, die jedoch momentan nur von Google Chrome/Chromium unterstützt wird. Neuere Linux-Versionen des Flash-Plugins werden aus diesem Grund auch nur zusammen mit Google Chrome ausgeliefert und nicht mehr bei Adobe zum Download angeboten werden.

Auch wenn Adobe die Version 11.2 des Plugins weiterhin pflegen wird, wird damit das Flash-Plugin für Linux de facto eingestellt, da die Nutzer gezwungen werden, Google Chrome zu nutzen, falls eine Seite eine Flash-Version neuer als 11.2 benötigen sollte.

Google-Talk-Plugin jetzt auch als reine 64bit Version

Die 64bit Version des Google-Talk-Plugins für Linux benötigte bislang aufgrund einer unportierten Datei unzählige 32bit Pakete, um funktionieren zu können. Ende Dezember hab ich mich daher an Google gewandt um mich zu erkundigen, wann mit einer reinrassigen 64bit zu rechnen ist.

Heute bekam ich eine Mail von Tristan Schmelcher von Google, mit folgendem Inhalt

Today. We have released version 2.6 and the 64-bit package no longer contains any 32-bit code or requires any 32-bit libs.

Auf Deutsch: Die 64bit Version des Plugins benötigt ab sofort keine 32bit Pakete mehr, da die „schuldige“ 32bit Datei anscheinend zwischenzeitlich nach 64bit portiert wurde.

Fedora und Facebook

Ich bin vermutlich nicht der einzige, der sich täglich in sozialen Netzwerken tummelt. Gerade als heavy-user schätzt man einen dedizierten Client, der optimalerweise mehrere Netzwerke unterstützt und sich in den Desktop einpasst. Nachdem ich auch Facebook so verwenden will, bleiben mir für Linux nicht gerade viele Alternativen.

Gwibber war früher die erste Wahl und gerade in Ubuntu 9.04 und 10.04 hat es auch ausgezeichnet funktioniert. Dort haben dann aber die Probleme mit Facebook angefangen. Nach einiger Zeit Absenz habe ich es wieder probiert und musste feststellen, dass der Facebook-Support jetzt komplett kaputt ist. Die Authentifizierung funktioniert wunderbar, allerdings werden weder Nachrichten empfangen, noch gesendet. So wie es aussieht, ist den Gwibber-Entwicklern der Bug bereits vor Monaten gesendet worden. Ein Grund für die Fehlfunktion wird wohl sein, dass Gwibber in Fedora die Facebook-App fedora-gwibber und nicht die „offizielle“ Gwibber-App von Facebook benötigt – wieso auch immer. Fedora-Gwibber erteilt nicht die Rechte, um auf die Wall schreiben und die Wall lesen zu können, da kanns wohl nicht funktionieren.

Bisher hat Tweetdeck als Chromium-Extension immer gut funktioniert. Jetzt ist der Facebook-Support kaputt. Der News-Feed wird zwar angezeigt und neue Postings können erstellt werden, allerdings sind alle anderen Funktionen gestrichen worden. Absicht oder keine? Der zeitliche Zusammenhang mit dem Kauf durch Twitter lässt einen eindeutigen Schluss erahnen.

Yoono als Standalone-App/Plugin für Firefox kommt bei mir unter Windows zum Einsatz, dort funktioniert die Desktop-Integration der Standalone-App sehr gut – unter Linux/Gnome 3 scheint die Integration überhaupt nicht zu funktionieren. Das Mozilla-Plugin funktioniert zwar, aber ich war noch nie ein Freund von Browserlösungen, da viel zu unflexibel.

Was ist los mit den Gwibber-Leuten? Vor allem, was ist mit den Mainteinern bei Redhat? Gwibber war mal wirklich ein vernünftiger Client. Ich kann mir bei Gott nicht vorstellen, dass niemand Fedora in Gwibber verwendet. Von außen sieht es so aus, als ob man immer noch mit dem Versionssprung auf 3.x beschäftigt ist. Es wäre sehr schade, wenn der einzige wirklich vernünftige Client vor die Hunde geht.

Übrigens: Wenn irgendjemand eine wirklich gute Alternative  für einen Twitter/Facebook/Statusnet-Client hat, ich bin immer für Vorschläge offen.

Googles kleiner Gemischwarenladen: Google-Talk-Plugin für x86_64

Wer sich die 64bit Version des Google-Talk-Plugins, das u.a. für die Hangouts von Google+ benötigt wird, installieren will, wird feststellen, dass das Plugin-Paket einen Haufen an 32bit Paketen installieren will.

Nach kurzer Google-Recherche bin ich auf einen Post in den Google Groups gestoßen, der dieses Phänomen wie folgt erklärt (Hervorhebung von mir):

The x86_64 google-talkplugin package currently contains one file which has not yet been fully ported to 64-bit. That file is 32-bit even in the x86_64 package, and as a result the package has some i686 dependencies. We are working toward a fully 64-bit version of google-talkplugin but in the meantime we recommend users to simply allow the package to install all of its dependencies.

Soll heißen, dass das Plugin nach wie vor ein Datei verwendet, die noch immer nicht nach 64bit portiert wurde und deshalb die 32bit Pakete installiert werden müssen.

Gut zu wissen 😉

npapi-vlc ersetzt mozilla-vlc

Wer sich die VLC Version 1.13 aus dem rpmfusion-free-updates-testing Repository installiert, wird feststellen, dass das Paket vlc das Mozilla-Plugin, welches sich in dem Paket mozilla-vlc befindet, während des Updates ersetzt. Sobald man seinen Browser das nächste mal startet, wird man jedoch feststellen, dass das VLC-Plugin fehlt.

Wer sich jetzt aber wohl möglich Sorgen macht, dass das Mozilla-Plugin ersatzlos gestrichen wurde, darf beruhigt sein. Das Plugin „versteckt“ sich ab sofort in dem Paket npapi-vlc, welches mit folgendem Kommando nachinstalliert werden kann

su -c'yum install npapi-vlc --enablerepo=rpmfusion-free-updates-testing'

Nach erfolgreicher Installation und einem obligatorischen Neustart des Browsers steht das VLC Plugin auch dort wieder wie gewohnt zur Verfügung.

Update-Benachrichtigungen mit Xfce4 Bordmitteln

Wir haben hier ja bereits gezeigt, wie man die Update-Benachrichtigungen unter Xfce nachrüsten kann.

Es gibt jedoch noch eine etwas elegantere Methode, um das ganze mit Xfce Bordmitteln zu realisieren. Dazu benötigen wir zuerst einmal das Xfce Genmon Plugin, welches wir über

su -c'yum install xfce4-genmon-plugin'

installieren und anschließend auf dem Panel platzieren.

Als nächstes legen wir ein Shell-Script mit folgendem Inhalt an

#!/bin/bash

# Reference: 
http://lists.fedoraproject.org/pipermail/xfce/2011-November/000841.html

# From "man yum"
#    check-update
#        Implemented  so  you  could know if your machine had any updates
#        that needed to be  applied  without  running  it  interactively.
#        Returns exit value of 100 if there are packages available for an
#        update. Also returns a list of the packages  to  be  updated  in
#        list  format. Returns 0 if no packages are available for update.
#        Returns 1 if an error occurred.

# Dependencies:  Oxygen icons
#                gpk-update-viewer  (yum install gnome-packagekit)

updates=$( yum check-update -q )
status=$?

if [ $status = 100 ]
    then
       echo -e "<img>/usr/share/icons/gnome/22x22/status/software-update-available.png</img>"
       echo -e "<tool>Updates Available</tool>"
       echo -e "<click>gpk-update-viewer</click>"
elif [ $status = 1 ]
    then
       echo -e "<img>/usr/share/icons/gnome/22x22/status/error.png</img>"
       echo -e "<tool>the script returned an error</tool>"
       echo -e "<click>gpk-update-viewer</click>"
elif [ $status = 0 ]
    then
       echo -e "<img>/usr/share/icons/gnome/22x22/status/dialog-information.png</img>"
       echo -e "<tool>all updates applied</tool>"
       echo -e "<click>gpk-update-viewer</click>"
else
       echo -e "<img>/usr/share/icons/gnome/22x22/status/stock_dialog-warning.png</img>"
       echo -e "<tool>status is unknown</tool>"
       echo -e "<click>gpk-update-viewer</click>"
fi

Im vorletzten Schritt machen wir das Script ausführbar, indem wir folgenden Befehl im Terminal ausführen

chmod +x <Pfad und Dateiname des Scripts>

Zum Schluss öffnen wir die Eigenschaften des Genmon-Plugins und tragen unter „Befehl“ den Pfad inklusive Dateinamen unseres Scriptes sowie unter „Intervall“ das Intervall für die Update-Prüfung ein. Persönlich würde ich ein Intervall von 3600 Sekunden (= 60 Minuten) empfehlen. Sobald Updates verfügbar sind, ändert sich das Icon in das selbe, welches PackageKit für die Anzeige von verfügbaren Icons verwendet.

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

zif als Backend für PackageKit nutzen

zif ist ein schlanker und schneller Paketmanager, der in C geschrieben ist. Im Gegensatz zu yum ist zif von Beginn an als Backend für PackageKit entwickelt worden und verzichtet deshalb auf einige Features von yum.

Zif wird momentan noch nicht standardmäßig installiert, soll mit Fedora 17 jedoch yum als PackageKit-Backend ablösen1. Um bereits heute zif als PackageKit-Backend zu nutzen, sind lediglich folgende Schritte notwendig:

Zuerst installieren wir das zif-Plugin für PackageKit mittels

su -c'yum install PackageKit-zif'

Im Anschluss daran beenden wir den PackageKit-Daemon, damit wir die PackageKit-Konfiguration anpassen können, mittels

gdbus call --system  --dest org.freedesktop.PackageKit \
 --object-path /org/freedesktop/PackageKit \
 --method org.freedesktop.PackageKit.SuggestDaemonQuit

Als nächstes bearbeiten wir die PackageKit-Konfiguration mittels

su -c'nano /etc/PackageKit/PackageKit.conf'

dort suchen wir die Zeile

default=yum,zif

und ändern sie in

default=zif,yum

Zum Schluss aktualisieren wir sämtliche Caches und Datenbanken von PackageKit mittels

pkcon refresh

dadurch wird auch der PackageKit-Daemon neu gestartet und nutzt ab sofort zif anstatt yum.

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

  1. noch nicht offiziell durch das FESCo abgesegnet []