Где наша свобода?
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}
Re: и не стыдно?
Date: 2008-06-19 05:27 pm (UTC)И должен сказать, что гуй, принесенный в линукс гимпом, застопорил, увы, развитие гуя в линуксе. Ибо есть быть суть гадость, но увы, получившая конкурентное преимущество у тех кодеров, которые модели иксов не осилили и нелокального дисплея в глаза не видали.
Re: и не стыдно?
Date: 2008-06-19 05:50 pm (UTC)но таких все же немного.
А остальному большинству нужны инструменты попроще и попонятнее. Для прогрмирования рядовых неэзотерических задач.
Да и поспорить можно... так ли уж велико преимущество "нелокального дисплея"... когда большинству совершенно необходим локальный.
Вообще, это обычная штука. Есть отдельные джи... специалисты, которые ради удовлетворения своего эго придумывают всякие навороченные системы, а потом куча других людей мучается их програмируя. :)
Нет, на команду Иксов гнать как-то не досуг.
Но есть другой пример. Технология COM у мелкомягких.
Все гладко, красиво (на бумаге), эзотерично.
Только с той маленькой особенностью, что подавляющему большинству все эти навороты с нелокальными сетевыми интерфейсами -- нафиг не надо.
Так же как и разбираться в десятке видов маршалинга и т.п. :)
ЗЫ А что до Гимпа... вы всетаки не правы.
Потому как разработанные в ходе проекта библиотеки дают много больше того, что собой представляет, и может дать голый Икс.
И это что-то нужно и сейчас (ану-ка гляньте какие либы использует ваша любимая прога), и тем более нужно было тогда, когда еще не было современного изобилия, к которому мы так быстро привыкли.
Re: и не стыдно?
Date: 2008-06-19 06:14 pm (UTC)Tk и постарше gtk будет, и попроще, и попрямее по интерфейсу, и уровнем повыше, и ведет себя получше. Что, спрашивается, мешало его развить?
Некоторые - athena, некоторые - tk (у меня любимых больше одной, ага; даже если учитывать только гуевые). gtk - исключительно нелюбимые. За кривизну. Да, emacs можно собрать с gtk. Но к счастью, можно и без...
У меня была недавно возможность сравнить. На N800 я попытался написать программу на python/gtk. (Там это оправдано - интерфейс у системы в основном гномовский, и выдрать его очень сложно, полсистемы переписать надо.) Так вот. Нет, за 20 лет gtk по возможностям чуть-чуть обогнал tk. Но при этом чудовищно (по сравнению с tk) многословен, изрядно глючен (угу, документированные возможности не работают) и все равно нужной мне табличной функциональности (сохранение хедеров при прокрутке, возможность вставлять в хедера произвольные виджеты, реагирующие на действия пользователя) не имеет. А вот сортировка его хренова мне как раз нафиг не нужна...
Re: и не стыдно?
Date: 2008-06-19 06:34 pm (UTC)http://ru.wikipedia.org/wiki/GTK+
и особенно
http://ru.wikipedia.org/wiki/GLib
если не принимакть во внимание что GTK послужил основанием для формирования инфраструктуры большой части того что мы сейчас имеем. Причем сделал это тогда, когда алтернативных-то реализаций и не было.
то да... тогда вы правы
Re: и не стыдно?
Date: 2008-06-19 08:39 pm (UTC)Я довольно редко принимаю во внимание ложные утверждения...
Re: и не стыдно?
Date: 2008-06-20 07:24 am (UTC)но надеюсь с тем, что в рамках GDK происходила разработка библиотек касающихся не только отрисовки ГУИ вы спорить не будете?
как и с тем, что эти библиотеки теперь используются во многих местах.
Например, для меня характерный пример -- МС
Вообще... я с таким же успехом могу указать на мотивацию ваших оценок.
Вы мечете молнии на ГДК за то что он плохая, некрасивая, неэзотеричная библиотека. И предпочитаете не обращать внимания на более важные прагматичные причины она есть, существует и много для чего использунтся. И если бы её не было, то это еще вопрос, было бы что то на её месте?
Напомнить вам, что это напоминает?
Например спор Таненбаума против Торвальдса. В котором первый исторически проиграл. Потому что, сколько бы он не разукрашивал эзотерические красоты своего Миникса, Линукс имеет свой неоспоримый успех благодаря тому что он ЕСТЬ и РАБОТАЕТ.
ЗЫ Если вы так уж любите эзотерику, то можете поставить себе в качестве ядра последнюю версию Миникса. :)) Еще один "красивый", эзотеричный дизайн.
Re: и не стыдно?
Date: 2008-06-20 07:34 am (UTC)Чтобы было, что бы было - lesstiff бы был. Потому что хотя бы часть ресурсов, которые ушли на разработку Gtk, пошли бы туда. А поскольку его и без этих ресурсов допилили до юзабельного состояния.
Если взять индустрию в целом, а не только OpenSource то обнаружится гораздо больше случаев, когда технически продвинутое решение проиграло заведомо ублюдочному. Например, процессоры Alpha - процессорам Intel, Geoworks - микрософту, Ethernet - USB и т.д.. Но там это можно было свалить на то, что-де некоторые фирмы вкладываются в технарей, а некоторые в маркетологов, и выигрывают вторые. Но в случае php, mysql, gtk явное вложение в маркетинг моожно не учитывать.
А вообще ваша аргументация сводится к "миллион леммингов не могут быть неправы".
Еще можно провести такую аналогию - вот была система Птолемея - сложная, запутанная, но место корабля в открытом море позволяла вычислять с требуемой точностью. И тут приходит Коперник и говорит, что все это не так, что не может природа быть устроена так заковыристо. Все ваши возражения по поводу того, что старая систеаа есть и много для чего используется вполне применимы. Но смогли ли бы без Коперника Кеплер с Ньютоном довести новую систему до такого состояния, что она смогла решать задачи, которые со старой системой и представить себе было невозможно (например предсказание существования новых планет)?
Re: и не стыдно?
Date: 2008-06-20 08:04 am (UTC)Re: и не стыдно?
Date: 2008-06-20 08:51 am (UTC)наоборот, я постоянно ЗА... то что улучшать и можно и нужно.
помнится и наше с вами знакомство состоялось по этой причине.
Так что я не тот лемминг, которого вам нужно переубеждать.
Но вот ведь штука... чем больше я изучаю возможности улучшения, тем больше понимаю почему существующие решения были сделаны именно так, а не иначе. И тем меньше тогда желания огульно обвинять их разработчиков во всех смертынх грехах.
Re: и не стыдно?
Date: 2008-06-20 08:02 am (UTC)Re: и не стыдно?
Date: 2008-06-20 04:52 pm (UTC)+1. Мало что нанесло такой вред FOSS, как Gtk =)