О шароваре и десктопном Линуксе
Sep. 17th, 2009 01:46 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonВнезапно всплывший перевод интервью двухлетней давности с кернел-разработчиком, который пытался улучшить поведение декстопного Линукса, но не мог толком эти улучшения продемонстрировать, вызвал очередные дискуссии про перспективы Линукса на десктопе.
Да нет у него никаких перспектив.
Основная его проблема - мало нужного, качественного и удобного софта. И главная ее причина, на мой взгляд, - отсутствие бинарной совместимости. Когда есть куча плохо совместимых дистрибутивов, в них куча несовместимых версий, единственный более-менее работающий способ распространения софта - в исходниках, со сборкой на месте. Кому это подходит?
Сильно дорогой софт может себе позволить распространяться в исходниках или поставляться сразу с настроенной системой и даже аппаратурой. Но среднему юзеру на десктопе он не по карману, да и не нужен вобщем-то - нет у него ни терабайтных баз, ни тысячи процессоров, для которых такой софт делается.
Бесплатный софт может поставляться в исходниках, но он пишется либо гиками для себя, либо большими корпорациями для продажи чего-то другого (оборудования, например), поэтому никогда его авторы не будут делать его настолько простым и удобным в использовании, чтобы им могли пользоваться рядовые хоум-юзеры, не гики.
Типичные слова линуксоеда: "Если бы люди умели пользоваться vim, grep, sed, awk, то миллионы программных продуктов так никогда и не были бы созданы (C) кто-то умный". В том-то и беда. Именно так теряется 95% аудитории - основная масса юзеров не будет тратить по полгода на изучение этих ваших vim, grep, sed, awk, perl и bash. Им нужна программа с красивым окошком и кнопкой "сделать п%$дато", а не набирать в консоли "ps aux | grep dmz | awk '{ print $3, " ", $2 }' | sort | tail -n 5 | awk '{ print $2 }' | xargs kill -9". Нужен простой и удобный в использовании софт, решающий конкретные задачи рядовых и не очень пользователей. Такие программы будут только там, где будут коммерческие разработчики, которые смогут их продавать за доступные хоум-юзерам деньги. А для такого софта дистрибуция в исходниках никак не годится.
Вот есть, например, Маки. Там дистрибуция и установка программ в бинарной форме была отточена отлично, оттого куча удобного, приятного и радующего пользователей софта, за который те с радостью платят деньги. Есть винда, где я компилю в Win7 бинарник с минимумом зависимостей, и он прекрасно работает и в Висте, и в ХР, и даже в Win98. В нем я могу реализовать какую-то пусть не идеальную, но работающую защиту от взлома, и спокойно его продавать. А вот понадобилось мне недавно простейшую консольную прогу запустить на хостинге с этим вашим линупсом, так нет - нужного компилятора там не стоит и прав нет поставить, просто собранный бинарник не работает из-за другой версии GLIBC, а статически собранный - не работает, потому что ядро, дескать, слишком старое, хотя и там и там 2.6.чего-то. При таком подходе я буду продолжать делать шаровары для винды и мака, а линуксоеды пусть дальше довольствуются своими поделками.
Да нет у него никаких перспектив.
Основная его проблема - мало нужного, качественного и удобного софта. И главная ее причина, на мой взгляд, - отсутствие бинарной совместимости. Когда есть куча плохо совместимых дистрибутивов, в них куча несовместимых версий, единственный более-менее работающий способ распространения софта - в исходниках, со сборкой на месте. Кому это подходит?
Сильно дорогой софт может себе позволить распространяться в исходниках или поставляться сразу с настроенной системой и даже аппаратурой. Но среднему юзеру на десктопе он не по карману, да и не нужен вобщем-то - нет у него ни терабайтных баз, ни тысячи процессоров, для которых такой софт делается.
Бесплатный софт может поставляться в исходниках, но он пишется либо гиками для себя, либо большими корпорациями для продажи чего-то другого (оборудования, например), поэтому никогда его авторы не будут делать его настолько простым и удобным в использовании, чтобы им могли пользоваться рядовые хоум-юзеры, не гики.
Типичные слова линуксоеда: "Если бы люди умели пользоваться vim, grep, sed, awk, то миллионы программных продуктов так никогда и не были бы созданы (C) кто-то умный". В том-то и беда. Именно так теряется 95% аудитории - основная масса юзеров не будет тратить по полгода на изучение этих ваших vim, grep, sed, awk, perl и bash. Им нужна программа с красивым окошком и кнопкой "сделать п%$дато", а не набирать в консоли "ps aux | grep dmz | awk '{ print $3, " ", $2 }' | sort | tail -n 5 | awk '{ print $2 }' | xargs kill -9". Нужен простой и удобный в использовании софт, решающий конкретные задачи рядовых и не очень пользователей. Такие программы будут только там, где будут коммерческие разработчики, которые смогут их продавать за доступные хоум-юзерам деньги. А для такого софта дистрибуция в исходниках никак не годится.
Вот есть, например, Маки. Там дистрибуция и установка программ в бинарной форме была отточена отлично, оттого куча удобного, приятного и радующего пользователей софта, за который те с радостью платят деньги. Есть винда, где я компилю в Win7 бинарник с минимумом зависимостей, и он прекрасно работает и в Висте, и в ХР, и даже в Win98. В нем я могу реализовать какую-то пусть не идеальную, но работающую защиту от взлома, и спокойно его продавать. А вот понадобилось мне недавно простейшую консольную прогу запустить на хостинге с этим вашим линупсом, так нет - нужного компилятора там не стоит и прав нет поставить, просто собранный бинарник не работает из-за другой версии GLIBC, а статически собранный - не работает, потому что ядро, дескать, слишком старое, хотя и там и там 2.6.чего-то. При таком подходе я буду продолжать делать шаровары для винды и мака, а линуксоеды пусть дальше довольствуются своими поделками.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: подсказка
Date: 2009-09-20 05:53 pm (UTC)Re: подсказка
Date: 2009-09-20 06:01 pm (UTC)Я про это недавно писал у себя в блоге — в значительном количестве случаев оверхед на проверку выхода за границу массива отсутствует.
Повторяю ещё раз: запретить обращение к удалённому объекту в статике невозможно.
Но можно придумать какую-нибудь более хитрую атаку.
Нельзя. Насколько я знаю, за последние несколько лет ни одной уязвимости Sun JVM (к примеру) не было — а это очень мощная и сложная виртуальная машина.
Re: подсказка
Date: 2009-09-20 07:30 pm (UTC)Если мы говорим о языках со сборкой мусора и без арифметики указателей, то там обращение к удалённым объектам просто невозможно, его и запрещать не надо.
Нельзя.
Это доказано кем-то или это только эмоции?
Re: подсказка
Date: 2009-09-20 07:43 pm (UTC)Код создания какого объекта?
Переключения контекста вообще не будет, и это одна из фишек виртуальных машин.
Если мы говорим о языках со сборкой мусора и без арифметики указателей, то там обращение к удалённым объектам просто невозможно, его и запрещать не надо
Виртуальная машина не поддерживает арифметику указателей, это я и имел в виду. При этом код реально компилируется в машинный код с арифметикой указателей, и всем от этого хорошо.
Это доказано кем-то или это только эмоции?
Либо я не понял вопрос, либо это очевидно. В виртуальной машине есть набор инструкций, каждая из которых не позволяет выйти за рамки машины, поэтому нет такой атаки. В реальных ВМ, конечно, могут быть баги.
Re: подсказка
Date: 2009-09-20 08:18 pm (UTC)Того объекта, к которому невозможно будет обратиться, если он удалён.
Переключения контекста вообще не будет, и это одна из фишек виртуальных машин.
Вообще никогда? То есть, у нас получится однозадачная система?
Виртуальная машина не поддерживает арифметику указателей
Арифметика указателей - свойство не реализации, а языка. Не важно, компилируем мы C статически или создаём для него VM - арифметика указателей будет. Языки без арифметики указателей тоже бывают разные - рассчитанные на VM и статически компилируемые. Правда, у статически комилируемых в рантайме появляется обязательно сборщик мусора, а это уже как бы кусок виртуальной машины.
В виртуальной машине есть набор инструкций, каждая из которых не позволяет выйти за рамки машины
Вы не поняли вопрос. В рамках машины доступны все ресурсы процесса под данной ОС. То есть, можно много всего испортить, не выходя из рамок машины. Например, ява-задачам я на своём компе не ставлю каких-то ограниченных прав, не понижаю им scheduling priority по сравнению с обычными программами, не запускаю их под специальным бесправным юзером java-task и т.д. Они, вероятно, не могут делать атаки на ядро через переполнение стека и т.п. - от этого защищает их проверка типов (возможные баги в JVM исключаем напрочь - речь не о них). Защищает ли их типизация от открытия сокетов без закрытия, от поедания данным куском кода излишнего количества памяти (что, напоминаю, должно проверяться статически, перед началом выполнения задачи, динамически линукс умеет сишные задачи убивать, когда весь своп выжрут) и подобных неприятностей? А если мы размещает ВМ в ядре, то у неё возможностей ещё больше и проверять правильность запускаемого кода хотелось бы ещё строже. Либо тупо следить в рантайме - есть ли выход за границы массива, не схавала ли она памяти больше положенного и т.д.
Re: подсказка
Date: 2009-09-20 08:30 pm (UTC)Того объекта, к которому невозможно будет обратиться, если он удалён.
Создание объекта через malloc и в хитрой виртуальной машине стоит примерно одинаково. Удалять объект дорого. Удалять можно через GC. Можно делать escape analysis.
Re: подсказка
Date: 2009-09-20 09:25 pm (UTC)А почему?
Re: подсказка
Date: 2009-09-20 08:33 pm (UTC)Вообще никогда? То есть, у нас получится однозадачная система?
Не будет переключеня контекста в смысле изменения адресного пространства. Переключение потоков, конечно, будет.
Re: подсказка
Date: 2009-09-20 09:24 pm (UTC)Re: подсказка
Date: 2009-09-20 09:33 pm (UTC)неясно
Date: 2009-09-20 10:23 pm (UTC)То есть, таких штук, как realloc в той виртуальной машине нет? Нельзя уже выделенный массив увеличить, не меняя его адреса? Или в ней просто нет понятия "адрес", а доступ ко всем объектам идёт по нечисловым ссылкам?
Re: неясно
Date: 2009-09-20 10:54 pm (UTC)Этого и с помощью realloc нельзя.
Re: подсказка
Date: 2009-09-20 08:42 pm (UTC)Виртуальной машине все ресурсы доступны, конкретному модулю — нет. Драйверу сетевой карты доступен интерфейс DMA. Драйверу файловой системы доступен только интерфейс блочных устройств, и никакого прямого доступа к оборудованию у него нет. У пользовательского процесса есть только API типа POSIX.
От поедания памяти защищает счётчик использованной памяти, привязанный к каждому модулю. Сокеты должны явно закрываться (либо неявно при завершении процесса/модуля), и тут нет отличия от обычных операционных систем.
Re: подсказка
Date: 2009-09-20 09:21 pm (UTC)Re: подсказка
Date: 2009-09-20 09:29 pm (UTC)Загрузчик модуля выдаст ошибку, если в коде модуля файловой системы будет присутствовать упоминание класса для работы с DMA.
Re: подсказка
Date: 2009-09-20 10:18 pm (UTC)Re: подсказка
Date: 2009-09-20 11:08 pm (UTC)(тут была небольшая неточность, я смешал в кучу файловые системы блочных устройств и файловые системы без устройств)
Но модуль NFS не сможет напрямую обратиться к сетевой карте, только через модуль сетевого стека, набор вызовов которого очень ограничен. Поэтому модуль NFS не сможет ничего поломать.
А почему?
Почему что? Почему загрузчик модуля выдаст ошибку? У него есть список правил, что можно модулю делать, а что нельзя.
Но на самом деле разговор ущёл немного в сторону. Описанные рассуждения про то, что разрешено делать, а что запрещено, важны, скорее, для пользовательских процессов.
Для модулей ядра важно то, что модуль, например файловой системы Ext3, после того, как он будет подгружен, никакими действиями злоумышленника, при наличии каких угодно багов в коде модуля не сможет напрямую обратиться к сетевой подсистеме (конечно, возможны, косвенные вызовы, типа, записать данные на диск, которые после этого прочитает какой-то процесс).
Re: подсказка
Date: 2009-09-21 03:00 am (UTC)Не продолжить ли вам это на своих страницах?
Re: подсказка
Date: 2009-09-21 05:51 am (UTC)Re: подсказка
Date: 2009-09-20 06:04 pm (UTC)