Большое спасибо за статью! Давно хотел посмотреть, что же там внутри USB с программной точки зрения, да всё руки не доходили. Теперь-то точно разберусь, даже в закладки добавил А если серьёзно, возможность "прорешать" простые примеры и посмотреть на всё это вживую выглядит очень полезной для первоначального ознакомления. При наличии одноплатника с правильным OTG, думаю, даже ни один смартфон не пострадает.
С удивлением узнал, что современный нерутованный Android предоставляет API для записи сырых данных на USB-флешку, которым умеет пользоваться, например, EtchDroid. Сейчас для теста взял пустую флешку, сделал абсолютно бессмысленный файл из мегабайта нулей и TESTTEST12345678 в самом начале, и успешно записал файл на флешку, подключенную через OTG. Ну, то есть как успешно... после завершения записи (то есть в моём случае примерно мгновенно) экран погас и смартфон перезагрузился, но тут уже претензии, скорее, к заводской прошивке нерутованного Samsung-A22 :) Так или иначе, а на компьютере я вижу тестовую строку по смещению 0x0, потом много нулей, а по смещению 0x100000, по-видимому, начинается то, что раньше было на этой флешке.
Возможно, с новым редактором статей всё стало вообще по-другому, но раньше привычным для меня режимом работы был примерно такой: статья пишется в Markdown на локальном компьютере (и на всякий случай кладётся в приватный git-репозиторий), после чего целиком копируется в редактор, переключенный в режим Markdown, настраиваются заголовок, хабы и теги, статья публикуется. Если позже я понимаю, что нужно что-то поправить или дополнить — исправляю локальную версию, перезаливаю в редактор, применяю изменения. Если знаю, что делал быстрые правки прямо в редакторе, то сначала копирую статью в обратном направлении. То есть я подразумевал, что за "когерентность кэшей" отвечаю только я.
Правильно ли я понимаю, что на самом деле после публикации статьи модераторы могут исправить некритичные недочёты, и если недочёты были ну совсем некритичные, то автора не беспокоят почём зря? Если так, то было бы полезно, чтобы в подобных случаях хотя бы отображался какой-нибудь флажок. Иначе получается, что я могу абсолютно без злого умысла откатить исправления модераторов просто потому, что я о них не подозревал.
UPD: В одном из предыдущих анонсов видел упоминание подобного режима модерации, а сейчас перечитал концовку этого поста, и понял, что там нигде и не говорится о редактировании статей произвольных авторов. Может, показалось... :)
"Любой символ, не являющийся буквой"? Согласен, по-хорошему, в моём примере первым делом нужно было бы уточнить, а как конкретно определяется "граница" (плюс в логах из примера обычно латиница, а тут ещё и о локали стоит задуматься). Но у вас, вроде бы, надо к случаю "любой символ кроме..." добавить "отсутствие символа" (т.е. начало строки). Как говорится, "у меня была проблема, и я решил использовать регулярные выражения..."
Когда ищешь что-то в логе, то не всегда помогает — приходится использовать регулярки, что-нибудь вроде \bдатчик. Сначала подумал, что для "человеческого" текста, может, и вариант с пробелом сойдёт, но потом понял, что нет: в вашем же примере перед словом "датчик" не пробел, а открывающая кавычка. Ну и с заглавными/строчными буквами тоже придётся как-то разбираться.
В том, что привычная техника полна загадок, я убедился, наблюдая, как мой десктоп на базе чипсета Intel Z370, зависнув, демонстративно игнорировал нажатие на Reset. И ведь, что интересно, после попробовал — Reset подключен, работает — пока система намертво не зависнет.
Полез на сайт Intel, и к моему удивлению, обнаружил там в открытом доступе весьма подробную документацию на чипсет. Про процедуру сброса говорилось что-то вроде "если по прошествии времени T после подачи сигнала reset процессор не перезапустился по-хорошему, то попробуем другой способ".
Похоже, что таймаут измерялся в секундах (а не в милли- / микросекундах, как мне показалось при беглом чтении), поскольку при последующих зависаниях я наблюдал, что секунд через десять после нажатия Reset, видимо, происходил полный сброс с характерным всхрюком вентилятора, как после сохранения новых параметров DRAM в UEFI Setup.
Про кнопочки, разумеется, согласен -- просто "улыбнуло" наличие такого параметра. На самом деле не удивлюсь, если команды DDC принимаются сразу со всех видеовходов, но тут уже от монитора зависит.
Ниже уже упомянули DDC, но вскользь. А я недавно был очень удивлён, когда полез гуглить, что же это за загадочный пункт "DDC/CI: Enable" в меню моего монитора. Оказывается, давно есть стандарт, чтобы управлять монитором с компьютера: поставил ddcutil из репозитория -- и можно, например, регулировать яркость по HDMI. Ну или видеовход на мониторе на VGA переключить (но это уже попахивает настройкой фаервола по ssh).
Мой комментарий был скорее шуткой. Если серьёзно, то не спорю, что возможность работать на меньшем количестве памяти лучше, чем её отсутствие. Другой вопрос, что если ресурсы уже имеются, то почему бы забесплатно не улучшить производительность ещё сильнее, творчески используя излишки. Хотя, вот драйвер интеловского видеочипа, i915, предлагает на некоторых системах использовать framebuffer compression для оптимизации энергопотребления. Уж не знаю, что там за системы, но для них использование излишков, видимо, не бесплатное.
Да и вообще, чем сильнее оптимизируем потреление ресурсов софтом, тем больше излишков останется "на мелкие расходы" ОС при одинаковом железе. :)
виндовз15 с удовольствием сожрет всю свободную память
Ну, не всегда это проблема. Насколько я понимаю, как раз Linux kernel ведёт себя подобно Винде из древнего анекдота: "сколько [оперативной] памяти находит, столько и занимает [для страничного кэша]". Видел даже сайт https://www.linuxatemyram.com/ , объясняющий новичкам, почему это не проблема, а особенность терминологии.
Боюсь, по грамотному использованию UNIX-сокетов и расстановке прав доступа из меня советчик так себе. Фраза "что такое условно защищённый компьютер" была скорее "... но сначала надо сформулировать модель угроз" -- просто в форм-факторе риторического вопроса :)
Я с такой задачей не сталкивался, но, думаю, неплохой отправной точкой для изучения могут быть способы коммуникации, реализованные в ssh-agent, X-сервере и других подобных программах, а в ещё большей мере -- обсуждения, почему сделано именно так, какие логические уязвимости всплывали в процессе развития этих проектов, и как они были исправлены (но тут ещё вопрос, что такое "условно защищённый компьютер").
Смотря что понимать под "смотрел" :) Само существование JSLinux меня и сподвигло сделать "такое же, но с JIT". В первой части как раз был небольшой обзор существовавших ранее эмуляторов и известных мне попыток портировать QEMU.
Детально в JSLinux я не углублялся. Насколько я помню, там была задумка, наоборот, используя все возможности JS реализовать эффективный эмулятор практически с нуля. Я же не хотел разбираться со всеми деталями x86 (не говоря уже о десятке других архитектур), а сосредоточиться на JIT.
А еще можно не бояться стирать ключ в машинке — разработчики говорят, что он это выдерживает без проблем.
Мельком увидел фразу в контексте аппаратных ключей. Воображение начало рисовать управляющую плату, которая делает некий "правильный" erase криптографического ключа — а то здесь же даже кнопку не разместишь.
Перечитал. Понял, что и "стирать" здесь — wash, а не erase, и ключ — это физическая плата, а не данные в ней, и машинка несколько другая.
Большое спасибо за статью! Давно хотел посмотреть, что же там внутри USB с программной точки зрения, да всё руки не доходили.
Теперь-то точно разберусь, даже в закладки добавилА если серьёзно, возможность "прорешать" простые примеры и посмотреть на всё это вживую выглядит очень полезной для первоначального ознакомления. При наличии одноплатника с правильным OTG, думаю, даже ни один смартфон не пострадает.С удивлением узнал, что современный нерутованный Android предоставляет API для записи сырых данных на USB-флешку, которым умеет пользоваться, например, EtchDroid. Сейчас для теста взял пустую флешку, сделал абсолютно бессмысленный файл из мегабайта нулей и
TESTTEST12345678в самом начале, и успешно записал файл на флешку, подключенную через OTG. Ну, то есть как успешно... после завершения записи (то есть в моём случае примерно мгновенно) экран погас и смартфон перезагрузился, но тут уже претензии, скорее, к заводской прошивке нерутованного Samsung-A22 :) Так или иначе, а на компьютере я вижу тестовую строку по смещению0x0, потом много нулей, а по смещению0x100000, по-видимому, начинается то, что раньше было на этой флешке.Весьма изысканный способ доказать превосходство человеческого разума над ChatGPT :)
Шикарная статья!
Возможно, с новым редактором статей всё стало вообще по-другому, но раньше привычным для меня режимом работы был примерно такой: статья пишется в Markdown на локальном компьютере (и на всякий случай кладётся в приватный git-репозиторий), после чего целиком копируется в редактор, переключенный в режим Markdown, настраиваются заголовок, хабы и теги, статья публикуется. Если позже я понимаю, что нужно что-то поправить или дополнить — исправляю локальную версию, перезаливаю в редактор, применяю изменения. Если знаю, что делал быстрые правки прямо в редакторе, то сначала копирую статью в обратном направлении. То есть я подразумевал, что за "когерентность кэшей" отвечаю только я.
Правильно ли я понимаю, что на самом деле после публикации статьи модераторы могут исправить некритичные недочёты, и если недочёты были ну совсем некритичные, то автора не беспокоят почём зря? Если так, то было бы полезно, чтобы в подобных случаях хотя бы отображался какой-нибудь флажок. Иначе получается, что я могу абсолютно без злого умысла откатить исправления модераторов просто потому, что я о них не подозревал.
UPD: В одном из предыдущих анонсов видел упоминание подобного режима модерации, а сейчас перечитал концовку этого поста, и понял, что там нигде и не говорится о редактировании статей произвольных авторов. Может, показалось... :)
"Любой символ, не являющийся буквой"? Согласен, по-хорошему, в моём примере первым делом нужно было бы уточнить, а как конкретно определяется "граница" (плюс в логах из примера обычно латиница, а тут ещё и о локали стоит задуматься). Но у вас, вроде бы, надо к случаю "любой символ кроме..." добавить "отсутствие символа" (т.е. начало строки). Как говорится, "у меня была проблема, и я решил использовать регулярные выражения..."
Думаю, в качестве иллюстрации проблемы будет уместно вспомнить старую шуточную статью "Стоит ли до верится спел чек еру? Про стой пять ни чинный пост до бра".
Когда ищешь что-то в логе, то не всегда помогает — приходится использовать регулярки, что-нибудь вроде
\bдатчик. Сначала подумал, что для "человеческого" текста, может, и вариант с пробелом сойдёт, но потом понял, что нет: в вашем же примере перед словом "датчик" не пробел, аоткрывающаякавычка. Ну и с заглавными/строчными буквами тоже придётся как-то разбираться.В том, что привычная техника полна загадок, я убедился, наблюдая, как мой десктоп на базе чипсета Intel Z370, зависнув,
демонстративноигнорировал нажатие на Reset. И ведь, что интересно, после попробовал — Reset подключен, работает — пока система намертво не зависнет.Полез на сайт Intel, и к моему удивлению, обнаружил там в открытом доступе весьма подробную документацию на чипсет. Про процедуру сброса говорилось что-то вроде "если по прошествии времени T после подачи сигнала reset процессор не перезапустился по-хорошему, то попробуем другой способ".
Похоже, что таймаут измерялся в секундах (а не в милли- / микросекундах, как мне показалось при беглом чтении), поскольку при последующих зависаниях я наблюдал, что секунд через десять после нажатия Reset, видимо, происходил полный сброс с характерным всхрюком вентилятора, как после сохранения новых параметров DRAM в UEFI Setup.
Кстати да, чтение SPD оперативки, вроде, довольно типичный пример применения видимых в системе I2C-интерфейсов.
Про кнопочки, разумеется, согласен -- просто "улыбнуло" наличие такого параметра. На самом деле не удивлюсь, если команды DDC принимаются сразу со всех видеовходов, но тут уже от монитора зависит.
Ниже уже упомянули DDC, но вскользь. А я недавно был очень удивлён, когда полез гуглить, что же это за загадочный пункт "DDC/CI: Enable" в меню моего монитора. Оказывается, давно есть стандарт, чтобы управлять монитором с компьютера: поставил
ddcutilиз репозитория -- и можно, например, регулировать яркость по HDMI. Ну или видеовход на мониторе на VGA переключить (но это уже попахивает настройкой фаервола по ssh).Мой комментарий был скорее шуткой. Если серьёзно, то не спорю, что возможность работать на меньшем количестве памяти лучше, чем её отсутствие. Другой вопрос, что если ресурсы уже имеются, то почему бы забесплатно не улучшить производительность ещё сильнее, творчески используя излишки. Хотя, вот драйвер интеловского видеочипа, i915, предлагает на некоторых системах использовать framebuffer compression для оптимизации энергопотребления. Уж не знаю, что там за системы, но для них использование излишков, видимо, не бесплатное.
Да и вообще, чем сильнее оптимизируем потреление ресурсов софтом, тем больше излишков останется "на мелкие расходы" ОС при одинаковом железе. :)
Ну, не всегда это проблема. Насколько я понимаю, как раз Linux kernel ведёт себя подобно Винде из древнего анекдота: "сколько [оперативной] памяти находит, столько и занимает [для страничного кэша]". Видел даже сайт https://www.linuxatemyram.com/ , объясняющий новичкам, почему это не проблема, а особенность терминологии.
Похоже, они использовали положительный и отрицательный ноль, когда это ещё не было
мэйнстримомIEEE754.Тоже представилось: сначала 50 Гц, потом пару кВт мощности, потом трёхфазное питание. :)
Боюсь, по грамотному использованию UNIX-сокетов и расстановке прав доступа из меня советчик так себе. Фраза "что такое условно защищённый компьютер" была скорее "... но сначала надо сформулировать модель угроз" -- просто в форм-факторе риторического вопроса :)
Я с такой задачей не сталкивался, но, думаю, неплохой отправной точкой для изучения могут быть способы коммуникации, реализованные в ssh-agent, X-сервере и других подобных программах, а в ещё большей мере -- обсуждения, почему сделано именно так, какие логические уязвимости всплывали в процессе развития этих проектов, и как они были исправлены (но тут ещё вопрос, что такое "условно защищённый компьютер").
Было несколько неожиданно увидеть привычную формулу
(addr+0xfff) & ~0xfffили(A+N-1)/N*N, сводящуюся квычисленную на управляющих символах ASCII.
Смотря что понимать под "смотрел" :) Само существование JSLinux меня и сподвигло сделать "такое же, но с JIT". В первой части как раз был небольшой обзор существовавших ранее эмуляторов и известных мне попыток портировать QEMU.
Детально в JSLinux я не углублялся. Насколько я помню, там была задумка, наоборот, используя все возможности JS реализовать эффективный эмулятор практически с нуля. Я же не хотел разбираться со всеми деталями x86 (не говоря уже о десятке других архитектур), а сосредоточиться на JIT.
Мельком увидел фразу в контексте аппаратных ключей. Воображение начало рисовать управляющую плату, которая делает некий "правильный" erase криптографического ключа — а то здесь же даже кнопку не разместишь.
Перечитал. Понял, что и "стирать" здесь — wash, а не erase, и ключ — это физическая плата, а не данные в ней, и машинка несколько другая.