Где наша свобода?
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-10 09:36 am (UTC)конечно не так все просто и интуитивно, но все же есть, и вроде в полном объеме... похоже ответ положительный, где-то процентов на 70-80... интерактивность все же очень желательная, а не опциональная функция... так же как и интуитивная простота -- все же я нашел сию функцию только после вашей подсказки... это не есть + ИМХО.
Ну а что до консерватизма... я вроде смягчил в конце сей пассаж, упомянув что сам не чужд...
А упоминание об эволюционных преимуществах вообще не имело целью представить чьи-либо воззрения в уничижительном свете... просто я люблю использовать междисциплинарные аналогии и терминологию. :) (без претензий что удачно)
no subject
Date: 2008-07-10 01:03 pm (UTC)Которую из двух? customize-face? customize-face is on (Сиречь Menu -> Options -> Customize Emacs -> Specific Face...) show-paren-mode? В том же Options второй пункт, Paren Match Highlighting
no subject
Date: 2008-07-10 01:28 pm (UTC)Универсальность тоже имеет свои недостатки.
no subject
Date: 2008-07-10 04:26 pm (UTC)На третьем. Это у меня, при принудительно выключенном menu-bar, она на четвертом. А у Вас-то меню наверняка присутствует.
Путь к ней вполне очевиден. Я, натурально, начал настройку емакса, когда ему учился, именно оттуда - с Options->Customize.
Сейчас, став поопытнее, я уже представляю себе принцип именования команд, и начинаю с M-x и использую Tab completion. Получается удобнее, особенно в терминале (а на N800 emacs приходится в терминале использовать).
no subject
Date: 2008-07-11 06:41 am (UTC)например в том же нотепаде++ такая опция находится на втором (Опции->Определение стилей)
И дальше открывается диалоговое окно, где и настройки лучше структурированы, и цвета из палитры...
Всетаки -- это специальизированная задача, и решать её лучше специальными средствами, а не полагатся на вроде бы реализацию с использованием универсальных... а вы как думаете?
no subject
Date: 2008-07-11 10:41 am (UTC)А можно там показать "вроде бы реализацию с использованием универсальных (кого, кстати)?" И что именно Вы понимаете под "это специализированная задача"? А то что-то мне подсказывает, что Вы под этим понимаете совсем не то, что я...
А что до "с использованием универсальных" - можно я Вам Ваше же возражение верну? Если я настраиваю emacs в иксах, у меня есть палитра. Называется xcolorsel. Я на ней посмотрю цвет, посмотрю его название, и впишу. В терминале с палитрами вообще проблемы. В виндах палитра другая и названия цветов другие. Вы предлагаете сделать универсальную палитру, работающую во всех трех случаях, или все же можно воспользоваться специализированными? А почему? А почему тут так, а там - по-другому?
На самом деле отсутствие палитры в емаксе объясняется всего лишь тем, что такого виджета для него никто пока не сделал. Сделаете - будет, кто б возражал? Я, кстати, даже подозреваю, почему не сделано. Потому что тем, кто может, оно нафиг не надо, у них есть куда более интересные задачи, чем по часу в день рихтовать цвета шрифтов. А раз в полгода можно и xcolorsel рядышком запустить, все равно любая стандартная палитра для цвета шрифта, в отличие от цвета фона, малопригодна - разница между полем и тонкой линией...
no subject
Date: 2008-07-11 12:56 pm (UTC)Фэйс -- тоже не воспринимается с первого раза, без подготовки как относящийся к цвету текста.
Да и привычка тут непричем.
Настройка "Определение стилей" находится прямо под пунктом меню "Опции", в котором в свою очередь всего еще два пункта "Preferences" и "Горячие клавиши".
Так что не найти сложно...
Так что это какраз вы путаете... привычное вам, с понятным любому.
//И что именно Вы понимаете под "это специализированная задача"? А то что-то мне подсказывает, что Вы под этим понимаете совсем не то, что я...
Вот есть задача "открыть файл"... и практически в любой системе ГУИ существует простой и стандартный способ вызова такого диалога.
//Я, кстати, даже подозреваю, почему не сделано. Потому что тем, кто может, оно нафиг не надо, у них есть куда более интересные задачи, чем по часу в день рихтовать цвета шрифтов.
Это какраз илюстрация к тому о чем я говорил.
Эффект второй системы... когда человек вростает в среду, которая вроде бы удовлетворяет все его потребности (может и правда удовлетворяет, но вопрос не в этом), но с другой стороны исподволь, незаметно, приучает к некоторому конкретному взгляду на вещи, просто потому что с одной стороны возможности, а с другой ограничения... и хотя последние и обоснованы могут быть, но с течением времени они просто становятся унаследованными ограничениями, тормозящими дальнейшее развитие.
И что касается цвета шрифтов конкретно... вот вы сделали оговорочку "часу в день рихтовать цвета шрифтов", а я вам продемонстрирую что она значит.
По час в день -- это только потому что в этой системе именно эта задача достаточно сложная, трудоемкая и действительно может потребовать часа в день, а то и больше.
Но вот в той системе о которой говорю я -- нотепад++.
Это все очень просто и интуитивно, и потому я могу не то что специально настраивать (игратся с цветом шрифтов), а даже просто по ходу работы, зайти в диалог и поменять, что хочу и так, как ИМЕННО СЕЙЧАС мне кажется удобным/нужным.
Вы понимаете что это значит?
У меня появляется дополнительная степень свободы, когда не я завишу от системы, от её унаследованных ограничений, а наоборот, могу свободно использовать её приимущества.
“границы моего языка – это границы моего мира” Витгенштейн
no subject
Date: 2008-07-11 09:48 pm (UTC)А я и не утверждал, что "Customize Face", в свою очередь, понятнее. Нет, если знать, что такое face (а это вопрос терминологии, т.е. привычности - просто слово "стиль" в этом контексте Вы уже знаете, а "face" еще нет), то глагол-то понятнее как раз у емакса. Да, уровней получается чуть больше. Но. На первом уровне ровно то же самое (ну, с точностью до того, что слово Options англоязычному человеку понятно, а слово "опции" русскоязычному - не очень). На втором - у емакса просто Customize. Мы сюда что делать пришли? to customize, натурально. Наводим мышку на это слово - нажимать уже не надо, менюшка сама выезжает, и там можно выбрать, что именно customize. Телодвижений чуть больше, но не могу сказать, чтобы они были менее понятны без подготовки.
И вот я бы без подготовки не сходу сообразил бы, что цвет шрифта надо править в определении стилей, а не в Preferences... Это при том, что я - профессиональный программист и в прошлом админ, и на подобных штуках собаку съел и кошкой закусил.
Ага. Вот только гномовский, скажем, легко позвать, но трудно им воспользоваться (я Вам просто передать не могу, как меня задрал этот диалог, характерный тем, что при более чем десятке файлов в каталоге начинает с того, что пару минут жрет процессор - мне приходится изредка иметь с ним дело в мозилле и в N800). И любой из стандартных уступает в удобстве использования юзером тому способу, который предлагает шелл, vim или emacs. Нет, не тем юзером, который открывает файлы раз в полгода, естественно. Ну так открыть файл - это одна из весьма частых операций... Нет, и vim, и emacs для желающих предлагают стандартные диалоги (стандартные для той гуевой библиотеки, с которой собраны - благо умеют собираться более чем с одной). Только я их отрываю немедленно. Потому что мне ехать, а шашечки стандарта меня в экстаз не приводят, мой мозг еще достаточно гибок, чтобы переучиться на более эффективный способ.
Я в емаксе - тоже. Иногда так и делаю. Именно с цветом шрифта. Цена вопроса - один раз узнать название команды и три раза ею воспользоваться, чтобы привыкнуть к стилю фиксации настроек (который, понятно, у емакса общий на все кастомизации).
Э, нет. Если Вы выбираете notepad++ вместо emacs, вы вместе с преимуществами получаете и недостатки этого перехода - теряете кучу возможностей emacs. Да, сейчас, пока Вы emacs только что увидели, Вы еще не знаете, что это за возможности, не говоря о том, что не привыкли ими пользоваться. А я уже привык. Я в случае такой замены их, натурально, потеряю. А чтобы иметь и то, и другое, мне надо дописать недостающую функциональность либо в notepad++, либо в emacs. Второе, прямо скажем, на порядки проще, поскольку и требуется меньше, и сама функциональность проще, и способ расширения куда более продуман (что и является причиной того, что у emacs эта самая функциональность есть).
Другое дело, что для меня функциональность палитры не настолько ценна, чтобы потратить пару часов на изучение того, как ее туда будет наиболее правильно встроить, и еще полчаса на ее создание. У меня есть более интересные задачи.