Эрик Реймонд: «GPL больше не нужна»

Убиццо. Вот это я понимаю блоат!

Но чтоб дойти до конца, попробуйте оценить, насколько FIFO (c кучей переключений контекста в ядро и обратно!) будет тормозить работу в случае HD контента.

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

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

> А я-то, наивный, думал, что GPL — это такая прагматичная лицензия, обязывающая других патчи выкладывать :)

Только в том случае если MS признается, что взяла GPL-код, пока они утверждают, что не брали.

> Убиццо. Вот это я понимаю блоат!

Тебе показали как сделать не просто лого, а анимированное лого, а ты недоволен :-(

1. Это не блоат. Это классический юникс-вей, который у меня вызвает восхищение. Именно -- mplayer делает ровно одно дело -- показывает аудео/видео. Но делает это исключительно качественно -- твоя фантазия о показе лого воплощается без проблем.

2. Это модуль. Ты можешь дописать еще один (правда он будет под ГПЛ)

> Но чтоб дойти до конца, попробуйте оценить, насколько FIFO (c кучей переключений контекста в ядро и обратно!) будет тормозить работу в случае HD контента.

Я так полагаю, что оверхед все равно составит проценты от затрат проца на показ 1 кадра, и пожет даже от затрат на чтение видеофайла с диска (или ты предлагаешь и видеофайлы скармливать mplayer-у не через файловый дескриптор, а по иному??? :-)

> И давайте не будем говорить о мире, где весь софт как мплейер - тема построения царства божия на земле мне не очень интересна.

И давайте не будем говорить о мире, где весь софт под GPL - тема построения царства божия на земле мне не очень интересна.

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

Это зависит от задачи. Но мое понимание юникс-вея -- это предоставлять 3 вещи -- С(++) АПИ, ком. строчный интерфейс, гуй. Если пропустить п.2, то получится винда или макось.

> Я так полагаю, что оверхед все равно составит проценты от затрат проца на показ 1 кадра
Переключение контекста в ядро и обратно - это очень дорого. А тут еще и процессы разные, так что кэш проца с нехилой веростностью не справится. Даже если это будут "проценты" - на системе, работающей "на пределе" (что часто происходит в случае HD) это чревато проблемами с качеством вывода.

> и пожет даже от затрат на чтение видеофайла с диска
Да щаз. Чтение осуществляется довольно крупными блоками, там в ядро лезут один раз на каждый блок (в рамках одного процесса, заметьте!)

> И давайте не будем говорить о мире, где весь софт под GPL
А кто о нем говорит??? Я вообще этой темы не касался. Я говорил о том, что попытки сбежать от GPL через командную строку создают проприетарщику серьезные технические проблемы. Причем проблемы есть даже в случае таких очень раздутых по интерфейсу утилит как mplayer. А если утилита не такая дружественная, получается и того хуже, сначала надо потратить усилия (возможно, немаленькие) для обеспечения этого всех необходимых возможностей через этот самый интерфейс (да еще и с риском не уложиться по параметрам производительности, ибо inproc calls принципиально и сильно дороже outproc calls, при любом интерфейсе).

Говорят, однако, что в современной макоси все скритуется, а в старой не было даже понятия stdin/stdout (не говоря уже об stderr)

> С(++) АПИ, ком. строчный интерфейс, гуй. Если пропустить п.2, то получится винда или макось.
Макось только на картинках видели? Ни в одном из обычных юниксов нет аналога эпплскрипта. Который как способ организации межпрограммных интерфейсов (на десктопе) в каком-то смысле сильно удобнее классического унихового шелла.

Да, командная строка необходима, чтобы пользователю было удобно и гибко. Но она совершенно не обязана предоставлять всю ту гибкость, которая доступна через C API. Более того, в случае функционально богатой софтины полная поддержка _всех_ возможностей через командную строку скорее всего приведет к кошмару. Только представьте себе утилиту, обеспечивающую через командную строку доступ ко всем функциям libc/xlib/gtk/qt/...

Правда эпплскрипт сам по себе некрасив и там нехватает функционала иногда.

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

Мне уже интересно -- ты веришь в то, что сам пишешь?

1. Если лого анимированное, то генерация лого, копирование лого и наложение его поверх с альфа-каналом займет больше ЦПУ, чем переключение контекста.

2. Если лого статическое, то картинка из ФИФО прочтется 1 раз (я не проверял, но это логично) и никаких переключений.

В кэше проца довольно быстро останется только работающий код, который одинаков как в случае вызова внутри процесса, так и через ФИФО.

___________________________________

З.Ы. Я сам любитель эффективных решений, но сейчас на первом плане стоимость разработки.

> Макось только на картинках видели?

Я сразу же после своего поста поправился -- я про старую макось говорил.

> Ни в одном из обычных юниксов нет аналога эпплскрипта.

Есть ли существенная разница с КДЕ-шным DCOP?

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

Каждый боится того косяка, в котором что-то прищемил. Я прав?

Кстати, вот тест на профпригодность: является ли вывод команды ps -Alf однозначно разбираемым? А команды cp -v?

> Только представьте себе утилиту, обеспечивающую через командную строку доступ ко всем функциям libc/xlib/gtk/qt/

При условии что модули установлены, это perl -We '...'

Хотя это уже наверно бесполезный флейм

>> Если есть командно-строчная версия, то там эта проблема как-то решается.
> У вас куча усилий будет уходить на сериализацию и десериализацию данных.

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

> Другое дело, что язык программирования должен быть таким, чтобы внутри него можно было иметь удобство комстроки в "нормальном АПИ". Ни один из изветных мне языков это не дает.

Тебе shell незвестен? ;)

> Да, командная строка необходима, чтобы пользователю было удобно и гибко. Но она совершенно не обязана предоставлять всю ту гибкость, которая доступна через C API.

Давай сойдемся на том, что ком.строка = 95% от С АПИ, и тогда получится что GPL = LGPL c точность 95%.

> ты веришь в то, что сам пишешь?
Я _знаю_, что межпроцессные интерфейсы - дороги. И в случае, если требуется передача больших объемов - они сразу проседают без специальных мер (типа шаренной памяти).

> то генерация лого, копирование лого и наложение его поверх с альфа-каналом займет больше ЦПУ, чем переключение контекста.
Это надо доказать. С учетом того, что наложение делают обычно аппаратно. А вот расходы на постоянное запихивание картинки в фифо, чтение ее оттуда, да еще и на смену контекста (это ведь даже не шаренная память!) - это довольно дорого.

> то картинка из ФИФО прочтется 1 раз
Вот это вызывает сомнения. Потому что в тексте примера они там постоянно в фифо гонят всякую ерунду.

> но сейчас на первом плане стоимость разработки
Согласен. Именно поэтому удобнее безо всяких извращений использовать нормальный API. Если хочется еще большей скорости - взять байндинг к скриптовым языкам. Но не запихивать себя в прокрустово ложе старого унихового интерфейса командной строки.

> Каждый боится того косяка, в котором что-то прищемил. Я прав?
Не совсем. Я слишком часто тусуюсь вблизи этого косяка, чтоб позволить ему что-то прищемить;)

> является ли вывод
Сейчас не скажу - линуха под рукой нет.

> Тебе shell незвестен?

Речь идет немного о другом. О языке программирования с достаточно вариабельным синтаксисом (в шелл это есть) и при этом достаточно низкоуровневом, чтобы можно было из него дергать непосредственно C API without FFI.

> perl -We '...'
Э, не, это читерство;)

> Лень намекает нам, что ваять либу на том месте, где можно грепнуть, неразумно.
Где можно грепать - грепайте на здоровье. Но не считайте, что в общем случае удастся решать сложные задачи таким образом.

> что ком.строка = 95% от С АПИ
Объясните мне смысл знака "=" в этом выражении. Долженствование? Реальность? Мечта?

> Я _знаю_, что межпроцессные интерфейсы - дороги. И в случае, если требуется передача больших объемов - они сразу проседают без специальных мер (типа шаренной памяти).

Более того, мне например бы хотелось маппить кусок памяти по одинаковым адресам в разных процессах, чтобы указатели между ними передавать без изменений :-)

Но я вел речь о программах, ориентированных на пользователя, а не на сервер. Ибо на серверерном софте все и так пользуются либами LGPL, а не GPL.

Давай таки сойдемся на том, что ком.строка = 95% от С АПИ, и тогда получится что GPL = LGPL c точность 95%, и прекратим данную тему.

>> Каждый боится того косяка, в котором что-то прищемил. Я прав?
> Не совсем. Я слишком часто тусуюсь вблизи этого косяка, чтоб позволить ему что-то прищемить;)

Ну значит боишься этого :)

>> является ли вывод
> Сейчас не скажу - линуха под рукой нет.

Но задумайся. И всем остальным читающим предлагаю :)

>> что ком.строка = 95% от С АПИ

> Объясните мне смысл знака "=" в этом выражении. Долженствование? Реальность? Мечта?

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

>> Лень намекает нам, что ваять либу на том месте, где можно грепнуть, неразумно.
> Где можно грепать - грепайте на здоровье. Но не считайте, что в общем случае удастся решать сложные задачи таким образом.

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

> по одинаковым адресам в разных процессах
Фигассе наглость!;)

> ориентированных на пользователя, а не на сервер
Дело не в ориентации, а в характере интерфейса.

Кстати, еще одна крайность - представьте себе реализацию графики через командный интерфейс с функцией "закрасить точку с координатами (неразборчиво) цветом (неразборчиво)". Оверхед представляете?;) Отдельно представить - с демонизацией и (!!!) без оной.

>> perl -We '...'

> Э, не, это читерство;)

Но ведь работать будет? и удобно в режиме REPL

> Ну значит боишься этого :)
Это ж естественно?;)

>> Тебе shell незвестен?
> Речь идет немного о другом. О языке программирования с достаточно вариабельным синтаксисом (в шелл это есть) и при этом достаточно низкоуровневом, чтобы можно было из него дергать непосредственно C API without FFI.

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

> В линуксе я думаю это реальность.
Это _очень_ сильная лесть линуксу. Пройдитесь про /usr/lib и посмотрите, у какого процента есть аналоги для командной строки. Только без читерства с запуском через скриптовые языки.

> Кстати, еще одна крайность - представьте себе реализацию графики через командный интерфейс с функцией "закрасить точку с координатами (неразборчиво) цветом (неразборчиво)". Оверхед представляете?;) Отдельно представить - с демонизацией и (!!!) без оной.

Чем это отличается от программы рисования графиков на питоне? Текст есть, команды на закраску есть, скрипт можно скормить на stdin.

> Но и не считайте, что сложные задачи таким способом решить нельзя.
Нельзя. Иначе это не сложная задача (должен ли я привести определение "сложной задачи по сву"?:)

>> Но и не считайте, что сложные задачи таким способом решить нельзя.
> Нельзя. Иначе это не сложная задача (должен ли я привести определение "сложной задачи по сву"?:)

Изволь. За определение "задача, которая не может быть решена в стиле 'скомбинировать несколько известных алгоритмов'" буду бить подсвечником :)

> Кстати, еще одна крайность - представьте себе реализацию графики через командный интерфейс с функцией "закрасить точку с координатами (неразборчиво) цветом (неразборчиво)". Оверхед представляете?;)

Такая прога имеет право на жизнь (в смысле была бы иногда полезна), но именно ее я вряд ли юзал в роли мплеера. Я бы юзал несколько более специализированную версию, и даже предположу, что такого класса проги обязательно будут иметь сопровождающие либы под LGPL (libSDL например)

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

ЗЫ Хотя да, границу трудно установить четко.

> За определение "задача, которая не может быть решена в стиле 'скомбинировать несколько известных алгоритмов'" буду бить подсвечником :)
У самих подсвечники найдутся =}-|

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

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

До абсурда можно довести что угодно, исключений нет. Что ты хотел этим показать?

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

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

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

> Это _очень_ сильная лесть линуксу. Пройдитесь про /usr/lib и посмотрите, у какого процента есть аналоги для командной строки. Только без читерства с запуском через скриптовые языки.

Мне не понятно, как это автоматизировать -- это все руками придется делать. Есть там либы, которые вряд ли имеют доступ из ком. строки -- но это по причине того, что они чисто технические, типа /usr/lib/libthread_db.so

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

Не знаю как в гноме, а в КДЕ почти все можно делать через DCOP (и значит через комстроку). Например, получить селекцию конкверера или спрятать его окно.

Кто б спорил. NP - она и в пайпе NP, и вне пайпа.

> и при этом не обеспечивают чисто технические моменты типа нитей
Мне не очень понятно это разграничение. Вот, например, gobject - это куда?

> Не знаю как в гноме,
В гноме с этим сильно хуже.

> Изначальный мой тезис - что обход GPL через создание утилит командной строки хоть и возможен, но в общем случае неудобен коммерсантам, которые не могут укусить свой локоть и украсть свободный код.

Я в своей проприетарной деятельности этот обход последний раз использовал не ранее чем сегодня: нагло и без нарушения лицензии использую GNU awk через командную строку :)

> Изначальный мой тезис - что обход GPL через создание утилит командной строки хоть и возможен, но в общем случае неудобен коммерсантам, которые не могут укусить свой локоть и украсть свободный код.

А мой ответ -- там где это неудобна, эта либа и так уже распостраняется под LGPL. Так что чистая GPL (а не LGPL) в общем-то смысла имеет очень мало.

> А мой ответ -- там где это неудобна, эта либа и так уже распостраняется под LGPL. Так что чистая GPL (а не LGPL) в общем-то смысла имеет очень мало.

Я тебе раскрою Планъ Столлмана, только никому не рассказывай: подсадить всех на LGPL-либы, а потом яростно рекомендовать авторам либ сменить лицензию на GPLvN :)

Да мы ж сошлись на том, что либов под GPL практически нет%)

Да, подумайте о смысле GPL в применении, например, к самбе. Это очень хороший и показальный пример. И это не библиотека.

А я пока пошел домой...

> обход GPL через создание утилит командной строки хоть и возможен, но в общем случае неудобен

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

Вот пример.

Нужно распарсить логи, большие, повыдёргивать некоторые поля отобрать из них нужные и прочая обработка. Написан скрипт на sed, grep, awk. Считал 8 часов. Потом втянули данные в sql. Запрос выполняется 8 секунд.

А вроде конструктор на пайпах должен был рулить.

>> и при этом не обеспечивают чисто технические моменты типа нитей
> Мне не очень понятно это разграничение. Вот, например, gobject - это куда?

Разумеется, ответ "в топку" не принимается? :)

GObject или gtk --- это не конечные сущности, которые может возникнуть необходимость "дёргать". Потому они тут не к месту.

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

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

> Нужно распарсить логи, большие, повыдёргивать некоторые поля отобрать из них нужные и прочая обработка. Написан скрипт на sed, grep, awk. Считал 8 часов. Потом втянули данные в sql. Запрос выполняется 8 секунд.

Тут решена одна и та же задача совершенно разными способами, отсюда и разница в скорости. Перепиши один-в-один "скрипт на sed, grep, awk" на си и увидишь, что быстрее он станет максимум раза в полтора.

> Мне не очень понятно это разграничение. Вот, например, gobject - это куда?

Ну во-первых он и так под LGPL.

А по сути -- я думаю это техническая либа, так как вряд ли кому-то потребуется передать куда-то именно объект gobject. Вот создать из комстроки формочку с тремя полями ввода и двумя кнопками и поскриптовать их -- это уже другое дело.