LINUX.ORG.RU

Вышел LLVM 2.8

 , , , ,


0

0

Спустя полгода активной разработки анонсирован выход версии 2.8 набора компиляторов LLVM , распространяемых по условиям BSD-подобной лицензии UIUC. Одновременно вышли и обновления подпроектов LLVM: компилятора C/C++ — Clang, модифицированной версии GCC 4.2.x (использует LLVM для генерации кода) — llvm-gcc, плагина для GCC 4.5 (и выше) — dragonegg.

Наиболее значимые изменения:

  • в основной проект вошел отладчик LLDB;
  • другим дополнением проекта стала замена libstdc++ — совместимая с C++0x стандартом библиотека libc++;
  • LLVM Machine Code (MC) — подсистема для поддержки ассемблирования, дизассемблирования и обработки бинарных форматов файлов (подробности в блоге);

    К сожалению, вышеперечисленные новшества реализованы в LLVM 2.8 только для платформ Mac OS X (x86 и x86-64).

  • llvm-diff для семантического сравнивания .ll-файлов.

В числе других изменений можно отметить:

  • оптимизация внутренних функций работы с памятью;
  • более эффективная отладка за счет генерации метаданных для отладчика в режиме реального времени;
  • более эффективная оптимизация циклов, вложенности функций (inlining), -loweratomic pass;
  • Clang теперь поддерживает ключи -momit-leaf-frame-pointer, -ffunction-sections, -fdata-sections;
  • значительно улучшен аллокатор регистров (особенно для -O0), возможен выбор алллокатора (в зависимости от ключа -O) при использовании ключа -regalloc=default, также будет задействованы SSE-регистры;
  • множество процессор-специфичных оптимизаций для платформ ARM и x86 (SSE, AVX, NEON).

Просмотреть полный список изменений (также по ссылке доступен и список нерешённых проблем выпуска).
Ознакомиться с материалами конференции разработчиков LLVM, прошедшей перед выпуском.
Загрузить source-tarballs.

>>> Сайт проекта

★★★★★

Проверено: hibou ()
Последнее исправление: MuZHiK-2 (всего исправлений: 3)

Ответ на: комментарий от Vudod

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

Если бы она мешала продавать только чудой труд... а часто она мешает продавать свой

annulen ★★★★★
()
Ответ на: комментарий от namezys

>Вроде результат компиляции кода может даже кэшироваться.

это и с gcc можно делать (ccache) :)

annulen ★★★★★
()
Ответ на: комментарий от anonymous

>У меня 265 МБ ОЗУ, селерон и гента.

плохо совместимые вещи)

Собираю с использованием GCC — всё тормозит.
Собираю с использованием clang — всё тормозит гораздо меньше.

мб в первом случае все тормозит из-за фоновой компиляции генты, которая с gcc более ресурсоемка?

annulen ★★★★★
()
Ответ на: комментарий от namezys

>> То, что условия лицензии не утроили Яббл - личные половые проблемы Яббла.

Не спорю. Но нам от этого лучше.

Чем лучше? Что яббл взяд LLVM под крыло? Это да, и за это надо сказать спасибо GPL %)

Скажи за это спасибо жопсу.

За то, что NEXTStep закрыт? Это их право.

Безусловно, но благодарность ему не за это...

За то, что open source не захотел реализовать совместимую библиотеку?

...а за то, что совместимую бблиотеку запретили выпускать.

tailgunner ★★★★★
()
Ответ на: комментарий от iZEN

портирование уровня смены версии в описательном файле сборки ? оно и так собирается без каких-либо проблем.

Sylvia ★★★★★
() автор топика
Ответ на: комментарий от iZEN

Предположим, по договору имущественные права на код

Код какого рода: исходный текст, бинарный код, конечный продукт?

На исходный код.

Имущественные права точно отчуждаемы.

aist1 ★★★
()
Ответ на: комментарий от namezys

у меня остаются только неимущественные права, которые неотчуждаемы. Хватит ли их, чтобы сменить лицензию?

нет

по этой логике получается, что для смены лицензии нужны имущественные права, так?

aist1 ★★★
()
Ответ на: комментарий от aist1

> по этой логике получается, что для смены лицензии нужны имущественные права, так?

Смотри, ты передал все права, кроме неотчуждаемых, так?

Значит у тебя остались только:

а) Авторство — право называться автором;

б) Право на имя — можешь диктовать, назвать тебя именем, псевдонимом или вообще распространять произведение анонимно;

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

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

Всё остальное уже не твоё.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

не мог бы ты прояснить, на что попал покупатель в этом случае?

и еще, может кто следил... под давлением чего FSF пошла на включение механизма плагинов в gcc?

aist1 ★★★
()
Ответ на: комментарий от aist1

> не мог бы ты прояснить, на что попал покупатель в этом случае?

Нельзя законно обнародовать произведение без согласия автора. Более того, автор может запретить это навечно (право бессрочно) в завещании, например.

Возможна ситуация, когда ты разработал ПО, но никому его целиком ещё не показывал («демки частей – цитаты» не считаются), затем продал права и умыл руки. :)

> под давлением чего FSF пошла на включение механизма плагинов в gcc?

Сообщества пользователей. Очень многим людям нужны плагины, без них приходится править сам gcc, постоянно поддерживать свой форк. С плагинами будет немного проще: придется только отслеживать изменения API, который собираются регулярно специально ломать. RMS до сих пор боится, что кто-то сможет использовать фронтенд без бекенда (и наоборот) или оптимизировать промежуточное представление. Можно подумать, и так никто этого не делал :)

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

А кто и когда это делал?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> А кто и когда это делал?

Достаточно прочитать тему, чтобы узнать как минимум об одном проекте: llvm-gcc :)

Также легко узнать о edoc, gcc-xml, milepost, и так далее… Чуть сложнее подумать, в каких случаях людям нужно вытащить из gcc семантику.

Я тебе даже покажу воплощение самого страшного кошмара RMS: http://www.optimitech.com/ru_004.htm.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Я тебе даже покажу воплощение самого страшного кошмара RMS: http://www.optimitech.com/ru_004.htm.

Да... Но в данном конкретном случае разработчики всего лишь теряют исключение к GPL, что не страшно. Т.к. целевой софт для применения под заказ. Думаю, RMS может расслабиться :)

aist1 ★★★
()
Ответ на: комментарий от baka-kun

Сообщества пользователей.

Они ни это сообщество долгое время клали с пробором. И продолжали бы это делать, не появись и не вырасти LLVM. А теперь доигрались до того, что у них появился серьезный, динамично развивающийся конкурент. Мне так кажется, это начало конца эпохи GCC.

aist1 ★★★
()
Ответ на: комментарий от baka-kun

>> А кто и когда это делал?

Достаточно прочитать тему, чтобы узнать как минимум об одном проекте: llvm-gcc :)

Также легко узнать о edoc, gcc-xml, milepost, и так далее…

Это всё открытые проекты.

Я тебе даже покажу воплощение самого страшного кошмара RMS: http://www.optimitech.com/ru_004.htm.

Что ж, RMS снова оказался прав. Пожелаем этим классным парням счастливого пути на LLVM.

tailgunner ★★★★★
()
Ответ на: комментарий от aist1

> Мне так кажется, это начало конца эпохи GCC.

Если LLVM накопит значительную базу пользователей _и_ разработчиков - может быть. Но это большое «если». А пока что LLVM - это свободный фронтенд Си и Си++.

tailgunner ★★★★★
()
Ответ на: комментарий от aist1

> Они ни это сообщество долгое время клали с пробором.

И получили, что получили. Решение никогда не было техническим, только политическим: RMS откровенно боится просрать gcc «злым корпорациям», которые его и развили до текущего уровня. Дальше класть будет всё сложнее. Тем более llvm сейчас пилят и будут пилить все, от проприетарщиков до опенсорса, даже аффилированные FSF (чтобы не отстать от прогресса). Уже понятно, что gcc останется основным компилятором только в части GNU сообщества (даже не во всём) и для сборки «линуксизмов».

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

baka-kun ★★★★★
()
Ответ на: комментарий от tailgunner

> Это всё открытые проекты.

Они от этого перестали быть «использовать фронтенд без бекенда (и наоборот) или оптимизировать промежуточное представление»? Для того, чтобы отдавить мозоль RMS достаточно того, чтобы некоторые из них не были под крылом FSF.

Что ж, RMS снова оказался прав.

RMS снова оказался лев. Ультралев (ну, типа, liberté, égalité, fraternité). Накладывать ограничения на результаты работы компилятора (пусть даже промежуточные результаты) — это верх «освободизма».

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

>> Это всё открытые проекты.

Они от этого перестали быть «использовать фронтенд без бекенда (и наоборот) или оптимизировать промежуточное представление»?

Нерелевантно. Цель RMS - увеличить количество свободного софта, и в данном случае цель полностью достигнута.

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

[quote] Если LLVM накопит значительную базу пользователей _и_ разработчиков - может быть. Но это большое «если». А пока что LLVM - это свободный фронтенд Си и Си++. [/quote]

Если точнее, то не LLVM, а CLang. Пару лет назад я бы в этом не сомневался, что С/С++ над llvm победит. Порог вхождения в LLVM намного ниже такового для GCC. Плюс VM - то, чего в GCC нет.

А сейчас... Если приглядеться, то дополнительные оптимизации сверх уже имеющихся в GCC дают какие-то %%, не более. Остается место разве что для специфических оптимизаций типа распараллеливания специализированного кода. Массовому софту это фиолетово. Менять здесь GCC на CLang имеет смысл только по идеологическим или коммерческим соображениям. Люди не дураки и это понимают.

Т.е. GCC vs CLang уже ничего не решает. Молодежь из C/C++ ушла. Решает LLVM, потому, что фрэймворк для VM.

aist1 ★★★
()
Ответ на: комментарий от baka-kun

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

Gcc они просрали, когда Hotspot стал выдавать код, почти не уступающий по быстродействию таковому от Gcc. И только техническая импотенция Sun в области UI не позволила массовому софту перейти на Java. Сейчас кто-нибудь возьмется объединить LLVM и Qt - и понеслась :)

Могу ошибаться, но мне кажется, что в целом BSD-like мир развивается динамичнее. Единственные исключения - это gcc и linux kernel. Теперь ядро Linux остается последним оплотом GPL, да и то оно под 2.0

Кроме того, индустрия медленно но верно переходит от обладания кодом к обладанию данными. Код уже не решает.

aist1 ★★★
()
Ответ на: комментарий от aist1

> Решает LLVM, потому, что фрэймворк для VM.

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

VM всем нужны. Вона сколько их развелось сейчас.

Если Яббл потеряет к LLVM интерес, то последний просто замедлится в развитии. Технически он и так уже довольно зрелый. Будет развиваться в академической среде. Gcc вздохнет с облегчением и тоже тормознет в развитии :)

Но по уже освещенным здесь причинам Яббл не прекратит развитие LLVM. Скорее переориентирует силы на свой obj-c++, забрав кровь у всего остального.

aist1 ★★★
()
Ответ на: комментарий от tailgunner

> Нерелевантно.

Ты понимаешь, что вся боязнь RMS плагинов сводится к одному: «ах, кто-нибудь сделает классный оптимизатор, семантический анализатор, бла-бла-бла, и мы останемся не у дел, если он нам не передаст права на код, без которых мы ни в жизнь не захотим принять этот оптимизатор, анализатор, бла-бла-бла, поскольку не хотим терять контроль»?

Если бы RMS потерял ту минимальную связь с действительностью, которая у него осталась, лицензия на gcc давно бы говорила, что им можно компилировать только GPL код, причем только той версии, которую RMS пожелает.

> Ты просто не поимаешь некоторых очевидных вещей.

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

baka-kun ★★★★★
()
Ответ на: комментарий от aist1

> дополнительные оптимизации сверх уже имеющихся в GCC дают какие-то %%, не более.

Беда gcc в том, что он на любой платформе пытается «эмулировать» x86. Многим людям хватило бы от него только парсера, чтобы взять IR, а дальше уже своими силами оптимизировать и генерировать код.

Могу ошибаться, но мне кажется, что в целом BSD-like мир развивается динамичнее.

Не ошибаешься, так и есть. Причем в пост-GPLv3 мире перекос AFAICS только возрастает.

Если Яббл потеряет к LLVM интерес, то последний просто замедлится в развитии.

Там есть кому развивать без Эппла, далеко не все направления замедляться заметно. Да и не бросит он, вполне очевидно.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Не ошибаешься, так и есть.

Ты не в курсе, FSF требует передачи ей имущественных прав на код патчей, которые она собирается принять?

aist1 ★★★
()
Ответ на: комментарий от aist1

> Скорее переориентирует силы на свой obj-c++, забрав кровь у всего остального.

Ну сколкьо раз говорить, что objective это малая часть obj-c/c++

Сейчас кто-нибудь возьмется объединить LLVM и Qt - и понеслась :)

А что там объядинять. Вот если слоты/сигналы прооптимизят, как в NEXTStep

Цель RMS - увеличить количество свободного софта, и в данном случае цель полностью достигнута.

Нет. Его цель - увеличить кол-во открытого несвободного кода

namezys ★★★★
()
Ответ на: комментарий от annulen

> Если запилят распространенные gcc-измы, будет, интеловский же собирает

Обещали, но apple за это платить не будет

namezys ★★★★
()
Ответ на: комментарий от tailgunner

> Чем лучше? Что яббл взяд LLVM под крыло? Это да, и за это надо сказать спасибо GPL %)

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

...а за то, что совместимую бблиотеку запретили выпускать.

Как это они ее запретили? Чем же?

namezys ★★★★
()
Ответ на: комментарий от tailgunner

>> Можно подумать, и так никто этого не делал :)

А кто и когда это делал?

яблоки и делали

namezys ★★★★
()
Ответ на: комментарий от aist1

> FSF требует передачи ей имущественных прав на код патчей, которые она собирается принять?

Да.

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

При этом:

а) Сразу передаются все права как на прошлый, так и будущий код, связанный с этим проектом.

б) До кучи сразу передаются и права на любой прошлый и будущий код, основанный на том или включающий в себя тот, который ты патчишь.

в) В ответ FSF, чисто по доброте душевной, дает тебе неэксклюзивные право использования на твои собственные патчи (и только на них).

г) FSF получает все авторские права на патчи и производные работы, включая право использовать, изменять, распространять, лицензировать и так далее.

д) FSF оставляет за собой право взимать деньги за доступ к ПО.

е) Разработчик обязуется по первому требованию отчитываться обо всем, что делает с кодом сам, кому его ещё передает, включая производные работы.

И так далее, включая отказ от гарантий со стороны FSF, но гарантии со стороны разработчика правдиво отчитываться и нести ответственность за прямой или непрямой вред, причиненный разработчиком FSF.

Мы когда-то давно давно патчили гнутый код, но отправляли свой вариант договора, много мягче и симметричней. RMS подписал.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

е) Разработчик обязуется по первому требованию отчитываться обо всем, что делает с кодом сам, кому его ещё передает, включая производные работы.

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

Мы когда-то давно давно патчили гнутый код, но отправляли свой вариант договора, много мягче и симметричней. RMS подписал.

Гы. А где его принципиальность? Или это был _очень_нужный_им_код_? :)

aist1 ★★★
()
Ответ на: комментарий от namezys

>> Чем лучше? Что яббл взяд LLVM под крыло? Это да, и за это надо сказать спасибо GPL %)

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

Легко говорить это теперь, когда твои слова невозможно проверить. А RMS считал (и я с ним согласен) что без GPL GCC захирел бы и, если не помер, то вел бы жизнь какого-нибудь kencc или Tendra CC. Ссылку на закрытый распараллеливатель давали выше - и это делается даже при GPL, а представь, что лицензия официально разрешала бы закрытые модификации.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> открытого несвободного кода

Что это такое?

Очевидно, что gpl. Он не свободен

А RMS считал (и я с ним согласен) что без GPL GCC захирел бы и

HURD их очень хорошо с gpl живет. Не в лицензии дело. А продукты на BSD все загнулись

что лицензия официально разрешала бы закрытые модификации.

Вообще-то, продукты на lgpl прекрасно развиваются. А тут полное рабство кода. Открой все, что трогает gcc

namezys ★★★★
()
Ответ на: комментарий от namezys

>>> открытого несвободного кода

Что это такое?

Очевидно, что gpl. Он не свободен

Этот софт несвободен только в твоем понимании. Понятно, что RMS до этого нет дела, и он исходит из своего понимания.

А RMS считал (и я с ним согласен) что без GPL GCC захирел бы и

HURD их очень хорошо с gpl живет. Не в лицензии дело.

Не передергивай. Понятно, что дело _не только_ в лицензии, а еще и в нужности. Но в 90-х годах GCC был единственным бесплатным фронтендом Си и Си++ - если бы не GPL, его бы просто растащили по норам.

Вообще-то, продукты на lgpl прекрасно развиваются. А тут полное рабство кода. Открой все, что трогает gcc

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Мне кажеться, чтоб NEXTStep лучше бы сделал интерфейсы, чем забить код obj-c #ifdef #endif

namezys ★★★★
()
Ответ на: комментарий от aist1

> Я должен буду отчитываться, что я дальше делаю с кодом, который им передал?

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

Гы. А где его принципиальность? Или это был _очень_нужный_им_код_?

Нет, ничего серьезного. Просто договор подразумевает две стороны, а не тупое подмахивание бумажки: они предложили свой вариант, мы — свой. После двух-трех итераций подписали договор, с которым согласны обе стороны. Сперва они, как любой прожженный капиталист, пытаются подсунуть, в виде некоего «шаблона», самый выгодный для себя вариант. Но никто ведь не заставляет сразу подписывать.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> …с тебя могут спросить, что ты с ним делаешь, чтобы он не ушел из-под GPL.

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

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

FSF пытается отобрать, остальные просят поделиться.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

Вот. Вот оно, настоящее рабство.

Я хоть с яблоком знаю, что только в анальном состою. А тут полное: во всех местах

namezys ★★★★
()
Ответ на: комментарий от tailgunner

> Но в 90-х годах GCC был единственным бесплатным фронтендом Си и Си++ - если бы не GPL, его бы просто растащили по норам.

Недовольство вызывает не столько GPL, сколько фактически дополнительное ограничение к нему, не позволяющее пользоваться промежуточным представлением кода.

______________________________

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

Но нельзя!

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

То же с кипяченой водой. Заварить в ней чай в стакане стороннего производителя тоже нельзя.

Интересно, будет ли легально выпустить такую борщеварку?

А если в борщеварке используется программное обеспечение? И если прописать все эти пункты в лицензию?

И куда скатиться мир после этого?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от tailgunner

> Нерелевантно. Цель RMS - увеличить количество свободного софта, и в данном случае цель полностью достигнута.

При этом полностью потеряв лояльность (части) программистов?

Я, при наличии выбора, куда бесплатно написать мои патчи, в gcc или llvm, не буду иметь даже 0.1% сомнений.

З.Ы. Как бабло, так и «свободный» в понимании RMS софт — не самоцель.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от tailgunner

>> Также легко узнать о edoc, gcc-xml, milepost, и так далее…

Это всё открытые проекты.

Если использовать выхлоп gcc-xml для того, чтобы пропраетарной тулзой сгенерить из него сишный код, то это будет, как я понимаю, нарушение Eligible Compilation Process.

Впрочем, я мог не до конца разобраться, или они таки внесли туда исключение.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от baka-kun

> Чуть сложнее подумать, в каких случаях людям нужно вытащить из gcc семантику. Я тебе даже покажу воплощение самого страшного кошмара RMS: http://www.optimitech.com/ru_004.htm.

У вас описан формат, в которой вытаскивается семантика? Он предполагается стабильным?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от namezys

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

Вот. Вот оно, настоящее рабство.

Доо. Не говоря о том, что принятие участия в разработке GCC - это дело добровольное, не мог бы ты объяснить, какой свободы тебя _лишают_? Только со ссылками на то, что ты теряешь право распространять код, переданный FSF, на любых условиях, которые сам выберешь

tailgunner ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>> Нерелевантно. Цель RMS - увеличить количество свободного софта, и в данном случае цель полностью достигнута.

При этом полностью потеряв лояльность (части) программистов?

Хм. А ты был лоялен? Писал софт, публиковал его под GPL? Что именно RMS может потерять - закрытый инструмент, который ты собираешься написать? Думаю, он будет рад этому - он считает закрытый софт аморальным.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Хм. А ты был лоялен? Писал софт, публиковал его под GPL? Что именно RMS может потерять - закрытый инструмент, который ты собираешься написать? Думаю, он будет рад этому - он считает закрытый софт аморальным.

Разговор (хотя и мотивированно) перешел в личную плоскость. Ну ладно.

И что по-твоему я должен быть написать? 100500-й музыкальный плеер? 100500-й идиотский веб фреймворк на динамическом языке? Или -надцатый *ttpd с банановым вкусом?

Или очередной велосипед «я не осилил реализацию исключений и дженериков, поэтому решил сдедать google go без них»?

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

Гораздо более важно, с моей точки зрения, что во всем этом хаос. Люди называют дистрибутив свалкой софта, и это хотя обидно, но за небольшими исключениями это правда. Хотя бы, где единый доступ к параметрам конфигурационных файлов? Чтобы можно было сказать config.apache.section.subsection.value=123 ? Или грепануть по этому названию? Где единый синтаксис для указания ключей всем командно-строчным прогам?

Где правильная архитектура командно-строчных утилит типа cp, чтобы mc делался *простой* оболочкой вокруг них?

Навести тут порядок и единобразие интересно и полезно. Только тут требуется образование и обсуждение, а не объемы GPL кода (типа glob, ага).

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> У вас описан формат, в которой вытаскивается семантика?

Там у них xml, схемы опубликованы.

Он предполагается стабильным?

Сам по себе xml, очевидно, стабилен. ;)

baka-kun ★★★★★
()
Ответ на: комментарий от tailgunner

> Только со ссылками на то, что ты теряешь право распространять код, переданный FSF, на любых условиях, которые сам выберешь

Где-то был документ посвежее, но и старый подойдёт:

«For good and valuable consideration, receipt of which I acknowledge, I, NAME OF PERSON, hereby transfer to the Free Software Foundation, Inc. (the „Foundation“) my entire right, title, and interest (including all rights under copyright) in my changes and enhancements to the program NAME OF PROGRAM, subject to the conditions below. These changes and enhancements are herein called the „Work“. The Work hereby assigned shall also include any future revisions of these changes and enhancements…

„Upon thirty days' prior written notice, the Foundation agrees to grant me non-exclusive rights to use the Work (i.e. my changes and enhancements, not the program which I enhanced)…

Ещё раз: FSF требует передать права безвозвратно (добровольно, куда же без этого), остальные просят разделить права (соавторство с равными возможностями распоряжаться кодом).

baka-kun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.