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

[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: подсказка

[nealar.livejournal.com]

Виртуальная машина в принципе не может выдавать "максимальную производительность", потому что виртуализация - это всегда оверхед. Но это никому и не нужно, ибо "тормозить" - понятие субъективное: у некоторых и виста тормозит. Работу с совсем хардкорными (железными) вещами в ВМ не положат, поэтому, ядро с тормозной ВМ, может быть, даже не будет глючить.
Это архитектура (и реализация) микроядра.
Так ведь этих реализаций сколько угодно. Уверен, что есть и лучше. По скорости переключения контекста http://odin-os.sf.net уделывает всех, ну и где операционки, сделанные на ней?

Re: подсказка

[stepancheg.livejournal.com]

виртуализация - это всегда оверхед

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

уделывает всех, ну и где операционки, сделанные на ней

Качественного микроядра недостаточно для того, чтобы все резко начали пользоваться операционной системой, и вы это, наверное, понимаете. Тогда неясно, в чём вопрос.

Re: подсказка

[nealar.livejournal.com]

компиляцию можно сделать один раз при старте программы
И это: 1) даст одноразовый оверхед на компиляцию, 2) неясно, почему считается виртуализацией. Вот под линуксом заметная часть софта компилируется один раз при установке программы и
1) неужели Вы ни разу не встречали недовольных этим, которые требуют дистрибуцию в бинарной форме?
2) неужели это можно назвать виртуализацией?

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]

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

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

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

Re: подсказка

[nealar.livejournal.com]

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

Re: подсказка

[stepancheg.livejournal.com]

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

Re: подсказка

[nealar.livejournal.com]

Тогда неясно, в чём вопрос
Вопрос в том, что призвано доказать Ваше утверждение "Mach устарел, L4Ka лучше". Да, лучше. А другое ядро - ещё лучше. Ичё?

Re: подсказка

[stepancheg.livejournal.com]

Это вы начали с того, что говорили, что Linux устарел, а MacOS X (который на Mach) — лучше. Я ответил, что Mach тоже устарел, а L4Ka лучше. Но по совокупности факторов Linux всё равно выигрывает, несмотря на то, что работает на устаревшей технологии монолитного ядра.

Re: подсказка

[nealar.livejournal.com]

Начнём с того, что я не говорил "Линукс устарел". Идея монолитного ядра - да, устарела, поэтому для новых разработок я бы не рекомендовал её брать. Ну так и Mach для новых разработок тоже брать не стоит, есть ядра поновей и получше. А для старых - Apple взял и доволен. "По совокупности факторов" - это не та ли мантра, которой пользуются, когда выбирают винду? :))

Re: подсказка

[stepancheg.livejournal.com]

По совокупности факторов выбирают Mac на десктоп и Linux на сервер. Винду выбирают по незнанию :)

случаи всякие бывают ;)

[nealar.livejournal.com]

Совокупности разные бывают и вообще это мутное понятие. Есть задачи, с которыми (пока?) лучше винды ничего не справляется. Ну и такие варианты, как BSD на сервере.
Хорошо, когда можно померить и привести чиселку, а когда вместо чиселки "совокупность" - трудно. Вон в статье по ссылке аффтар пытался "торможение компа" тестами замерить, получилось не очень. Я тоже не умею.

Re: случаи всякие бывают ;)

[stepancheg.livejournal.com]

Есть задачи, с которыми (пока?) лучше винды ничего не справляется

Какие это задачи? Насколько я понимаю, это только случаи, когда под Windows есть очень специфичное ПО.

BSD на сервере

BSD на сервере уже не жжёт.

Re: случаи всякие бывают ;)

[nealar.livejournal.com]

Насколько я понимаю, это только случаи, когда под Windows есть очень специфичное ПО.
Да. Его не так уж мало.
BSD на сервере уже не жжёт.
Интересый критерий. :)