Столлман, как всегда, велик

[vitus_wagner]

В недавнем интервью Столлман сказал It doesn't matter how popular GNU/Linux gets, if it fails to give you freedom.

Собственно, в этой одной фразе сконцентрировано всё содержание моих двух предыдущих постов про интерфейсы (1, 2

Современные DE (и не только DE, Office suites и даже браузеры туда же) именно что fail to give me freedom.

Свобод, согласно тому же Столлману - 4:
0. To run the program as you wish.
1. To study the source code and change it so the program does what you wish.
2. To redistribute exact copies when you wish, either giving them away or selling them.
3. To distribute copies of your modified versions when you wish.

Речь идет, естественно, о свободе N 1 - изучать и модифицировать код. В реальной жизни у меня есть не более чем сколько-то времени, которое я могу потратить на устранение мелких неудобств или повышение своей квалификации.

В традиционном Unix этого времени более чем хватает, чтобы понимать что оно делает и как его исправить (или обернуть в обертку). Потому что система аккуратно разбита на компоненты, которые можно изучать по отдельности. Способы взаимодействия этих компонентов (пайпы, environment, коды завершения) просты и понятны, а также неплохо документированы.

А сколько времени надо потратить на изучение, скажем XUL, чтобы исправлять поведение браузера? Куда больше, чем на изучение shell.

Comments

[vitus_wagner]

Не понял вопроса. Мой оппонент предлагает поменять основной язык программирования (и соответственно, выкинуть существующую codebase).
Я предлагаю отказаться только от некоторых, не слишком распространенных технологий (плагинов в форме shared library). Которые легко заменяются на плагины в виде отдельных процессов с обменом данными с основным приложением через D-BUS, RPC, да хоть SOAP с сохранением всей функциональности и 95% codebase.
А процессоры менять совсем не предлагаю. По мне они и так неплохи. И мощности у них более чем достаточно, чтобы выдержать overhead от планируемого усложнения взаимодействия приложения с плагинами.
Бенефит - очевиден. Приложение будет способно обработать ЛЮБУЮ ошибку плагина, включая Segmentation Fault.

[cmike.livejournal.com]

> "Система должна быть построена исходя из предположения что любой кусок кода в ней - untrusted."

Я эту фразу воспринял как предложение вообще отказаться от shared library в существующем виде. А в этом случае overhead будет больше.

А вот твоего оппонента я читал не очень внимательно.

[vitus_wagner]

Ну я всё-таки не столь максималистичен. Я имел в виду только подгружаемые через dlopen плагины. Системные библиотеки можно считать заслуживающими доверия. Хотя, конечно, местами и временами в категорию системных библиотек попадают слишком громоздкие и развесистые вещи.

В принципе, должна быть выстроена иерархия доверия. Ядру и libc мы верим всегда. Драйверам устройств - уже не всегда, поэтому драйвера устройств, которые не настолько критичны для жизни системы, чтобы при отказе этого устройства она не могла функционировать, имеет смысл выносить из ядра в userspace процессы. Что уже активно делается всякими libusb, sane, ghostscript и т.д.

Прикладной программе мы верим меньше чем wm или login shell. Плагинам - ещё меньше. Например, имеет смысл устраивать основную программу так, чтобы в случае падения какого-нибудь фильтра или экспортилки в конкретный формат, несохраненное изображение в графическом редакторе не гибло.

[cmike.livejournal.com]

Со всем согласен. С тем добавлением, что для плагинов задача решается заменой dlopen на fork/exec/dlopen + передача данных. Последнее - самое сложное и нестандартное, но должно писать не каждый раз для нового плагина, а все же один раз для каждого типа плагина, что все же не очень трудоемко.

Это не процесс, это фича. :)

... И слава Богу ...

[netch]

Вот когда ты решишь, например, задачу передачи по пайпу 10 мегабайт данных (одно изображение) и обратно несколько раз в секунду без существенных затрат процессора - тогда, может, что-то и получится.
А так как сейчас - фигушки.

Вот когда появится разумное API вида "передать сообщение" в котором можно будет аттачить куски данных (хотя бы размером кратным странице) и чтобы они шарились между процессами - может, что-то и получится. Только не надо предлагать mmap.