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

Current Location: Koh Samui, Thailand

Flat | Top-Level Comments Only

From:

stepancheg.livejournal.com

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

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

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

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

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

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

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

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

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

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

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

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

void f(int);

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

o = obj;
f(i);

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

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

void f(Obj*);

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

i = it;
f(o);

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

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

f(Obj*);

Obj* objects[100];

f(objects[123]);

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

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

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

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

From:

nealar.livejournal.com

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

From:

stepancheg.livejournal.com

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

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

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

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

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

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

Page Summary

Style Credit

Expand Cut Tags