NDK, безусловно, очень интересная вещь. И если бы была только одна аппаратная платформа, то (ИМХО) все бы только на С/С++ и кодили. Но сила Android-а в его всеядности по отношению к железу, за счёт DalvikVM прослойки. Т.е. написав только на Java, программа должна (теоретически) запускаться на любом железе с подходящей версией API. Если писать нативный код, то, по-хорошему, нужно поддерживать версии для всего актуального железа, на сейчас это (пока) только ARM, x86 и начинается MIPS. И если даже само количество платформ вряд-ли увеличится, то текущие точно будут развиваться. Фрагментация — зло, очень тяжело поддерживать весь этот зоопарк. В Google это очень хорошо понимают и без самой крайней необходимости использовать не советуют. И не просто не советуют, а в каждых новых версиях открывают всё больше низкоуровнего API, для которого раньше без NDK никак. Тем не менее NDK они тоже продолжают развивать, и даже подтягивают туда Clang!
Сам сейчас стараюсь все делать на Java. Да, иногда сильно медленней, но такова идеология Android-а.
По поводу примера — он хорош, но область наверное не самая показательная, т.к. никакого преимущества в скорости работы это не даст, одни только лаги. Нужно стараться использовать родные форматы, в идеале — аппаратно ускоряемые (mp3,aac).
В нескольких проектах я использовал NDK, для того, что бы прикрутить библиотеку MuPDF для рендера PDF-ок в битмапу. Так как ничего родного (как в iOS) не нашёл, а Java-реализации ну совсем не радовали скоростью.
Простой и правильный вариант — устанавливайте себе на сервере watchdog демон, и он будет вам перегружать систему по настроенным вами критериям. Главное не забыть в ядре Linux-а подгрузить нужные модули, либо включить их в состав ядра. На материнках Supermicro как минимум один аппаратный watchdog timer вы найдёте, а то и все три.
Сложный, но интересный вариант — в панели управления мониторингом сервера создаёте проверку (ping, http-get и т.п.), настраиваете параметры уведомления на email. Где-то у себя вешаете на cron скрипт, который проверяет почту, и если пришло уведомление об ошибке — дёргаете (curl-сессия) панель управления на предмет перезагрузки вашего сервера.
Согласен, для простой конфигурации — очень удобно. Но если надо выявлять злостных плохишей, то нужна статистика, а она в базе. Кроме того база пригодится для создания white-list-ов. Скорее всего оптимальныйм будет гибридный вариант: использовать таймаут, для того чтобы не тулить в cron скрипт по удалению старых записей, а базу использовать для сбора статистики и решения о том, на сколько банить очередного плохиша, т.е. первый раз засветился — на три минуты, второй раз — на 10 и т.п.
P.S.: Очень люблю статистику, просто млею от rrd графиков.
One major problem for using NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 1-3 writes, depending on the manufacturers specifications.
зачем? Может это как-то связано с безопасностью, с залоченными бутлодерами?
Мне тоже очень интересно. На забугорных форумах этот вопрос довольно активно обсуждается, выдвигаются разные версии. Например такая. Что это связано с безопасностью и защитой know-how технологий от чужих глаз. Дело в том, что спецификации ARM ядер доступны всем лицензиатам, а вот проприетарные видеоядра — это тайна за семью печатями, соответственно если производителю нужно что-то «спрятать», то это лучшее место, где это можно сделать. Косвенно эту теорию подтверждает тот факт, что на SoC-ах с открытым (лицензируемым) видеоядром (PowerVR, Manli) процесс загрузки отличается.
Aux, спасибо что зацепили, пришлось искать документацию, узнал очень много интересного. Это тема для отдельной статьи.
Но вкратце, действительно можно говорить о том, что на некоторых SoC загрузкой управляет GPU (?!). Только это будет не совсем точно (технически).
Для Raspberry Pi вот что получается. Есть основной процессор (CPU) ARM1176JZF-S, есть графический сопроцессор (GPU) VideoCore IV® Multimedia Co-Processor, внутри (на территории) которого есть маленький сопроцессор, который управляет начальной загрузкой и также обеспечивает многие системные функци. Тут процесс загрузки описывают так:
At power-up, the CPU is offline, and a small RISC core on the GPU is responsible for booting the SoC, therefore most of the boot components are actually run on the GPU code, not the CPU.
На картинке FIG. 1B видно, что внутри Video Processing Core (на который часто ссылаются, как на GPU), есть ещё один блочёк, который тоже называется GPU — собственно та часть, которая обрабатывает 3D-графику и имеет право так называться.
Таким образом, на мой взгляд, корректным определением было бы такое: «Начальной загрузкой управляет сопроцессор, находящийся в VPU»
There are two processors in the MSM 7x30, an ARM9 for the radio and an ARM11 auxiliary applications processor
и далее
The ARM9 running REX loads the eMMC «hboot» partition into memory at 0x8D00000 (virtual) and starts the ARM11 auxiliary applications processor executing at this location.
Таким образом можно сказать, что начальной загрузкой управляет сопроцессор радиомодуля!
A co-processor known as the AVP (Audio-Video Processor), or sometimes by its legacy name, COP. This processor implements the initial boot process. This processor need not be the same architecture nor implementation as the main CPU complex; on all current Tegra variants, it is an ARM7TDMI.
и
When Tegra is powered on, the AVP executes code from the boot ROM. The main CPU complex is not started.
Т.е. тут загрузкой занимается сопроцессор, входящий в состав Аудио-Видео-Процессор-а.
Raspberry Pi — это микрокомпьютер, а вы писали про ARM-микропроцессор. Это разный вещи.
И кроме того, да — ничто не мешает инициализировать этот Пи без GPU. Именно так я и делал, когда устанавливал Android на плату с i.MX51. Система загружалась (при чёрном экране), а я через текстовый терминал на последовательном порту смотрел сообщения загрузчика, ядра и Android-а, и пересобирал, перепрошивал, опять смотрел, и так, пока не добился работоспособной (почти) системы.
Поэтому при подаче питания сначала запускается видео-карта
Что-то очень странное вы написали. Возможно трудности перевода? Процессор всегда инициализируется первым, выполняет свой BootROM, который загружает bootloader, который потом загружает ядро операционной системы. Видеокарта тут вторична. Её может инициализировать bootloader, а потом ядро. А часто видеокарты нет вообще, зачем она, например, в роутере?
Вот тут описан процесс загрузки типичного ARM-процессора. Могу ещё на Freescale i.MX51 доки (выдержки) кинуть, одно время я с ними поковырялся прилично.
У меня такая же. Специально покупал для обучения слепому набору. Ей бы ещё пробел пополам разделить, а то сильно тугой и громкий. Сразу чуть не плакал, так не удобно было работать. Но потом привык (ключевое слово), теперь набираю быстрее, а подсматриваю реже. Клавиатура усиливает эффект предложенного автором метода
Запретите себе нажимать клавиши неправильными пальцами.
т.к. нажимать неправильными пальцами на ней просто очень неудобно.
Во-первых, извращаться с fcgiwrap не пришлось — он у меня уже был настроен для collectd. Думаю что у многих так же.
Во-вторых, я тоже сразу подумал про PHP, но нужно, чтобы скрипт выполнялся от рута. А для этого пришлось бы подымать ещё один экземпляр php-fpm и запускать его от рута, что громоздко и не красиво.
А по моему сейчас если можно защититься программными средствами от атаки
Cпорный вопрос — на многих аппаратных фаерволах установлены вполне себе программные операционные системы, и даже Linux. Так что это, ИМХО, вопрос терминологии.
уже ддосом не назвать…
Если атака с большого количества адресов приводит к деградации или недоступности сервиса — то это есть чистый DDoS, по определению.
С серьёзным SYN-флудом пока не сталкивался. Да и статья не про этот тип атаки.
fail2ban помог, но я описал его недостатки — при высокой нагрузке на WEB-сервер, он уже сам по себе является тормозящим фактором (усиливающим эффект атаки?). Вот например, при ~800 запросах в секунду (это только на динамику), у нас лог вылетает со скоростью ~ 200кб/с
В данном случае это недостаток polling-архитектуры, логичнее и быстрее event/interrupt подход, что я и сделал.
Атаки, что я наблюдал у себя, были двух видов:
— не прекращающийся POST на регистрацию в форуме — вероятно спамеры подбирают логины
— ярко выраженный волнообразный наплыв однообразных запросов с нескольких сотен адресов
Респект! Почерпнул оттуда идею — надо вместе с IP хранить в базе хэш URL-а, тогда плохишей будет легче отделять, они действительно ломятся (как правило) по одному адресу. А если начнут бегать по всему дереву форума? Решение хорошее, но всё равно парсер логов, от которого я пытался избавиться. Да и от логов тоже можно избавляться — нечего им убивать SSD-шку или отжирать память в tmpfs-е. В идеале — лог — это только средство отладки (ИМХО).
От DDoS-а это не спасаёт, так как атакующих много. Да и в пределах одного keep-alive соединения можно порядочно насолить.
А в случае с SPDY (VBart, поправьте меня, если ошибаюсь) соединение и так будет всего одно.
В моём понимании CDN — это тоже хостинг, узко-специализированный. Про CloudFlare я очень высокого мнения, особенно после атаки на Спамхаус.
Бесплатный звучит заманчиво, возможно он даже очень хорош, но вот бесплатный Heroku вызывает только слёзы, а платный широко раскрывает глаза.
А вообще всё надо считать — у меня была ситуация, когда «CDN» из пяти «серверов» на Intel Atom оказался выгодней настоящих CDN-ов.
Т.е. если как-то можно грубо оценить нагрузку, то я беру dedicate, а если нагрузка может расти до облаков — то и хоститься там же.
Скорость обработки запросов в SPDY-соединении не может быть ограничена.
И ссылка на документацию ngx_http_limit_req_module.
По-моему, однозначно написано. Да и логично, т.к. в SPDY отдельные запросы мультиплексируются в один пакет данных. И в теории, в одном HTTP-запросе может прийти вся страничка целиком — с текстом, картинками и скриптами.
C Cloudflare не доводилось работать, но был опыт с Amazon и Heroku. Ничего плохого не скажу, на всякий товар найдётся свой покупатель. Пока ещё dedicated-серверы могут конкурировать с «облаками» как по аптайму, так и по цене. Ну и философско-шкурный вопрос — если «не изобретать велосипед» и отдавать услугу (хостинг/администрирование) на откуп «дядькам с большими квадратными головами» (фраза знакомых из Intel-а), то самому придётся зарабатывать чем-то другим.
из запретил доступ со всех IP, не принадлежащих им
Сам сейчас стараюсь все делать на Java. Да, иногда сильно медленней, но такова идеология Android-а.
По поводу примера — он хорош, но область наверное не самая показательная, т.к. никакого преимущества в скорости работы это не даст, одни только лаги. Нужно стараться использовать родные форматы, в идеале — аппаратно ускоряемые (mp3,aac).
В нескольких проектах я использовал NDK, для того, что бы прикрутить библиотеку MuPDF для рендера PDF-ок в битмапу. Так как ничего родного (как в iOS) не нашёл, а Java-реализации ну совсем не радовали скоростью.
Сложный, но интересный вариант — в панели управления мониторингом сервера создаёте проверку (ping, http-get и т.п.), настраиваете параметры уведомления на email. Где-то у себя вешаете на cron скрипт, который проверяет почту, и если пришло уведомление об ошибке — дёргаете (curl-сессия) панель управления на предмет перезагрузки вашего сервера.
P.S.: Очень люблю статистику, просто млею от rrd графиков.
А по поводу настоящей безопасности, то ARM (и некоторые лицензиаты — AMD, Samsung) активно продвигают технологию TrustZone, аппаратно поддерживаемую современными ARM-ядрами. Позволяет, в том числе, и обеспечить безопасную загрузку. Пока она не особо используется, но попытки есть — "Android app taps secure resources via ARM TrustZone" и Samsung Galaxy S3 may be the first smartphone with full ARM TrustZone support for enabling 100% security in everything online.
4. Запуск приложения, и тыканье пальцами левой руки в iPad, а правой — в GalaxyTab
5. Потягивание за чашкой кофе
6. А кто-то ещё и курит
Но вкратце, действительно можно говорить о том, что на некоторых SoC загрузкой управляет GPU (?!). Только это будет не совсем точно (технически).
Для Raspberry Pi вот что получается. Есть основной процессор (CPU) ARM1176JZF-S, есть графический сопроцессор (GPU) VideoCore IV® Multimedia Co-Processor, внутри (на территории) которого есть маленький сопроцессор, который управляет начальной загрузкой и также обеспечивает многие системные функци. Тут процесс загрузки описывают так: На картинке FIG. 1B видно, что внутри Video Processing Core (на который часто ссылаются, как на GPU), есть ещё один блочёк, который тоже называется GPU — собственно та часть, которая обрабатывает 3D-графику и имеет право так называться.
Таким образом, на мой взгляд, корректным определением было бы такое: «Начальной загрузкой управляет сопроцессор, находящийся в VPU»
У Qualcomm ещё интересней:и далее Таким образом можно сказать, что начальной загрузкой управляет сопроцессор радиомодуля!
С Tegra-ми инфы больше: и Т.е. тут загрузкой занимается сопроцессор, входящий в состав Аудио-Видео-Процессор-а.
И кроме того, да — ничто не мешает инициализировать этот Пи без GPU. Именно так я и делал, когда устанавливал Android на плату с i.MX51. Система загружалась (при чёрном экране), а я через текстовый терминал на последовательном порту смотрел сообщения загрузчика, ядра и Android-а, и пересобирал, перепрошивал, опять смотрел, и так, пока не добился работоспособной (почти) системы.
Что-то очень странное вы написали. Возможно трудности перевода? Процессор всегда инициализируется первым, выполняет свой BootROM, который загружает bootloader, который потом загружает ядро операционной системы. Видеокарта тут вторична. Её может инициализировать bootloader, а потом ядро. А часто видеокарты нет вообще, зачем она, например, в роутере?
Вот тут описан процесс загрузки типичного ARM-процессора. Могу ещё на Freescale i.MX51 доки (выдержки) кинуть, одно время я с ними поковырялся прилично.
т.к. нажимать неправильными пальцами на ней просто очень неудобно.
Во-вторых, я тоже сразу подумал про PHP, но нужно, чтобы скрипт выполнялся от рута. А для этого пришлось бы подымать ещё один экземпляр php-fpm и запускать его от рута, что громоздко и не красиво.
Если атака с большого количества адресов приводит к деградации или недоступности сервиса — то это есть чистый DDoS, по определению.
С серьёзным SYN-флудом пока не сталкивался. Да и статья не про этот тип атаки.
В данном случае это недостаток polling-архитектуры, логичнее и быстрее event/interrupt подход, что я и сделал.
Атаки, что я наблюдал у себя, были двух видов:
— не прекращающийся POST на регистрацию в форуме — вероятно спамеры подбирают логины
— ярко выраженный волнообразный наплыв однообразных запросов с нескольких сотен адресов
А в случае с SPDY (VBart, поправьте меня, если ошибаюсь) соединение и так будет всего одно.
Спасибо!
Бесплатный звучит заманчиво, возможно он даже очень хорош, но вот бесплатный Heroku вызывает только слёзы, а платный широко раскрывает глаза.
А вообще всё надо считать — у меня была ситуация, когда «CDN» из пяти «серверов» на Intel Atom оказался выгодней настоящих CDN-ов.
Т.е. если как-то можно грубо оценить нагрузку, то я беру dedicate, а если нагрузка может расти до облаков — то и хоститься там же.
По-моему, однозначно написано. Да и логично, т.к. в SPDY отдельные запросы мультиплексируются в один пакет данных. И в теории, в одном HTTP-запросе может прийти вся страничка целиком — с текстом, картинками и скриптами.
Вот этого не понял. Разъясни, пожалуйста.