Во-первых, IOMMU есть не на всякой платформе. Во-вторых, работает оно с переменным успехом.
И главное, когда доходит до сравнения микроядерной архитектуры с монолитом, микроядерщики очень любят говорить, что их подход принципиально надежнее потому, что поверхность атаки меньше.
Но при этом не говорится о такой обширной и малоисследованной поверхности атаки, как аппаратура.
Если гарантии защиты, предоставляемые процессором, более-менее широко известны и хорошо исследованы (что не мешает находить в них уязвимости с завидной регулярностью), то чипсеты и периферийные контроллеры, никто их толком не исследовал.
При этом процессор, его интерфейсы открыты всем разработчикам и он всё время под пристальным вниманием. А драйвера пишутся по принципу, "работает и ладно". При обнаружении ошибок в аппаратуре, если есть возможность обойти её в драйвере, то и хорошо. Но целью всегда является соблюдение функциональных требований. Если сетевая карта посылает и принимает пакеты, ну, всё ОК. Никто никогда не зафайлит ошибку, позволяющую добраться через сетевую карту к чужой памяти, потому что штатный драйвер этого делать не будет, а возможность работать с недоверенным драйвером никогда не исследовалась (и чтобы всерьёз этим заниматься, драйвер надо с самого начала проектировать под эту задачу, а не помещать опенсорсный в песочницу).
Не надо думать, что в аппаратуре нет ошибок. Их там есть, и очень много. И поскольку исправление ошибок в аппаратуре очень дорого, в целом, если ошибку можно обойти в драйвере, это считается вполне приемлимым решением. Но работает оно только при условии, что драйверу можно доверять.
Современная аппаратура очень сложная, и нередко там не только микросхемки, но и сложная прошивка. У некоторых видов оборудования сложность вполне сравнима с системным ПО хоста. И какие там есть гарантии изоляции, никто не знает (скорее всего, никаких).
В общем, если честно, я не вижу возможности обеспечить надежность ОС, помещая драйвера в изоляцию - именно потому, что это изолирует только код самих драйверов, но не обеспечивает никакой изоляции со стороны периферийной аппаратуры, которая находится полностью под контролем драйверам и которой можно доверять только при условии, что мы доверяем драйверу.
Что до возможности восстановить работоспособность системы после падения/зависания драйвера путём его перезапуска, тут я бы тоже поспорил.
Если драйвер нас покидает в самый неожиданный момент времени, он оставляет подконтрольную ему железку в неконсистентном состоянии. Теоретически, у многих видов оборудования есть интерфейсы, позволяющие железку обресетить и перевести в изначальное состояние. Практически, разные железки реагируют на эти воздействия по-разному.
У меня больше опыта с принтерами-сканерами, и опыт показывает, что одно устройсво среагирует на reset, как положено, обресетится. А другое или зависнет, или перейдет вообще в какое-то полурабочее загадочное состояние.
Я подозреваю, что с другими классами оборудования картина примерно та же.
Поэтому нельзя рассчитывать, что мы обресетим устройство каким-то универсальным способом, перезапустим драйвер и всё будет хорошо. Это можно делать, только если известно (путём испытаний), что с данной конкретной моделью это работает. Да еще и версию прошивки невредно было бы учесть. В общем случае, это приведет скорее к зависанию аппаратуры или нештатному её функционированию, чем к решению каких-то проблем.
Так что с теоретической точки зрения контейнеризация драйверов устройств звучит заманчиво, но с практической точки зрения есть много нюансов.
Как вы собираетесь защищаться, если зловредный драйвер запрограммирует свою сетевую карту, чтобы она через прямой доступ к памяти сходила, куда не положено, и нахулиганила там?
Спасибо, но мне нужна тьюринговская полнота. Ну и сам язык, хотелось бы, чтобы он был знаком широким народным массам (ваш правда, вроде на Си похож...)
Во-первых, мне не очень нравится, что оно привязывается к конкретной версии Питона. Во-вторых, я не очень понимаю, как оно может устойчиво работать: гороутинка может в любой момент сбежать на другую OS thread, Питону это не понравится. В третьих, мне всё же хотелось бы иметь возможность работать с несколькими экземплярами интерпретатора. Ну и наконец, разговаривать самому с собой через protobuf внутри одного процесса как-то очень тяжеловесно, что ли...
Просмотрев статью, я не смог ответить на вопрос, для чего, вообще, иметь внутри хорошей, красивой программы на go, или на си++, такой якорь на шее, как какой-нибудь скриптовый язык?
Чтобы предоставить пользователю domain-specific language, который не надо отдельно учить.
Для меня Go был бы идеальным выбором. Я люблю этот язык. И есть интерпретатор, кстати.
Если выбирать под мой личный вкус из перечисленных, я бы предпочёл JS. Он хоть на Си похож. И опять же, есть интерпретатор, написанный на Go, и в отличии от Питона, никто не будет ждать от него полной совместимости (непонятно с чем, потому что реализаций JS в обороте много, и все разные).
Но что-то мне подсказывает, что встроенный Питон найдёт большее понимание среди широких народных масс. Хоть я и правда его не люблю.
Git хранит файлы в какой-то своей внутренней структуре, и ничего, все привыкли и не боятся
Git - это всего лишь хранилище текстовых файлов с аннотированной историей. Он не навязывает никому свой богатый внутренний мир. Из git-а можно совершенно спокойно перенести проейкт в какую-нибудь другую систему контроля версий и даже историю не потерять.
Но диффы будут кривыми.
Во-во.
А по моему опыту (C#, Typescript) почти все импользуют IDE в 99% случаев.
Итак, давайте представим, что мы разрабатываем систему для разработчиков, где они могут писать код, читать его и обмениваться изменениями. Должны ли мы использовать текстовые файлы в качестве основного источника истины? Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Нифига не очевидно. Пока мы работаем с текстовыми файлами, у нас полная свобода в выборе инструментов. Кому-то нравится vim, а кому-то вендовый блокнот. Кто-то использует для поиска хитрую цепочку из find, grep и xargs, а кому-то нравится кнопка F7 в Far-е. Кто-то использует ctags, а кто-то - сложный IDE с анализом кода и навигацией. И каждый волен выбирать инструменты на свой вкус, текстовый формат в этом плане очень гибок и ничего не навязывает.
Как только на месте текстовых файлов окажется какая-то хитроумная база данных, все окажутся привязаны к её инструментам. А если производитель решит закрыть этот проект, то и все данные, представленные в этом формате, превратятся в тыкву.
Пассажир (уровень 7) говорит: «Хочу зайти на главную страницу сайта» (HTTP-запрос).
Уровень представления (6) сжимает текст главной страницы и шифрует его.
Сеансовый уровень (5) открывает «сеанс» связи с сервером.
Транспортный уровень (4) разбивает текст на пакеты и нумерует их (TCP).
Ну ерунда ведь. В HTTP решение о сжатии и шифровании можно принять только после того, как клиент и сервер поговорят между собой. И это, скорее, сеансовый уровень.
Я уж не говорю о том, что «Хочу зайти на главную страницу сайта» и сама главная страница существуют по разные стороны сети, так что перечислять действия над ними единым списком несколько-странно. Пока вся эта цепочка не прокрутится, сервер даже и не знает, что кто-то там захотел какую-то страницу.
Вот в этом - вся ваша OSI. Она полезна, чтобы отличать коммутатор от маршрутизатора (уровни "2" и "3"), но на этом ее полезность кончается. Те сети, которые выжили (т.е., TCP/IP), в модель OSI не очень укладываются.
Дорого. Надо или каждый раз utf-8 парсить, или хранить в 32-битном UNICODE и придумать, что делать с графемами, которые отображаются как один символ, но состоят из нескольких.
При этом это еще и редко надо. Типичные задачи: понять, сколько места надо зарезервировать для строки, сконкатенировать несколько строк, найти в строке символ '/' - для них для всех простой Сишный strlen - то, что надо. А для отображения на экране нужен не умный strlen, а функция, которая вычислит экранный размер с учётом особенностей фонтов.
когда-то в доисторические времена, когда динозавры свободно бродили по улицам а код писался руками без ИИ-помощников и даже без подглядывания в гугл, это казалось совершенно очевидным...
Принтеры недешевые, но производитель зарабатывает на принтерах, а не на расходниках. Поэтому родные расходники стоят вполне разумных денег, в пересчете на напечатанную страницу. Особенно для старших, самых скоростных моделей - там картридж с тонером раза в два больше, чем у более младших моделей, и при этом не сильно дороже.
И сами по себе аппараты, механически, весьма надежны. Это видно даже и по весу, черно-белый вариант под лист A4 весит 25 кг (средний принтер такого типа весит килограмм 15). Видно, что он выфрезерован из цельного куска чугуна :)
Я что-то не понимаю. Если нативному яндексмому или фейсбуковскому приложению хочется пообщаться с ихними же скриптами на веб-страничках, это удобно, конечно, делать через http://localhost:NNNN/, но вроде принципиально ничего не добавляет. С таким же успехом они могли бы общаться через свои сервера...
На ноутах и прочем bleeding edge железе было хуже, но терпимо. Рекомендовалось при покупке железа задумываться заранее на предмет совместимости с линухом.
Эта машинка прожила под линухом долго и счастливо всю свою нотбучную жизнь, состарилась и была готова уйти на пенсию в качестве детской машинки для детей, но ее неудачно уронила с подоконника на пол собака, запутавшись в проводе, существенно повредив матрицу. До этого момента в машинке работало всё.
Ну т.е., надо где-то что-то искать в довольно развесистом гуглохромовском меню. Да еще и на втором уровне вложенности. Нормальный человек туда не полезет, конечно.
ИМХО, правильно бы было, чтобы бровсер сам проявлял инициативу и спрашивал (например, на первом запуске) пользователя об его языковых предпочтениях.
Примерно так, как гуглёвый поисковик пристает (да еще и весьма настойчиво) с вопросом, не надо ли предпочитать ответы на определенном языке и не надо ли организовать трансляцию найденных текстов.
Во-первых, IOMMU есть не на всякой платформе. Во-вторых, работает оно с переменным успехом.
И главное, когда доходит до сравнения микроядерной архитектуры с монолитом, микроядерщики очень любят говорить, что их подход принципиально надежнее потому, что поверхность атаки меньше.
Но при этом не говорится о такой обширной и малоисследованной поверхности атаки, как аппаратура.
Если гарантии защиты, предоставляемые процессором, более-менее широко известны и хорошо исследованы (что не мешает находить в них уязвимости с завидной регулярностью), то чипсеты и периферийные контроллеры, никто их толком не исследовал.
При этом процессор, его интерфейсы открыты всем разработчикам и он всё время под пристальным вниманием. А драйвера пишутся по принципу, "работает и ладно". При обнаружении ошибок в аппаратуре, если есть возможность обойти её в драйвере, то и хорошо. Но целью всегда является соблюдение функциональных требований. Если сетевая карта посылает и принимает пакеты, ну, всё ОК. Никто никогда не зафайлит ошибку, позволяющую добраться через сетевую карту к чужой памяти, потому что штатный драйвер этого делать не будет, а возможность работать с недоверенным драйвером никогда не исследовалась (и чтобы всерьёз этим заниматься, драйвер надо с самого начала проектировать под эту задачу, а не помещать опенсорсный в песочницу).
Не надо думать, что в аппаратуре нет ошибок. Их там есть, и очень много. И поскольку исправление ошибок в аппаратуре очень дорого, в целом, если ошибку можно обойти в драйвере, это считается вполне приемлимым решением. Но работает оно только при условии, что драйверу можно доверять.
Современная аппаратура очень сложная, и нередко там не только микросхемки, но и сложная прошивка. У некоторых видов оборудования сложность вполне сравнима с системным ПО хоста. И какие там есть гарантии изоляции, никто не знает (скорее всего, никаких).
В общем, если честно, я не вижу возможности обеспечить надежность ОС, помещая драйвера в изоляцию - именно потому, что это изолирует только код самих драйверов, но не обеспечивает никакой изоляции со стороны периферийной аппаратуры, которая находится полностью под контролем драйверам и которой можно доверять только при условии, что мы доверяем драйверу.
Что до возможности восстановить работоспособность системы после падения/зависания драйвера путём его перезапуска, тут я бы тоже поспорил.
Если драйвер нас покидает в самый неожиданный момент времени, он оставляет подконтрольную ему железку в неконсистентном состоянии. Теоретически, у многих видов оборудования есть интерфейсы, позволяющие железку обресетить и перевести в изначальное состояние. Практически, разные железки реагируют на эти воздействия по-разному.
У меня больше опыта с принтерами-сканерами, и опыт показывает, что одно устройсво среагирует на reset, как положено, обресетится. А другое или зависнет, или перейдет вообще в какое-то полурабочее загадочное состояние.
Я подозреваю, что с другими классами оборудования картина примерно та же.
Поэтому нельзя рассчитывать, что мы обресетим устройство каким-то универсальным способом, перезапустим драйвер и всё будет хорошо. Это можно делать, только если известно (путём испытаний), что с данной конкретной моделью это работает. Да еще и версию прошивки невредно было бы учесть. В общем случае, это приведет скорее к зависанию аппаратуры или нештатному её функционированию, чем к решению каких-то проблем.
Так что с теоретической точки зрения контейнеризация драйверов устройств звучит заманчиво, но с практической точки зрения есть много нюансов.
Как вы собираетесь защищаться, если зловредный драйвер запрограммирует свою сетевую карту, чтобы она через прямой доступ к памяти сходила, куда не положено, и нахулиганила там?
Правилов песочницы драйвер при этом не нарушит...
Спасибо, но мне нужна тьюринговская полнота. Ну и сам язык, хотелось бы, чтобы он был знаком широким народным массам (ваш правда, вроде на Си похож...)
Спасибо за рекомендацию, но...
Во-первых, мне не очень нравится, что оно привязывается к конкретной версии Питона. Во-вторых, я не очень понимаю, как оно может устойчиво работать: гороутинка может в любой момент сбежать на другую OS thread, Питону это не понравится. В третьих, мне всё же хотелось бы иметь возможность работать с несколькими экземплярами интерпретатора. Ну и наконец, разговаривать самому с собой через protobuf внутри одного процесса как-то очень тяжеловесно, что ли...
Чтобы предоставить пользователю domain-specific language, который не надо отдельно учить.
Для меня Go был бы идеальным выбором. Я люблю этот язык. И есть интерпретатор, кстати.
Если выбирать под мой личный вкус из перечисленных, я бы предпочёл JS. Он хоть на Си похож. И опять же, есть интерпретатор, написанный на Go, и в отличии от Питона, никто не будет ждать от него полной совместимости (непонятно с чем, потому что реализаций JS в обороте много, и все разные).
Но что-то мне подсказывает, что встроенный Питон найдёт большее понимание среди широких народных масс. Хоть я и правда его не люблю.
Что до скорости, она в для меня не критична.
Есть еще Netbpm. Его прям даже не только X11 понимают...
https://en.wikipedia.org/wiki/Netpbm
Git - это всего лишь хранилище текстовых файлов с аннотированной историей. Он не навязывает никому свой богатый внутренний мир. Из git-а можно совершенно спокойно перенести проейкт в какую-нибудь другую систему контроля версий и даже историю не потерять.
Во-во.
А по моему - нет.
Нифига не очевидно. Пока мы работаем с текстовыми файлами, у нас полная свобода в выборе инструментов. Кому-то нравится vim, а кому-то вендовый блокнот. Кто-то использует для поиска хитрую цепочку из find, grep и xargs, а кому-то нравится кнопка F7 в Far-е. Кто-то использует ctags, а кто-то - сложный IDE с анализом кода и навигацией. И каждый волен выбирать инструменты на свой вкус, текстовый формат в этом плане очень гибок и ничего не навязывает.
Как только на месте текстовых файлов окажется какая-то хитроумная база данных, все окажутся привязаны к её инструментам. А если производитель решит закрыть этот проект, то и все данные, представленные в этом формате, превратятся в тыкву.
Ну ерунда ведь. В HTTP решение о сжатии и шифровании можно принять только после того, как клиент и сервер поговорят между собой. И это, скорее, сеансовый уровень.
Я уж не говорю о том, что «Хочу зайти на главную страницу сайта» и сама главная страница существуют по разные стороны сети, так что перечислять действия над ними единым списком несколько-странно. Пока вся эта цепочка не прокрутится, сервер даже и не знает, что кто-то там захотел какую-то страницу.
Вот в этом - вся ваша OSI. Она полезна, чтобы отличать коммутатор от маршрутизатора (уровни "2" и "3"), но на этом ее полезность кончается. Те сети, которые выжили (т.е., TCP/IP), в модель OSI не очень укладываются.
Дорого. Надо или каждый раз utf-8 парсить, или хранить в 32-битном UNICODE и придумать, что делать с графемами, которые отображаются как один символ, но состоят из нескольких.
При этом это еще и редко надо. Типичные задачи: понять, сколько места надо зарезервировать для строки, сконкатенировать несколько строк, найти в строке символ '/' - для них для всех простой Сишный strlen - то, что надо. А для отображения на экране нужен не умный strlen, а функция, которая вычислит экранный размер с учётом особенностей фонтов.
strlen - наследие Си
когда-то в доисторические времена, когда динозавры свободно бродили по улицам а код писался руками без ИИ-помощников и даже без подглядывания в гугл, это казалось совершенно очевидным...
Тут, наверное, речь об том, что интервалов много. Нет, не много, а вот прям МНОГО.
И надо как-то быстренько определить, не пересекается ли следующий интервал с уже имеющимися, попадает ли точка в какой-то из интервалов и т.п.
Тут, конечно, можно поизобретать что-нибудь, типа обобщенного бинарного поиска и т.п.
Это такая реклама, да?
P.S. Я так и не дождался окончания загрузки сайта. Видимо, реклама удалась.
Я читал. Да еще и на английском языке. Весьма остроумная и увлекательная книжка.
Я бы еще упомянул Kyocera, серию ECOSYS.
Принтеры недешевые, но производитель зарабатывает на принтерах, а не на расходниках. Поэтому родные расходники стоят вполне разумных денег, в пересчете на напечатанную страницу. Особенно для старших, самых скоростных моделей - там картридж с тонером раза в два больше, чем у более младших моделей, и при этом не сильно дороже.
И сами по себе аппараты, механически, весьма надежны. Это видно даже и по весу, черно-белый вариант под лист A4 весит 25 кг (средний принтер такого типа весит килограмм 15). Видно, что он выфрезерован из цельного куска чугуна :)
Я что-то не понимаю. Если нативному яндексмому или фейсбуковскому приложению хочется пообщаться с ихними же скриптами на веб-страничках, это удобно, конечно, делать через http://localhost:NNNN/, но вроде принципиально ничего не добавляет. С таким же успехом они могли бы общаться через свои сервера...
На ноутах и прочем bleeding edge железе было хуже, но терпимо. Рекомендовалось при покупке железа задумываться заранее на предмет совместимости с линухом.
Вот мой пост примерно этой давности про особенности инсталляции Федоры на современный, на тот момент, ноут: https://pzz.livejournal.com/12102.html
Эта машинка прожила под линухом долго и счастливо всю свою нотбучную жизнь, состарилась и была готова уйти на пенсию в качестве детской машинки для детей, но ее неудачно уронила с подоконника на пол собака, запутавшись в проводе, существенно повредив матрицу. До этого момента в машинке работало всё.
Что я делаю на хабре? Пытаюсь донести до Вас простую мысль: это слишком сложно для большинства пользователей. На которых и ориентируется Интернет.
Что там просто или сложно для меня, значения не имеет, я - не массовый рынок.
Ну т.е., надо где-то что-то искать в довольно развесистом гуглохромовском меню. Да еще и на втором уровне вложенности. Нормальный человек туда не полезет, конечно.
ИМХО, правильно бы было, чтобы бровсер сам проявлял инициативу и спрашивал (например, на первом запуске) пользователя об его языковых предпочтениях.
Примерно так, как гуглёвый поисковик пристает (да еще и весьма настойчиво) с вопросом, не надо ли предпочитать ответы на определенном языке и не надо ли организовать трансляцию найденных текстов.