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

[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

[vitus_wagner]

Это мне люди, агитирующие за Qt втирают про "высокую производительность"?
Почему-то как раз там, где медленные процессоры и ограниченная память используются всякие QNX и VxWorks, которые микроядерные. И обеспечивают гарантированное время отклика. А там где гигагерцы и гигабайты используются монолитные ядра и системы то-о-ормозят.

[vitus_wagner]

Ну, когда мне понадобилось tun-драйвер к солярису поправить, у меня ушел на это рабочий день.

[potan.livejournal.com]

Гарантированное время отклика не обязательно означает максимальную производительность.
Просто обеспечить его могут не многие программисты и у них эффективные программы получаются "на уровне рефлексов".

[karpion.livejournal.com]

Почему-то как раз там, где медленные процессоры и ограниченная память используются всякие QNX и VxWorks, которые микроядерные. И обеспечивают гарантированное время отклика.

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

А там где гигагерцы и гигабайты используются монолитные ядра и системы то-о-ормозят.

Мне почему-то кажется, что тормозят не ядра, а приложения. Взгромоздите ту же самую Qt на QNX и посмотрите.

[vitus_wagner]

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

От противопоставления работа-игра зависит совсем другое.

Игра - это когда мы получаем удовольствие от преодоления сопротивления оппонента. В том числе когда оппонентом является компьютер.

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

[vitus_wagner]

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

[vitus_wagner]

Другое дело, что для Вас или меня предмет работы, так или иначе, текст.
А вот не надо распространять на меня ваш ограниченный опыт. Для меня пять лет основным предметом работы были карты.

[potan.livejournal.com]

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

[karpion.livejournal.com]

Удивительно, как это его ухитрились придумать на пять лет раньше, чем GUI.

Видимо, потому что идея "обработки событий" в то время витала в воздухе - даже я подумывал о чём-то таком. ООП ориентирована на обработку событий, а GUI на ней строится.

Хотя вообще-то, GUI можно строить и без обработки событий (по кр.мере, свести обработку событий к минимуму). Достаточно посмотреть на работу Web/CGI-сервера: он же не обрабатывает каждый клик мыши в созданное им окошко. Вот так и надо строить работу приложения с операционкой: приложение формирует некое описание содержимого окна (причём не только видимой в данноый момент части, а вообще всего отображаемого документа) и передаёт указатель на описание операционке. Операционка же сама обрабатывает скроллинг и масштабирование. А обработка событий предусмотрена для тех случаев, которые операционка обрабатывать не умеет.

все равно поток событий остается.

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

[vitus_wagner]

Там где имеется GUI, нужно именно гарантированное время отклика. Поскольку именно оно обеспечивает максимальную производительность ЧЕЛОВЕКА, сидящего за компьютером.

А maximal throughput - это к серверам.

[tzirechnoy.livejournal.com]

>ни разу не приходилось что-то наследовать,

Это скорее всего потому, что ты им пользовался. Кстати, это тожэ свойство ООП в применении GUI: разработчики библиотек практически всегда используют ООД на полную катушку, в то жэ время как пользователи чаще всего — нет (или используют, но лучшэ бы они чем-нибудь другим при этом занялись).

>Метавидгеты писать приходилось.

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

[karpion.livejournal.com]

Мышью нажимают в русскоязычный пункт меню, а пишут иностранные команды.

Что мешает сделать русские алиасы ко всем командам?

[vitus_wagner]

Так приложения у нас по той же схеме организованы. Развесистые API, многомегабайтные разделяемые библиотеки (помещающиеся в общее адресное пространство, т.е. аналоги модулей монолитного linux).

[vitus_wagner]

А GNU Radio у нас еще не доросло до того уровня, чтобы на нем можно было bluetooth-протокол реализвоывать?
Если доросло, то это идеальная платформа для снифферов.

[roman_sharp.livejournal.com]

Боюсь, мне трудно понять это в таком изложении...

Не могли бы Вы указать пример - ну вот, скажем, в том же Gnome desktop?

[vitus_wagner]

Дело в том, что "лица" у компьютера пока нет. То что есть - злобная оскаленная морда, а не лицо.
Компьютер по идее, это программируемое устройство обработки информации. Сказал ему, что тебе надо, и он это делает. Более высокоуровневого интерфейса, чем скрипты для этого пока, к сожалению не придумали.

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

[vitus_wagner]

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

[potan.livejournal.com]

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

[tzirechnoy.livejournal.com]

Это какие трансформацыи? Афинные преобразования+тени(сдвиг и разный цвет)+anti-aliasing?

Легко и непринуждённо. В том числе на голом X11R6 (через XIE). Кстати, оно и сейчас обычно без клиентской отрисовки делается через векторный Xrender.

[tzirechnoy.livejournal.com]

Кстати, афинные трансформацыи шрифтов были начиная по-моему с X11R5. Как делать описано в xlfd.ps. Но таки да, всякие дэ-иказы и дажэ по-моему Паккарды об этом не подозревают.

[tzirechnoy.livejournal.com]

При чём здесь типакомпиз? Типакомпиз вообще к месту отрисовки шрифтов не имеет никакого отношэния. И, кстати, он вполне клиент-серверный, без каких-то прибабазов на эту тему вроде.

[duke-igthorn.livejournal.com]

Расскажите. Хотя бы простенький пример с иксовым API!

В xrender нет ни слова о серверных шрифтах. Там есть глифы, но это другое.

[tzirechnoy.livejournal.com]

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

[duke-igthorn.livejournal.com]

Про компиз, конечно, я сгоряча, он тут не при чем. Удобный и предсказуемый рендеринг тулкитов - вот основной двигатель...

[duke-igthorn.livejournal.com]

http://www.linux.ie/articles/interviews/levien.php

This is a fundamental design flaw of X. The abstract concept of "font" contains both glyph shapes and metrics. But the X11 implementation of "font" only contains glyph shapes. Further, the connection between between the X11 server and client has no way to transmit either glyphs or metrics, in either direction. This confluence of limitations _forces_ the glyphs to live on the server side, and the metrics to live on the client. There's no really clean, general way to make sure the two are in sync. Indeed, if you run AbiWord over a plain X terminal, the fonts just fail.
This didn't happen because the X people were stupid. At the time the X font mechanism was being worked on, its designers genuinely believed that Display PostScript would take over the world. Applications that needed only simple text display would use the existing X mechanisms, while applications that required high quality text would use DPS. Well, this didn't end up happening, so there's a void.
One way out of the bind is just to render the text on the client side. This has the advantages of reuniting the glyphs with their font metrics, and also allows fancier stuff like antialiasing. There is a performance hit compared with doing it in the X server, but it's not too bad on modern hardware running locally. So that's where I think this should go.
I'm in touch with Jim Gettys and other X people about a possible X extension for antialiased graphics, and that would certainly include a reasonable mechanism to do server-side rendering of high quality text.

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