Der Daemon pyPimd

Der Daemon pyPimd welcher ein Teil des neuen Openmoko Frameworks ist, kümmert sich um das Personal Information Managment (PIM). Dazu gehören die Adress-, und Nachrichtenverwaltung (z.B. E-Mails, SMS, Instant Messenger), Anrufhistory, Kalender und Events und weitere Sachen. Neben diesen Funktionen stellt er (bzw. soll es in Zukunft) auch Funktion zur Synchronisation mit dem Desktoprechner (z.B. über Protokolle wie SyncML) bereit. Es handelt sich also um einen Daemon welcher die PIM Backend Funktionen bereit stellt. Er wird im Rahmen des Google Summer of Code 2008 von Abraxa entwickelt.

Der Entwicklungsplan von Abraxa gliedert sich dabei in etwa in folgende Punkte: Im ersten Schritt soll ermittelt werden welche Features für eine vollständige PIM Infrastruktur benötigt werden. Danach wird versucht dieses Features in eine logische Struktur zu bringen (Telefonbuch API, Messaging API, API für intelligente Abfragen) damit diese in eine dbus API gegossen werden können.

Anschließend sollen ein prototypisch Daemon/Client Paare für den Test geschrieben werden, damit die ganze API getestet werden kann. Nach diesen Tests kann dann damit begonnen werden die API soweit verbessert das sie für Drittentwickler einfach zu nutzen ist.

Zur Speicherung der Daten ist zu sagen, das jedes Plugin dabei selber bestimmten darf wie es seine Daten speichert (z.B. als CSV Datei oder als SQLite Datenbank). Natürlich kann sich an diesem Konzepten immer noch viel ändern bis die finale Version erscheint.

Weitere Informationen dazu gibt es unter http://www.neo1973-germany.de/wiki/pyPimd.

Status des neuen Openmoko Frameworks

Mir sind grade die Statusberichte des neuen Frameworks über den Weg gelaufen was natürlich eine tolle Möglichkeit darstellt mal etwas über den aktuellen Status zu schreiben :)

Im großen und Ganzen sind einige Leute zur Entwicklung des Frameworks hinzugestoßen und vor kurzem wurde der erste Meilenstein (Groundhog Day) freigegeben. Das passende Image dazu ist unter http://downloads.openmoko.org/framework/ zu finden. Dieses Framework liefert Zhone (zusammengesetzt aus Zen und Phone) als Testapplikation für das Framework mit.

Um den Meilenstein zu testen sind folgende Schritte nötig:
– das neue uImage (Kernel) und die .jffs2 (Root Dateisystem) für das passende Gerät müssen heruntergeladen werden (http://downloads.openmoko.org/framework/milestone1/)
– dann kann das neue Image mittels dfu-util draufgeflasht werden (om-gta01 für Neo1973, om-gta02 für NeoFreerunner)
– anschließend kann das Gerät gebootet werden und dann heißt es warten bis der „Openmoko – Please wait…“ Screen verschwindet.

Sollte der Screen nach zirka zwei Minuten immer noch nicht verschwunden sein, so heißt es neubooten. Dies ist durch einen Bug bedingt bei dem das erste booten des Images nicht wie gewünscht funktioniert.

Mit diesem ersten Meilenstein sind schon simple Telefonanrufe möglich. Außerdem wurden folgende dbus APIs veröffentlich:
– org.freesmartphone.Device
– org.freesmartphone.Usage
– org.freesmartphone.Event
– org.freesmartphone.GSM

Suspend und Resume funktionierend in diesem Release noch nicht zu 100%. Außerdem sollte man an Funktionalität auch nicht mehr als die eben erwähnte Fähigkeit zum Führen von Telefonaten erwarten. Feedback und Kommentare zur API sind ausdrücklich erwünscht.

Im nächsten Schritt soll die API Dokumentation verbessert werden (http://www.freesmartphone.org) und an dem Meilenstein 2 gearbeitet werden.

Links:
http://wiki.openmoko.org/wiki/OpenmokoFramework

Es kommt…

Noch knapp zwei Wochen (heute wird mal großzügig geschätzt) dann ist mein Freerunner hier :) Aus diesem Anlass habe ich mich mal wieder ein bisschen intensiver auf den Openmoko Seiten umgeschaut. Als erstes ist mir ins Auge gefallen das zurzeit an einem neuen Framework gearbeitet wird. Mit diesem Framework sollen dann die „Brot und Butter“ Anwendungen fertig sein. Das neue Framework verfolgt folgende Ziele:

– es soll eine Infrastruktur geschaffen werden mit denen solide Software für die Openmoko Plattform geschrieben werden kann
– mehrere UI Systeme sollen unterstützt werden
– die Benutzer sollen neue Sachen zum Framework beitragen

Dazu sollen folgende Voraussetzungen geschaffen werden:
– das Framework soll einfach gehalten sein
– es soll sich auf die Kernfunktionalitäten konzentrieren
– es soll UI unabhängig programmiert werden
– existierende Technologien sollen wiederverwendet werden wenn dies praktikabel erscheint (nicht auf Kosten einer schlechten API)

Dieses neue Framework trägt den Namen Openmoko 2008 und sieht wenn es fertig ist in etwa so aus:

Die Kommunikation soll das über dbus einen Interprozesskomunikationsbussystem (http://de.wikipedia.org/wiki/Dbus) stattfinden. Das Framework soll zwar für Openmoko Geräte optimiert werden, allerdings sollen auch andere Architekturen wie z.B. OpenEZX oder Xanadu unterstützt werden.

Damit die API bzw. das Framework auch benutzt werden die Anwendungen welche die Grundfunktionalitäten für das Telefon bereitstellen auf diesem neuen Framework aufbauen, damit man gleich sieht wie mächtig das Framework ist.

Der Status des Framework ist mittlerweile schon ein wenig gediegen, wenn auch noch lange nicht komplett. Konkret sieht das so aus:

Low Level
– Hardware: 50%
– Audio: 80%
– GSM: 80%
– Bluetooth: 80%
– GPS: 80%
– Network: 50%

High Level
– Usage: 0%
– Event: 0%
– Preferences: 50%
– Context: 0%
– Telephony: 50%
– Networking: 0%
– PIM: 0%

Die Verantwortlichen für das neue Framework sind:
– Michael ‚Mickey‘ Lauer (Teamleiter / Freelancer / Deutschland)
– Guillaume ‚Charlie‘ Chereau (Angestellter bei Openmoko / Taipei)
– Jan ‚Shoragan‘ Luebbe (Student / Deutschland)
– Daniel ‚Alphaone‘ Willmann (Student / Deutschland)

Interessante Links zu diesem Thema:
http://www.vanille-media.de/site/index.php/2008/05/05/openmoko-framework-initiative/
http://wiki.openmoko.org/wiki/OpenmokoFramework
http://blogs.thehumanjourney.net/finds/entry/20080520
http://downloads.openmoko.org/framework/milestone1/FrameworkMilestone1.m4v

Bittorrent für die Konsole

Heute wollte ich auf meinem vServer mal Bittorrent laufen lassen. Das ganze soll dann natürlich auf der Konsole laufen. Also erst einmal Google angeschmissen und nachgeschaut was der „Markt“ so zu bieten hat. Nach einer Weile fiel meine Wahl dann auf rTorrent.

Das ganze wurde dann mit einem beherzten „apt-get install rtorrent“ auf dem Server installiert. Damit man das ganze später dann im Hintergrund laufen lassen kann sollte man noch das Paket screen installieren (apt-get install screen).

Nun sollte man seinen Midnight Commander starten und aus dem Verzeichnis /usr/share/doc/rtorrent/examples/ die Datei rtorrent.rc in sein home Verzeichnis kopieren. Die Konfigurationsdatei am noch in .rtorrent.rc umbenennen und öffnen. Bei mir sieht die fertige Konfiguration dann so aus:

# This is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
#max_peers = 100

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
#max_peers_seed = 50

# Maximum number of simultanious uploads per torrent.
#max_uploads = 15

# Global upload and download rate in KiB. „0“ for unlimited.
download_rate = 0
upload_rate = 0

# Default directory to save the downloaded torrents.
directory = ./bt/downloads

# Default session directory. Make sure you don’t run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = ./bt/session

# Watch a directory for new torrents, and stop those that have been
# deleted.
#schedule = watch_directory,5,5,load_start=./watch/*.torrent
#schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=100M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
#schedule = ratio,60,60,“stop_on_ratio=200,200M,2000″

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
#port_range = 6890-6999

# Start opening ports at a random position within the port range.
#port_random = no

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
#check_hash = no

# Set whetever the client should try to connect to UDP trackers.
#use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip’s.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
# encryption = allow_incoming,enable_retry,prefer_plaintext

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to „disable“ (completely disable DHT), „off“ (do not start DHT),
# „auto“ (start and stop DHT as needed), or „on“ (start DHT immediately).
# The default is „off“. For DHT to work, a session directory must be defined.
#
# dht = auto

# UDP port to use for DHT.
#
# dht_port = 6881

# Enable peer exchange (for torrents not marked private)
#
# peer_exchange = yes

#
# Do not modify the following parameters unless you know what you’re doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10

# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10

Es sind nur ein paar Sachen aktiv. Als erstes ist die Up- und Downloadrate auf unendlich gestellt:

# Global upload and download rate in KiB. „0“ for unlimited.
download_rate = 0
upload_rate = 0

Das Verzeichniss in dem die fertigen Downloads liegen sollen wurde definiert:

# Default directory to save the downloaded torrents.
directory = ./bt/downloads

Und dann wurde noch ein Verzeichnis für die Session definiert, damit rTorrent die Sitzung beim nächsten Start fortsetzt:

# Default session directory. Make sure you don’t run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = ./bt/session

Damit das ganze nun im Hintergrund läuft und nicht gleich terminiert wird sobald die SSH Verbindung beendet wurde, werden wir screen benutzen. Dazu geben wir „screen rtorrent“ auf der Konsole ein. Anschließend öffnet sich rtorrent. Wir drücken Enter und geben den Link des Torrents ein und bestätigen das ganze wieder mit Enter. Damit der Download des Torrents auch anfängt drücken wir Strg + S.

Nun trennen wir die Sitzung ab indem wir Strg + a und dann d drücken. Nun kann man die SSH Verbindung ruhigen Gewissens beenden, rTorrent läuft im Hintergrund weiter. Mit „screen -r“ kann die Sitzung wiederhergestellt werden, falls man mal wieder etwas ändern möchte.

Eine schöne Doku zu rTorrent findet man unter http://wiki.ubuntuusers.de/rTorrent

Freier Notensatz

Dank der c’t bin ich heute über etwas gestolpert was ich schon lange gesucht habe: ein freies Notensatzprogramm ähnlich Sibelius. Das ganze nennt sich MuseScore und sieht schon sehr ausgereift aus. Der Download findet sich unter http://www.musescore.org. Jetzt muss ich bloß noch eine Möglichkeit finden meine alten Sibelius Dateien in ein brauchbares Format zu konvertieren welches ich in MuseScore importieren kann.