rPman

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

В конце концов e-ink это оно и есть, каждый пиксел это переворачивающаяся чернобелая сфера под действием электростатики или электромагнитных сил.

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

Единственный способ - взять готовое, копать в сторону www.cyanogenmod.org

Оформить php как сервис, в зависимости от того, какая система загрузки установлена читаnь документацию, upstart, systemd и т.п. во всех случаях это будет либо простейший скрипт (скопированный из примеров документации или из интернета) в котором вы укажете запуск своего php в виде запуска в цикле на том же bash - while(true);do php main.php;slep 1;done или на любом другом скриптовом языке, пусть и php.

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

А штатные средства резервного копирования? Недостатки - резервное копирование происходит на запущенной машине, зачастую с использованием http://ru.wikipedia.org/wiki/Теневая_копия а это значит что восстановленные данные будут в 'не консистентном' / 'не актуальном' состоянии (критично для баз данных) и может потребовать проверку и починку таблиц, вплоть до потери данных, т.е. для резервного копирования БД необходимо использовать их собственные средства.

namecheap.com, бесплатно только первый год (например домен + private + ssl <10$ на первый год)

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

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

Менее быстрое зато правильное - использование штатного memcache (чуть более быстрой базы данных с не гарантированным хранением данных), у нее свои лимиты, проверьте по тарифному плану.

Самое неправильное, если это возможно и выносится на клиентском уровне, продублировать базу данных на несколько разных аккаунтах и соответственно доменах. Например если бы данные были картинками, домен случайным образом можно было бы подставлять в адресе.

p.s. два года назад, бесплатные лимиты на практике были в разы меньше чем заявлено по тарифам - Проблемы с лимитами GAE, почему завышенны Datastore Read Operations?

Если обсуждать 'сферического коня' то выбор между 'notepad' и 'полнофункциональный IDE с отладчиком' диктуется не только выбранными библиотеками и фреймворками, но и банальной трудоемкостью развертывания и первоначальной настройки.

Отличный пример - попробуйте настроить с ходу на windows машине какой-нибудь php-IDE с работающей отладкой, вы меня поймете.

Например, долгое время, разработку серверной части php-сервисов (не только веб кстати) проходил в windows в FAR+несколько плагинов, без отладчика, зато без каких либо требований к рабочей машине, каких-то настроек и установки приложений, а на linux мне хватало vim.

Ваша задача очень эффективно решается обычным файлом на диске (открытый с запретом lazy writes, либо принудительным flush после каждой записи). Если инструментарий (язык программирования и библиотеки) позволяет - откройте файл маппингом на память.
Индекс для таких запросов не нужен, ведь ячейки можно индексировать примитивно - (x+maxx*y). запрос 100x100 блока превращается в 100 быстрых чтений по 100байт. Если это оправдано, можно хранить не ячейки а блоки 100x100, тогда при чтении будет читаться в 4 раза больше данных но четырьмя чтениями. Но если блок данных экрана влезает в буфер опережающего чтения операционной системы (драйвере файловой системы) то такой метод хранения будет неактуален.

Любой другой метод будет медленный либо по записи (например хранить в базе не ячейки а блоки 100x100, соответственно при запросе блока будут считываться четыре соседних), либо медленный по чтению (хранить по одной записи на ячейку) и не эффективный по месту на диске.

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

Еще есть вариант с использованием достижений (задания/квесты), количество выполненных - оценка для рейтинга. Можно систему рейтингов сделать зависимой (достижения могут быть выполнены только после выполнения предыдущих, можно даже сделать дерево достижений, чтобы игрок мог выбирать, чем именно заниматься)

Практика показала, что в конечном счете сложные и универсальные property/value решения все равно разовьются до кеширования значений в полях рядом (совершенно нормально будет тригерами наполнять полупустые кеш-таблицы с 100500 полей).

Т.е. для скорости вы все равно создадите эти поля (иначе реляционные базы ну оооооооооооочень медленные), но наличие property/value подхода развязывает руки и дает больше возможностей в будущем.

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

namecoin ;)
пора уже вовсю его использовать начинать… пока как дополнительный домен
p.s. кстати есть патчи для i2p

На текущий момент ЕДИНСТВЕННЫЙ генератор случайных чисел не подверженный манипуляциям и проверяемый (точнее с точной оценкой гарантии в деньгах или иных понятных величинах) — это bitcoin (а точнее любые криптовалюты, просто он достаточно дорогой).

Из недостатков — вы можете получить любое количество псевдослучайных чисел на базе нескольких случайных величинах (хеши из блоков или id транзакций), которые формируются (а точнее принимаются) не чаще чем достаточно большой интервал, а гарантия напрямую зависит от их количества. Речь идет о десятках минут и часах (6 подтверждений ~ час)… и главное, этот интервал тоже подвержен случайному числу.

Алгоритм очень прост — вы выбираете и публикуете — выбранную криптовалюту, номер блока (больше последнего найденного), алгоритм (детерминированный) получения числа из хеша блока и количество блоков, найденных после него (чем больше, тем дороже манипуляции, которые повышают вероятность 'отмены' значения).
Далее все участники ждут появления этого блока и необходимого количества блоков после него (это грубо говоря подтверждения) и вычисляют число по указанному алгоритму.

Возможные манипуляции — обладатель достаточных вычислительных мощностей (для PoW) и для некоторых криптовалют достаточного количества монет (для PoS), а сейчас разрабатываются еще более интересные технологии, например Proof-of-Wasted-Space (наличие памяти со случайным доступом) — может 'отменять' найденные блоки, таким образом меняя обнаруженное случайное число (но на какое то иное, значение которого так же не прогнозируемо).

Например пусть это будет следующий за текущим блок и 6 подтверждений после него. Алгоритм — последний байт в хеше блока (т.е. интервал числа 0..255)

Оценка стоимости атаки зависит от параметров сети, например для bitcoin это награда в блоке (статья исследование оценки требуемой мощности btcsec.com/double-spending/ ), на текущий момент это достаточно дорогое удовольствие (оценка стоимости хотя бы 2% — сейчас это 72терахеша — по цене хотя бы облачного майнинга cex.io в 0.12btc за GH/s ~ 8640btc или в$ по 223$/btc — ~2 миллиона $, и сюда не входит стоимость поддержания этого процента).

Если оригинальный скрипт не сохранил идентификатор таймера, возвращаемого при иннициализации, то никак. Официального способа перечислить запущенные таймеры нет, кроме как переопределить setInterval ДО вызова на свою функцию.

Если повезет, можно найти в вызываемом скрипте условие, при котором он завершится с ошибкой или будет работать вхолостую (удалить используемый DOM объект например).

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

По уму это кстати настраивается в политиках (для IE).

ID это просто идентификатор, определяется программистом (правда есть какие то предопределенные варианты, но если ресурсвьювер их не понял… значит чистый custom user)

Все это великолепие определяется в исходных текстах проекта в resource.h и подключается при компиляции файла resource.rc в котором текстом все это было описано. Если вас нет это го файла, значит обламывайтесь… и ничто не мешает в новой версии программисту переопределить эти идентификаторы на свой вкус.

p.s. начните с этой кнопки msdn.microsoft.com/en-us/library/windows/desktop/aa380599%28v=vs.85%29.aspx

Я не знаю, какие могут быть проблемы…
Если опасаетесь досмотр именно цифровой части, то все просто — зашифруйте раздел и скажите что везете новые пустые диски.