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

[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

[vladimir000]

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

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

[(Anonymous)]

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

[vladimir000]

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

[vitus_wagner]

Проблема современных интерфейсов в том, что они неоптимальны по скорости освоения программистом. А с этим мощь компов никак не поможет справиться.

[vladimir000]

Вот именно!

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

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

[vitus_wagner]

То есть, более медленный но более простой в освоении интерфейс не имел шансов 10 лет назад,
Ну как не имел шансов? Unix (классический Кернигановско-Томпсоновский) был как раз таким интерфейсом. И период его триумфа - это где-то 25-30 лет назад.

[vladimir000]

Он был, насколько я понимаю, более безопасным и стабильным, и _за это_ пониженным быстродейстием готовы были платить.

То етсь может я конечно не прав...

[gineer.livejournal.com]

это по нынешним временам он простой.
подобное надо сравнивать с подобным.

да и в применении ограниченный, хоть в своей нише и почти идеален.

[slobin.livejournal.com]

Всё-таки иногда поможет. Недавно у кого-то читал замечательный пример. К сожалению, потерял ссылку, перескажу своими словами:

Представьте себе, что вы делаете ворд-процессор. На дворе 1990-й год (примерно), на типичных машинах ваших пользователей -- 512 килобайт памяти. Но хорошо бы, чтобы на 256 он тоже работал. И вот вы хотите реализовать спелл-чекер. Хрен с ней, с грамматикой, пускай тупо проверяет слова по списку. Список в память попросту не лезет. Ну хорошо, придумаем какую-нибудь хитроумную схему кодирования. Не забываем, что она должна быть ещё и быстрой, лазить за словом в карман на диск некогда. В крайнем случае просто урежем словарь вдвое -- иногда такие грубые решения тоже годятся. В общем, пол-человеко-года для довольно квалифицированного человека. А сегодня? Одна строчка на любом перлопитоне. Так что прогресс иногда способствует.

P.S. С днём рожденья!

... Хороший язык - мёртвый язык ...

[gineer.livejournal.com]

глупый пример

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

[slobin.livejournal.com]

Вообще-то именно это и называется "повышение производительности компьютеров иногда может способствовать повышению понятности API". В условном 1990 такая библиотека была невозможна -- каждый случай был уникален. Точнее, она была невозможна для такого объёма данных, для меньших -- сколько угодно. А при нынешнем объёме памяти эта библиотека (написанная и отлаженная безусловно умным человеком) имеет API, понятный пятикласснику.

... Наслаждайтесь вашим стоянием! ...

[gineer.livejournal.com]

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

Ведь на это собственно и сетует уважаемый автор.

[besm6.livejournal.com]

Ведь уровень задача растет.

Это заблуждение.

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

И это тоже.

[gineer.livejournal.com]

Ну да?
наверное АПИ для написания команд-лайнового интерфейса сравним по сложности с современным GUI API? наверное древнего создателя какой-нибудь командно-строковой утили заботил вопрос "каким шрифтом вывести этот текст на экран?" :))

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

Или вы имели в виду что-то другое?

[besm6.livejournal.com]

наверное АПИ для написания команд-лайнового интерфейса сравним по сложности с современным GUI API? наверное древнего создателя какой-нибудь командно-строковой утили заботил вопрос "каким шрифтом вывести этот текст на экран?" :))

Его зато волновало, какие именно слова из текста вывести. Что не волнует программиста, кодирующего GUI - у него на все содержимое виджета один параметр, все остальные - представление оного содержимого. Вы API Tk видели? Нет, не кое-как приляпанный перловый, а родной тикловый? В "более современных" набор возможностей практически тот же, и модель один в один. А API за каким-то хреном сложнее на порядок, и хрен чего в документации найдешь.

[besm6.livejournal.com]

И все это уже невозможно как раньше порешать, просто вызвав отладчик, или проанализировав дамп...

И для этого давно решение придумано. Только леммингам не хватает интеллекта для освоения функциональной парадигмы.

[gineer.livejournal.com]

в лес... это уже пахнет банальным холи варом.

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

[besm6.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[vitus_wagner]

Кир, ты выбрал крайне неудачный пример.

Ispell is a very old program.The original was written in PDP-10 assembly in 1971

Поэтому в настоящем, а не условном 90-м году, человек у которого в распоряжении была нормальная рабочая станция с тогдашнем unix, вполне мог использовать для spell-чекинга
пайп в ispell -a.

[slobin.livejournal.com]

То есть фактически пакетный режим, быстро проверить одно слово нельзя. А если хочется подчёркивание ошибок на лету? Кстати, на случай, если я что-то наврал при пересказе, вот оригинал.

P.S. Про спелл-чекеры: смотри мой журнал буквально минут через пять. ;-)

... Вот и окончился сказочный вечер ...

[besm6.livejournal.com]

То есть фактически пакетный режим

Кир, ispell -a, а не ispell filename. Поднимаешь пайп и выдаешь на проверку по одному слову.

[ramendik]

Вот только массовому пользователю (которому тексты набивать) не была доступна тогдашняя нормальная рабочая станция.

1990 год и 512 килобайт памяти - значит, мы в СССР. 386-х с 2-4 мегабайтами _единицы_, на них можно что-то раннеBSDшное водрузить. Но основной парк - XT и 286, под досом.

[vitus_wagner]

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

[sergey_ver]

В ближайшей перспективе она будет обращаться к нейронной сети, натренированной на 10ккк примеров, так как там результаты уже сейчас лучше чем у любых ручками запрограммированных систем. И что вы с ней будете делать в рамках парадигмы Open Source?