Где наша свобода?
Jun. 19th, 2008 11:27 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Есть такой анекдот:
Диалог в бюрократическом учреждении:
- Имею ли я право?
- Конечно имеете!
- Так могу ли я?
- Нет, не можете!
Положение дел в области 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-х, кончавших одни и те же университеты, и понимавших друг друга с полуслова, повалила толпа любителей, осваивавших программирование на персональных компьютерах самостоятельно.
Как теперь из получившейся ямы вылезать я не знаю. Выкингуть существующие миллионы строк кода просто так не получится. Хотя место большей части этого кода - именно на помойке.
no subject
Date: 2008-06-19 06:25 pm (UTC)Впрочем, я таскаю с собой системник с аккумулятором и настроенным под меня емаксом. В нагрудном кармане...
no subject
Date: 2008-06-19 06:42 pm (UTC)no subject
Date: 2008-06-19 11:03 pm (UTC)no subject
Date: 2008-06-20 06:29 am (UTC)no subject
Date: 2008-06-20 06:46 am (UTC)не, ну я конечно понимаю... эмакс это редактор всех времен, но лёрнинг курв у него всетаки не нулевой, а очень даже ощутимый.
так что скажем я к нему так пока и не подобрался.
предпочитаю использовать (мне хватает) кое-что попроще. (например -- Notepad++) где есть все что мне нужно именно сейчас, а не после длительного изучения.
так что -- ваш эмакс -- отнюдь не панацея для всех, а только лучшее средство для людей со вполне определенными отдельными потребностями.
no subject
Date: 2008-06-20 07:25 am (UTC)А дальше уже изучать те возможности, которых в нотепаде и визуалковом редакторе нету. А потом таки найти способ подключить емакс вместо родного редактора в визуалку. Насколько я знаю, он есть, только мне оно не надо...
no subject
Date: 2008-06-20 08:11 am (UTC)текст который мне приходится набирать, это или исходный код (для которого мне возможностей легкого и быстрого нотепад++ достаточно) или вот такой, как пишу сейчас вам ответ, в окне браузера.
и я как-то не вижу... каким образом написание таких текстов было бы для меня еще лучше, удобнее в эмаксе...
потому и говорю -- своим потребностям -- свой инструмент.
no subject
Date: 2008-06-20 08:54 am (UTC)no subject
Date: 2008-06-20 09:07 am (UTC)Просто... не все йогурты, не для всех, не одинаково полезны...
no subject
Date: 2008-07-10 07:12 am (UTC)Так вот что я скажу... в зависимости от того как ответите не следующий вопрос, будет зависеть поменяю я свое отношение или нет.
Так вот... первое что меня заинтересовало в эмаксе -- это поддержка подсветки синтаксиса, но покамест то что я увидел не показалось мне конкурентно лучшим.
Мне нужна подсветка синтаксиса, с возможностью выбора цвета фона и самого символа для каждого класса лексем, выбора шрифта и его размера, тоже для каждого класса отдельно, коде-фолдинг, ну и такие мелочи как подсветка закрывающей скобки и т.д.
И... важный момент, чтобы это можно было делать, подбирать цвета и т.п. интерактивно, а не набивая конфиги. Потому как, скажем, та настройка что у меня сейчас появилась у меня исключительно потому, что менять эти настройки исключительно легко -- изменения отображаются тут же.
Все что выше указано, у меня уже есть... и как я уже указывал -- не вижу смысла в том, что бы менять удобное сейчас, на что-то большее, более эзотеричное, знаменитое, но не поддерживающее именно конкретных нужных фич.
ЗЫ Еще одно... вы нашли для себя систему, которая вам лучше всего подходит, делает для вас все, даже моет посуду, но по сути такое "полное" удовлетворение потребностей ведет к консерватизму.
Я же постоянно меняю системы, нахожусь в поиске более лучших, и пусть даже текущий мой выбор не удовлетворяет меня полностью -- я готов к переменам. И такое поведение, как известно, имеет решающее эволюционное преимущество -- постоянно изменяться гораздо важнее, чем застрять навечно в одной, пусть и идеальной, экологической нише.
ЗЗЫ Хотя, я возможно был бы и не против оказатся на вашем месте. :) Изменения иногда утомляют.
no subject
Date: 2008-07-10 07:51 am (UTC)Вопрос-то в чем? Можно ли увидеть цвет шрифта интерактивно? M-x customise-face RET. Если курсор стоит на нужном месте, он сам предложит соответствующий face. Палитру он показывать, правда, все же не умеет, насколько я понимаю (оно все-таки рассчитано на работу и в терминале тоже). Но умеет показать результат. Подробности - в его info (C-h r s Face Customization RET RET).
Коде-фолдинг бывает в зависимости от языка, на котором документ. Для некоторых есть, для некоторых не написали. Подсветка парной скобки в комплекте. По умолчанию, правда, кажется, выключено. C-h r s show-paren RET, и читать весь раздел (он небольшой, при моем 50-строчном экране умещается в один экран).
А я использую систему, которую можно улучшить. Не поменять на другую, с ее достоинствами и недостатками, а именно улучшить - устранить недостаток, сохранив достоинства.
А про консерватизм и застревание - это Ваша фантазия, Вы с ней и спорьте...
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)
From:(no subject)
From:(no subject)
From:no subject
Date: 2008-07-10 09:49 am (UTC)Можете оценивать это как максимализм.
Но я все же рассчитываю создать свою систему, максимально соответствующую именно моим теперешним воззрениям на то какой она должна быть, чем расширять уже существующую.
Всетаки проблема невозможности дальнейшей модернизации в виду несовместимости её с существующими техническими решениями -- это не такая простая проблема.
Унаследованый код -- это и преимущество, и баласт.
Тогда как наново написаный -- это только приемущество, хоть и с риском провала.
no subject
Date: 2008-07-10 12:11 pm (UTC)А вот это из предыдущих слов не следовало. Или я что-то уже успел забыть. Это, конечно, пожалуйста, но...
Засада в том, что пока наново написанный код еще не написан, он еще не преимущество, а только риск провала. А как только он написан, он становится унаследованным...
no subject
Date: 2008-07-10 12:51 pm (UTC)no subject
Date: 2008-07-10 01:56 pm (UTC)Это вроде как рефрен общей темы. "Или этих помыть, или новых сделать"
\\Засада в том, что пока наново написанный код еще не написан, он еще не преимущество, а только риск провала.
ubi nihil nihil... нет кода, нет риска
Проблема не в риске. Гораздо сложнее придумать что-то действительно нетривиальное и стоящее реализации. Зато тривиальных поделок с претензией на иновационность -- пруд пруди.
//А как только он написан, он становится унаследованным...
А это дургой вопрос.
Почему даже только что написанный код превращается в баласт?
И никакие палеативы типа "литературного", "быстрого", модульного или еще какого... ответа на него не дает.
ИМХО, в консерватории нужно что-то менять...
no subject
Date: 2008-07-10 04:22 pm (UTC)Мне кажется, условие "нетривиальное" тут лишнее. Тривиальность сама по себе ничем не плоха, и часто даже наоборот. А вот претензия на инновационность - как раз нехороший признак. Ага, в частности поэтому я предпочитаю учиться не новому, а хорошо развивающемуся старому. Вот правда, слово "хорошо" тут ключевое (emacs, скажем, развивается хорошо, а мозилла - плохо), а четкого определения ему я дать не могу.
А вот этого я не утверждал. Унаследованный код является балластом (да, если можно, пишите, пожалуйста, это слово с двумя "л", а то у меня "врожденная грамотность", и я дергаюсь; то же касается слов "паллиатив" и "инновационность") не по определению, а как правило.
Но - да, пожалуй, как правило таки сразу. И даже до того, как будет дописан. Потому что если его там достаточно немалое количество, он успевает показать проблемы в архитектуре еще в процессе его написания.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:с моей стороны
From:Re: с моей стороны
From:Re: с моей стороны
From:Re: с моей стороны
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:Убедили постороннего
Date: 2008-06-20 08:16 am (UTC)День(?) добрый.
С увлечением слежу за обсуждением. В своё время отказался от освоения эмакса со стандартными виндоаргументами: "не понятно, не привычно, не наглядно". И это при том, что в AutoCAD, например, мне изначально было проще работать через командную строку...
Не посоветуете ли Вы ресурс, с которого имеет смысл начать знакомство? Желателен упор на философию подготовки текста unGUI way, в идеале - специально заточенный вводный курс под людей, испорченных визуальными редакторами.
Re: Убедили постороннего
Date: 2008-06-20 12:14 pm (UTC)Философия негуевой подготовки текста, собственно, состоит в том, что мы пишем содержание текста, указывая смысловые выделения, а оформление производит программа, которая все равно лучше нас умеет это делать. Нам же должно быть удобно работать с содержанием и смысловой структурой текста. А верстать нам не нужно ни удобно, ни неудобно - никак. Ибо отвлекает от смысла.
Поэтому ввод в задачу для людей, испорченных визуальными редакторами, начинается с отбирания у них этих самых визуальных редакторов. Я бы рекомендовал вводный курс по LaTeX'у (любой) и неделю работы над ним в emacs, освоенном в размере его родного tutorial (добываемого из свежезапущенного емакса комбинацией Ctrl-H, t; через меню он, наверное, тоже добывается, но у меня меню отключено.) и никак не настроенного.
А вот по прошествии этой недели, когда парадигма "смысл отдельно, внешний вид отдельно" освоена, имеет смысл настраивать emacs по его же собственному info (C-h r) и изучать режимы редактирования, которые позволяют еще лучше отвлечься от разметки - рекомендованный тут где-то muse или режимы верстки для выбранного исходного формата документов. Ибо исходным форматом совсем не обязательно будет LaTeX, хотя для крупных работ по документации почему-то все равно все сходится именно к нему. Ну вот muse я не пробовал пока.
А заодно освоить org-mode (органайзер в комплекте, todo можно автомагически привязывать к той точке, где о нем было подумано, а потом видеть его в списке дел, назначать время и т.п.), работу с почтой из него же (у емаксовых почтовых клиентов свои тараканы, но почему-то они гораздо мельче, чем у специализированных гуевых, их меньше, а главное - большинство при желании таки можно удавить в смысле этого поста), и даже с шеллом. Конечно, до единства жестов по всему интерфейсу, как предлагалось Раскиным, это все не дошло, но гораздо ближе, чем у гуевых программ.
Впрочем, в том, что emacs - это такая операционная система, тоже есть свои недостатки.
Re: Убедили постороннего
Date: 2008-06-21 10:30 am (UTC)Например?
Re: Убедили постороннего
Date: 2008-06-23 11:12 am (UTC)И до последнего времени был далеко не реалтаймовой ОС. Асинхронное сетевое соединение появилось только в 22, и в результате сейчас большинство сетевого софта для него работают с сетью исключительно синхронно. А как следствие, архитектура у них такова, что и с шелловой прослойкой к сети они работают синхронно, хотя программу асинхронно запустить emacs умеет уже довольно давно.