Linux ”perf” ускорили в 60 раз

[gresolio]

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

Свободные лицензии действительно являются эффективными, а корпорастам это как кость в горле, и в последнее время вырабатывают всё более изощренные техники по захвату контроля. Рекомендую к чтению:
* Why Open Source Misses the Point of Free Software
* Why you shouldn't use the Lesser GPL for your next library

[andreymal]

это довольно эффективный способ

С MIT/BSD-подобной лицензией было бы намного эффективнее...

[leotsarev]

Ричард Сталман требует включения в лицензионные соглашения оговорки «а также на таких условиях, как Ричард Сталман захочет позже». Кто тут ещё вырабатывает техники по захвату контроля.

Статья про LGPL очень занимательна, но в реальности выбор между GPL/LGPL давно не стоит, просто все выпускают библиотеки на BSD-like лицензиях и все.

[gresolio]

Не всё так однозначно, а так же во многом зависит от того, по какую сторону баррикад вы находитесь. BSD-like лицензия удобней таки для использования совместно с закрытым проприетарным софтом, но она не дает никаких особых гарантий: это как безвозмездный подарок, за который многие могут поблагодарить, а некоторые используют и хрен положат, могут даже не вспомнить. Канонический пример — это операционка Sony Playstation основанная на FreeBSD, что получило сообщество взамен?

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

[leotsarev]

Это все очень интересно, только новые визионерские и крутые проекты с лицензией копилефт не набирают всемирной известности. Последним был Linux kernel

[gresolio]

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

[leotsarev]

С тех пор родилось куча всего интересного. Например, родился свободный компилятор clang и разгромил в одну колонку копилефтный GCC (с тех пор копилефтных реально важных проектов осталось один). Вопреки предсказаниям о том, что BSD-like лицензии не приводят к развитию.

[gresolio]

Не знаю, что там за предсказания о развитии, но так голословно заявлять что clang разгромил gcc не стоит. Пермиссивная Apache License 2.0 как раз таки на руку корпорастам.

[leotsarev]

А в чем это РЕАЛЬНО на руку? Покажите проект, которому BSD лицензия помешала, его захавали «корпорасты» (ну и сленг конечно).

[gresolio]

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

В современном мире «open source» используется большими корпорациями в основном лишь для пиара и своих интересов, очень далеко от тех идей и принципов которые подразумевает RMS.

Тут вопрос философский, и если вам нравится дивный проприетарный мир — то мне нечего больше добавить. Я лично склоняюсь к миру без DRM и возможностью контроля над собственными железяками/софтом.

[leotsarev]

А конкретику приведете?

[gresolio]

Меня бесят закрытые устройства в ежедневной жизни, например смартфон, пк, читалки, плееры, «умные» гаджеты, тв, etc.

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

[leotsarev]

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

Окей, давайте взглянем на андроид. Какие компоненты там были под пермиссивной лицензией и благодаря этому были захвачены «корпорастами» ( ну и сленг) и закрыты?

[gresolio]

Почему это были? До сих пор остаются под пермиссивной. Apache 2.0 там является предпочтительной лицензией, также есть BSD и MIT, за исключением ядра естественно.
source.android.com/setup/start/licenses

Какие именно? Да практически всё, можете взглянуть сами при желании:
android.googlesource.com

Например такие ключевые компоненты:
art (Apache 2.0), dalvik (Apache 2.0), bionic (BSD), toybox (BSD), BlueDroid (Apache)

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

Считаете пермиссивные лицензии не способствует корпорации удерживать контроль над этим всем добром?

[WicRus]

Интересно более подробное описание юридического бага. Не все знаю расхождения в GPL по версиям.

[leotsarev]

GPLv2 и GPLv3 несовместимы из-за дополнений в GPLv3 (запрета тивоизации). Для совместимости v3+ библиотекой нужно, чтобы либо другая из библиотек была лицензирована одновременно под v2 и v3, либо на условиях v2+ (то есть v2 или любая последующая версия).

Perf, как и все проекты, связанные с ядром Linux, отказался включать в свое лицензионное соглашение оговорку «или как захочет Ричард Столман», так что он строго v2.

[gudvinr]

Почему вместо libbdf в этом случае не использовали альтернативы? elfutils, в котором есть libdw, как раз под GPLv2+ лицензирован.

[Halt]

Проблема только в том, что perf record очень медленно работает под Debian по юридическим причинам.

Все же perf report а не record

[alexeyrom]

который предложил написать для addr2line долгоживущий процесс типа talk-through-a-pipe, примерно так

Если я правильно понял, ровно наоборот. Это то, что perf делает сейчас. А писать для addr2line ничего не надо, долгоживущий процесс и общение с ним через stdin/stdout это и есть его обычный режим работы.