Die Antwort hier ist ein klares nein, das Galaxy Nexus braucht eine normale SIM Größe. Wenn man eine Micro-SIM hat dann benötigt man einen Adapter von Micro SIM auf normale SIM Größe.
Den gibt es zum Beispiel hier: MicroSIM Adapter mit eingebauter Halterung, sicheres einlegen ohne Klebefixierung (Farbe: Schwarz) für iPhone 4+iPad Micro SIM Karten zur Verwendung als normale SIM-Karte
Ich bin bekennender iphone 4S Nutzer, dazu stehe ich. Aber die Apple Welt hat einen Nachteil, bleibt man permanent in ihr fühlt man sich irgendwie so sehr umsorgt, das man einfach denkt etwas zu verpassen. Also braucht man ab und zu mal den Blick in die Außenwelt.
Die Außenwelt als Iphone User ist nicht die vergessene Welt der Blackberrys sondern die der Androiden. Wenn man denn mal an Androiden denkt dann nimmt man sich doch das was alle als das Ziel ihrer Systeme so sehen. Ice Cream Sandwich, oder wie gestern gelernt – ICS. Das Ziel aller Träume. Die Vereinigung von Tablet und Phone. Gut, fein, ein guter Grund die angebliche Mutter aller Telefone zu kaufen.
Mein Dealer Amazon hatte es auf Vorrat und lieferte es Anfang der Woche. Gut, SIM rein, Exchange Account eingerichtet und einfach mal probiert. Da man ja mehr als eine SIM hat war auch nicht das Problem die Normalgröße des Nexus mit der Micro-Sim des iphones zu füllen. Parallelbetrieb hilft über die ein oder andere Hürde.
Gut ist das die Installation relativ problemlos funktionierte, einen Google Account habe ich ja nun auch. Damit kann man dann auch die Essentials einrichten, die da mit Hilfe des Android Markes da sind, Twitter, Facebook,Skype als erstes. Gut, das ging prima. Google+ kriegt man natürlich auch konfiguriert, das Ding will dann auch gleich Photostream in Richtung Google+ spielen. Nö, davon halte ich dann nichts. Icloud und Stream ist fein, der ist nicht erstmal in was das Freigaben unterstützt. Gefällt mir irgendwie besser und macht nicht gleich so viel Angst.
Generell dem Phone bei Google Diensten die Location zu erlauben fand ich dann auch mal daneben, also aus damit.
Nun gut, was braucht man noch so – hmm, ich habe eine große Itunes Library also eine Software die itunes synced. Gibt es im Android Market auch mit Wifi Add-On. Prima, kaufen wir – kostet um die 5 euro, halten wir aus.
If you do own an intel 82756 quad port adapter and are having problems with centos or fedora in such a way that your ethernet card just goes into a stage of being unavailable you’re having trouble with the power save modes that occur on the pcie bus.
Before there is any other fix a workaround is to disable pcie power saving by
a) appending
pcie_aspm=off
to your kernel boot command line
and/or
b) setting it at run time through:
echo "performance" > /sys/module/pcie_aspm/parameters/policy
That way you do turn of power saving on the pcie bus but in my opinion that is better than crashing machines or network cards.
Usualy, the crash will look like this in your logs:
Sep 23 19:55:43 cloudstorage1 kernel: NETDEV WATCHDOG: eth3 (igb): transmit queue 1 timed out Sep 23 19:55:43 cloudstorage1 kernel: Modules linked in: be2iscsi bnx2i cnic cxgb3i ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi xfs uio cxgb3 mdio nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipmi_devintf ipmi_si ipmi_msghandler 8021q garp stp llc bonding ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support e1000e igb dca sg ext4 mbcache jbd2 sd_mod crc_t10dif ahci arcmsr(U) dm_mod [last unloaded: scsi_transport_iscsi] Sep 23 19:55:43 cloudstorage1 kernel: Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 Sep 23 19:55:43 cloudstorage1 kernel: Call Trace: Sep 23 19:55:43 cloudstorage1 kernel: <IRQ> [<ffffffff8106b857>] warn_slowpath_common+0x87/0xc0 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff8106b946>] warn_slowpath_fmt+0x46/0x50 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff8142928d>] dev_watchdog+0x26d/0x280 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff8107d235>] ? internal_add_timer+0xb5/0x110 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff81429020>] ? dev_watchdog+0x0/0x280 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff8107de07>] run_timer_softirq+0x197/0x340 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff810a0c90>] ? tick_sched_timer+0x0/0xc0 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff8102f52d>] ? lapic_next_event+0x1d/0x30 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff81095a50>] ? hrtimer_interrupt+0x140/0x250 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff810142cc>] call_softirq+0x1c/0x30 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff81015f35>] do_softirq+0x65/0xa0 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff810739d5>] irq_exit+0x85/0x90 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff814cfa01>] smp_apic_timer_interrupt+0x71/0x9c Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff81013c93>] apic_timer_interrupt+0x13/0x20 Sep 23 19:55:43 cloudstorage1 kernel: <EOI> [<ffffffff812d9faf>] ? acpi_idle_enter_bm+0x28f/0x2c3 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff812d9fa8>] ? acpi_idle_enter_bm+0x288/0x2c3 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff813de987>] cpuidle_idle_call+0xa7/0x140 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff81011e96>] cpu_idle+0xb6/0x110 Sep 23 19:55:43 cloudstorage1 kernel: [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f Sep 23 19:55:43 cloudstorage1 kernel: ---[ end trace 70209fdc4667b544 ]---
In this situation an unload of the IGB driver does not help as the card never wakes up from power-save again:
Sep 23 20:55:52 cloudstorage1 kernel: igb 0000:04:00.0: Refused to change power state, currently in D3
So far I believe the only way is to reboot in order to get that issue cleaned up.
Neulich hatte ich ein Gespräch mit einigen Leuten aus einem Startup, es ging im wesentlichen um die Frage des Einsatzes kommerzieller Middleware versus der Selbstentwicklung eines Message-Queueing Systems in einem speziellen Fall.
Dabei wäre es durchaus möglich gewesen mit komplexen Modellen das gewissermassen zu modellieren und bei der abzählbar endlichen Anzahl Transaktionen pro Sekunde hätte man dabei auch noch mit Hardware nach einem Problem werfen können (wenn das auch teuer geworden wäre da pro CPU Core lizensiert wurde).
Heute dann in einem komplett abgesetzten Fall der Schock der Realität. Eine Banking-Software in der Version Business 5.0 in ihrem ersten Start hatte eine 90 MB Datenbank zu bearbeiten. Zwischen Client und Server lag ein Gigabit Lan, allerdings mit NAT und Firewall. Nach einem Start der Software und den aufkommenden Zweifeln nach 30 Minuten Wartezeit schaute ich mittels Windows Process Monitor mal nach was da passierte. Da passierte genau das wenn man Menschen ohne Verstand für das was darunter passiert an Frameworks/Middleware lässt. Es wurde eine Datei gelesen, 90 MB gross. Immer in 240 Byte Schritten, was auch immer diese Blocksize bedeutete – aber es wurden immer 64KB gelesen ab den 240 Byte increment.
Das ist irgendwie cool, man hat also aus 90 MB Daten die man lesen wollte über das arme Netzwerk einfach mal 90.000.000 / 240 = 375000 Leseereignisse gemacht. Tut nicht weiter weh, wenn man natürlich immer 64 KB liest und das immer über das Netz dann liest man einfach mal eben 375000x64KB = 24.576.000.000 = 24 GB !
Bei den 6 MByte/Sec die über das Netz vom Server kamen über Nat/Firewall und Soße und scharf dauert der Start der Software dann mal eben 1.5h. Gut gemacht die die verstanden haben was sie da tun und was für ein Read kommt wenn man mal 240 Byte von der Datei über eine Windows-Share liesst. Grandios.
Daher habe ich Angst vor Frameworks, Middleware und Programmieren die nicht verstehen was passiert wenn man etwas tut. Vermutlich bin ich damit aber fast alleine.
Da denkt man, das mit dem Einsatz von SSD das Leben im Bereich der großen schnellen Storage-Systeme ein wenig besser wird. Ja, das Zeugs hat noch seine Haken und Ösen und wird im Laufe der Zeit langsamer und verliert vielleicht auch Platz aber das es nicht einmal ein Jahr im Einsatz bereits böse verreckt, das hätte ich nicht gedacht.
Vor ca. 8 Monaten verbaute ich in einem mit geringem Schreibzugriff genutzten System eine 30 GB SSD der Firma Super Talent (STT_FTM32GX25H) als System-”Festplatte”. Darauf lief ein braves Centos bis vor einigen Tagen.
Während ich auf dem System (irrwitzigerweise zum Backup machen) eingeloggt war ging die Welt unter. Das Backup (auf ein iscsi-network device, also nicht auf die SSD) failte mit der Nicht-Lesbarkeit von Dateien. In den dmesg-Ausgaben taucht die Meldung auf, das das Root-Filesystem auf Read-Only ging und de-fakto ging die Welt der Maschine unter.
Nun gut, aktive Dienste auf ein anderes System umgeschaltet und einen Reboot inittiert der dann schon zeigte das eigentlich nichts mehr gehen wird – das Root-Filesystem konnte nicht gemounted werden. Ok, Rescue System gebootet und nachgeschaut, fsck sagt es geht nichts mehr, abgebrochen und den Datenbestand aufgegeben.
In einem Testsystem dann die SSD mal ein wenig getestet, und was durfte ich da sehen – Dinge die man eigentlich nicht glaubt, man würde davon ausgehen, das diese durch die SSD von selbst beseitigt werden.
root@sysresccd /root % badblocks -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
3546048
3546049
3546050
3546051
3546052
3546053
3546054
3546055
7562272
7562273
7562274
7562275
7562276
7562277
7562278
7562279
Das ging dann noch einige Zeit so weiter. Spannend sind dabei die 4k Blöcke, d.h. 8×512 Bytes am Stück waren kaputt. Warum ist das so ?
Nun gut, was kaputt ist, das ist halt kaputt und man probiert damit andere Dinge. Also das gleiche Kommando noch einmal und nun kam das echte Staunen:
root@sysresccd /root % badblocks -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
3969808
3969809
3969810
3969811
3969812
3969813
3969814
3969815
5012672
5012673
5012674
5012675
5012676
5012677
5012678
5012679
Mehr davon ?? Sehr spannend. Viele und vor allem: ANDERE !! Die Bad-Blocks haben also ihre Location verändert bzw. bei dem was auch immer die SSD da so veranstaltet hat sind es mehr bzw. andere geworden. Natürlich konnte ich es danach dann nicht mehr lassen:
root@sysresccd /root % badblocks -s -v -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in read-write mode
From block 0 to 31266647
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: 202816% done, 16:20 elapsed
202817
202818
202819
202820
202821
202822
Es wurden wieder mehr und andere. Nach einigen Läufen dann aber wiederholbar, auch nach dem Ein- und Ausschalten:
root@sysresccd /root % badblocks -s -v -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in read-write mode
From block 0 to 31266647
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found.
Merke: SSDs sind anders. Das tolle ist, das es auf der OS-Seite keine Read-Errors gab, nur es gab eben andere Daten zurück als hingeschrieben wurden. Quasi-Daten-Roulette.
Wenn man nun brav hinschriebt auf so ein Device, block 1-20 und dann Block 1,2,8,9,3,4,5,6,7,11-20 in der Reihenfolge kommentarlos zurück-bekommt, manchmal zumindest, dann ist das großes Kino.
Das sind dann die Momente wo ein Mirror von zwei SSDs auch nichts hilft, dann weiß man nachher nicht einmal mehr welche der Devices kaputt ist aber ist sich total sicher, das die Daten es sind. Datenrettungsansätze kann man auch vergessen, denn bei fast allen Filesystemen steht nicht im Block welcher der Block ist.
Bei den guten alten Festplatten konnte man sich wenigstens noch drauf verlassen das nach Block 1 der Block 2 kam. Und wenn der nicht kam, dann kam er nicht und nicht was anderes.
SSDs im Server ohne Cryptografisch-gesicherte Filesysteme – nein, das macht man nicht. SSDs für Daten die es nur einmal gibt und nicht in Mehr-Generationen-Backups über lange Zeiten, nein das macht man auch nicht. Das schlimmste ist die Kommentarlosigkeit des Datenverschwindens/Tauschens. Das ist geradezu obszön gefährlich.
