Столлман проснулся

[vitus_wagner]

Почитал тут отчет о Software Freedom Day в Бостоне.

Обратил внимание на впечатление о речи RMS

Control has replaced Free Speech in Stallman’s the rhetoric. This is one of the most noticeable things I took away from today, that there has been a cultural shift from the way proponents of Free Software talk and communicate about the ideas and rationalities of Free Software principles. Although I’ve been picking up on the same advantages to using control language instead of freedom of speech in my own advocacy.

и

Miguel de Icaza “is basically a traitor to the Free Software community”

Блин, где был Столлман 10 лет назад, когда Иказа начинал свое предательство - проект GNOME.
Тогда RMS отзывался об Иказе с куда большим энтузиазмом. Mono - это фигня, это мертвому припарки.
Лицензионные и патентные проблемы где-то как-то преодолимы. А вот принципиальная проблема
Windows-подобного десктопа, который все делает за юзера сам, и если он что-то делает не так, хрен разберешься кто виновать - десктоп, hal или настройки конкретного дистрибутива.

В принципе, понятно что на протяжении многих лет control казалался естественным и неотъемлемым правом пользователя. Free Speech - это на самом деле как раз про control - это возможность изучить систему настолько, чтобы полностью её контролировать.

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

Заметим что последнее время Столлман также борется с проприетарным Javascript. Там в общем-то картина почти та же самая - код по определению открыт для пользователя, чай не флэш. А вот разобраться в нем далеко не всегда возможно.

Comments

[phd_ru]

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

[vitus_wagner]

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

[aceler.livejournal.com]

Это прекрасно можно сделать и в большом проекте, просто этого почему-то не было сделано.

[vitus_wagner]

В большом проекте это можно сделать только в рамках большой корпорации, где менеджер с кнутом за спиной каждого сотрудника стоит.

Если мы хотим чтобы система развивалась множеством независимых разработчиков, нам нужно рассчитывать на то,
что у любого из них вожжа под хвост попадет, и он будет развивать свою компоненту не туда.
Как скажем Шиллинг с cdrecord-ом делает. Но cdrecord это как раз маленькая компонента с четко специфицированными интерфейсами. Поэтому сделать drop-in replacement - wodim оказалось несложно.

[dzz.livejournal.com]

В Apache foundation, вроде, не стоит... В PHP не стоял, когда я в нём участвовал. Самоорганизация иногда делает чудеса, в особенности, при наличии грамотного лидера-архитектора, определяющего спецификации интерфейсов.

[vitus_wagner]

То-то чем дальше, тем больше серьезных сайтов отказывается от apache в сторону lighttpd и ngiix.
Про то, сколько лет в этом Apache DAV до работоспособного состояния довести не могут, я уж вообще молчу.

[dzz.livejournal.com]

Неработающий DAV в апаче - это, IMHO, проблема нехватки ресурсов разработки в core team-е. Кстати, код открыт, архитектура достаточно прозрачна, напиши как надо :)

[sa-chernomor.livejournal.com]

от апача отказываются там, где нужно раздавать статику - lighttpd и nginx это умееют делать более эффективно.
а для динамики используют либо fast cgi, либо все тот же апач, который стоит за lighttpd или nginx

[potan.livejournal.com]

Мне очень нравится эта "маленькая компонента", которую чаще используют для сканирования SCSI-шины, а не для записи дисков :-).

[phd_ru]

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

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

Так что создание таких проектов такими командами откладывается до эры коммунизма.

[vitus_wagner]

Как раз наоборот. Это проекты типа GNOME со сложным взаимодействием между компонентами можно сделать работоспособными только в таких условиях.

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

[potan.livejournal.com]

Если я правильно понимаю, то GNOME именно и стремится разбить десктоп на много маленьких изолированных компонент. И dbus нужен именно для этого.

[vitus_wagner]

Это вы неправильно поняли. Если бы это было так, как вы поняли, в природе не существало бы libdbus, а сообщения от программы к программе писались бы посредством fprintf(bus_socket,"%s %s "%s"\n",another_app,command ,parameter)

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

[potan.livejournal.com]

То есьт беда GNOME в том, что libdbus не смогли сделать стандартным.
fprintf(bus_socket,...) - не лучший способ обмена сообщениями. Защита от блокировки, обработка ошибок, формальная верификация протокола - фсе эо будет слишком сложно при таком низкоуровневом подходе.

[vitus_wagner]

Беда GNOME в том, что протокол DBUS не смогли сделать ЧЕЛОВЕКОЧИТАЕМЫМ.
Чтобы можно было к dbusd коннектиться если не telnet-ом, то netcat-ом.

Защита от блокировок, обработка ошибок и прочие мелочи АБСОЛЮТНО не зависят от того, бегают ли по протоколу удобочитаемые текстовые сообщения, или бинарные последовательности непонятного формата.

Вот SMTP, IMAP и HTTP прекрасно обходятся человекочитаемым форматом.

Кроме того, там не смогли четко позиционировать D-BUS. Область применения которой ограничена небольшими и редкими сообщениями. А по ней сейчас чуть ли не многомегабайтные аттачменты к электронной почте собираются гонять.

Ну и естественно, идея типизированных сообщений для такой шины - это бред.

И они еще гордятся тем, что у них там не XML. (хотя, конечно, xml там был бы не очень на месте. Там должны аналоги shell-овских команд бегать).

[potan.livejournal.com]

Сообщения между программами не обязательно меленькие. Так по SMTP передаются данные в MIME-обрамлении, которое читабельно не более чем исходники OpenOffice.
Лично я предпочитаю по возможности работать не через telnet, а через команды shell. Хотя бы такие ( echo '(select)' ; sleep 5 ; ) | telnet localhost 2244 :-).

[vitus_wagner]

Сообщения между программами не обязательно меленькие.
Ну так и не надо немеленькие сообщения через общую шину гонять.
D-Bus это аналог instant messenger. Что делают instant-messegner-ы, если надо передать большое сообщение?
Договариваются о том, как установить ПРЯМОЕ соединение и передают файл по нему. В современном internet это не всегда возможно, поэтому xmpp предоставляет возможность in-band file transfer.
Но у приложений внутри одной сессии этой проблемы нет. У них есть по крайней мере общий X-сервер, через который можно гонять большие объемы данных.

[potan.livejournal.com]

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

[vitus_wagner]

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

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

Вообще за идею "давайте все делать прозрачно, не думая о размерах" мне хочется немедленно убивать с особой жестокостью. Потому что именно из-за идиотов, проводивших эту идею в графические библиотеки у меня на N800 нет ни одного графического вьюера, способного просмотреть картинку 20000x15000. И это на целых 128 мегабайтах памяти. Хотя в свое время существовали программы, позволявшие такие картинки смотреть, масштабировать и панорамировать под DOS в real mode, причем в режимах VESA заметно превосходящих по разрешению жалкие 800x480 N800.

[potan.livejournal.com]

nip2 под него не собирается?

"Читать глазками, писать ручками" можно на очень разных уровнях. Почему это уровень telnet, а не tcpdump?

[kostix.myopenid.com (from livejournal.com)]

XML в d-bus есть: там можно позвать нечто вроде "получить интерфейс такого-то объекта на шине", и описание интерфейса приходит в виде XML (http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format). Другое дело, что это можно не считать частью протокола. Вопрос сложный.

[kisa-i-osya.livejournal.com]

Ох, не знаю, не знаю. Я в свое время немало озадачивался вопросом "нафига в GNOME так все упрощают". HIG и юзабилити -- оно понятно, но это явно только часть правды ;-) Другая ее часть заключается в том, что сокращается число сущностей -- и делается это явно не от хорошей жизни.

[beldmit.livejournal.com]

Извини, из "Конца радуг" вспомнилось - на кубике надпись "здесь нет ничего, что можно было бы починить человеческими руками". И когда герой его таки разломал, на внутренних кубиках было написано то же самое.

[vitus_wagner]

Ну, до этого уровня мы еще не доросли. Это разве что операции процессора у нас такие кубики.

[savant-d.livejournal.com]

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