iOS Facebook Apps saugen Akku leer

Vor ein paar Tagen geisterten ein paar Artikel die die Netzwelt, die darüber Auskunft erteilten, dass die Facebook Apps unter iOS (dazu zählen auch Messenger und der Seitenmanager) ziemlichen Strombedarf verursachen. Nachdem mich dieses Thema schon länger nervt – nämlich ein sehr schwankender Verbrauch, aber nie ein hinauskommen über 18 Stunden Betrieb, teilweise sogar nur 10-12 Stunden – war ich natürlich gleich heiß und hab es ausprobiert. Und siehe da, es stimmt. Bereits am nächsten Tag hielt mein Akku locker durch, sodass ich erst einen Tag später laden musste. Sprich, im Gegensatz zu nicht mal 18 Stunden komme ich nun auf bis zu 30 Stunden.

Zu meinem Nutzungsschema: ca. 2 Stunden am Tag Musik oder Podcasts hören plus ca. 2-4 Stunden Surfen oder lesen. Alles in allem sicher kein Heavy User. Trotzdem freue ich mich, dass ich nun endlich unbesorgt über den Tag komme.

Warum tritt dieses Problem eigentlich auf? Die Facebook Apps sind so gebaut, dass sie alle 10 Sekunden “aufwachen”, irgendwas tun und sich dann wieder schlafen legen. Damit umgehen sie Apples eigentlich sehr gute Stromsparmechanismen massiv, was dann im stark erhöhten Verbrauch mündet. Whatsapp ist übrigens auch so ein Kandidat, auch wenn sie nicht ganz so aggressiv wie Facebook vorgehen. Ich verstehe hier ehrlich gesagt nicht, warum Apple derartige Apps überhaupt im Store zulässt. Bis dato habe ich tatsächlich angenommen, dass der Akku vom iPhone so schlecht ist.

Da Facebooks Webapp zumindest für mich deutlich stabiler als die native App ist, komme ich soweit auch ganz gut ohne zurecht. Einzig die nun fehlenden Push Benachrichtigungen trüben das Gesamtbild etwas.

Ehrlicherweise muss man aber sagen, dass selbst 30 Stunden ein lächerlicher Wert sind. Ich hätte kein Problem damit, wenn mein iPhone etwas dicker wäre, dafür aber auch mal mehr als 2 Tage durchhalten würde. Mittlerweile habe ich das Gefühl, dass selbst wenn die Technik besser wird, die Hersteller die Geräte lieber dünner machen und damit wieder gleich bleibende Akku Laufzeit in Kauf nehmen. Eine sehr ungünstige Entwicklung…

Ps: die Akku Problematik soll übrigens auch bei den Androiden Freunden auftreten. Falls ihr da also auch Schwächen beim Akku habt, probiert es mal aus….

[Quicktip] Symfony2 bringt weiße Seite und keinen Eintrag in den Error Logs

Wenn auch euch dieser Fehler begegnen sollte und ihr nicht mehr weiter wisst: prüft, ob in euren Config Dateien (bei mir war es die service.yml) die Keys (also z.B. der Name eines Service) ungültige Zeichen enthalten – wie z.b. Bindestriche 😉

Confluence HSQLDB auf mysql migieren

Folgende Problematik: ihr habt Confluence testweise auf einem Server installiert und nutzt für die Evaluation erstmal die hsqldb – also die integrierte in-Memory Datenbank, die NICHT für den produktiven Einsatz gedacht ist, da sie im Falle eines Absturzes zu Datenverlust führt. Die gestützter sehen das jedoch anders und nutzen das System umgehend produktiv und nun müsst ihr schnell auf eine richtige Datenbank wie MySQL, Oracle usw. umsteigen. Und genau für diesen Punkt ist dieses kleine Tutorial gedacht:

Im Confluence Admin in den Bereich Administration und dort “Sichern und Wiederherstellen” wechseln. “In Sicherungsordner archivieren” sowie “Anhänge sichern” aktivieren und auf sichern klicken.

Das nun erstellte Backup befindet sich (standardmäßig) unter

/var/atlassian/application-data/confluence/backups

Ladet die Datei xmlexport-xxxxxxxx-xxxx.zip herunter – die richtige Datei erkennt ihr am jeweiligen Timestamp.

Anschließen Confluence herunterfahren und die Datei

/var/atlassian/application-data/confluence/confluence.cfg.xml

löschen (auch hier ist der Pfad wieder standardmäßig und kann bei euch evtl. abweichen).

Unter

https://confluence.atlassian.com/display/DOC/Database+JDBC+Drivers

den entsprechenden Treiber für eure zu verwendende DB herunterladen (ist für MySQL und Oracle notwendig), entpacken und die jeweilige .jar Datei in den Pfad (standardmäßig)

/opt/atlassian/confluence/confluence/WEB-INF/lib/

legen.

Mysql my.cnf (/etc/mysql) einstellen:

[mysqld]
character-set-server=utf8
collation-server=utf8_bin
default-storage-engine=INNODB
max_allowed_packet=32M

Mysql neu starten.

Datenbank einrichten:
CREATE DATABASE confluence;
GRANT ALL PRIVILEGES ON confluence.* TO ‘confluenceuser’@’localhost’ IDENTIFIED BY ‘confluencepass’;
FLUSH PRIVILEGES;

Nun müsst ihr Confluence wieder starten und im Browser unter der ursprünglichen URL aufrufen – der Setup Wizard beginnt erneut. Sprache einstellen und dann “Kundenspezifische” Installation wählen. Dort die externe Datenbank Mysql auswählen und auf der nächsten Seite die Zugangsdaten zur Datenbank eintragen:

URL: jdbc:mysql://[db-host]/[db-name]?sessionVariables=storage_engine%3DInnoDB
Benutzer: [db-username]
Kennwort: [passwort]

Anschließend wird die Datenbank erzeugt.

Im nächsten Schritt ganz unten “Wiederherstellen aus Backup” wählen und im folgenden Upload Dialog die vorhin gesicherte

xmlexport-xxxxxxxx-xxxx.zip

wählen. Nun wird die ursprüngliche Datenbank wieder hergestellt und ihr könnt confluence wieder wie gewohnt nutzen.

Confluence zählt LDAP Benutzer mehrfach für die Lizenz

Ein etwas wirrer Titel, aber ich möchte auf folgende Problematik hinweisen – die evtl. auch einfach nur ein Bug ist:

Confluence erlaubt in seinen einzelnen Lizenzpaketen nur eine gewisse Anzahl an Nutzern. Wenn man die Nutzerdaten per LDAP in das System spielt und z.B. nicht alle LDAP Nutzer auch als Confluence User berechtigen möchte, kann man über die Zuweisung von Gruppen regeln, wer Zugriff bekommt und wer nicht.

Anschließend legt man unter “Globale Berechtigungen” einfach die Gruppen oder einzelnen User an und bestimmt, was sie dürfen und was nicht. Nur DIESE User, die entweder der entsprechenden Gruppe angehören, oder aber einzeln gelistet sind, können sich einloggen.

Ein nicht ganz so offensichtlicher Bug/Feature: wenn man den gleichen User in unterschiedlichen Gruppen hinzufügt und diese für Confluence berechtigt, so wird dieser User auch mehrfach für die Lizenz gezählt! Also legt den User einfach in die entsprechend seiner Berechtigungen höchste Gruppe, dann wird er auch nur einmal gezählt.

[Quicktip] Vagrant Fehler “Provider useradd does not support features manages_passwords”

Falls sich Vagrant bei euch auch mal mit folgendem Fehler melden sollte:

Provider useradd does not support features manages_passwords; not managing attribute password

dann ist das ein sehr “offensichtlicher” Hinweis, dass die libshadow-ruby1.8 fehlt 😉