LibreOffice startete nach Update auf Version 4 nicht mehr

Verfasst von Christoph am 05.04.2013 | 0 Kommentare

Nach dem Update von LibreOffice auf Version 4 startete dieses unter ArchLinux nicht mehr. Gut, es startete, aber sobald ich eine Datei öffnete beendete sich LO sofort. Wenn man eine ODT/ODS Datei direkt öffnen wollte, sah es zumindest so aus als ob es gar nicht startet. Nach dem Splashscreen ging es einfach aus und in der Konsole standen keine Fehler. Komisch war nur, dass es auf dem anderen PC noch funktionierte – trotz gleicher Distribution und Version.

Google half nicht so recht weiter. Es wurde empfohlen die Config zu löschen (~/.config/libreoffice/) und LibreOffice neuzuinstallieren. Das half aber nichts. Dann nach einer Stunde rumtesten und rumsuchen fand ich die Lösung:

Es waren noch alte Extensions für die Version 3.5 installiert. Mit “pacman -Qs libreoffice-extension” habe ich alle installierten Extensions gesucht. Daraufhin habe ich dann alle Pakete mit einer 3.5er Version entfernt (“pacman -R “). Und siehe da: LibreOffice hat wieder Dateien geöffnet. Bei dem anderen PC waren keine alten Extensions installiert. Daher gab es dort keine Probleme.

Kommentar verfassen

Firefox: Plugins standardmäßig deaktiviert / bei Bedarf aktivieren

Verfasst von Christoph am 05.02.2013 | 0 Kommentare

Firefox - Flashblock

Ich benutze im Firefox schon eine Weile die Extension Flashblock, um Flash standardmäßig zu deaktivieren und mit einem Klick auf das Flash Objekt zu aktivieren. Dies hatte ich mal installiert, als das Flashplugin unter Linux noch instabiler war und mir der Browser regelmäßig abgestürzt ist. Die Zeiten sind (bei mir) zum Glück vorbei, aber die Extension blieb. Es kann auch sehr angenehm sein, wenn die Flash-Inhalte nicht sofort laden. Bei vielen Flash-Inhalten wird mein Laptop manchmal ziemlich langsam. Auch aus Datenschutzsicht ist es ideal. Ich frage mich manchmal, wozu manche Seiten Flash brauchen – wenn man es dann aktiviert, funktioniert alles wie vorher. Vielleicht benutzen sie es zum tracken? Und falls eine Seite Flash öfters benötigt, so kann ich diese in Flashblock einfach whitelisten (z.B. Youtube, wobei dort ja auch HTML5 möglich ist).

Spätestens seit den vielen Sicherheitslücken in Java (Sicherheitslücken hatte Java schon immer, aber nun kam es ja mehr in den Medien) wollte ich so etwas auch für Java und die ganzen anderen Plugins. Theoretisch würde es reichen, wenn ich unter “about:addons” Java deaktiviere und bei Bedarf aktiviere. Ich frage mich gerade, wann ich das letzte mal ein Java Applet gesehen habe. Wenn dann habe ich eher diese “Java Web Start” Dinger gesehen – also die mit den jnlp-Endungen. Noch nicht gesehen? Nichts verpasst. Jedenfalls braucht man dort kein Java-Plugin.

Trotzdem wollte ich dies auch für z.B. Java haben. Die einen schwören ja auf NoScript. Neben das Blocken von Java Script kann man auch die Plugins blocken und bei Bedarf aktivieren lassen. Ich habe es ja nie geschafft NoScript dauerhaft aktiv zu lassen. Ständig habe ich Java Script temporär oder permanent für die Webseite aktiviert, weil diese es entweder unbedingt benötigt hat oder mir Funktionen gefehlt haben. Daher habe ich es nicht installiert.

Firefox - Click to Play

Vor kurzem habe ich dann aber ein Blog Beitrag von Sören Hentzschel entdeckt. Dort beschreibt er, dass man mit der Config-Option

plugins.click_to_play = true

die Plugins standardmäßig deaktivieren kann und dass erst durch ein Klick auf das Objekt (oder über die Browserleiste) das jeweilige Plugin aktiviert wird. Dies funktioniert im Grunde genommen genau wie bei Flashblock – nur für alle Plugins. Das Whitelisten von Webseiten ist auch möglich. Um diese Option also zu aktivieren, muss man unter “about:config” den Eintrag “plugins.click_to_play” suchen und auf “true” ändern. Laut Sören möchte Mozilla dies zukünftig standardmäßig aktiviert haben.

Auf jeden Fall bin ich begeistert und konnte Flashblock entfernen. :)

Kommentar verfassen

Piratenkleider für Drupal

Verfasst von Christoph am 10.08.2012 | 0 Kommentare

Da ich derzeit Semesterferien habe und zwischen den restlichen mündlichen Prüfungen viel Zeit liegt, habe ich mir jetzt vorgenommen, die Seite der Piratenpartei Sachsen-Anhalt endlich mal zu erneuern. Dies war eines meiner größeren Ziele in der Vorstandszeit, die schon Anfang Oktober endet.

Bei einer nicht repräsentativen Umfrage (^^) auf der Mailingliste kam heraus, dass die Leute das Piratenkleider Theme bevorzugen, was auch auf der Webseite der Bundespartei verwendet wird. Dieses wurde erst für Drupal 7 erstellt, dann aber zu WordPress portiert, weil das Webseiten Team eher WordPress gewohnt war. Das Repository vom Drupal-Theme verschwand, das WordPress-Theme erblickte die Welt. Wolfgang Wiese erstellte dann einen Fork, um das Theme barrierefreier zu gestalten und weitere Features hinzuzufügen.

Nun überlegte ich sehr lange, ob wir auf WordPress umsteigen oder lieber bei Drupal bleiben, aber von Version 6 auf Version 7 upgraden sollten. Ich wog die Features beider CMS ab und entschied mich nun nach Monaten auf Drupal 7 umzusteigen. Zwischenzeitlich probierte ich die Webseite upzugraden, was komischerweise misslang (es gab später erneute misslungene Versuche). Bei dem Blog der Piratenpartei Sachsen-Anhalt gelang es aber. Dort konnte ich gleich Erfahrungen beim portieren des Piratenhagen-Themes sammeln. Ganz abgeschlossen ist es noch nicht, aber das meiste funktioniert.

Jetzt gab es nur noch zwei Probleme:

  1. Webseite upgraden bzw. Artikel in einer Neuinstallation übernehmen
  2. Drupal Theme bekommen

Webseite upgraden bzw. Artikel in einer Neuinstallation übernehmen

Wie gesagt, funktionierte das Upgraden nicht. Bei der Suche, wie man die Artikel bei einer Neuinstallation übernehmen kann, entdeckte ich das Drupal Module Migrate. Nach einigen rumfummeln schaffte ich es, die Artikel zu migrieren. Die Seiten ließ ich aus, da ich sie gerne manuell übernehmen möchte.

Drupal Theme bekommen

Das Drupal Repository vom Piratenkleider-Theme gibt es leider nicht mehr. Zum Glück hatte ich bei meinem Testsystem noch eine Kopie. Diese war aber ziemlich veraltet. Nur die CSS Dateien zu updaten funktionierte nicht. Da mir ein paar Sachen auch nicht gefielen, habe ich mit einer eigenen Portierung angefangen, wobei ich aber ein wenig von der alten Version abschaute. Ziel war es für mich, die CSS Dateien so weit wie möglich unberührt zu lassen und für Drupalspezifische Sachen eine separate Datei zu erstellen. Damit der Code nicht zu sehr redundant wird, habe ich doch kleine Änderungen in den bestehenden CSS Dateien vorgenommen, die man theoretisch gefahrlos ins WordPress Theme übernehmen könnte. Bis jetzt sind die Grundfunktionalitäten implementiert. Weitere Features werden noch folgen – beispielsweise der Slider auf der Startseite, wo ich noch überlegen muss, wie ich ihn am besten implementiere.

Generell muss ich überlegen, wie ich strategisch weiter vorgehe. Drupal ist sehr flexibel und hat wenige feste Vorgaben. So gibt es beispielsweise das “Artikelbild”, was es bei WordPress gibt, in Drupal nicht. Das müsste man dann als “Feld” beim “Inhaltstyp” hinzufügen. Außerdem bin ich noch am überlegen, wie viel ich als Theme Option fest einbaue oder flexibel durch Blöcke gestalte, so dass ich den Benutzern die Gestaltung überlasse. Beispiele hierfür sind die Socialmedia Icons oder die Sticker rechts oben. Definitiv werde ich beispielsweise keine fertigen Impressumsseiten einbauen. Das WordPress Theme hat meiner Meinung nach viel zu viele Vorgaben bzw. Optionen.

Beim Portieren ist mir auch die schlechte Qualität des Codes aufgefallen. Die HTML-Struktur ist schon in Ordnung. Problematisch sind aber die uneinheitlichen Einrückungen oder unnötige Leerzeichen am Ende der Zeilen. Die HTML Blöcke habe ich beim portieren schon korrigiert – die CSS Dateien lasse ich derzeit von Tools formatieren. Schlechten Code kann ich einfach nicht so stehen lassen.

Wenn es so weiter geht, habe ich Ende nächste Woche das meiste vom Theme fertig. Dann werde ich beginnen, spezielle Node Templates (für z.B. Stammtische) zu erstellen.

Kommentar verfassen

Firefox Extension “Ghostery”

Verfasst von Christoph am 26.03.2012 | 4 Kommentare

Heute möchte ich euch eine meiner Lieblings Firefox Extensions vorstellen: Ghostery.

Was ist Ghostery? Ghostery ist eine Extension, die deine Privatsphäre schützen soll. Sie blockt alle bekannten Seiten, die dein Surfverhalten ausspähen könnten. Schauen wir uns doch einfach mal Zeit Online als Beispiel an:

Sceenshot von Zeit Online (Firefox Extension Ghostery)

Wie wir hier sehen, sind dort DoubleClick (Anbieter von Werbung, aufgekauft durch Google), INFOnline (binden Zählpixel zur Erfassung von Werbemittel-Reichweiten im Internet ein), Meetrics (“erfasst die Sichtbarkeit von Online-Inhalten und errechnet mit innovativen Erhebungsverfahren in Echtzeit den Aufmerksamkeits- und Lesefokus von Webseitenbesuchern.”), Nugg.Ad (“zielgruppengenaue Onlinewerbung”), VG Wort (Verwertungsgesellschaft, so etwas wie die GEMA für nicht-musikalische Texte) und Webtrekk (“Webanalysesystem”) eingebunden.

Oder schauen wir uns noch die Seite von Spiegel Online an:

Screenshot von Spiegel Online mit der Firefox Extensions Ghostery

Hier sieht es wieder ähnlich aus, aber enthält auch bekanntere Webseiten wie Facebook, Google Analytics und Twitter.

Das Problem bei dieser ganzen Sache ist ja nicht nur das ausspähen, sondern auch, dass viele Server in anderen Ländern wie den USA stehen, wo es andere Gesetze zu Datenschutz etc. gibt. Ich persönlich möchte auch nicht die ganzen Skripte herunterladen müssen, welche die Ladedauer der Webseite verlängern.

Installiert euch doch einfach mal Ghostery. Meine Empfehlung zu den Einstellungen: “GhostRank” deaktivieren, “Auto Update” aktivieren, alle “Zählpixel” und “Cookies” blockieren, “Warnmeldungen” ausblenden und Ghostery in der Navigationsleiste anzeigen lassen.

Wie ihr dann feststellen werdet, wird eine Menge geblockt. So auch die Tweet, G+ und Facebook Buttons. Die Blockierung dieser könnt ihr ja bei Bedarf komplett ausstellen oder nur kurzzeitig, wenn ihr einen Artikel mit anderen teilen wollt. Ein Problem ist mir bei Facebook aufgetreten: Falls ihr den Apps Zugriff auf euer Facebook Account geben wollt, so müsst ihr die Blockierung von “Facebook Connect” rechtzeitig ausschalten, da ansonsten schnell weiße Seiten oder Verbindungsfehler auftreten.

4 Kommentare

CyanogenMod selber gebacken

Verfasst von Christoph am 26.02.2012 | 0 Kommentare

Screenshot von AndroidLange Zeit konnte ich mein HTC Wildfire gar nicht Rooten, weil HTC mit einem update irgend eine Sperre eingebaut hatte. Dann gab es irgendwann AlphaRevX beta tool (jetzt gibt es von den AlphaRev und unrevoked Leuten Revolutionary) und seit dem benutze ich CyanogenMod. Da die stabile Version meist ein paar kleine Bugs hatte, habe ich mir die Nightly Builds installiert. Leider gab seit November 2011 keine neuen mehr – dafür aber eine Menge Commits.

Und was macht man da? Selber bauen! :D

Leider hat das bei mir bisher nicht funktioniert. Doch gestern hat es endlich geklappt. Ich habe die Anleitung von alex_dpsg benutzt.

Da ich nicht Ubuntu sondern ArchLinux benutze, habe ich es ein wenig anders gemacht:

Das Android SDK (+ Platform Tools) habe ich aus dem AUR genommen:

yaourt -S android-sdk android-sdk-platform-tools

Da seit dem letzten SDK Update im AUR eine Menge Pakete von diversen Herstellern hinzugekommen sind, sollte man “./android update sdk -u” nicht ausführen (das dauert nämlich ewig). Stattdessen startet man den Android SDK Manager:

sudo android

Hier installiert man die wichtigsten Pakete (die von Google sollten reichen). ADB muss man eigentlich nicht updaten. Fastboot sollte auch schon vorhanden sein. Dann machen wir weiter:

mkdir -p ~/bin
mkdir -p ~/android/system
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
chmod a+x ~/bin/repo

Das kopieren nach /usr/bin und den Pfad anpassen lassen wir mal. Das können wir nämlich besser lösen. ;) Jetzt installieren wir uns openjdk6 (aufpassen: das wird uns die 7er Version entfernen. Die könnt ihr nach dem kompilieren ja wieder installieren ^^). Dann richten wir uns noch einen SymLink für Python 2 ein, da das Script Python 3 nicht mag.

sudo pacman -S openjdk6
ln -s /usr/bin/python2 ~/bin/python

Jetzt brauchen wir nur noch den PATH setzen. Entweder tippt ihr den jedes mal so ein oder speichert es euch in die .bashrc oder andere Konfigdatei deiner Shell:

export PATH=$HOME/bin:/opt/android-sdk/platform-tools:$PATH

Den Teil mit dem Android SDK kann man eigentlich weglassen, wenn man die Shell neugestartet hat, da das AUR Paket den Pfad schon global in die PATH Variable geschrieben hat.

Nun könnt ihr im verlinkten Tutorial nach dem PATH setzen weitermachen. Bitte beachtet, dass bei seinem Blog zweimal zwei aufeinanderfolgende Bindestriche zu einem großen zusammengefasst werden. Das ist bei “–repo-url” und bei “–progress” der Fall. Die Shell möchte gerne zwei und nicht einen langen haben. ;) Achja: Ihr müsst noch ein Paket installieren. Das merkt ihr ihr aber, wenn er abbricht, weil ein Befehl nicht funktioniert (habe leider vergessen wie das Paket hieß).

Und nach langen warten habt ihr dann Glück oder Pech. :D Updaten könnt ihr dann wie gehabt.

Kommentar verfassen