Блог:Виталий Филиппов
Вас приветствует YourcmcWiki!
2016-09-08 Тестирование скорости дешёвого SSD Silicon Power Slim S55 120Гб
Спойлер: Чтение приличное, а вот скорость записи — не очень (устоявшаяся 95 Мб/с).
Отчёт о реальных скоростях данного SSD. Тестировал утилитой fio, под Linux. Глубина очереди везде 128, планировщик noop, слияние запросов в очереди для теста отключено. При снижении глубины очереди производительность сильно проседает; ну, так и не надо её снижать.
- Последовательное чтение в идеальном случае (блоками >= 256кб) — 550 Мб/с
- Последовательное чтение блоками по 4к — в среднем 190 Мб/с, но прилично колеблется в пределах 170—280 Мб/с
- Последовательное чтение блоками по 8к — 370 Мб/с; по 16к — 450 Мб/с; по 32к — 500 Мб/с; по 64к — 530 Мб/с; по 128к — 540 Мб/с. Тут уже все цифры абсолютно стабильны, не колеблются.
- Случайное чтение блоками по 4к — 170 Мб/с (~41000 iops), тоже колеблется в пределах 120—220 Мб/с.
- Случайное чтение блоками по 8к — 305 Мб/с. По 16к — 340 Мб/с. По 32к — 380 Мб/с. По 64к — 440 Мб/с. По 128к — 510 Мб/с. По 256к — 535 Мб/с (это уже фактически последовательное чтение, а не случайное). Тут скорость опять стабильна, практически без колебаний.
- Есть «псевдо-SLC кэш». Последовательная запись первых 2.4 Гб блоками по 4к — 244 Мб/с. Крупными блоками (>= 256к) — 490 Мб/с.
- После 2.4 гб запись устаканивается на уровне 95 Мб/с, независимо от размера блока (SLC кэш кончается).
- Скорость случайной записи абсолютно идентична скорости последовательной записи.
- Скорость записи сохраняется постоянно, в том числе после полной перезаписи всего диска без TRIM.
- 30 секунд простоя достаточно, чтобы SLC кэш сбросился и запись вернулась к 490 Мб/с.
Наибольший «физический смысл» имеют случайные чтение/запись блоками 4к (стандартный размер блока ФС как в винде, так и в линуксе), а также последовательное чтение/запись блоками по 16к (так будет, если программа читает по 4к, а драйвер будет объединять соседние запросы), ну либо уже максимальными блоками (если программа копирует данные крупными блоками).
В общем, с чтением всё ок, но огорчает устоявшаяся скорость записи, 95 Мб/с — для SSD мало. Хотя, наверное, за эти деньги ожидать чего-то сильно лучшего и не приходится.
2016-09-07 ФС для флешек
Давно уже люблю на всяких мелких/тестовых серверках / с флешек монтировать. Удобно — места под rootfs много не надо, а скорость чтения — что случайного, что последовательного — вполне адекватная.
Другое дело, что случайная запись с обычными ФС типа ext4 очень медленная, флешки — это не SSD, гигагерцовых контроллеров и гигабайтов оперативки у них внутри нет — потому и Translation Layer внутри тупой, всё, что он обычно умеет — это «открыть» (стереть) и держать «открытыми» 2-3-4 блока стирания (обычно по 2 мб) и поддерживать в них последовательную запись. То есть, случайную запись мелкими блоками флешки не переваривают вовсе — iops на запись при этом обычно ограничивается 3-4 запросами в секунду.
Стандартно это решается лог-структурированными ФС, которые никогда не перезаписывают файлы «на месте», а всегда дописывают новую версию «в конец», одновременно постепенно освобождая место от старых блоков «в начале». То есть такие ФС чем-то похожи на кольцевой буфер :). И такие ФС под linux есть, я их ещё раньше уже тестировал: ubifs, jffs2, yaffs, logfs, nilfs2… фиг кстати знает почему, но в прошлый раз я почему-то остановился на ubifs, хотя она (как и jffs2, и yaffs) предназначена для MTD (голой флеш-памяти, не блочных устройств) и монтировать её одно извращение, и после краша она ещё не восстанавливается потом.
На самом деле из этих лучше брать nilfs2 — вроде самая живая и для блочных устройств подходит. Правда есть у неё как минимум один «нюанс» — на пустой ФС можно получить ошибку «нет свободного места», потому что она защищает (отказывается удалять) часть недавно созданных снапшотов. Время защиты вроде бы задаётся параметром `-o pp` при монтировании, но что-то я даже с pp=1 эту ошибку всё равно время от времени (при интенсивной записи) получал. Да и в общем в стабильность её работы у меня, честно говоря, особой веры нет. Экзотика, в общем.
Ещё отдельный юмор — это самсунговская F2FS (Flash-Friendly FS). Фиг знает, в каком она месте friendly и зачем она вообще создана — случайную запись она не ускоряет вообще.
Вот… некуда казалось бы податься любителю флешек. Но вчера возникла у меня идея — есть же btrfs! А в нём cow по дефолту для всех данных! Это ж как раз то, что нужно! И популярная, и по стабильности — не ext4, конечно, но я думаю уж точно получше экзотических nilfs’ов.
И таки точно! Берём обычную флешку (5 мб/с скорость последовательной записи), бенчмаркаем случайное чтение+запись блоками по 4-16кб (с помощью fio, в 8 потоков). Получаем суммарно (чтение+запись):
- ext4=7.15 iops
- f2fs=7.38 iops
- nilfs2=160.8 iops (лог-структурированная ФС)
- btrfs=128 iops (круто, почти не хуже чем nilfs2)
Короче всё, я на флешках буду btrfs теперь юзать.
2016-08-27 Математическое наблюдение на тему MTBF и AFR
Есть такой параметр, заявляемый производителями жёстких дисков — MTBF (Mean Time Before Failure), среднее время наработки на отказ. Ясно, что он чисто маркетинговый, так как очевидно, что невозможно честно определить его для новой модели. И фигурируют там обычно миллионы часов, самое меньшее 800000 — аж 91 год с гаком.
И вот непонятно — а какого чёрта харды вообще мрут при такой оценке надёжности? :-) ну как же, он 91 год в среднем прожить должен?
Ответ кроется в математике. Есть более осмысленный параметр — AFR (Annualized Failure Rate), вероятность выхода из строя в течение года. По статистике Backblaze (кроме них никто её по ходу не публикует) реальный AFR у дисков Seagate и WD как минимум процентов 5-10, у некоторых «особо надёжных» моделей аж 25-28 %, и даже у дисков HGST не ниже 0,8 % (а в основном 1-1.5 %).
А давайте попробуем по AFR посчитать MTBF? Если предположить, что AFR диска не меняется со временем, то MTBF в годах = 1*(1-AFR) + 2*(1-AFR)² + 3*(1-AFR)³ + … (матожидание числа лет). Разворачиваем формулу дважды в сумму геометрической прогрессии (так как это по сути сумма геометрических прогрессий, начинающихся с 1… 2… 3… и т. п. членов), и получаем MTBF в годах = (1-AFR)/AFR². Можно записать это и наоборот, решив квадратное уравнение, и получить AFR = (-1 + sqrt(1+4*MTBF)) / (2*MTBF).
По этой формуле MTBF 800000 часов = 9,93 % AFR, MTBF 1400000 часов = 7,6 % AFR, MTBF 2000000 часов = 6,4 % AFR. А 1 % AFR соответствует MTBF аж 86724000 часов! То есть, в принципе, MTBF 800000 часов не так уж и много, так как на самом деле он означает, что 10 % дисков выйдет из строя в первый же год :-).
Упс. В вычисления закралась досадная ошибка — правильная формула MTBF в годах = AFR + 1*AFR*(1-AFR) + 2*AFR*(1-AFR)² + 3*AFR*(1-AFR)³ + … = AFR + (1-AFR)/AFR. Соответственно AFR = (MTBF+1 — sqrt((MTBF+1)²-4)) / 2.
И, соответственно, никаких впечатляющих % там не будет — 800000 MTBF = 1.08% AFR, 1400000 MTBF = 0.62% AFR, 2000000 MTBF = 0.44% AFR. Ну ладно, тогда да, MTBF — просто ничего не значащая маркетинговая цифра :). Даже 1.08% — абсолютно нереально реально, современные HGST так и живут. Но когда я это писал, было таки нереально.
UPD: Вторая версия формулы, по-моему, тоже была неправильной, но, что удивительно, численные результаты получились верными. Правильно так:
MTBF = 1*AFR*(1-AFR) + 2*AFR*(1-AFR)^2 + ... = Sum_{i=0..+inf}((1-AFR) * (1-AFR)^i) = (1-AFR) / AFR 1 - AFR = MTBF * AFR <=> AFR = 1/(1+MTBF)
По этой формуле MTBF 800000 часов = 1.08% AFR, MTBF 1400000 часов = 0.62% AFR, MTBF 2000000 часов = 0.44% AFR.
А, и ещё картина по идее может зависеть от распределения отказов — интуиция подсказывает, что вряд ли оно равномерное. Но сильно, наверное, это вряд ли повлияет, так как вот тут http://www.cs.cmu.edu/~bianca/fast/ есть статья, из которой видно, что, по-видимому, лет где-то до 5 каждый год вероятность отказа неуклонно возрастает, а потом даже немного снижается.
2016-08-21 Паттерн бэд блоков в ddrescueview
Короче прогнал ddrescue на своём сдохшем Seagate Constellation ES.3 3 тб (ST3000NM0033). Вот такая картина (ddrescueview):
Если поближе, то вот:
О чём нам говорит такой паттерн? Судя по всему, об одной полностью сдохшей головке. Если посмотреть на цифры, то становится чётко видно, что картина по всему диску следующая — в начале диска идёт 50мб читаемых, 50мб нечитаемых, потом 600мб читаемых, потом примерно 50мб нечитаемых, 100мб читаемых, 50мб нечитаемых и дальше так и повторяется — 600-50-100-50… 600мб ближе к концу диска (к центру пластин), на самом деле, превращается в ~265мб, но соотношение всё время сохраняется чётко — 12:1:2:1 (где-то 11.8, где-то 12.2, но суть одна).
Блина у этой модели 4, головок 8. Потеряна как раз 1/8 данных. Логично, что это как раз и должно означать мёртвую головку. Единственным непонятным для меня моментом был паттерн — я думал, раз головок 8, хард с них должен читать по порядку — 12345678 12345678 и т. п. Но тогда картина читаемых-нечитаемых областей выглядела бы как 7-1-7-1-7-1…, а не 12-1-2-1-12-1-2-1…, как у меня.
Ответ, оказывается, простой — вместо традиционной схемы диски сейчас применяют также схемы «Cylinder Serpentine», «Surface serpentine» и их комбинации. В моём случае это как раз «Cylinder serpentine»: 12345678 87654321 12345678 87654321…, и плохая тут, видимо, как раз 2-я головка: 1(2)345678876543(2)11(2)345678876543(2)1…
Такой вот получился «RAID 0» из одного диска — сдохла одна головка, а потеряется почти всё, так как все данные дырявые, максимальный размер неповреждённой области — 614 мб.
Интересные ссылки по теме:
2016-07-30 Корпус Aerocool - наедалово
Твою мать! Козлы! https://market.yandex.ru/product/9275336, https://market.yandex.ru/product/9275333 - написано, что безвинтовое крепление HDD, в отзывах кто-то подтверждает — да, безвинтовое крепление, да, удобно.
А там оно не то что безвинтовое! Там и винтового-то не очень! Схема крепления через дикую жопу. Какие салазки, вы о чём! Крепления хардов просто какой-то суперизвращенец придумывал:
- два 3.5" в самом низу на винтах, вставляются со стороны материнки.
- один 2.5" плашмя на отведённом месте + с ОДНОЙ стороны крепится винтами.
- один 2.5" аж вертикально, крепится к панели внутри корпуса 4 винтами.
- один 3.5" плашмя на отведённом месте под 5.25" отсеками и крепится винтами.
- и один 3.5" прикручивается к специальной 5.25" панельке-переходнику, к ней же по желанию под хард лепится доп.вентилятор (если докупишь) и этот страшный бутерброд ставится в 5.25" отсек.
И ещё остаётся пара свободных 5.25" отсеков (нафиг они вообще нужны в 21 веке). ЖЕСТЬ.
Повёлся блин на описание товара. Заказал, теперь возвращать буду.
2016-07-21 Опа! В связи с законом о перс данных Seagate гарантии больше нет
За#бцааааа…
Гарантия производителя на диски Seagate Constellation ES.3 — 5 лет, но похоже, что теперь в связи с законом о персональных данных ей невозможно воспользоваться: http://www.seagate.com/ru/ru/support/russia-law/
Типа мы же иностранная компания, гарантийные запросы обрабатываем за рубежом. А они включают персональные данные.)). запретили обрабатывать персональные данные — вот и идите со своей гарантией в жопу в магазин, где покупали. :-))
Это у меня такой хард дуба дал. производство 2013, купил либо в 2013, либо в 2014, гарантия в магазинах обычно года 2-3, но главное чек не могу найти и не помню где брал…
2016-07-21 Helvetica Neue Condensed
Всегда считал, что Helvetica — это тот же Arial, а так как Arial не люблю, считал, что и Helvetica — отстой. Потом, правда, понял, что в мелких размерах Arial выглядит неплохо, но уже было не важно).
А недавно открыл для себя, что Helvetica Neue ещё бывает Condensed и вот это классный шрифт. Правда, в теории платный, но кого ж это волнует на самом деле, он настолько похож на свободный Roboto Condensed, что фактически можно юзать его (хотя субъективно гельветика чуть поаккуратней). Ещё один похожий шрифт — PT Sans Narrow (но он-то точно покривей). Вот все три:
Посередине Helvetica, сверху Roboto, внизу PT Sans.
2016-06-27 Минутка юмора nodejs
Задача: вытащить часть пути до первой части, содержащей glob-паттерн (glob — это стандартные шаблоны имён файлов: * ? [] {}).
Решение: один регэксп, да? Нееееет!
Для node.js есть целая библиотека glob-parent. Очень содержательная:
var path = require('path'); var isglob = require('is-glob'); module.exports = function globParent(str) { str += 'a'; // preserves full path in case of trailing path separator do {str = path.dirname(str)} while (isglob(str)); return str; };
Не, ну наверно там парсинг сложный, да? Давайте посмотрим, как написан is-glob:
var isExtglob = require('is-extglob'); module.exports = function isGlob(str) { return typeof str === 'string' && (/[*!?{}(|)[\]]/.test(str) || isExtglob(str)); };
Гм. Ну что ж, может вся хитрость в is-extglob?
module.exports = function isExtglob(str) { return typeof str === 'string' && /[@?!+*]\(/.test(str); };
Это весь код этих 3-х библиотек, ну за исключением всяких README и package.json, конечно… которые там в 5 раз больше.
2016-06-16 ClickHouse
ВАУ! ЖИР!
Яндекс сделал опенсорсную столбцовую СУБД! ClickHouse.
2016-03-04 А между прочим, в 5-м Android'е (в ART) запилили именно то, о чём я говорил
А между прочим, в 5-м Android’е, в новом рантайме ART, запилили именно то, о чём я говорил!
А именно — «разделяемые assembly». То есть чтобы можно было писать dalvik-библиотеки, которые не нужно, как jar’ники, загружать заново в каждый java-процесс.
Именно это и сделано в ART (ART — прозрачная замена Dalvik): вместо JIT-компиляции они теперь перешли к AOT, dex’ы теперь компилятся в нативный код, складываются в файлик на диске, а потом из него mmap()ятся — и, соответственно, ведут себя приблизительно как обычные .so’шки, не сжирая память отдельно в каждом процессе. Точно так же это сделано и в .NET — чтобы assembly превратить в разделяемый код, нужно её прекомпилировать.
Зиготу (zygote), правда, всё равно оставили, чтобы держать в общей памяти ещё и преинициализированные данные, и таким образом всё-таки экономить ещё чуть-чуть памяти. Но всё равно молодцы. По сути, это теперь получается, что ART чуть ли не круче самой явы :) вот бы его на десктопе попробовать с java кодом… :)
2016-03-01 Тупняк, но реально Quadro и FirePro - нае..надувательство
Обалдеть, вот дурь-то. Производимые и Nvidia, и AMD «профессиональные» видеокарты (Quadro, FirePro) — тупое искусственное разводилово. Просто в «непрофессиональных» на уровне firmware обрезают часть функционала и производительности в числах двойной точности, а аппаратно они ИДЕНТИЧНЫЕ.
В качестве пруфа можно привести тему на форуме, в которой чувак путём перепайки пары SMD-резисторов смог поменять PCI ID своей GTX690 и она ВНЕЗАПНО превратилась в Quadro K5000: http://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/
Жёсткое нае..дувательство, я бы такое запретил законодательно… запретил бы физически один и тот же продукт продавать по разной цене и под разными названиями. Вполне, по-моему, на мошенничество тянет)
2016-02-19 Уроды на службе FCC
Вашу ж мать. TP-LINK уже внедряет запрет обновления прошивки в соответствии с уродством FCC... http://www.opennet.ru/opennews/art.shtml?num=43907
2015-12-30 Итоги 2015 года
В общем, по итогам 2015 года стало чётко ясно, что всё это не временный маразм и кризис, а вполне осознанно установленный курс:
- внешнеполитический — на конфронтацию с Западом
- внутриполитический — на защиту жуликов и подавление оппозиции
- в интернете — цензурно-запретительный
- в рубле-баксе — 50р за $ уже видимо не будет никогда, не говоря уже о 35. дай бог на 80-90 не улететь.
- народного протеста не будет — половина ЗА, половина просто делает вид, что ничего не происходит
Всё это было и в 2014 году, но тогда надежда на скорое выравнивание ситуации ещё была, а теперь, по-видимому, понятно, что это было лишь начало тренда, а ближайшие лет 3-5-10 будет продолжение.
Так что чем НГ ближе, тем что-то мне грустнее…
Вот кстати хорошая статья по теме: http://www.gazeta.ru/column/vladislav_inozemcev/7996685.shtml
...И подчеркну еще раз: ничто из отмеченного не привлекает особого внимания.Это означает только одно: в отличие от 1998, 2008 или 2014 годов, кризис стал восприниматься в России как нечто обыденное.
Это огромный успех российской власти: народ окончательно превратился в безмолвную массу. Даже многократно обсуждавшийся протест дальнобойщиков не привлек к себе широкого внимания и не породил волны поддержки не потому, что их требования показались кому-то несправедливыми, а скорее, потому, что все хорошо понимают: против пожеланий власти народ бессилен, и ничего не изменится, сколько ни протестуй.
Население действительно перестало так пристально, как прежде, следить за курсом доллара, смирившись с тем, что страна деглобализировалась и нужно переходить на пошехонский сыр и белорусскую мебель, так как альтернативы им нет и не предвидится. Стало понятно, что любое развитие международной обстановки не приведет ни к отмене санкций, ни к притоку в Россию инвестиций, и это означает, что со снижением уровня жизни придется смириться на несколько лет.
2015-07-21 ExtJS - status update
Пописал я в очередной раз на ExtJS’е, и в очередной раз имею сказать следующее:
- На голом HTML писать быстрее
- На голом HTML писать проще (не нужно «натягивать» всё на «десктопную» парадигму)
- На голом HTML код лаконичнее
- Голый HTML легче стилизовать
- Голый HTML гораздо, на порядки шустрее.
Если перефразировать, то ExtJS — тормоз с однояйцевым интерфейсом, при этом писать на нём НЕ быстро, НЕ просто и НЕ лаконично. И даже если вы работаете не над чисто HTML’ным интерфейсом, а, например, с биндингами, всё равно есть лучшие альтернативы (тысячи их — Angular.JS, React и так далее). И GPL свой они трактуют так, что по их мнению ты должен открыть код не только фронтенда, но и бэкенда — и денег просят за любое коммерческое использование.
Был бы он хотя бы быстрым… но это же невозможно с таким нагромождением кода! Простой пример: самый полезный компонент Ext’а, Grid — реализован не в виде ОДНОЙ таблицы, а в виде множества, по таблице на каждую строку! Естественно, оно не использует layout браузера и естественно, оно лагает.
И самое главное, что ИМХО приложений, для которых «десктоп-подобный» интерфейс бы подходил ЯВНО лучше — НЕТ! Просто люди, которые раньше писали десктопные приложения, припёрлись в веб и тащат туда свой способ разработки. Чистый «BECAUSE WE CAN», короче.
2015-07-19 Турбина дула хорошо, но недолго
Пару недель назад заодно с ремонтом субарика (была немного продута прокладка ГБЦ) попросил Альпину вырезать катализаторы и прошить мозг, дабы дуло побольше и мощность была повыше. Сделали, Альпинский вроде как дунул туда 1.15 бара, машина поехала явно пободрее.
И ехала так две недели и где-то 1000 км, до сегодняшнего дня — а сегодня турбина перестала дуть вообще =) то есть машина едет тупо как атмосферная, никакого подхвата не наблюдается, и привычного свиста турбины тоже не слышно. Хотя я не понял, по форумам вроде пишут, что исправная турбина свистеть и не должна — а моя свистела всегда, сколько езжу)).
Варианты — либо сама турбина сдохла (заклинила), либо вестгейт, либо где-то дырка в тракте — во впуске, но тогда по идее движок нестабильно работать должен, либо может в аппайпе…
Абыдно, да, а я только датчик наддува купил, поставить хотел))
2015-07-11 WD Black2
Производитель зачем-то извратился и сделал так, что изначально видна только SSD-часть, а чтобы увидеть ещё 1 Тб HDD, его нужно сначала активировать путём запуска официальной Windows или MacOS утилиты. В комплекте идёт внешний USB 3.0 кабель — бонус приятный, но вот только активацию через него не сделаешь — она делается только через SATA интерфейс, не помогут даже более умные, поддерживающие SMART (в лице scsi-to-ata трансляции) USB кабели.
К счастью, после этой самой активации диск можно использовать в любой ОС, HDD уже никуда не «девается». Собственно, всё, что делает утилита — отправляет диску пару VSC (Vendor-Specific Command) и создаёт два раздела — один на SSD, второй на HDD. Теоретически VSC команды можно относительно легко подсмотреть, дизассемблировав консольную софтинку, идущую в составе MacOS версии официальной утилиты — она маленькая, написана на C++ и довольно легка к пониманию. Я даже немного попробовал туда взглянуть, но не добил.
SMART диском поддерживается хреново — работает лишь несколько общих показателей (температура, наработка часов и т.п). С TRIM, напротив, проблем нет.
Число 512-байтных секторов SSD: 234441648 (именно такого размера нужно делать раздел SSD). Общее число 512-байтных секторов SSD и HDD: 2187966778.
SSD’шка в составе довольно вшивая, последовательное чтение всего 133 Мб/с. Для сравнения, последовательное чтение с HDD в начале диска — 110 Мб/с, в конце (на внешнем краю блина) — 57 Мб/с. Вшивость SSD связана, видимо, с тем, что там всего 2 чипа флеш-памяти — непонятно, почему нельзя было поставить побольше: место над корпусом HDD на самом деле пустует, вся электроника SSD располагается с краю, там же, где и электроника HDD.
А вот скорость случайного чтения и записи. Тестировал утилитой fio, в 8 потоков блоками по 4-16 кб и по 1 мб:
- WD Black2 HDD:
- 4-16 кб: 0.46/1.57 Мб/с (чтение/запись)
- 1 мб: 37/32 Мб/с
- WD Black2 SSD:
- 4-16 кб: 13/43 Мб/с
- 1 мб: 64/51 Мб/с
- Для сравнения нормальный SSD Plextor PX-128M3:
- 4-16 кб: 23/78 Мб/с
- 1 мб: 128/114 Мб/с
То есть SSD WD Black2 примерно в 2 раза медленнее обычного SSD. Но, конечно, при случайном доступе всё равно гораздо быстрее HDD.
2015-07-09 Тупое клонирование интерфейсов
Вот никогда не понимал, зачем в некоторых программах настолько тупо клонировать некоторые интерфейсы?
Пример — Open/LibreOffice Document Recovery, абсолютно втупую склонированный с MS Office. Никогда не понимал, нафига для восстановления документа показывать отдельный модальный диалог при следующем запуске? Ну хочешь восстановить мой документ — просто открой закэшированную копию и покажи тонкой строчкой сверху «Документ восстановлен» или «Документ не восстановлен». На хрен для этого показывать отдельный диалог и заставлять меня ещё несколько раз кликнуть «Далее», «Finish» и «OK» в окне с ошибкой, если восстановить не удалось? Налицо же совершенно тупорылое копирование интерфейса MS Office, причём, очевидно, ещё старого, в котором был ровно такой же диалог.
И, наконец, самая дурь! Это самое «Recovery» происходит даже тогда, когда несохранённых изменений в документе вообще не было…
2015-06-21 Вкатил себе попи лоль 5.1 + нашёл нормальную тулу для MTP
Потратил чуть не день, но наконец-то выпилил штатную самсунговскую чудо-прошивку с кучей блотвари и залил какой-то левый билд CyanogenMod 12.1 (Android 5.1, попи лоль, SaberMod). Вообще можно было ещё взять JDC — там OTA есть.
Вроде стало побыстрее.
Так как, чтобы не прилетели какие-нибудь идиотские фантазии типа KNOX, официальные обновления отключены с первого дня, загрузчик остался XXUAMDE — это самый древний, а радиомодуль обновил до XXUBMH1 — это последняя версия модема, совместимая с не-KNOX’овым загрузчиком. Смысл буковок в том, что пока все нормальные люди нумеруют версии цифрами, самсунг это делает буквами: XXUA.., XXUB.., и т. п. Вот первая XXUD.. версия — уже KNOX, а KNOX нормальному человеку не друг.
И ещё наконец-то нашёл нормальную тулу для монтирования MTP в виде FUSE файловой системы: simple-mtpfs — она ЕДИНСТВЕННАЯ не тормозит (как, например, jmtpfs, go-mtpfs и android file transfer) и не глючит (как просто mtpfs).
2013-10-28 Каким бы мог быть Андроид
Этот пост я начал писать ещё 28 октября 2013 года :-)
А возвращаюсь я к нему каждый раз, когда думаю об обновлении прошивки на телефоне, задумываюсь об устройстве Андроида и испытываю по этому поводу сильный рвотный рефлекс. Ну почему там внутри такое уродство? Зачем лицемерный гугл, болтающий что-то об опенсорсе, делает его таким монолитным, неудобным для ковыряния и по факту закрытым?
Короче, вот каким бы, по-моему, мог быть ПРАВИЛЬНЫЙ андроид:
- Первое, что должно быть — модульность и пакетная организация системы, как в любом нормальном linux’е. Возможность обновления системной части по кускам или установки различных версий интерфейса: захотел — воткнул TouchWiz, захотел — воткнул гугловскую оболочку, захотел — MIUI, захотел — от Sony… без извращений со скачиванием идиотских «Zver Edition» сборок с бестолковых файлообменников. Без сбросов, без бэкапов. Опять-таки, как в любом нормальном linux’е!!!
- Вот эту фичу, кстати, в последнем андроиде почти реализовали: возможность выбора конкретных разрешений, предоставляемых приложениям, при установке, вместо безальтернативного «согласиться». «Почти» реализовали потому, что вроде-как возможности отрубить приложению доступ в интернет всё равно нет.
- Работать оно должно на стандартном ядре Linux, без костылей типа binder’а, «зиготы», эмуляции регистронезависимой ФС через fuse… Вместо первого — нужна тоненькая обёртка над банальными unix сокетами, вместо второго (с целью экономии памяти) — assembly, то есть «разделяемые библиотеки» на dalvik’е — насколько я понимаю, это есть в .NET, нужно было бы запилить аналогично.
- С учётом выпиленной зиготы запуск приложений тоже надо делать нормально — не через intent и вызов activity, а запуском обычного процесса. Тут конечно будут нюансы с обеспечением запуска под нужным юзером, но всё равно всё решаемо.
- GUI фреймворк делать надо так, чтобы его можно было использовать из любых языков, а не только из управляемого кода на яве! Самый очевидный способ сделать это — написать его на C/C++, а не на управляемой яве/далвике. Менее очевидный способ — как-то умудриться предоставить API с помощью Assembly, см. предыдущий пункт (тем более что AOT компиляция в андроиде уже есть). Также очень полезна была бы возможность замены UI фреймворка на другой (хоть Qt, хоть GTK, если захочется), без создания дополнительной прослойки.
- Естественно, обязательна поддержка usb mass storage (выпиленного в 4-ом андроиде каким-то идиотом), хоть даже напрямую в ext4, чтобы мелкософт своим убогим патентом на FAT32 LFN не потрясывал.
- Коли уж APK приложения не имеют зависимостей, вполне нормально было бы поддержать установку приложений вместе с данными в собственный каталог или раздел, не затрагиваемый при обновлении системы, а также поддержать произвольное разбиение диска. Чтобы на флешке при этом не копилась дикая свалка разнородного мусора, оставляемого приложениями — запись в другие директории разрешать только после подтверждения пользователем. При сносе приложений данные не удалять! Ибо они — собственность пользователя, а не приложения, и, соответственно, пользователь должен иметь к ним доступ. Бывает, конечно, всякий мусор типа кэша webview, но его просто нужно складывать отдельно, да и всё.
- Root права для пользователя должны быть доступны ВСЕГДА! Телефон и вообще софт должен защищать пользователя, а не ЗАЩИЩАТЬСЯ ОТ пользователя. То есть все selinux’ы и прочее фуфло должно быть либо отключаемым, либо реализовано так, чтобы пользователь всегда имел доступ ко ВСЕЙ системе.
- DRM, разумеется, быть не должно, в частности потому, что при наличии рута (который в итоге-то всё равно всем доступен) он всё равно БЕСПОЛЕЗЕН. На половые проблемы проприерастов, занимающихся продажей приложений (и фильмов, и прочего), мне в целом положить, но если уж им очень хочется, пусть делают свою защиту через привязку к серверу — способ вполне адекватный для смартфонов: уже сейчас нехилая часть приложений — тупо UI для чего-нибудь. Ну, калькуляторы продавать, конечно, уже не получится — НУ ТАК И НЕ ХРЕН. Ну не будет фильмов в маркете — тоже мне потеря. Всегда мечтал смотреть фильмы за деньги на 5" экране мобилы. Через мобильный интернет, ага. Всегда мечтал.
- Маркет должен быть более ориентирован на интеграцию с процессом разработки приложения: пусть там будет багтрекер, исходники в git, wiki, история версий, информация о лицензии, документация… Ну или просто интеграция с github’ом.
- НОРМАЛЬНАЯ опенсорсность самой системы. Сейчас андроид под лицензией Apache, в официальном репозитории поддерживается только для nexus’ов, и это создаёт огромные неудобства — каждый производитель городит свою закрытую оболочку со своими патчами, своим закрытым загрузчиком, своей системой обновления прошивки, да что там системой обновления… зачастую вообще без обновлений! Чтобы такого не было, нужно либо поменять лицензию на GPLv3 и вынудить производителей открывать все доработки, либо просто административным ресурсом загнать всех в ОДИН общий репозиторий, в котором и поддерживать. По сути, всё должно разрабатываться как CyanogenMod — система общая, а для разных девайсов различаются только специфичные части. Ещё лучше, если сделать и лицензию нормальную (GPLv3), и загнать всех в общий репозиторий. И поддерживать было бы проще, и обновлялись бы все охотно, и «фрагментации» бы пресловутой не было, и можно было бы изначально использовать нормальные компоненты, например, busybox и нормальный uclibc вместо bionic.
P.S: Ещё есть идея по поводу кроссплатформенных HTML/JS приложений — так как их очевидная проблема это непосредственно сам HTML, с его reflow’ами и отсутствием нативных контролов — нужно просто придумать другой нормальный скриптуемый язык описания интерфейсов (причём без особой специфики, чтобы можно было его сделать кроссплатформенным). Типа как стандартный андроидовский язык описания интерфейсов, только более приведённый к «вебовому» виду, со скриптами и даже, наверное, с возможностью грузить описания Activity с сервера аналогично HTML страницам сайтов (с кэшированием, конечно). Было бы, по-моему, очень круто — многие мобильные приложения сейчас представляют из себя просто нативные интерфейсы к сайтам, а так их даже не нужно было бы оборачивать в приложения — нативный интерфейс появлялся бы прямо в процессе просмотра интернетов.