Где наша свобода?
Jun. 19th, 2008 11:27 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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-х, кончавших одни и те же университеты, и понимавших друг друга с полуслова, повалила толпа любителей, осваивавших программирование на персональных компьютерах самостоятельно.
Как теперь из получившейся ямы вылезать я не знаю. Выкингуть существующие миллионы строк кода просто так не получится. Хотя место большей части этого кода - именно на помойке.
Диалог в бюрократическом учреждении:
- Имею ли я право?
- Конечно имеете!
- Так могу ли я?
- Нет, не можете!
Положение дел в области 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-х, кончавших одни и те же университеты, и понимавших друг друга с полуслова, повалила толпа любителей, осваивавших программирование на персональных компьютерах самостоятельно.
Как теперь из получившейся ямы вылезать я не знаю. Выкингуть существующие миллионы строк кода просто так не получится. Хотя место большей части этого кода - именно на помойке.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-07-12 02:35 pm (UTC)Пожалуй я действительно неудачно написал.
Но все равно не ваша правда. Это мы влезли уже в такую область где нужно много осторожнее и покорректнее высказыватся. А мы пока рубим друг другу аргументы с плеча.
Вот у вас и у меня тут многое намешано, давайте разделять.
1) Нет низкого и высокого уровня языка, а есть: соответствует ли он проблемной области? достаточно ли он мощный и выразительный?
для КАЖДОЙ отдельной задачи нужно определятся с обеими этими вопросами.
Если не них не отвечать -- попадаеш в ловушку некорректного обобщения. Начинаеш некртично переносить наработки в одной области в другую.
2) Возможность решить данную задачу вообще. Вы ведь знаете что далеко не все задачи решаемы, и очень много задач тяжело решаемых.
Плюс то несомненое, что не учитывается в машине Тьюринга -- нам нужно не только чтобы задача теоритически решалась, но и могла быть реально просчитана на компютерах современной мощности, а не за время до охлаждения белого карлика. :)
3) Вопрос который присутствует неявно. Програмирование это не только математика, но еще и инженерия. И тут тоже еще очень много чего неясно и очень сложно.
Можна продолжать и дельше... но сами видите, к чему может привести излишнее углубюление в дефиниции и класификации...
Давайте говорить О ГЛАВНОМ.
//Потому что Бор сталкивался с реальной сложностью природы, а у нас задача стоит в том, чтобы результат был понятен человеку (чтобы человек мог пользоваться системой для решения своих задач).
А челоек что, уже не часть Природы???
И разве задачи стоящие перед програмистом не суть одно из проявлений самой природы?
//Человек в принципе может решать только такие задачи, постановку которых он может понять.
Не пойдет.
С таким успехом мы сейчас еще и в когнитивную психологию залезем, пробуя установить как же человек понимает...
Это дебри, это болото, это какраз то что происходит когда пытаются решить очень сложные фундаментальные задачи В ЛОБ, используя стереотипные методы, понадеявшись на их "мощность" и всеядность...
Вместо того, чтобы отойти в сторонку и подумать, постаратся осмыслить, обобщить задачу, подойти у другой стороны.
Нет. Делабт как всегда и... или обявляют задачей нерешаемой или неактуальной, неинтересной (как вы например сделали с вопросом о палитре)
Или же зарываются в частности.
no subject
Date: 2008-07-16 03:53 pm (UTC)Нет. Сложность задач, стоящих перед программистом, в норме по крайней мере на порядок ниже сложности задач, стоявших перед Нильсом Бором. Ибо это - задачи, понятные обычному человеку, а вовсе не задачи, которые перед ним как перед частью Природы, могут стоять.
А что, задача о палитре должна была стать мне интересной просто по факту того, что Вам хочется палитру?
С неактуальными - другой вопрос. "Не актуально" обычно означает "я не готов потратить на эту задачу то количество ресурсов, в которое я оцениваю ее решение". Часто даже не "в которое я оцениваю", а "менее чем которым точно не отделаться", что обычно куда правдоподобнее, и от чего "отойти в сторонку и подумать" не спасает - действительно не отделаться.
Я бы сказал, что с этого надо начинать, если серьезно браться за задачу. А Вы хотите закончить, туда не залезая...