v9's aren't fast, so you may have a skewed idea of what super slow is... :)
however, if you don't have a working sim card in the phone then it'll be very very slow - the radio layer is looping and crashing all the time.
try turning on flight mode and see if it speeds up a lot.
if that works then there are posts around here somewhere that tell you which file to edit to fix it properly (so you can use wifi, bt), but try the above first to see if that really is your problem. get back to this forum if that fixes it and someone'll point you at instructions for the real fix.
sorry about that. my fault. I should have mentioned that different machines have different devices for the sdcard, and that my recipe was for zte v9 (like blade) not blade3. I just didn't think :( and to be honest I didn't expect you to try it! you are brave...
is there a way you can unbrick it?
and no, I think newer phones just have more and more partitions. sigh
try with -f to force the fsck.
also double check which filesystem is read-only with 'mount | grep ro'.
also triple check that your /data partition is large enough for the image you are flashing onto it.
if you want to avoid using the internal flash /data entirely, then it's tricky but possible. in the initramfs you can mount an ext3/4 partition from the sdcard (I use p3), and instead of the normal /data mount instead do a bind mount of /data to a directory on the sdcard partition eg.
# comment out the old mount of data/userdata and replace it with
mkdir /mnt_tmp 0771 system system
mount ext4 /dev/block/mmcblk0p3 /mnt_tmp nosuid nodev noauto_da_alloc barrier=1
mount none /mnt_tmp/cm11.0 /data bind
which mounts the directory "cm11.0" on partition 3 of the sdcard as your new /data.
it requires unpacking your boot.img, editing the rc script in the initramfs, re-packing it to a boot.img again, and then flashing it. it's very hard to debug if something goes wrong.
I don't suggest anyone use this who doesn't have to 'cos sdcards are usually a bit slower than internal flash, so the normal ways of shifting apps off a small internal /data to external sdcard work a little better, but I like it :)
it's good for devel work where I'm going backwards and forwards between OS versions - each OS version has their own separate /data in a different directory on the sdcard - cm10.1/ cm10.2/ cm11.0/ etc..
when I add a new OS version I just make a new directory and either leave it blank or rsync the last OS's /data onto it.
when filesystems turn read-only it's almost always because the kernel has detected corruption. if you are forcefully crashing or turning off your machine a lot then that can cause the problem. you could also be flashing images that are too big for the partitions would lead to a partial writes and hence a corrupted filesystem.
if it's not those, then it's likely a hardware problem...
is it an internal flash partition (cache, data) or the sdcard that is going read-only?
if it's the internal nand flash, and you really are doing complete wipes and reformats, then it's probably time to buy a new phone. the flash could just be worn out. a different partition layout that avoids using dodgy areas of the flash, maybe symlinking /cache to somewhere else, or an initramfs that bind mounts /data to an area on the sdcard are tricky but possible ways around this if you are an expert. if you are really reformatting your sdcard each time and it's still repeatedly turning read-only then try another sdcard.
I didn't know about Orbot - neat! I just tried it (my v9 rom is very similar to this blade rom) with install via Fdroid, and it connected ok, and check works fine. does your su work ok? maybe try the Fdroid version of the app rather than the play version (although likely they are the same)?
functionality is much the same. the main difference is that now we have complete access to all the source for the kernel (no more binary ar6000 kernel module holding us back) so in the future we can alter the kernel more (or even change kernel version entirely) and fix any wifi driver bugs too. the binary blob ar6000.ko we have used for yonks, and the built-from-src driver we now have, are both based on the atheros sdk 2.2 sources. the sdk was modified in unusual ways by zte to get it to work with blade & v9. now that I have worked out how to build the driver from src, it should be relatively easy for someone to port the zte hacks to atheros sdk 3, and that might yield some minor improvements to our wifi. frankly though, I don't see any problems with our current wifi, apart from it always having taken a few more seconds to scan and associate than I would like... the primary goal was to have complete source available. I don't have any immediate plans to port to sdk 3. I'm frankly a bit fed up with wifi having spend so much time getting it this far, so if anyone is keen to work on it further then go for it - the all the sources are on github. little fame and no fortune await - who could say no to that? :)
you are wrong :)
heartbleed is a client (your browser and your computer) problem as well as web server. both ends of the ssl (https) connection can be attacked equally.
in the android world, only android 4.1.1 was vulnerable though.
for me the big feature is that the wifi driver is now built from source. this was a lot of work and took a looooong time. done now though. phew :)
having all the kernel source means we can change and add features to the kernel more freely, and even one day maybe use a newer kernel version!
also battery saving stuff, bug fixes & features... the usual... enjoy.
new 20140309 rom - see first post. important fix for muted microphone in phone calls.
it's hard to believe this bug has been there since the first 4.4 rom - I guess not many people (including me) regularly use v9's as phones?!
no, that is not correct. you can have the current wifi with usb-host, just the battery will drain fast as the USB chips are always powered up. a cm7 kernel for v9 briefly had this configuration but it was a backwards step for 99.9% of users so was removed. also IIRC you will need an odd USB cable, and also (if v9 is like blade) then probably an external power source for your USB device too.
I don't have a cable to test and debug with, so I'm not going to do a modified kernel for you, but you can do it yourself!
git clone https://github.com/plaguedbypenguins/zte-kernel-msm7x27
and get a toolchain and build the kernel. change cyanogen_v9_defconfig to add usb host support. eg.
apart from the kernel there may well be other parts of the cm11 firmware that needs modification to detect and mount usb devices too, but you won't know what they are until you try :)