Pull to refresh
57
0
Игорь @nehyrb

Пользователь

Send message
А может быть всё проще и внутри кластера сидит карлик? Лет 200 назад подобное с шахматами провернули.
Великая постройка!

Вы не читали про вездеходы Грачева? Конструктивным решением сделать привод колес по бортам, Вы повторили его основную идею. Почитайте, в частности, про а/м «Синяя птица», который использовался для эвакуации космонавтов.
Поясните, пожалуйста, почему прививка от гепатита В — без вопросов?
Как-то считал что именно она без вопросов — не требуется…
А не вспомните, в момент когда вводили пароль к разделу, оригинальная флешка была подключена?
Может все-таки софт стащил ключ из криптомодуля с нее?
А зря… Очень интересная штука получается… Вся эта аппаратная начинка… пыль в глаза.

Во-первых, производитель пароль на MicroSD не поставил. В случае пароля, Вам бы не получилось карточку прочитать (Windows ее просто бы не увидел ее, а что-то более умное запросило бы этот самый пароль).

Алгоритм шифрования там симметричный. Если в софте реализовано чтение, то и запись должна быть. Тут скорее предположение, что софт универсальный и в нем реализована некая совместимость с обычными флешками, где разделы шифруются программно. Эта совместимость и сработала на сторонней флешке без криптомодуля. Однако, получается что и ключ шифрования хранится не внутри криптомодуля. По-правильному пароль в данном случае должен быть неким пин-кодом для доступа к ключу в железе (со всеми механизмами защиты от перебора), получается же что ключ шифрования напрямую генерируется из пароля.
Да, именно в обход драйвера файловой системы.
Можно вообще организовать и прямой доступ к разделу (в Windows):
HANDLE hFile = CreateFileA("\\\\.\\F:",
		GENERIC_READ | GENERIC_WRITE,
		FILE_SHARE_READ | FILE_SHARE_WRITE,
		NULL, 
		OPEN_EXISTING,
		FILE_FLAG_WRITE_THROUGH | FILE_FLAG_NO_BUFFERING,
		NULL);
DeviceIoControl(hFile, FSCTL_LOCK_VOLUME, NULL, 0, NULL, 0, &dwLen, NULL);
SetFilePointer(hFile, dwOffset, &dwOffsetH, 0);
ReadFile(hFile, pbFileBuff, dwLen, &dwLenR, 0);

Запросы ReadFile/WriteFile при этом идут как непосредственные запросы SCSI_READ/WRITE в USB устройство, в обход кеша ОС. Адрес чтения соответсвует физ. адресу сектора.
Для использования в самоделках — может быть. Для прошивки больших партий — очень спорно, может вылезти куча других проблем.
Да, еще интересный факт: LPC13xx содержит ошибку в загрузчике, причем так и не исправленную. Проявляется задержкой подключения раздела в 20 секунд (в Windows точно, в Linux никогда не было надобности проверять).
Спасибо за библиотеку! Может и пригодиться.
Просто к слову: подобную идею эмуляции файловой системы реализуют микроконтроллеры NXP LPC134x для загрузки в них микропрограммы. Там при подключении в режиме USB-загрузчика появляется раздел с файлом firmware.bin, стерев который и записав новый образ (причем не обязательно с таким же именем), перепрошивается память микроконтроллера.
Да, с таким расширением сохранять можно. Учитывая, что непосредственной адресации к номерам не нужно, так что не страшно, что длина данных в файле будет «плавать».
С ростом простых чисел, расстояние между ними постепенно увеличивается (вики). Когда встречается первый интервал больше 256 надо проверять. Так что такое сжатие допустимо только в определенных пределах.
Малое потребление BLE достигается за счет того, что модуль просыпается на очень короткие промежутки времени и при некоторых настройках чуть ли не 1 раз в 5 секунд. В момент передачи потребление не сказать что и низкое. Общая концепция nRF24l01 В моем примере Broadcast пакет можно слать так же не часто, засыпая в промежутках, как следствие — потребление будет сравнимым с BLE.
Странно, а в виде готовых модулей, все True-BLE очень сильно проигрывают в стоимости. В случае чипа CSR прибавьте еще внешнюю память для прошивки. Для по-настоящему массового устройства даже несущественная разница в цене может и оправдаться. Хотя для массового продукта, использовать устройство основанное на хаке не совсем и корректно.
Звонилки? Все выходящие нынче топовые телефоны имеют поддержку Bluetooth 4.0, и как следствие BLE. Сам же BLE создан как раз для передачи небольших объемов информации, поддержки передачи голоса у него нет, т.к. не хватает пропускной способности. Интернет через него шарить теоретически можно, но это добро-пожаловать в эпоху модемов. Его ниша — умные часы (отображение небольшого кол-ва информации с телефона) и датчики (запись небольшой информации в телефон), т.е. там, где объем данных мал и имеются жесткие требования к питанию.
Понятное, что во многих случаях лучше скомбинировать готовые решения. Эта статься описывает скорее рыбу, то как можно реализовать на самом нижнем уровне все составные части. Главный недостаток системы, который надо решить — нормальная долговременная работа.

Да, а графит (и скорее всего большое количество прочих готовых решений) я и вовсе не смог бы запустить в имеющихся требованиях, поддержка Python на сервере отсутствует, так же как и поддержка базы данных.
Наблюдая, каким образом растет объем данных (и в теле отдаваемой страницы), уже появилась идея реализовать подобный алгоритм.
В примерах к Highcharts подобного картинке нет. Думаю, подобные полосы в нем можно получить, если вывести 2ой график с состояниями 0-1 с заполнением.
Прошу прощения. Ссылки исправлены.
Хоть бы прокомментировали, что за ссылка. Я так понимаю, пакет визуализации данных, который покрывает то, о чем я написал?
Что есть из готового я не смотрел: не те цели были. Цель ставилась в первую очередь — протащить данные из датчика/контроллера на сервер, а затем вывести их в удобоваримом виде.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity