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

[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]

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

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

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

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

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

Я не понял, в чём вопрос. Если я правильно понимаю, что происходит в мире, 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]

для кода, выполняющегося в ядре, не нужно проверять какие-нибудь дополнительные инварианты, кроме тех, которые проверяет сишный компилятор.

Да, кроме нескольких моментов, о которых я писал выше — выход за границы массива, обращение к удалённому объекту, присвоение переменных разных типов, может быть что-то ещё. Так работает JVM или CLR. Нет разницы, происходит ли работа с оборудованием в ядре или работа с ядром в процессе.

Re: подсказка

[nealar.livejournal.com]

Странно это. Например, вот таким моментом: обычная JVM работает под шедулером ОС, и он гарантирует, что время, отданное задачам (ява-задачм и обычным тоже) уложится в какие-то рамки и не нарушит правильной работы оборудования. Например, прилетевшее от диска прерывание: переключит контекст с текущей задачи на ядро, запустит код драйвера, поработает с регистрами диска, создаст/освободит буфера в памяти, отметит код, который ждёт данных с диска как разрешённый к выполнению, вернёт управление шедулеру ОС, переключит контекст на следующую задачу(например, ну ту, которая выполнялась до того, как диск попросил внимания). JVM всем этим не занимается и ничего про это не знает. Шедулинг своих, внутриJVMных потоков она может выполнять исходя из своих соображений, например, делать так, чтоб время процессора делилось между потоками пропорционально их приоритетам. Мне, почему-то, кажется, что разделение времени внутри подзадач ядра сложней. И разница есть.

Re: подсказка

[stepancheg.livejournal.com]

В "операционной системе будущего" шедулер будет примерно такой же, как и сейчас.

В современных JVM все "внутриJVMные" потоки — это потоки операционной системы, и шедулингом JVM не занимается (кроме каких-то специфичных случаев).

Re: подсказка

[nealar.livejournal.com]

Но тогда, получается, что на каждый "внутриJVMный" поток создаётся свой контекст ОС, в котором запущена JVM.

Re: подсказка

[stepancheg.livejournal.com]

Какой-то контекст есть на каждый поток. Но он лёгкий, по сравнению с контекстом, например, процесса в Linux.

Re: подсказка

[nealar.livejournal.com]

Размер контекста определяется тем, что у потоков разное. Если только продолжение, то он будет сверхлёгкий. У процессов разное: пространство памяти, открытые файлы, окружение и т.д.

Re: подсказка

[stepancheg.livejournal.com]

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

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

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

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

Re: подсказка

[nealar.livejournal.com]

Я имел в виду совсем не LLVM, когда описывал операционную систему будущего.
Я упомянул LLVM только в контексте C-на-виртуальной-машине. Естественно, ОС будущего пишут не на С и VM для неё делают такую, что C на неё кладётся плохо.
тонны научных работ
То есть, однозначно, техника будущего.