/dev/blog/ID10T

Advertisement

ROM-Empfehlung für das HTC Desire: Android 4.2.2

• Android • Comments

Ich nutze nach wie vor mein erstes Smartphone, ein HTC Desire. Abgesehen von einer hakeligen Zurück-Taste funktioniert es noch ziemlich gut, weswegen ich eigentlich keinen Grund sehe, es zu ersetzen. Ein funktionsfähiges Gerät auszutauschen widerstrebt mir, auch wenn ich damit vermutlich einer Minderheit angehöre.
Allerdings wird beim HTC Desire offiziell nur Android 2.3.7 unterstützt. Diese Version ist ziemlich veraltet und lässt einige Features vermissen, die den Umgang mit dem Gerät wesentlich einfacher und angenehmer machen, beispielsweise die erweiterten Notificationbar Funktionalitäten.

2013-04-23-desire-jelly-bean_4 Nachdem ich jetzt einige Android 4.x-Roms getestet habe, bin ich beim Cyanogenmod 10.1 ROM von vijendrah angekommen. Schon seine Jelly Bean 4.1.2 ROMs waren die besten, das 4.2.2. ROM ist meiner Meinung nach sogar noch ein bisschen performanter und stabiler. Wie bei allen 4.x ROMs funktionieren nicht alle Funktionen astrein, aber eine Kamera, die manchmal etwas spinnt, ist die größte Einschränkung, der ich im täglichen Umgang begegne. Ansonsten halte ich dieses ROM für unbegrenzt empfehlenswert. Inzwischen ist es sogar so schmal, dass es auch auf das Data++ Partitionslayout (HBoot) passt, wodurch mehr interner Speicher für Apps zur Verfügung steht. Wie man den HBoot ändert und das ROM installiert, sollten die meisten Benutzer eines Desires wohl wissen, der Rest ist vermutlich schon auf ein neueres Gerät umgestiegen.

Deswegen will ich gar nicht viel über die Installation schreiben, sondern wirklich nur dieses ROM loben und weiterempfehlen. Wenn ihr also auf der Suche nach einem Update auf JellyBean für euer HTC Desire seid, nutzt das 4.2.2 ROM von vijendrah. Das System fühlt sich butterweich an und läuft sehr stabil.
Und wenn dann die Hardwaretasten irgendwann richtig versagen, kann man sich auf die Softwaretasten flashen, die seit Ice Cream Sandwich für Smartphones verfügbar sind.
2013-04-23-desire-jelly-bean_22013-04-23-desire-jelly-bean_32013-04-23-desire-jelly-bean_1
Falls entgegen meiner Erwartung doch noch Bedarf an einer Anleitung zum Rooten, S-Off schalten, Recovery aufspielen, HBoot ändern, ROM flashen oder allem zusammen besteht, könnt ihr mir das gerne mitteilen. :-)
 

 

OT: Meine momentane Situation

• Offtopic • Comments

Diesen Strip habe ich über Reddit gefunden und kann mich hervorragend damit identifizieren.

2013-04-19-distraction-comic

Momentan könnte ich haufenweise Blogposts schreiben oder an meinen diversen Projekten arbeiten, aber mein Spieler #3 (und natürlich auch meine Spielerin #2) geht mir dann doch einfach vor. Vielleicht finde ich ja irgendwann die Zeit, um mal was über PHP-FPM zu schreiben oder über meine Erfahrungen mit Groupware-Installationen oder meine neusten Spinnereien. Vielleicht aber auch nicht, Familie geht eben vor. :-)

(Quelle: lunarbaboon.com)

Perl: CPAN durch Squid-Proxy mit HTTP nutzen

• Administration and Linux • Comments

Das Problem, dass ich keine Module über CPAN nachinstallieren konnte, weil ich hinter einem Squid-Proxy war, der kein FTP durchließ, hatte ich jetzt schon öfters. Weil ich jedes Mal wieder überlegen muss, wie man diese Problematik nun behebt, hier eine fixe Erklärung.

Dazu bearbeiten wir die Konfigurationsdatei von CPAN, die überaschenderweise Config.pm heißt. Wo diese Datei zu finden ist, hängt unter anderem von der verwendeten Distribution ab. Bei meinem SLES11SP2 Testsystem liegt die Datei unter /usr/lib/perl5/5.10.0/CPAN/. In diese Datei fügen wir nun folgenden Eintrag ein:

'dontload_hash' => { q[Net::FTP]=>q[1], q[LWP]=>q[1] },

und bearbeiten wenn nicht schon bei der Ersteinrichtung geschehen den Eintrag für den HTTP-Proxy, um unseren Proxy-Server mitsamt Port dort zu hinterlegen.

'http_proxy' => q[http://proxy.foobar.org:3128],

Das war's eigentlich schon, damit sollte sich CPAN verbinden können. Doch was haben wir genau getan?
Wir haben CPAN angewiesen, die für FTP verwendeten Module nicht mehr zu laden. Dadurch gibt es ein Fallback auf WGET oder CURL, welche sich über HTTP verbinden und die dafür benutzten Proxyeinstellungen nutzen.

2013-04-05-config.pm

Es kann sein, dass je nach Proxykonfiguration nicht beide Module deaktiviert werden müssen. Allerdings bin ich mit dieser Einstellungen bisher immer gut gefahren.

Warum liebe Mainboardhersteller?

• Hardware and Rants • Comments

Mal wieder ein Rant. Da sich mein Geburtstag langsam nähert und ich eigentlich keine großen Wünsche habe, dachte ich mir, dass ich mir einen vernünftigen Testrechner aufbaue. Der Dell Optiplex 740, den ich hier rumstehen habe, ist in sämtlichen Kategorien durchgefallen, weswegen ich mir jetzt lieber einen eigenen zusammenstellen möchte. Mein Fokus liegt dabei auf bestmöglicher Unterstützung von Virtualisierung - speziell ESXi - und guter Aufrüstbarkeit. Ich dachte an ein Sockel 1155 Mainboard mit einem entsprechenden Intel-Prozessor, das bis zu 32GB RAM aufgerüstet werden kann. Und hier fängt das Problem an. Intel bietet zwei Technologien für Virtualisierung an, das allseits bekannte und fast überall unterstützte VT-x und das weniger bekannte und weniger genutzte VT-d. Um VT-d nutzen zu können, muss das Mainboard VT-d Unterstützung anbieten. Auch wenn ich vorerst nicht vorhabe, VT-d zu nutzen, würde ich mir diese Möglichkeit gerne offenhalten, also ein Mainboard einbauen, welches VT-d unterstützt. Aber das machen einem die Mainboardhersteller so schwer wie möglich. Bisher habe ich auf keiner Herstellerwebsite direkt Angaben gefunden, ob das Mainboard VT-d unterstützt oder nicht. Bei ASRock habe ich es im Handbuch finden können, aber auch nur, weil dort der UEFI-Eintrag dafür beschrieben wird.

Liebe Hardwarehersteller, warum macht ihr es uns so schwer, an solche "Randgruppeninformationen" zu kommen?

Als Fazit werde ich mich wohl für ein Mainboard von ASRock mit Z77-Chipsatz* entscheiden, diese unterstützen offenbar alle VT-d. Mein Favorit momentan ist das Z77 Pro 3.

*=Affiliatelink

 

VMware: Marktführer, aber...

• Rants • Comments

...für eine Internetanbindung jenseits von DSL reicht es dann wohl doch nicht.

Hintergrund der Geschichte: Wir haben momentan einige Supportcalls bei VMware geöffnet. Essentieller Bestandteil davon ist die Übermittelung von Coredumps und Logbundles zu VMware, damit deren Techniker eine tiefergehende Analyse vornehmen können. Gerade die Coredumps können schnell ein paar Gigabyte groß werden. Das scheint die Firma VMware, deren Marktwert so um die 30 Milliarden US-Dollar beträgt und deren Umsatz jenseits von 3,5 Milliarden US-Dollar pro Jahr liegt, nicht davon abzuhalten, die Uploadgeschwindigkeit von FTP-Accounts zu begrenzen. Dass die Geschwindigkeit VMware seitig begrenzt wird, wurde uns von einem Supportmitarbeitet bestätigt. Es scheint, als wäre die Uploadgeschwindigkeit pro FTP-Account auf ca. 180 KB/s begrenzt. Und wie man sieht, kann die VMware-Leitung nichtmal diese "Geschwindigkeit" beibehalten.

2013-03-26-vmware-highspeed-ftp

Hier mal als Vergleich ein banaler Speedtest:

2013-03-26-speedtest

Das Problem liegt also sicher nicht bei uns.

Dass eine IT-Firma solche steinzeitlichen Begrenzungen bei Diensten konfiguriert, die man sowieso nur mit bezahltem Support nutzen wird, empfinde ich als ein ziemliches Armutszeugnis.

Advertisement