Тесты есть, из распространённого - тест от NIST, Diehard, Dieharder. Но автор, к сожалению, так глубоко не копал.
Не могу найти, вроде здесь же на Хабре как-то проскакивал куда более основательный подобный проект - человек прогнал тесты, подключил девайс в качестве источника энтропии в Linux. Но там конструкция чуть другая была - источник фонил на оголённую матрицу веб-камеры.
Эхх, за столько лет можно было бы реализовать доступную из коробки на многих далёких от ИТ форумах функцию предупреждения "Внимание, пока вы писали, появились новые ответы" при нажатии отправки.
Там ещё разница во времени лет в 10. На момент популярности 6502 (конец 70-х/начало 80-х), на территории СНГ популярен не Z80, а "никакой". А ко времени Z80 в СНГ тот западный гик уже подрос и развлекался с каким-нибудь Motorola 68K.
Ого, сурово, не знал. С памятью через дескрипторы действительно похоже на то, что изначально разрабатывали под 286 (DOS/16M ?), упёрлись в производительность и портировали на 386+ с минимальными переделками. Если бы сразу под DOS/4GW писали — с памятью бы не стали так время тратить.
Если так - всё нужное для Doom есть и у однобитной машины Тьюринга. Однако в сравнении с 16-битным 286, на 386 уйма вещей становится гораздо удобнее - «плоская» адресация памяти без богомерзких сегментов, в регистры нормально помещаются значения требуемой точности, новые режимы адресации (SIB). Ассемблер 386 после 286 ощущался просто песней - вместо жонглирования костылями наконец-то стало возможным сосредоточиться на задаче.
Похожая история. У самих ещё не было PC, зависали у однокурсника с каким-то жутко б/у железом, о том, что монитор севший, понятия не имели, пока не увидели одну из «наших» игр на другом мониторе и оказалось что там есть довольно тёмные надписи на ещё более тёмном фоне. На нашем мониторе таки удалось поднять яркость потенциометром на плате внутри (наружная ручка яркости давно была на пределе) - увидели много нового, но прожил монитор недолго.
Как раз sedutil PBA и пользуюсь сейчас, но он довольно медленный: сначала стартует сильно урезанный образ Linux, содержащий приложение, запрашивающее пароль, посылающее команду дискам и перезагружающее систему, дальше идёт повторная загрузка с того же диска, но уже из шифрованной части. Вместо этого хотелось бы как-то так: из MBR грузится UEFI-приложение, запрашивает пароль, посылает его диску, перечитывает конфигурацию диска и продолжает с него загрузку.
Режим сна и OPAL — отдельная проблема пока без нормальных решений (видел костыли с удержанием пароля в RAM и повторной отправкой его диску, спасибо, не надо), у меня он просто отключён. Проблему режима сна наверное решило бы встраивание вышеописанного UEFI-модуля в BIOS? (повторно запросить пароль и разблокировать диск до восстановления контекста ОС?) Или загружаемому модулю как-то можно "остаться резидентом" и вмешаться в процесс пробуждения?
MBR в заблокированном состоянии, естественно, видеться должен. Мои претензии к тому, что в нём так же видится (как неразмеченное пространство) и шифрованный объём. Так понимаю, диск сообщает системе полный объём, а та уже понимает что таблица разделов в MBR описывает существенно меньшее пространство и показывает «у вас там есть ещё».
Кстати, «раз уж все здесь», вопрос к специалистам по UEFI: давно мечтаю написать (или найти готовый) UEFI-модуль, загружаемый из этого самого видимого MBR-раздела, который бы запрашивал пароль, посылал в OPAL-диск (это команды Security Protocol In/Out), подхватывал изменившуюся конфигурацию диска и продолжал загрузку с него же, не перезагружая систему (как сейчас делает sedutil). Это вообще возможно?
Попробовал загрузиться с другого устройства без расшифровки основного OPAL 2.0 диска (Samsung 970 Evo Plus) — Evo видится как маленький EFI System Partition (где лежит sedutil, запрашивающий пароль) плюс "нераспределённая область" на весь размер шифрованной части. При этом, если расшифровать, маленький EFI раздел полностью исчезает. Непоследовательно как-то, могли бы точно так же скрывать большую часть в заблокированном состоянии.
Если не далеко, скатайтесь в Мадрид в воскресенье, тут оно огромное и аж минимум с 1740 года. Ул. Ribera de Curtidores (в старом центре), каждое воскресенье с 9 утра.
Решающее отличие Поиска от ZX Spectrum — Поиск худо-бедно, но был частью большого стандарта, в котором было предусмотрено масштабирование (слоты расширения, понятные адреса дополнительной памяти, API драйверов типовых устройств итд). Расширяете память — получаете доступ к новому софту со всего мира (либо запуску резидентов параллельно со старым). А на Спектруме за "общемировыми" 128к начинались фрагментация платформы и "энтузиазм полутора человек". Много было софта под ваши 512к? Или софта, поддерживающего какие-нибудь самодельные часы реального времени? (и на который порт их вообще вешать?)
Спектрум любили за детерминизм — можно было познать все адреса/порты и виртуозно работать с ними на низком уровне, но этот же детерминизм был и потолком, для масштабирования были нужны абстракции.
Мы тут как раз недавно ретроаркадный зал запускали (автоматы Capcom, Sega итд), возникла идея там же поставить старый PC с каким нибудь несложным квестом/adventure, чтобы очередной случайный посетитель продолжал с того места, где бросил предыдущий. При выборе игры без вопросов победили Гоблины 2 :)
О, интересно. По всей видимости, у нас была самая первая версия, никаких скрытых алгоритмов и разблокировок не было, игра сразу продавалась за деньги (лицензионная 5.25” дискета, на конверте синий штамп Геймоса, никакой защиты). Предполагаю, всё это быстро спиратили и авторы перешли на свободное распространение с платными интересностями. Сейчас ещё окажется, что и графику потом красивее сделали? Помнится, запустили и были разочарованы блёклым 16-цветным видом.
Мы с другом о ней в каком-то журнале прочитали, очень впечатлились, вскладчину купили лицензионную дискету в "Доме Книги", поиграли несколько дней на УПК и разочаровались — самая примитивная программа из встроенных ("Hunter" вроде звалась, где половина поля по диагонали головой заполнена) побеждала любые наши (и остальные встроенные).
У кого-нибудь получалось побеждать Хантера?
Стек сломает далеко не любой символ форматирования. Форматы, означающие непосредственные значения (%d, %f, %p итд) просто прочитают из стека «чужое» значение, ничего не испортив (кроме случая когда стек практически пуст/форматов много и чтение достаёт до отсутствующей памяти). А за удаление параметров отвечает вызывающий код, строка формата никак на это не влияет.
Конкретный телефон не назовёте? Ибо Symbian действительно заявляли что-то в этом духе при переходе на ядра EKA2, но на практике всё делалось ровно наоборот — у всех Nokia и Ericsson на Symbian 9.х модем был как раз полностью вынесен в отдельный чип. Подозреваю, речь шла о выдающихся достижениях в уменьшении задержек в ОС, достаточных для построения одноядерного телефона, будь у нас ядро соответствующей производительности (однако на дворе уже вовсю было 3G и поезд опять ушёл).
Процессор (точнее то ядро, которое все исследовали) там явно не один, его производительности просто не хватит на полный стек GSM. Типичной для тех времён была компоновка: целочисленное ядро (чаще - ARM, C166 у Siemens, AVR или CR16B у Ericsson) для UI и GSM L3 плюс DSP-ядро для GSM L2/L1 (а в совсем старых телефонах они ещё и физически в раздельных корпусах были). Код, исполняемый на DSP, у многих вообще частью прошивки не являлся (неизменяемый в mask ROM был) и на глаза исследователям не попадался. Единственным виденным мной исключением (да и то скорее «в обратную сторону») был процессор SCM-A11 у Motorola, у которого вообще весь GSM-стек работал на одном DSP-ядре (архитектуры StarCore - DSP, расширенный под целочисленные нужды. SCM - Single Core Modem), а целочисленное ядро (ARM1176) было полностью освобождено под простой с виду, но тяжёлый (из-за Linux под капотом) UI. И то, было это уже во времена заката GSM и расцвета 3G, а в описании SCM-A11 присутствовала фраза о том, что одноядерная производительность наконец достаточна для реализации всех трёх уровней GSM.
Тесты есть, из распространённого - тест от NIST, Diehard, Dieharder. Но автор, к сожалению, так глубоко не копал.
Не могу найти, вроде здесь же на Хабре как-то проскакивал куда более основательный подобный проект - человек прогнал тесты, подключил девайс в качестве источника энтропии в Linux. Но там конструкция чуть другая была - источник фонил на оголённую матрицу веб-камеры.
«Задача создания гипертекстового фидонета, как минимум, актуальна»
Под Windows вот этот софт показывает дерево.
Эхх, за столько лет можно было бы реализовать доступную из коробки на многих далёких от ИТ форумах функцию предупреждения "Внимание, пока вы писали, появились новые ответы" при нажатии отправки.
Там ещё разница во времени лет в 10. На момент популярности 6502 (конец 70-х/начало 80-х), на территории СНГ популярен не Z80, а "никакой". А ко времени Z80 в СНГ тот западный гик уже подрос и развлекался с каким-нибудь Motorola 68K.
С декодерами вообще странно было - в «Электронах» 4 поколения декодер PAL уже был, но почему-то не работал и всё равно приходилось ставить другой.
А ещё масштабирование малых чисел сделать не в 1000 раз умножением/делением, а в 1024 сдвигом на 10 бит.
Ого, сурово, не знал. С памятью через дескрипторы действительно похоже на то, что изначально разрабатывали под 286 (DOS/16M ?), упёрлись в производительность и портировали на 386+ с минимальными переделками. Если бы сразу под DOS/4GW писали — с памятью бы не стали так время тратить.
Если так - всё нужное для Doom есть и у однобитной машины Тьюринга. Однако в сравнении с 16-битным 286, на 386 уйма вещей становится гораздо удобнее - «плоская» адресация памяти без богомерзких сегментов, в регистры нормально помещаются значения требуемой точности, новые режимы адресации (SIB). Ассемблер 386 после 286 ощущался просто песней - вместо жонглирования костылями наконец-то стало возможным сосредоточиться на задаче.
Похожая история. У самих ещё не было PC, зависали у однокурсника с каким-то жутко б/у железом, о том, что монитор севший, понятия не имели, пока не увидели одну из «наших» игр на другом мониторе и оказалось что там есть довольно тёмные надписи на ещё более тёмном фоне. На нашем мониторе таки удалось поднять яркость потенциометром на плате внутри (наружная ручка яркости давно была на пределе) - увидели много нового, но прожил монитор недолго.
Как раз sedutil PBA и пользуюсь сейчас, но он довольно медленный: сначала стартует сильно урезанный образ Linux, содержащий приложение, запрашивающее пароль, посылающее команду дискам и перезагружающее систему, дальше идёт повторная загрузка с того же диска, но уже из шифрованной части. Вместо этого хотелось бы как-то так: из MBR грузится UEFI-приложение, запрашивает пароль, посылает его диску, перечитывает конфигурацию диска и продолжает с него загрузку.
Режим сна и OPAL — отдельная проблема пока без нормальных решений (видел костыли с удержанием пароля в RAM и повторной отправкой его диску, спасибо, не надо), у меня он просто отключён. Проблему режима сна наверное решило бы встраивание вышеописанного UEFI-модуля в BIOS? (повторно запросить пароль и разблокировать диск до восстановления контекста ОС?) Или загружаемому модулю как-то можно "остаться резидентом" и вмешаться в процесс пробуждения?
MBR в заблокированном состоянии, естественно, видеться должен. Мои претензии к тому, что в нём так же видится (как неразмеченное пространство) и шифрованный объём. Так понимаю, диск сообщает системе полный объём, а та уже понимает что таблица разделов в MBR описывает существенно меньшее пространство и показывает «у вас там есть ещё».
Кстати, «раз уж все здесь», вопрос к специалистам по UEFI: давно мечтаю написать (или найти готовый) UEFI-модуль, загружаемый из этого самого видимого MBR-раздела, который бы запрашивал пароль, посылал в OPAL-диск (это команды Security Protocol In/Out), подхватывал изменившуюся конфигурацию диска и продолжал загрузку с него же, не перезагружая систему (как сейчас делает sedutil). Это вообще возможно?
Попробовал загрузиться с другого устройства без расшифровки основного OPAL 2.0 диска (Samsung 970 Evo Plus) — Evo видится как маленький EFI System Partition (где лежит sedutil, запрашивающий пароль) плюс "нераспределённая область" на весь размер шифрованной части. При этом, если расшифровать, маленький EFI раздел полностью исчезает. Непоследовательно как-то, могли бы точно так же скрывать большую часть в заблокированном состоянии.
Если не далеко, скатайтесь в Мадрид в воскресенье, тут оно огромное и аж минимум с 1740 года. Ул. Ribera de Curtidores (в старом центре), каждое воскресенье с 9 утра.
Решающее отличие Поиска от ZX Spectrum — Поиск худо-бедно, но был частью большого стандарта, в котором было предусмотрено масштабирование (слоты расширения, понятные адреса дополнительной памяти, API драйверов типовых устройств итд). Расширяете память — получаете доступ к новому софту со всего мира (либо запуску резидентов параллельно со старым). А на Спектруме за "общемировыми" 128к начинались фрагментация платформы и "энтузиазм полутора человек". Много было софта под ваши 512к? Или софта, поддерживающего какие-нибудь самодельные часы реального времени? (и на который порт их вообще вешать?)
Спектрум любили за детерминизм — можно было познать все адреса/порты и виртуозно работать с ними на низком уровне, но этот же детерминизм был и потолком, для масштабирования были нужны абстракции.
Мы тут как раз недавно ретроаркадный зал запускали (автоматы Capcom, Sega итд), возникла идея там же поставить старый PC с каким нибудь несложным квестом/adventure, чтобы очередной случайный посетитель продолжал с того места, где бросил предыдущий. При выборе игры без вопросов победили Гоблины 2 :)
О, интересно. По всей видимости, у нас была самая первая версия, никаких скрытых алгоритмов и разблокировок не было, игра сразу продавалась за деньги (лицензионная 5.25” дискета, на конверте синий штамп Геймоса, никакой защиты). Предполагаю, всё это быстро спиратили и авторы перешли на свободное распространение с платными интересностями. Сейчас ещё окажется, что и графику потом красивее сделали? Помнится, запустили и были разочарованы блёклым 16-цветным видом.
Мы с другом о ней в каком-то журнале прочитали, очень впечатлились, вскладчину купили лицензионную дискету в "Доме Книги", поиграли несколько дней на УПК и разочаровались — самая примитивная программа из встроенных ("Hunter" вроде звалась, где половина поля по диагонали головой заполнена) побеждала любые наши (и остальные встроенные).
У кого-нибудь получалось побеждать Хантера?
Стек сломает далеко не любой символ форматирования. Форматы, означающие непосредственные значения (%d, %f, %p итд) просто прочитают из стека «чужое» значение, ничего не испортив (кроме случая когда стек практически пуст/форматов много и чтение достаёт до отсутствующей памяти). А за удаление параметров отвечает вызывающий код, строка формата никак на это не влияет.
Конкретный телефон не назовёте? Ибо Symbian действительно заявляли что-то в этом духе при переходе на ядра EKA2, но на практике всё делалось ровно наоборот — у всех Nokia и Ericsson на Symbian 9.х модем был как раз полностью вынесен в отдельный чип. Подозреваю, речь шла о выдающихся достижениях в уменьшении задержек в ОС, достаточных для построения одноядерного телефона, будь у нас ядро соответствующей производительности (однако на дворе уже вовсю было 3G и поезд опять ушёл).
Процессор (точнее то ядро, которое все исследовали) там явно не один, его производительности просто не хватит на полный стек GSM. Типичной для тех времён была компоновка: целочисленное ядро (чаще - ARM, C166 у Siemens, AVR или CR16B у Ericsson) для UI и GSM L3 плюс DSP-ядро для GSM L2/L1 (а в совсем старых телефонах они ещё и физически в раздельных корпусах были). Код, исполняемый на DSP, у многих вообще частью прошивки не являлся (неизменяемый в mask ROM был) и на глаза исследователям не попадался. Единственным виденным мной исключением (да и то скорее «в обратную сторону») был процессор SCM-A11 у Motorola, у которого вообще весь GSM-стек работал на одном DSP-ядре (архитектуры StarCore - DSP, расширенный под целочисленные нужды. SCM - Single Core Modem), а целочисленное ядро (ARM1176) было полностью освобождено под простой с виду, но тяжёлый (из-за Linux под капотом) UI. И то, было это уже во времена заката GSM и расцвета 3G, а в описании SCM-A11 присутствовала фраза о том, что одноядерная производительность наконец достаточна для реализации всех трёх уровней GSM.