О шароваре и десктопном Линуксе

[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.чего-то. При таком подходе я буду продолжать делать шаровары для винды и мака, а линуксоеды пусть дальше довольствуются своими поделками.

Comments

Re: подсказка

[stepancheg.livejournal.com]

даст одноразовый оверхед на компиляцию

При старте программы или операционной системы всегда есть оверхед — на подгрузку файла с диска, инициализацию внутренних структур. Да, первичная компиляция даст чуть больший оверхед, но это не так страшно, т. к.

1) результаты компиляции можно кешировать
2) возможен JIT, который может дать большую производительность, чем в случае статически-скомпилированной программы

почему считается виртуализацией

Потому что при таком подходе нельзя написать драйвер файловой системы, который поломает что-нибудь в сетевой подсистеме.

Re: подсказка

[nealar.livejournal.com]

Потому что при таком подходе нельзя написать драйвер файловой системы, который поломает что-нибудь в сетевой подсистеме.
Поясните, почему. Желательно, на примере файловой системы NFS.

Re: подсказка

[stepancheg.livejournal.com]

В виртуальной машине есть объекты и есть методы. ВМ не предоставляет инструкций типа "обратиться к произвольному адресу памяти" или "сделать переход на произвольную инструкцию". Сетевая подсистема, условно говоря, представляет четыре метода: открыть соединение, закрыть соединение, записать в сеть, прочитать из сети. Всё, что может сделать драйвер файловой системы — вызвывать эти методы. Поэтому он не может ничего поломать.

Когда ВМ компилирует программы из своего специального байткода в машинный код, все обращения к методам превращаются в переходы по определённым адресам. Это будут не произвольные адреса, а только те, которые указывают на безопасные, разрешённые методы, причём она же гарантирует правильную семантику вызова — на стек будет класться ровно то, что ожидает реализация метода. Обращение к полям объектов будет скомпилировано в обращение к конкретным адресам, которые окажуется данными полей объектов. Есть некоторая проблема с удалением объектов, но эта проблема решается, и garbage collector — лишь одно из решений.

Re: подсказка

[nealar.livejournal.com]

И в чём проблема статически откомпилировать код так, чтоб в нём были обращения только к определённым объектам и определённым методам? Без произвольных адресов. Тоже правильную семантику будет гарантировать компилятор.

Re: подсказка

[stepancheg.livejournal.com]

И в чём проблема статически откомпилировать код так, чтоб в нём были обращения только к определённым объектам и определённым методам?

void f(int);

Obj* obj = new Obj();
union {
  Obj* o;
  int i;
};

o = obj;
f(i);

Re: подсказка

[nealar.livejournal.com]

Это что? На таком языке теперь пишут ядро Линукса? А виртуальная машина для него существует?

Re: подсказка

[stepancheg.livejournal.com]

Это фрагмент кода на C++. Перепишите его на C, смысл от этого не изменится — это пример кода, который что-нибудь поломает.

Точнее, наоборот:

void f(Obj*);

int it = 4;
union {
  Obj* o;
  int i;
};

i = it;
f(o);

В метод f будет передан некорректный указатель.

Re: подсказка

[nealar.livejournal.com]

Код поломает, потому что в Вашем языке нестрогая типизация. А причёем тут виртуальная машина? И, кстати, для сей она существует?

Re: подсказка

[stepancheg.livejournal.com]

Вы меня спросили: "в чём проблема статически откомпилировать код так, чтоб в нём были обращения только к определённым объектам и определённым методам". Я привёл пример кода на C++, который ломает систему. Хорошо, вот более сложный пример:

f(Obj*);

Obj* objects[100];

f(objects[123]);

Происходит только обращение к правильным методам, но система ломается.

Виртуальная машина при том, что она такие конструкции запрещает в рантайме.

Re: подсказка

[nealar.livejournal.com]

1. Если это можно запретить в рантайме, то почему это нельзя запретить в статике?
2. Что-то мне подсказывает, что запретить класть инт в указатель или вылазить за границу массива в рантайме можно только путём хранения типа (что у нас там указатель, а не инт) или размера. Это не си, а другой язык программирования.

Re: подсказка

[stepancheg.livejournal.com]

Если это можно запретить в рантайме, то почему это нельзя запретить в статике

Это в статике запретить можно, но вот обращение уже удалённому объекту в статике запретить не получится.

Re: подсказка

[nealar.livejournal.com]

Можно и это закрыть, по той же цене, что и в рантайме (да, способа без оверхеда я не знаю). Но можно придумать какую-нибудь более хитрую атаку. А потом ещё более хитрую. Просто этот язык программирования предназначен для другого. Его не сделать безопасным (в этом смысле).

Re: подсказка

[stepancheg.livejournal.com]

Можно и это закрыть, по той же цене, что и в рантайме

Я про это недавно писал у себя в блоге — в значительном количестве случаев оверхед на проверку выхода за границу массива отсутствует.

Повторяю ещё раз: запретить обращение к удалённому объекту в статике невозможно.

Но можно придумать какую-нибудь более хитрую атаку.

Нельзя. Насколько я знаю, за последние несколько лет ни одной уязвимости Sun JVM (к примеру) не было — а это очень мощная и сложная виртуальная машина.

Re: подсказка

[nealar.livejournal.com]

Проверку обращений к удалённым объектам и выходы за границы можно, например, взвалить на MMU. Который и под линуксом работает и к времени выполнения свою долю прибавляет. Код создания объекта потяжелеет и переключение контекста будет медленней, чем в линуксе. А всё остальное не изменится. По сравнению с переключением между контекстами ВМ это всё равно копейки. И это самое примитивное тупое решение.
Если мы говорим о языках со сборкой мусора и без арифметики указателей, то там обращение к удалённым объектам просто невозможно, его и запрещать не надо.
Нельзя.
Это доказано кем-то или это только эмоции?

Re: подсказка

[stepancheg.livejournal.com]

Код создания объекта потяжелеет и переключение контекста будет медленней, чем в линуксе

Код создания какого объекта?

Переключения контекста вообще не будет, и это одна из фишек виртуальных машин.

Если мы говорим о языках со сборкой мусора и без арифметики указателей, то там обращение к удалённым объектам просто невозможно, его и запрещать не надо

Виртуальная машина не поддерживает арифметику указателей, это я и имел в виду. При этом код реально компилируется в машинный код с арифметикой указателей, и всем от этого хорошо.

Это доказано кем-то или это только эмоции?

Либо я не понял вопрос, либо это очевидно. В виртуальной машине есть набор инструкций, каждая из которых не позволяет выйти за рамки машины, поэтому нет такой атаки. В реальных ВМ, конечно, могут быть баги.

Re: подсказка

[nealar.livejournal.com]

Код создания какого объекта?
Того объекта, к которому невозможно будет обратиться, если он удалён.
Переключения контекста вообще не будет, и это одна из фишек виртуальных машин.
Вообще никогда? То есть, у нас получится однозадачная система?
Виртуальная машина не поддерживает арифметику указателей
Арифметика указателей - свойство не реализации, а языка. Не важно, компилируем мы C статически или создаём для него VM - арифметика указателей будет. Языки без арифметики указателей тоже бывают разные - рассчитанные на VM и статически компилируемые. Правда, у статически комилируемых в рантайме появляется обязательно сборщик мусора, а это уже как бы кусок виртуальной машины.
В виртуальной машине есть набор инструкций, каждая из которых не позволяет выйти за рамки машины
Вы не поняли вопрос. В рамках машины доступны все ресурсы процесса под данной ОС. То есть, можно много всего испортить, не выходя из рамок машины. Например, ява-задачам я на своём компе не ставлю каких-то ограниченных прав, не понижаю им scheduling priority по сравнению с обычными программами, не запускаю их под специальным бесправным юзером java-task и т.д. Они, вероятно, не могут делать атаки на ядро через переполнение стека и т.п. - от этого защищает их проверка типов (возможные баги в JVM исключаем напрочь - речь не о них). Защищает ли их типизация от открытия сокетов без закрытия, от поедания данным куском кода излишнего количества памяти (что, напоминаю, должно проверяться статически, перед началом выполнения задачи, динамически линукс умеет сишные задачи убивать, когда весь своп выжрут) и подобных неприятностей? А если мы размещает ВМ в ядре, то у неё возможностей ещё больше и проверять правильность запускаемого кода хотелось бы ещё строже. Либо тупо следить в рантайме - есть ли выход за границы массива, не схавала ли она памяти больше положенного и т.д.

Re: подсказка

[stepancheg.livejournal.com]

Нет, вру, баги в JVM, конечно, были. Но это совсем другое — вероятность поломки системы от бага в виртуальной машине на порядки меньше вероятности поломки системы от баге в модуле, выполняющемся в монолитном ядре.

Re: подсказка

[stepancheg.livejournal.com]

запретить класть инт в указатель или вылазить за границу массива в рантайме можно только путём хранения типа

В рантайме не обязательно хранить тип объекта, если весь код, работающий с этим типом знает, что он работает именно с этим типом.

Естественно, это не C. C не годится для компилирования в код для виртуальной машины (хотя это возможно).

Re: подсказка

[nealar.livejournal.com]

весь код, работающий с этим типом знает, что он работает именно с этим типом
Тогда оверхед на компиляцию внезапно возрастает. Придётся проверять, что код всё правильно знает про типы.
Естественно, это не C
Тогда что мы тут обсуждаем? Для не-С есть виртуальная машина, но нет статических компиляторов? :)
C не годится для компилирования в код для виртуальной машины
Я бы сказал "не годится для компилирования в код той виртуальной машины, о которой мы тут ведём речь".

Re: подсказка

[stepancheg.livejournal.com]

Тогда оверхед на компиляцию внезапно возрастает

Возрастёт по сравнению с чем? Мне кажется, компилировать код, который уже статически типизирован в байткоде виртуальной машины, сравнительно дёшево.

Тогда что мы тут обсуждаем?

Вы спрашивали про ядра, основанные на виртуальных машинах, я вам рассказываю.

Для не-С есть виртуальная машина, но нет статических компиляторов?

Я не понял, в чём вопрос. Если я правильно понимаю, что происходит в мире, managed environment без виртуальной машины (точнее, без рантайма) в принципе быть не может.

C не годится для компилирования в код для виртуальной машины
Я бы сказал "не годится для компилирования в код той виртуальной машины, о которой мы тут ведём речь".

Не годится для компилирования в код такой виртуальной машины, на которой можно запускать ядро операционной системы.

Суть копиляции C в код виртуальной машины — это эмуляция реальной машины на виртуальной, см., например, проект NestedVM. Т. е. это с трудом можно назвать компиляцией в код виртуальной машины.

Re: подсказка

[nealar.livejournal.com]

Возрастёт по сравнению с чем?
По сравнению с JIT-компиляцией кода, который не нужно проверять. В Вашей конструкции мы получаем на выполнение код, в котором надо провести вывод типов и убедиться, что некоторые важные инварианты соблюдаются. Не знаю, насколько трудна такая компиляция, но она явно тяжелей компиляции сишной.
Вы спрашивали про ядра, основанные на виртуальных машинах, я вам рассказываю.
И точно, спрашивал. Есть ли POSIX-совместимые (то есть, как бы, реальные) оси на таких ядрах или это техника будущего?
Не годится для компилирования в код такой виртуальной машины, на которой можно запускать ядро операционной системы.
Да, где-то так.
Не годится для компилирования в код такой виртуальной машины, на которой можно запускать ядро операционной системы.
LLVM-бэкенды к сишным компиляторам делают, значит, там всё не очень печально. Если бы сишный код (который представляет из себя высокоуровневый ассемблер для PDP-7) выполняли на виртуальной машине, а код виртуальной машины на реальной - то это было бы как-то совсем невесело. Наверно, где-то там что-то можно сэкономить.

Re: подсказка

[stepancheg.livejournal.com]

явно тяжелей компиляции сишной

По-моему проще. Компилятор C делает ровно те же проверки на типы.

int* a;
long* b;
a = b;

выдаёт ошибку.

По сравнению с JIT-компиляцией кода, который не нужно проверять

Компиляция вызова метода — это генерация инструкции перехода по определённому адресу, если есть статическая типизация. Проверка производится неявно — мы же вызываем метод класса, значит для генерации адреса перехода надо знать адрес метода именно этого класса. Всё, что нужно проверять — это соответствие типов при присвоении переменных, а это копейки.

А если статической типизации нет, то вызов метода — это вообще очень сложная конструкция, которая зависит от того, что представляет из себя объект виртуальной машины.

Re: подсказка

[nealar.livejournal.com]

Всё, что нужно проверять — это соответствие типов при присвоении переменных, а это копейки.
То есть, Вы предполагаете, что для кода, выполняющегося в ядре, не нужно проверять какие-нибудь дополнительные инварианты, кроме тех, которые проверяет сишный компилятор. Удивительно. Вы верите в магию? Взяли систему типов, не сложней сишной, засунули в виртуальную машину - и всё работает непосредственно с оборудованием со скоростью, сравнимой с сишным кодом, но изолированно и безопасно?

Re: подсказка

[stepancheg.livejournal.com]

Есть ли POSIX-совместимые (то есть, как бы, реальные) оси на таких ядрах или это техника будущего?

Есть JNode OS, есть Singularity, есть какие-то другие, есть тонны научных работ на эту тему. Существующие ОС — не POSIX и медленно работают. Да, это технология будущего. Бурного энтузиазма по поводу таких систем в сети я не вижу, так что в ближайшие 5 лет вряд ли это будет промышленное решение.

LLVM-бэкенды к сишным компиляторам делают, значит, там всё не очень печально

LLVM — это слишком низкоуровневая машина. Она не проверяет выход за границы массива (и вообще предоставляет арифметику указателей). Я имел в виду совсем не LLVM, когда описывал операционную систему будущего.

Re: подсказка

[stepancheg.livejournal.com]

Кроме того, C++ не гарантрирует, что нет будет обращения к удалённому объекту, а виртуальная машина гарантирует.