Где наша свобода?

[vitus_wagner]

Есть такой анекдот:

Диалог в бюрократическом учреждении:
- Имею ли я право?
- Конечно имеете!
- Так могу ли я?
- Нет, не можете!

Положение дел в области Free Software чем дальше, тем лучше описывается этим анекдотом.
Имею ли я право исправлять глюки и дописывать нужные мне фичи в Mozillу, OpenOffice, ядро Linux, Gimp etc - да сколько угодно. Лицензия позволяет.
Могу ли я? Увы, трудоемкость, необходимая для вникания в большой проект на несколько миллионов строк - соврешенно prohibitive. Даже при наличии квалификации. А протолкнуть свои изменения в upstream - еще сложнее.

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

Еще десять лет назад это было не так. Тогдашние OpenSource проекты были достаточно компактны, лучше документированы, и всё необходимое тайное знание содержалось в коде. Было дело в 99-м году я при каждом новом релизе ядра ветки 2.2 внимательно читал патчи чтобы решить - ставить это срочно на боевой сервер или погодить пока.

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

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

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

Более того, за последние 10 лет в Open Source пришло множество программистов воспитанных на Visual Basic и прочих изделиях Microsoft, где от программиста не предполагается четкого понимания задачи в целом - это понимание - коммерческая тайна Microsoft.
Вот пример в MSDN, делайте по образу и подобию. Воспринимайте эти слова как магическое заклинание, как ритуал.

Но там хотя бы сидят несколько сот человек, которые это дело документируют.

Заметим что микроядро в Hurd было на самом деле нужно не столько по тем техническим соображениям, которые приводил Таннебаум в споре с Линусом, сколько именно из соображений well-defined interfaces, которые позволили бы множеству независимых разработчиков работать над разными подсистемами ядра. Но ни Таннебаум, ни Столлман этого тогда сфонрулировать не могли. Потому что это на самом деле вопрос социальной психологии а не технологии.

Некторые решения, которые уже фактически приняты сообществом как стандарт, иначе как миной замедленного действия под идею свободного софта я назвать не могу. Ну про CUPS уже Раймонд всё написал. Ага, тот самый Раймонд, который выдумал термин Open Source как менее "страшный" чем "Свобода", чем немало способствовал возникновению данного положения. Еще большей миной замедленного действия я считаю D-Bus. Не то, чтобы плоха была самой идеи общесессионной или общесистемной шины сообщения. Но во-первых, реализация - нету стандартного набора утилит для работы с этим из shell. Не отладочних прибабахов вроде dbus-send и dbus-monitor, а полноценных инструментов для работы класса NetCat. Во вторых, документированность. Уже сколько лет в комплекте bluez, который иначе чем через dbus нынче с пинкодами не работает, идет passkey-agent, написанный настолько криво, что при его завершении libdbus ругается на stderr. И никто не соберется исправить.

К сожалению, в 96-97 году, когда начинались проекты KDE и GNOME не нашлось гения, который бы предложил архитектуру GUI-среды, способную развиватья в условиях Free Software, и при этом оставаться простой и понятной. Впрочем, это как раз был переломнымй момент, когда менялись условия Free Software - вместо немногочисленных, но весьма квалифицированных хакеров 80-х, кончавших одни и те же университеты, и понимавших друг друга с полуслова, повалила толпа любителей, осваивавших программирование на персональных компьютерах самостоятельно.

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

Comments

[alexkuklin.livejournal.com]

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

Зачастую в современных разработках забывают про принцип KISS и про необходимость работать с инструментами из командной строки (например, я так и не нашел, как можно получить PDF из ODT при помощи OpenOffice без запущенных иксов).

Тем не менее, попутно с усложнением, идет процесс систематизации и документирования. Медленнее, чем хотелось бы, но идет. Так что все плохо, но (пока) не фатально.

[(Anonymous)]

> Заметим что микроядро в Hurd было на самом деле нужно не столько по тем техническим соображениям, которые приводил Таннебаум в споре с Линусом, сколько именно из соображений well-defined interfaces, которые позволили бы множеству независимых разработчиков работать над разными подсистемами ядра. Но ни Таннебаум, ни Столлман этого тогда сфонрулировать не могли. Потому что это на самом деле вопрос социальной психологии а не технологии.

никто не мешает well-defined interfaces делать в нынешнем ядре.
для большинства компонент они вполне даже defined. и местами даже очень well.
проблема только в том, что "просто" очень редко соседствует с "быстро".
поэтому интерфейсы сложные и постоянно меняются.

А выкинуть придётся.

[volodymir-k.livejournal.com]

Нужны интерфейсы? - делайте версии с идентификаторами, и сборки будут точными и шелковистыми. Да как бы уже.

Нужно описание интерфейсов? -- пропагандируете документирование. Сейчас это второсортное занятие, нет мнения, что оно ценное. Ну давайте придумаем систему оценок документации, пусть народ за баллы качества борется.

[shadow-aka-hf.livejournal.com]

Если говорить о ядре, то идеи Singularity много интереснее чем Hurd. Не знаю, правда, на сколько такой OSS-проект будет конфликтовать с патентами.

Re: А выкинуть придётся.

[ro-che.info (from livejournal.com)]

Ну давайте придумаем систему оценок документации, пусть народ за баллы качества борется.
Уже есть. ohloh.net

[dennis_chikin.livejournal.com]

Крепнет подозрение, что оверхед от всех этих API давно превзошел все мыслимые пределы.

[vitus_wagner]

Можно конечно сказать, что «"просто" очень редко соседствует с "быстро"» - это "никто" - объективный закон природы. Но по-моему, в таких социальных явлениях как IT-индустрия любые объективные законы природы проявляют себя через деятельность людей.

[vitus_wagner]

Вообще-то Шумил про это еще когда писал. Он правда винил во всем ООП, но ООП это просто наиболее яркий пример technology misuse. Всякие не слишком объектные C API часто приводят к столь же грустным эффектам.

[vladimir000]

То есть, еще несколько лет - и появятся неоптимальные по скорости (но компы становятся все мощнее, и разница может стать уже незаметна) но простые, легкие и доступные интерфейсы?

Хорошо если так.

[vitus_wagner]

например, я так и не нашел, как можно получить PDF из ODT при помощи OpenOffice без запущенных иксов
Можно отдельно поругаться на практику использования Wiki и всяких doxygen-ов вместо нормальной документации.
Эта практика распространилась под впечатлением ложной идеи что такая документация лучше чем ничего.
Но увы, если не предпринимать специальных усилий, сравнимых с переходом с c на cweb, документация, сделанная doxygen-ом ХУЖЕ чем ничего (вернее, чем необходимость читать непосредственно код).

[tarkhil.livejournal.com]

Что я могу сказать? Так оно и есть. Для того, чтобы собрать конвертер RAW, нужно сначала собрать какую-то библиотечку для работы с тайским языком.

Как оторвать гному корявые попытки автомонтировать флешку - я так и не понял. Причем, читать он ее не читает, но при попытке отцепить - валится в панику...

[potan.livejournal.com]

В проекте Роса Руслана Богатырева вроде как эту проблему собираются преодолеть. Не знаю, есть ли у них шансы - "слишком далеки они от народа".

[amarao-san.livejournal.com]

Собственно, с позиции этой толпы любителей, несколько "умных хакеров" были странными и неудобными.

А концепция опен сорса подразумевает, что таки все, а не элита, могут писать, дописывать. А уж принцип "релизь чаще" и вовсе способствует к лёгкому (?) хаосу. Что просили, то и получили.

Когда человек получает право писать он получает в том числе и право писать как попало.

Re: А выкинуть придётся.

[potan.livejournal.com]

Документирование требует очень большой работы. Особонно поддержания когерентности кода и документации.

[potan.livejournal.com]

В свое время ходила рекомендация, как получить html из pdf: выложить на сайт, подождать пока проиндексируется Гуглум и далее "посмотреть как html" :-).

В больших программных системах документация и даже комментарии не успевают за кодом. К тому же описание архитектуры какого-нибудь OpenOffice займет не один толстый том, который читать без крайней необходимости ни кто не станет. Так что тотальное документирование свободы не много добавит.

[as-pushkin-by.livejournal.com]

Идёт маргинализация отрасли, не только Free Software.

[booosh.livejournal.com]

Виктор, на мой взгляд, вы мешаете в кучу последствия от двух явлений:

1. Отсутствия вменяемой школы программистов.

2. Существенного увеличения codebase.

[iakovz.livejournal.com]

Есть хорошие примеры ведь - OpenBSD (полностью бесплатный пример)
и Apple Mac OS X и все остальное из этой лавки

Linux перестал использовать пару лет назад и сейчас со страхом смотрю на это "поделие" без царя в голове

[(Anonymous)]

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

[metaclass.livejournal.com]

Свободы бы добавило нормальное проектирование архитектуры всех этих проектов. Чтобы можно было проект разобрать на 10 составных частей, которые отдельно билдятся и работают. Типа - понадобилось тебе только текстовый редактор из опен-офиса где-то использовать - выдрал кусочек из проекта и используй. Заодно проектирование в подобном стиле сильно дисциплинирует программистов и лечит баги.

[(Anonymous)]

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

[abbra]

google://unoconv
Начиная с OOo 2.3 режим -headless нормально работает и без DISPLAY.

[vitus_wagner]

Я не уверен что эти два явления можно разделить.

плюстыща

[neo-der-tall.livejournal.com]

Мечта: взять весь СтабФонд и потратить исключительно на рефакторинг Open Source.

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

[vitus_wagner]

Apple можно не рассматривать. Поскольку исходники закрыты. А у OpenBSD есть такая проблема что ничего полезного она делать не умеет. Я не могу себе представить OpenBSD на десктопе, чтобы работал Bluetooth PAN, SD card reader, веб камера etc, да еще чтобы там вместо Mozilla был браузер с вменяемой архитектурой, вместо gimp что-то что умеет делать garbage collection всем объектам во встроенной Scheme etc. Но при этом функциональность, которую я имею от Gimp, Mozilla, Audacity, Inkscape полностью бы покрывалась.