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

[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

[some41.livejournal.com]

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

протокол, как правило, предполагает обмен сообщениями в обе стороны. Зачем это нужно в 90% - не понимаю.
ну так когда не нужно, тогда будет в одну сторону. главное, чтобы когда нужно это было просто организовать. и никакой тут большой проблемы нету - socket вон работает в обе стороны, но сетевым программам это никак не помешало.

вообще же главным словом было "структурированными". ну и идея, что пайпы должны всегда равноправны с файлами.

[vitus_wagner]

Процесс - это очень правильное понятие. Если у нас есть функция на шелле, это её можем легко запустить как процесс - в сабшелле. А вот использование для создания компонент динамических библиотек стоит запретить законодательно. Ибо это нарушает принцип изоляции. Или надо динамические библиотеки как в Win16 делать - c собственным адресным пространством и всё такое.

Процесс в достаточной степени изолирует компоненту от взаимодействующих с ней компонент. С учетом существования ulimit-ов он дает шансы взаимодействующим с ним обработать ЛЮБЫЕ его ошибки, вплоть до SIGSEGV.
Реализация компоненты в виде динамической библиотеки такой возможности не даёт. Более того, дает компоненте возможность напакостить в памяти приложения, которое её использует, таким образом, что это станет заметно далеко не сразу.


Ну и, как я уже писал выше использование протоколов, даже самых примитивных, типа вопросов, требующих ответа yes/no в корне противоречит равноправию папйпов/сокетов с файлами.

[some41.livejournal.com]

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

протокол, требующий подтверждения, это отнюдь не примитивный протокол. примитивный протокол - это http 1.0 - послал запрос, получил ответ.

[vitus_wagner]

У нас процессоры сорок лет развивались исходя из того что будет исполняться код на языке C. Переключение контекстов - дешево. А замены этому portable assembler пока нет. Кстати, говоря о запрете компонент в виде разделяемых библиотек, я ничего не имею против
компонент в виде lightweight процессов Erlang, отдельных интерпретаторов SafeTcl и тому подобных конструкций. Если у нас интерпретатор, даже байткода, навроде JVM, то мы можем себе многое позволить - он проконтролирует (хотя в том же SafeTcl лимитов на память и CPU Cycles нету. А надо). Но если речь идет о бинарном коде - не важно, C это, Fortran или даже Oberon-2, то процесс - единственный осмысленный способ изоляции.

Заметим что в OTP (Erlang-системе) те вещи, которые требуют использования чужих бинарных библиотек, зачастую реализуются через механизм "портов". Т.е. выносятся в отдельный процесс нижележащей ОС.

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

[some41.livejournal.com]

У нас процессоры сорок лет развивались исходя из того что будет исполняться код на языке C.
и ничего хорошего в этом нет. ну ничего, думаю мультикоровость и вообще рост параллельности С таки добьет.

[(Anonymous)]

> У нас процессоры сорок лет развивались исходя из того что будет исполняться код на языке C.

Один вопрос. Почему ты считаешь, что массовое переписывание существующей codebase - проще, чем создание нового процессора (пусть даже с учетом усилий на распространение и портирование).

[vitus_wagner]

Массовое переписывание существующей codebase решает гораздо больше проблем. Создание нового процессора решает единственную проблему - наполнение карманов производителей процессоров (и то, если процессор окажется удачным).

И я как раз за сохранение существующей codebase в максимально возможном виде. Выкидывать только то, что последние 20 лет сделано, и то с разбором.

[cmike.livejournal.com]

Поясню. Аппаратные решения, позволяющие защищать пространство отдельного модуля, давно отработаны и их использование позволяет не менять ни одной строчки кода в приложении. Их, правда, тоже не используют. Спроса нет (как в советском анекдоте про черную икру).

Такие задачи, как несогласованность интерфейса, аппаратно не решаются. Но это другие задачи. Здесь сдерживает отсутствие идей ИМХО.

[vitus_wagner]

Всё равно не понял, какое отношение это имеет к вышележащему треду. И тем более к моей точке зрения, в нём выраженной.

[cmike.livejournal.com]

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

Один вопрос. Почему ты считаешь, что смена парадигмы программирования (вместе с переписыванием всего, что придется переписывать) проще, чем сменить процессор.

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