Пиринговый браузер

Bittorent планирует выпустить браузер базирующийся на использовании пиринга для получения данных с сайтов, возможно такая идея имеет некоторые затруднения:

1. популярность, нужно получить достаточный процент использования, чтобы выйти на уровень эффективности технологии и как следствие требуются плагины для основных браузеров или модуль проксирования для поддержки остальных браузеров;
2. при кажущейся приватности: сайт и провайдер теряют к какой-то степени возможность контроля за трафиком, переходя в ранг трекеров, но в тоже время все соседи с которых идет скачивание контента начинают видеть хоть и частично весь трафик. И появляются проблемы с https/http 2.0 - загнать такой трафик в пиринговую сеть сложно так как каждый пакет шифруется ключом зависящим от сессии и как следствие его не расшариш без сессии нужны надежные обходные пути. 

Анонимность номера

Счастье всем даром 

и пусть никто не  уйдет обиженным.

Стругацкие.

Маленькая идея решения проблемы мультисимочников и для людей вынужденных носить множество телефонов, когда забываешь зарядить телефон или он неожиданно сел из-за двойной нагрузки работающих двух приемников. 

Решение достаточно простое и повторяет решения мобильных операторов, когда за дополнительную плату предоставляется дополнительный телефонный номер у этого же оператора. Достоинство его в получении неограниченного количества псевдо анонимных номеров телефона не привязанных к конкретному мобильному оператору.

Технически логика такова: получение по запросу с мобильного приложения или другого легкодоступного метод новый номер телефона, который можно сразу использовать для регистрации в магазинах или для других любителей рассылок, что позволяет не дать привязку к одному телефону и деанимизировать пользователя и узнать его личные предпочтения. Реализации возможна в таком виде, нужно выделить несколько номеров стандартной длины с добавлением суффикса неограниченной длины и проксировать звонок на реальный номер и с него, для этого можно арендовать номерную емкость и постепенно расширять при увеличении количества клиентов. 

Добавление логотопчика при загрузке

Для пояснения, где эта картинка будет показываться рассмотрим последовательность загрузки телефона:

1. uboot или другой загрузчик, показывает логотип кампании производителя статическая картинка поменять в теории можно, но нужно понимать как загрузка происходит на низком уровне и иметь возможность изменить radio и hboot разделы.
2. загрузка ядра и инициализация устройств, можно добавить лого именно сюда и оно  продержится пару секунд до момента старта инита и замены на анимацию загрузки
3. загрузка инита и монтирования разделов и запуск сервисов  показывается обычная анимация из файла подобного /system/customize/resource/hTC_bootup.zip.

Для того чтобы заменить или добавить логотипчик на 2 шаг нужно сделать такие шаги:

1. Преобразовать картинку с размером экрана(480x800) в raw формат: convert -depth 8 -size 480x800  ~/Downloads/Tux.png rgb:tux.raw
2. Собрать програмку конвертор в формат который понимимает ядро: gcc to565.c -o to565
3. И с конвертировать в нужный формат ./to565  -rle < tux.raw > msmlogo.rle
4. Положить этот файл в корень ramdisk и проверить включен ли CONFIG_FB_MSM_LOGO. По умолчанию картинка должна имень название initlogo.rle, но в моем случае инит скрипт пытался чтото сделать с этой картинкой, что приводило к ребуту телефона и для избежания конфликта я ее переименовал. 

Пересборка boot раздела для android

Собираем утилиты для распаковки образов:

git clone git://github.com/CyanogenMod/android_system_core

cd  android_system_core

gcc -o ../mkbootimg libmincrypt/*.c mkbootimg/mkbootimg.c -Iinclude

gcc -o ../unpackbootimg libmincrypt/*.c mkbootimg/unpackbootimg.c -Iinclude

Распаковываем старый образ полученный с обновления или иным путем:

./unpackbootimg -i boot.img

mkdir ramdisk

cd ramdisk/

gunzip -c ../boot.img-ramdisk.gz | cpio -id

В папке с ramdisk меняем части которые нам нужно, разрешаем отладку и отключаем проверки безопасности (при входе под adb сразу root) меняем:

--- default.prop 2014-08-07 22:35:02.481322985 +0300

+++ default.prop 2014-08-07 22:35:18.293601299 +0300

@@ -1,8 +1,8 @@

 #

 # ADDITIONAL_DEFAULT_PROPERTIES

 #

-ro.secure=1

+ro.secure=0

 ro.allow.mock.location=0

-ro.debuggable=0

+ro.debuggable=1

 persist.service.adb.enable=0

 ro.metropcs.ui=0

Соберем ramdisk обратно:

cd ramdisk/

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

cd ..

Упаковываем в новый boot:

cp ../z4u-kernel/arch/arm/boot/zImage .

./mkbootimg --kernel zImage --ramdisk newramdisk.cpio.gz --base 0x3b00000 --cmdline 'no_console_suspend=1 console=null' -o new_boot.img, где 0x3b00000 значение из boot.img-base, no_console_suspend=1 console=null значение из boot.img-cmdline 

Рекомендации хорошего стиля css/js

Немного рекомендаций хорошего тона для веб-разработки основанных на проблемах с которыми сталкивался когда то давно и уже не правда, но все же чтобы не забыть:

1. Минимизировать использование модификаторов absolute и zindex, что очень сильно упрощает поиск и изменение стиля и дизайна ведь порядок элементов внутри страницы совпадает с ее внешним видом;
2. Стараться не использовать фиксированные размеры элементов, и только если это действительно нужно фиксировать только одно направление чтобы было куда увеличивать элемент автоматически не ломая верстку;
3. Если нужно отредактировать чтобы какой-то элементов стал шире - расширять и родительский если он был фиксированным;
4. Оставлять достаточный размер по бокам от текста, чтобы было место если будут проблемы с начертанием текста;
5. Использовать загружаемые шрифты с внешних ресурсов подобных Google fonts с указанием замены из системных шрифтов на случай проблем с сетью;
6. Грузить библиотеки с cdn (Google cdn) с проверками ошибок и загрузки с локального домена в случае проблем;
7. Стараться писать стили и разметку максимально структурировано с использованием максимально конкретного описания классов в css и js - на случай если вдруг на странице окажется больше каких то элементов чем вы ожидали и вы сломаете чью то логику и дизайн;
8. стараться минимизировать обьем js/css кода внутри html кода, так как этот код часто повторяется на других, на страницах и его сложно минимизировать и избегать побочных эффектов;
9. Не перекрывать чужие классы своими - только дополнять с указанием специфичного для вашего случая класса, так как возможен случай что на странице будут оба типа элементов ваш и оригинальный и вы получите бардак на странице.

Права на домашний каталог в debian

Debian стал очень ориентированным на домашних пользователей как и остальные дистрибутивы поэтому права на домашние папки стали 755(rwxr-xr-x), что не очень хорошо если смотреть со стороны безопасности - пользователи на компьютере могут просматривать рабочий стол и документы у других пользователей. На google chrome, настройки и ssh ключи это не распостраняется, так как там стоят более безопасные права. 

Чтобы это решить для новых пользователей нужно запустить: dpkg-reconfigure adduser

Обновление hboot/radio разделов

После замены и изменение прошивки оригинальное обновление может вызывать проблемы из-за того что раздел для восстановления и системный раздел может отличаться от оригинального. Поэтому обновление только системных разделов может быть очень полезным.

Для этого нужно заблокировать загрузчик:
$ adb reboot bootloader
$ fastboot oem lock

Иначе обновить не получиться, можно получить ошибку вида:
FAILED ( remote: 99 unknown error)

Перепроверяем версию обновления:
Смотрим на modelid в выводе:
$ adb reboot bootloader
$ fastboot getvar all

Распаковываем обновление(OTA_*.zip) и смотрим файл firmware.zip/android-info.txt Если номера совпали значит можно продолжать.

Устанавливаем обновление:
$ adb reboot bootloader
$ fastboot oem rebootRUU
$ fastboot flash zip firmware.zip 

В консоли может появиться:
FAILED (remote: 90 hboot pre-update! please flush image again immediately)
При эом нужно повторить последнюю команду.

После этого ждем пока в консоли не закончиться выполнение, и перегружаем телефон. Шкала прогресса на экране может не дойти до конца пару процентов, но это нормально.

Разблокируем загрузчик:
fastboot flash unlocktoken unlock_code.bin

Код разблокировки можно получить с официального сайта.

cm11 recovery for z4u

Удалось преодолеть первый шаг на пути создания собственной прошивки для z4u. Теперь можно использовать recovery раздел по назначению:-) Можно ставить новый прошивки и делать бекап для текущей прошивки. 

Ранее recovery имел следующие недостатки: 

• прыжки изображения на экране при смене пункта меню что было не критично, но все же было недостатком (благодаря комиту); 
• после подсказки в обсуждении разработки recovery и сравнения файлов используемых как fstab на разных версия cyanogenmod - удалось исправить этот файл, который поменял синтаксис для новых версий и теперь все грузится без проблем. Ранее экран просто мигал несколько раз каждую минуту и не показывал никакого меню. 

На данный момент в автоматически сгенерированной конфигурации нужно исправлять: 

• fstab - по данным из /proc/emmc - данный файл отличается для 10.1 и 11 версии cyanogenmod 
• BoardConfig: BOARD_*_SIZE - для указания реальных размеров разделов, TARGET_ARCH_VARIANT_CPU, TARGET_BOARD_PLATFORM, TARGET_BOARD_PLATFORM_GPU - для указания реальных значений процессора и видеокарты.

Далее нужно создать прошивку которая способна грузиться в обычном режиме загрузки телефона.

Мобильные ядра

Состояние исходных кодов ядра linux мобильных устройств на примере z4u: 

• Отсутствие документации и комментариев в файлах. Частично решаемо запуском скрипта, который проводит маленькую интеллектуальную работу над исходным кодом удаляя все комментарии и документацию из кода, и сравнивает с исходным кодом, прошедшим точно такой же фильтр, но уже из официальных исходных кодов ядра близкой версии(msm-3.4(aurora), 3.4(kernel.org)). Если все прошло нормально код заменяется на официальный. Но это помогает лишь частично так как при изменении кода скрипт не признает его как подобный. Посмотреть на результаты можно в данном репозитории. 
• Изменения в в системном разделе заблокированы, что легко решается изменением конфигурации. 
• Код ядра базируются на старом коде, если смотреть по некоторым файлам, то исходные коды уже на год полтора отстают от текущего состояния, и может содержать гигантское количество уже исправленных ошибок и не содержать новых улучшений. Что возможно и является причиной отсутствия документации, ее просто тогда не существовало, когда код писался. Как пример arch/arm/common/dmabounce.c находиться в состоянии между 0703ed2a6b260cd743adf49a8281eb064d728832 (04 Jul 2011) и 1dc8f0065cb2a274785fac9da61417908e22e0b9 (15 Aug 2012), если судить по msm-3.4.

Сборка recovery под новое устройство

Последовательность действий такова:

Подготовка окружения для сборки:

• curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
• chmod a+x ~/bin/repo
• mkdir cm10.1 && cd cm10.1
• ../repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1
• ../repo sync

Версия 10.1 предпочтительна, так как с следующей версии возможны проблемы с загрузкой.

Генирируем заготовку для сборки:

• cd vendor/cm
• ./get-prebuilts
• make otatools
• PATH=$PATH:`pwd`/out/host/linux-x86/bin/
• build/tools/device/mkvendor.sh htc z4u recovery.img

Вместо htc z4u используем имена производителя и модели, но можно использовать любые значения, так как эти значения используются только как название каталогов. Образ recovery.img изначальный образ recovery с официальной прошивки не обязательный параметр, но позволяет заполнить часть значений в конфигурации. После этого в сгенерированной папках нужно поменять значения в BoardConfig.mk и в fstab. Как подсказку для заполнения последнего файла можно использовать список разделов из файла /proc/emmc или в выводе mount.

После обновления конфигурации, можно пересобрать ядро для чистоты эксперимента, конфигурацию ядра можно получить из /proc/config.gz и попытаться пересобрать ядро из исходников подобного устройства c aurora для qualcomm или другого репозитория. Наиболее удобным вариантом может быть скачать исходника с сайта разработчика устройства, пересобрать и заменить файл в сгенерированом каталоге.

• make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm z4u_defconfig 
• make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4
• cp {каталог с ядром}/arch/arm/boot/zImage device/htc/z4u/kernel

Затем можно пересобрать recovery в каталоге 10.1:

• source build/envsetup.sh
• lunch cm_z4u-eng
• . build/tools/device/makerecoveries.sh cm_z4u-eng или make recoveryzip -j 4
• fastboot flash recovery out/target/product/z4u/recovery.img

Результаты запуска нового recovery при ошибках можно попробовать посмотреть в /proc/kmsg и /proc/last_kmsg. Необязательно там что-то будет, но попробовать стоит.

Дополнительно можно посмотреть:

1. Сборка recovery
2. Презентация о портировании на новые устройство
3. Replicant Porting Guide
4. How To Port CyanogenMod Android To Your Own Device
5. Porting Android to Devices

Proxy и маршрутизация

Нет предела совершенству.

Оптимизация трафика на уровне прокси имеет несколько ограничений, если верить данным с chrome beta на мобильном телефоне, он смог уменьшить затраты трафика на 65% для сайтов благодаря тому что пропускал трафик через свои сервера и минимизировал его. Недостатков я не заметил, но если верить статистике с httparchive - крупные сайты достигли 77 пунктов в pagespeed - что достаточно не плохо на уровне среднего уровня оптимизации и с сравнение трафика пропущенного с оптимизацией с чистым трафиком покажет достаточно не плохие результаты, подобные двойному уменьшению объёма трафика.

Но все же они тоже не спасут - если присутствует большой объем данных описывающих состояние передающихся на каждый запрос, как противоположность передачи только существенных изменений - никакая оптимизация не поможет, так как если разбить трафик на такие части: 

• анонимные данные, не зависящие от клиента, 
• данные специфичные для клиента, 
• информация о смене состояния. 

То первые два соответственно могут покрываться кешированием данных и сжатием данных, то третий случай никаким образом не уменьшишь, так как эти данные закешировать нельзя, сжать из-за динамического изменения контента качественно тоже не получится, так как эти данные описывают динамику работы сайты или другого источника контента и затраты ресурсов на генерацию этих данных скрыть уже не получится, невозможно избежать стадию анализа полученного контента, которую невозможно начать не получив полностью контент и сжатие только уменьшает негативные последствия, но не решает саму проблему. 

Оптимизации вида пропустить весь трафик через общий канал с проксированием на ближайшем к клиенту сетевом оборудовании или минимизации объёма трафика пропуская его через минимальный маршрут решает проблему только частично. Вследствие того что, только прогнав максимум трафика через подобные анализаторы, мы сможем его оптимизировать, но в тоже время мы создадим единую точку отказа, так есть только один путь передачи данных и проблемы с ним лишают нас соединения полностью. 

Но идея вида максимально совместного использования инфраструктуры всеми возможными видами использования канала, как например: телевиденье, мобильная связь, интернет, позволяет получить покрытие до 100%. Так как исчезает потребность установки в некоторой малопопулярной местности оборудования (сетевое оборудование, передатчиков) для всех видов связи, устанавливает один, остальные арендуют. Так же изменить принцип работы мобильной сети, когда любой трафик должен пройти до корневого оборудования, вне зависимости где находятся источники этого трафика, чтобы соединение между конечным оборудованием разных видов связи, как частный случай одного, не шло через корневые узлы, а происходило по минимально возможному маршрут, например трафик для голоса и передачи данных обменивался в рамках пары десятков километров, а управляющий трафик шел, как и раньше на корневые узлы. Что позволит получить в достаточно большую теоретическую выгоду, так как данные миновав низкоскоростной канал связи, которым является последняя миля, могут быть централизовано быть проанализированы и пущены кратчайшим путем до получателя.