Momentan hört man ja ziemlich viel, dass das iPhone 4 starke Probleme mit der verbauten Antenne hat. Das kann ich überhaupt nicht nachvollziehen. Bei mir funktioniert der Empfang einwandfrei, auch wenn die entsprechende Stelle komplett von der Hand umschlossen ist.

Was mir allerdings recht schnell aufgefallen ist, ist dass mein Philips Stereo Bluetooth Headset nicht mehr funktioniert. Mit dem iPhone 3G hatte ich nie Probleme, auch mit iOS 4 nicht. Versuche ich allerdings das Neue mit dem Headset zu koppeln funktioniert es überhaupt nicht. Die Geräte können sich nicht finden. Wenn man danach bei Google sucht, findet man auch tatsächlich einige Leute, die genau das gleiche Problem haben.

Scheinbar ist die Bluetooth Implementierung in iOS4 mit dem iPhone 4 etwas wählerisch bzw. fehlerhaft geworden. So berichten mehrere Personen darüber, dass sich Headsets gar nicht koppeln lassen, die Audio Qualität sehr schlecht ist und die Bluetooth Verbindung wieder abbricht.

Hoffentlich gibt es bald ein iOS Update, mit welchem die Probleme behoben werden :-/

Aber versucht es mal selber! Was kommt raus? Und bitte nicht kompilieren…

#include <stdio.h>
 
int func (int a, int b) {
	static int c = 1;
	return a + b * (c *= -1);
}
 
int main () {
	int a = 2, b = 3;
	int c = func(a, b);
 
	a *= a++;
	b *= ++b;
 
	printf("%d %d %d %d\n", a, b, c, func(a, b));
}

Als gute Lösung, ohne zusätzliches Plugin könnte man eine eigene config.yml im config Ordner erstellen

defaults: &defaults
  webservice_url: http://my.webservi.ce/rpc
 
development:
  <<: *defaults
 
test:
  <<: *defaults
 
production:
  <<: *defaults

Die Datei muss dann nur noch geladen werden. Dies kann man in config/initializers mit einem eigenen initializer machen

APP_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/config.yml")[RAILS_ENV]

Danach können die eingestellten Werte in der Rails Applikation einfach mit

webservice_url = APP_CONFIG['webservice_url']

abgefragt werden.

Es kam immer zu folgendem Fehler…

ActiveLdap::LdapError::NoSuchObject(No such object): filter 
(objectClass=subschema): attributes: ["objectClasses", "attributeTypes", "matchingRules",
"matchingRuleUse", "dITStructureRules", "dITContentRules", "nameForms",
"ldapSyntaxes"]

ActiveLdap hat eine zusätzliche Abfrage gemacht, und sich immer als anonymous beim LDAP Server angemeldet. Sobald man sehr restriktive ACLs auf dem LDAP Server hat, begegnet man diesem Problem sehr früh. Sobald also die ACL keine anonymen Verbindungen zulässt fliegt ActiveLdap auf die Nase.

Wenn folgende ACLs eingetragen werden

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

dann funktioniert es auch…

Mit dem Gem magic_model_generator ist das überhaupt kein Problem. Zuerst müssen wir uns erst mal das Gem installieren:

$ sudo gem install magic_model_generator

Als nächstes sollte die Datenbank Konfiguration der Rails Anwendung auf die bestehende Datenbank geändert werden. Danach brauchen wir noch eine aktuelle schema.rb Datei. Diese kann mit

$ rake db:schema:dump

schnell erzeugt werden. Und am Ende können die Models mit

$ ./script/generate magic_model

generiert werden. Momentan ist es aber leider noch nicht möglich, bereits vorhandene Models zu mergen, diese können nur überschrieben bzw. ignoriert werden.

Nach der Installation merkte ich, dass meine CPU immer zwischen 80-90% ausgelastet war, obwohl die VM eine Load von 0 hatte und nichts machte.

Es hat mich einige Zeit gekostet den Fehler zu finden. Grund hierfür war der Kernel von CentOS, dieser wurde nämlich mit einem internem “Takt” von 1000Hz kompiliert. Andere Distributionen verwenden hier noch 100Hz. Dies hatte zur Folge, dass VirtualBox sehr viel zu tun hatte und die CPU im Host-System nahezu ausgelastet war.

Das Problem kann aber recht einfach gelöst werden, indem der Kernel mit der Option divider=10 gebootet wird. Einfach an die Kernel Zeile in der grub.conf hängen und alles läuft.

Ich habe mir einige Zeit lang alle möglichen Receiver angeschaut, jedes Gerät kann so ziemlich das gleiche, sehen aber immer irgendwie optisch nicht ansprechend aus. Immerhin soll so ein Gerät sich auch richtig in die Einrichtung integrieren.

Nur Harman Kardon hatte auch optisch ansprechende Receiver, deswegen entschied ich mich für den AVR 255. Nachdem alles verkabelt wurde, war ich einfach nur begeistert. Selbst mit meinen alten Boxen (Canton) hörte man einen deutlichen Unterschied. Mit den 3 HDMI Eingängen konnte ich auch endlich alle Geräte zentral am Receiver anschließen und nicht immer beim Fernseher den Eingangskanal wechseln.

Da ich nur 5 Boxen hatte, musste ich den Receiver auch für Dolby 5.1 konfigurieren. Allerdings fand ich durch Zufall heraus, dass die 2 unbenutzten Boxenanschlüsse (eigentlich für 7.1 Anlegen gedacht) auch zur Beschallung eines anderen Raumses verwendet werden können. Da ich im Arbeitszimmer noch 2 Boxen an der Wand habe, welche momentan nicht benutzt wurden, habe ich die kurzerhand an den 2 freien Ausgängen angeschlossen. Durch den Mehrraumanschluss habe ich jetzt die Möglichkeit über den Receiver z.B. im Arbeitszimmer Radio zu hören und im Wohnzimmer fernzusehen. Natürlich kann man auch nur eine Quelle verwenden, um beide Räume zu beschallen.

Ebenfalls interessant ist die Art und Weise wie die Boxen eingerichtet werden. Mitgeliefert wird ein Mikrofon, welches sogar auf ein Foto Stativ angebracht werden kann. Dieses Mikrofon muss dort positioniert werden, wo man gewöhnlich sitzt. Der Receiver schickt nun ca. 5 Minuten aus jeder Box Tonsignale um die Boxen perfekt einzustellen.

Das einzige was noch fehlt, sind die passenden Harman Kardon Boxen (HKTS), welche sogar schon bestellt sind

Die Konfiguration unterscheidet sich ziemlich von der unter FreeBSD, so dass erst mal die Handbücher gewälzt werden mussten.

Als erstes sollte der NFS Service gestartet werden…

svcadm -v enable -r network/nfs/server

Danach ist die NFS Freigabe nötig, bei FreeBSD stehen die in /etc/exports, unter Solaris allerdings in /etc/dfs/dfstab. Eine Freigabe kann man allerdings auch auf der Konsole machen:

share -F nfs -o rw /export

Diese Methode überlebt allerdings keinen Reboot, so dass für eine permanente Freigabe die Zeile in der Datei /etc/dfs/dfstab eingetragen werden sollte.

Wenn auch der Benutzer root auf den NFS Clients verwendet werden soll, dann muss dies explizit freigegeben werden:

share -F nfs -o rw,root=host1:host2 /export

Die Option root=access_list legt fest von welchem Host der Benutzer root für die Freigabe Zugriff hat.

Um die Freigabe auf dem anderen System zu mounten, reicht der Befehl:

mount -F nfs server:/export /mount_point

Um das Volumen dauerhaft auf dem Client einzubinden, muss dies in der Datei /etc/vfstab definiert werden:

server:/export   -   /mount_point   nfs   -   yes    rw,soft

Also eigentlich gar nicht so schwer…man muss nur wissen, wo man alles nachlesen kann

Alle Sun Administration Handücher können übrigens unter http://docs.sun.com/app/docs/coll/47.16?l=de gefunden werden.

Im Bugtracker der MacPorts hat sich sehr lange wenig getan, das Problem wurde zwar scheinbar erkannt, es gab aber keine Lösung. Ohne einen Patch, lässt er sich immer noch nicht kompilieren. Damit er auch wirklich baut, muss das Portfile vom mplayer-devel Port mit folgendem Patch gepatcht werden.

Ist das geschehen, kann man endlich den Mplayer verwenden. Bin mal gespannt, wann es auch über den normalen Weg funktioniert.