В ответ на намерение (http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg002...) разработчиков добавить в текстовый редактор Emacs опциональную возможность вызова развиваемого проектом LLVM отладчика LLDB, в дополнение к штатно поддерживаемому отладчику GDB, Ричард Столлман заявил (http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg003...), что он против появления подобной поддержки. Более того, Столлман назвал продвижение подобных патчей систематическими попытками атак на пакеты GNU и призвал (http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg004...) ответить непринятием попыток добавления в GNU средств для работы с системами, развиваемыми в рамках собственнических моделей лицензирования. По мнению (http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg004...) Столлмана польза от добавления поддержки LLDB не компенсирует вред, которая такая поддержки может нанести GDB и свободе пользователей.Стефан Монье (Stefan Monnier), майнтейнер Emacs, не согласился (http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg004...) с такой позицией и намерен принять патч для поддержки LLDB. Ранее Столлман уже выступал с критикой LLVM, указывая (https://www.opennet.ru/opennews/art.shtml?num=38931) на то, что продвижение данного проекта ведёт к поражению сообщества сторонников СПО, так как LLVM/Clang поставляется не под копилефт-лицензией активно используется компанией Apple в качестве основы для создания несвободных компиляторов, т.е., любое участие в разработке LLVM непосредственно помогает развитию проприетарного ПО.
URL: http://www.reddit.com/r/linux/comments/2v441n/rms_rejects_ll.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=41631
Все правильно, не надо поддерживать LLVM. Нужно пресекать посредством физической расправы нытье C++-кодеров по поводу того, что GCC все никак не выкинут из GNU/Linux, что всю систему GNU нужно нахрен уничтожить, и что всем свободным утилитам есть такая стабильная и привычная замена, как криво-косые проприетарные программки с макинтоша.
Хороший сарказм, да.
Сдаётся мне, это был не сарказм...
Прикольный сарказм на сарказм, да.
О, пришёл столлман опнета. Местечковая истина с кнопками в задней инстанции.
> Сдаётся мне, это был не сарказм...Да это я тоже как бы понимаю. Проблема в том, что обычно от C++-компилятора требуется компилировать код в первую очередь.
> Да это я тоже как бы понимаю. Проблема в том, что обычно
> от C++-компилятора требуется компилировать код в первую очередь.а дело в том, что rms интересуют вещи намного более глобальные. в том числе и такие, которые могут проявиться через десятилетия. а то, что он таки видит далеко… ну, это вполне очевидно, если посмотреть на его предсказания и на то, как неумолимо они исполняются.
> а дело в том, что rms интересуют вещи намного более глобальные. в
> том числе и такие, которые могут проявиться через десятилетия. а то,
> что он таки видит далеко… ну, это вполне очевидно, если посмотреть
> на его предсказания и на то, как неумолимо они исполняются.Это всё замечательно, конечно, но альтернатив-то особо нет.
Я, впрочем, не голосую за то, чтобы линуксоэкосистема кончилась или ещё там что-то, не, зачем? У кого есть clang, тем и хорошо, у кого нет — ну, не собрать им свежие версии моих поделок годик-другой, никто не умрёт от этого. А в продакшене под линукс тоже clang и местами ghc, полёт нормальный.
ну дык rms и не против кланга, он против смешения GNU и не-GNU. сосуществование-то никто не опротестовывает.
С каких пор опциональная поддержка чего-либо с более разрешающей лицензией — смешение? Вполне себе отличное сосуществование, как по мне.
> С каких пор опциональная поддержка чего-либо с более разрешающей лицензией — смешение?с тех пор, как это хотят затащить в коробку. вне коробки, как отдельно устанавливаемый модуль — на здоровье.
p.s. «вне коробки» — это обозначает, что в авторском дереве исходников не присутствует, разработчики не разрабатывают, занимаются совсем сторонние пиплы.
Миша, ты ещё жив? Попочление почему не пошел?
> Миша, ты ещё жив? Попочление почему не пошел?предатель потому что.
Предатель кого и чего?
> Предатель кого и чего?своей страны, как минимум дважды. это цивилам можно, а мишенька у нас ахвицер. с честью ахвицерской. с ней и сбежал. и не самоубился от стыда.
А почему дважды?
>> Предатель кого и чего?
> своей страныМоя страна -- Россия; а честь -- не в том, чтоб самоубиться как можно быстрее, пытаясь в одиночку перевернуть четверть века выращивания идиотов и зомбирования самопровозглашённых "неидиотов" вроде тебя. Отчитываться перед таковыми не собираюсь.
А клевету буду всё так же зачищать по мере замечания, и в свой адрес тоже.
>>> Предатель кого и чего?
>> своей страны
> Моя страна -- Россия... кричит любой таджик. Ты, надо полагать, отличаешься от них проживанием
(до недавнего времени) всю сознательную жизнь на Украине, образованием - тоже там?
"Охвицер" ты какой, армии, болезный?> а честь -- не в том, чтоб самоубиться
> как можно быстрее, пытаясь в одиночку перевернуть четверть века выращивания идиотовА что ты делал эти четверть века? Тов. Ленин не плакался на идиотов (которых в то время, кстати,
весьма упорно выращивали в т.ч. и за государственный счет), за те же четверть века создал
партию, которая победила в революции и гражданской войне, а затем первую в мире соцстрану.> А клевету буду всё так же зачищать по мере замечания, и в
> свой адрес тоже.arisu, или я не прав в диагнозе что подлец уже давно вылупился? Ты вроде как-то возражал.
>> Моя страна -- Россия
> ... кричит любой таджик. Ты, надо полагать, отличаешься от них проживанием
> (до недавнего времени) всю сознательную жизнь на Украине, образованием - тоже там?Мимо по обоим пунктам.
> "Охвицер" ты какой, армии, болезный?
apt-get install hunspell, о сын Хама и Сима одновременно.
> А что ты делал эти четверть века?
Достаточно, хоть и можно было больше. Без немецкого золота и жидовской лжи притом.
PS: s/он /о /
>>> Моя страна -- Россия
>> ... кричит любой таджик. Ты, надо полагать, отличаешься от них проживанием
>> (до недавнего времени) всю сознательную жизнь на Украине, образованием - тоже там?
> Мимо по обоим пунктам.Киевский национальный университет им. Т. Г. Шевенко '2001
Эт че, московский вуз?
>> "Охвицер" ты какой, армии, болезный?
> apt-get install hunspell, о сын Хама и Сима одновременно.Таки какой?
>> А что ты делал эти четверть века?
> Достаточно, хоть и можно было больше.Я не имел в виду ИБД.
> Без немецкого золота и жидовской лжи притом.
Все сбежавшие держиморды РИ жаловались на недостаток жидовской лжи и
немецкого золота. А рядом с каждым из ~6 млн. красноармейцев стоял жид-комиссар с маузером.
И плевать что столько жидов и маузеров в РИ не было...
>>> Ты, надо полагать, отличаешься от них проживанием
>>> (до недавнего времени) всю сознательную жизнь на Украине,
>>> образованием - тоже там?
>> Мимо по обоим пунктам.
> Киевский национальный университет им. Т. Г. Шевенко '2001
> Эт че, московский вуз?Нет. Это, кстати, не главное образование было, но Вам Вашего образования (не говоря уж о воспитании) не хватает даже перечитать свой же вопрос, мой ответ, успокоиться и либо задавать правильные вопросы, либо хотя бы сойти за умного.
>>> "Охвицер" ты какой, армии, болезный?
>> apt-get install hunspell, о сын Хама и Сима одновременно.
> Таки какой?См. выше -- додумывать за Вас правильные вопросы считаю неуместным.
Вы же претендуете на ум? Вот и проявите.
> Нет. Это, кстати, не главное образование былоШо-ж было главным, краткие курсы вахтеров?
Тебя цитируют - сам указываешь так.
>задавать правильные вопросы [...] либо хотя бы сойти за умного.
Умные люди - как раз задают неудобные и неправильные вопрос. Потому их разная кодла и не любит.
>>>> "Охвицер" ты какой, армии, болезный?
>>> apt-get install hunspell, о сын Хама и Сима одновременно.
>> Таки какой?
> См. вышеВыше пишут что украинской. Это твой ответ?
>> Нет. Это, кстати, не главное образование было
> Шо-ж было главным, краткие курсы вахтеров?Нет.
> Умные люди - как раз задают неудобные и неправильные вопрос.
> Потому их разная кодла и не любит.Так то умные, а кодлу приходится сперва от ейной привычной грязи отмыть, чтоб хоть какой-то уровень обсуждения оставался.
>>>>> "Охвицер" ты какой, армии, болезный?
>>>> apt-get install hunspell, о сын Хама и Сима одновременно.
>>> Таки какой?
>> См. выше
> Выше пишут что украинской. Это твой ответ?Попробуйте всё-таки ещё одну итерацию с учётом выделенного.
Поймите: если человек задаёт вопрос коряво, но не злонамеренно -- вопрос поправить можно (хотя и тогда лучше явно указать свою интерпретацию, на которую и даётся ответ); когда человек ерепенится -- так лучше не делать; а когда человек хамит -- полезнее наказывать его за каждую букву не по делу.
И к Вам сейчас отношение ровно такое. Напирать ни к чему, просто закончится квота времени. Считал бы дураком -- не отвечал бы вовсе, поймите правильно.
>>> Нет. Это, кстати, не главное образование было
>> Шо-ж было главным, краткие курсы вахтеров?
> Нет.Т.е. ты сознательно лжешь, указывая у себя в профилях это киевское пту?
>> Умные люди - как раз задают неудобные и неправильные вопрос.
>> Потому их разная кодла и не любит.
> Так то умные, а кодлу приходится сперва от ейной привычной грязи отмытьТак никто уже и не пытается тебя отмыть.
> чтоб хоть какой-то уровень обсуждения оставался.
>>>>>> "Охвицер" ты какой, армии, болезный?
>>>>> apt-get install hunspell, о сын Хама и Сима одновременно.
>>>> Таки какой?
>>> См. выше
>> Выше пишут что украинской. Это твой ответ?
> Попробуйте всё-таки ещё одну итерацию с учётом выделенного.Все сошлось, на кой хрен еще мне персонально тебя интервьюировать.
> а когда человек хамит -- полезнее наказывать его за каждую букву
> не по делу.Кто ты такое, насикомое, чтобы кого-то наказывать и как технически собираешься это делать?
> Т.е. ты сознательно лжешьНет.
Квота закончилась.
>> Т.е. ты сознательно лжешь
> Нет.Значит это правда. К чему тогда претензии?
> Квота закончилась.
Проклятая аристотелева логика бредить дальше мешает?
> Миша, ты ещё жив? Попочление почему не пошел?Да, я ещё жив. С ляшко и аваковыми дружите сами.
Лалка, столлман боится что если добавить lldb в emacs, то люди начнут его ковырять и посылать патчи в этот самый llvm, если вдруг найдутся проблемы в процессе интеграции.Отправляя патчи в llvm, ты тем самым кормишь пропреетарные компании которые производят на нем продукты pvs-studio, intel c++, xcode и гребут бабло в не меренном количестве.
Все правильно Столлман сказал. Как и всегда.
А теперь вспомним, почему был создан LLVM.
Столлман против здоровой конкуренции? Ещё и палки в колёса ставит. Не нравится лицензия - форкай и развивай сам, а не заставляй пользоваться GCC.
GPL и был создан с целью вставлять палки в колеса копирастам с их проприетарным софтом. Точнее не способствовать и не помогать им.
И да, Столлман никак не мешает и не вредит проекту LLVM.
Правильно, он только GNU проектам вредит
> GPL и был создан с целью вставлять палки в колеса копирастам с
> их проприетарным софтом. Точнее не способствовать и не помогать им.
> И да, Столлман никак не мешает и не вредит проекту LLVM.А фашизм в Германии был создан, чтобы вставлять палки в колеса СССР.
Так всё-таки он за СПО или ОПО?
> А теперь вспомним, почему был создан LLVM.Потому что эппл хотел возможность зажимать сорцы и ни с кем не делиться. Правда я Каптан? :)
Это первая причина. Вторая в том, что кодовая база gcc - окаменелый кал мамонта.
> Это первая причина. Вторая в том, что кодовая база gcc - окаменелый
> кал мамонта.Начнем с того что это ложь. Apple вполне развивал obj-c под GPL v2, только столману захотелось сменить лицензию на GPL v3.
Я ж не говорю, что первая причина невалидна.Развивали костылями, плакали и кололись. А с gpl3 появился второй весомый повод. Было бы с кодовой базой все хорошо, просто форкнули бы последнюю gpl2-версию.
странный ты.. Не знаешь историю вопроса.
Apple хотел продолжать развивать obj-c под GPL v2, а столман решил что теперь надо GPL v3 и не волнует.
За одно забыл linking exceptions - после чего любой код скомпилированый при помощи gcc - менял лицензию.
К дедушке стоит прислушаться (хотя это не очевидно на 1й взгляд).
Дедушка часто потом оказывался прав.
У дедушки уже давно маразм.
Это правда.
Да поймите же, что общественные деятели также нужны сообществу. Иначе, кто же будет защищать интересы СПО программистов и пользователей?
Ага, вот смотрят нормальные люди на таких защитников прав и свобод и думают - да ну на, лучше уж кровавый диктат навеки.
ты то, дерьмо, откуда знаешь, о чём думают нормальные люди?
>ты то, дерьмоНет, ты!
> Нет, ты!А вот еще один зомбяк пропаганды насмотрелся и совершенно добровольно готов быть терпилой и лабораторной мышью.
Что это вы цитируете такими куцыми кусками? Цитируйте полностью:
"Мы все так говорим, значит, это правда!"
Маразм не маразм - а только в свете того, что некоторые компании блокируют работу своего ПО в Крыму прямо сейчас, т.е. реально сбывается то, о чем Столлман предостерегает постоянно - я весной попробую окончательно перейти только на то ПО, которое сам смогу из исходников собрать.
GeoIP? Нет, не слышал. Открытые исходники крымнашам не помогут, инфа 100%.
Ты предлагаешь бороться со следствием - а я хочу бороться с причиной. Открытые исходники помогут хотя бы тем, что я смогу найти строчки кода, мешающие работе, и тупо их закомментарить.
Хреново быть тобой. Бородатый фанатик тебе совсем мозги размягчил. Музыку играют владельцы сервиса, а не "властители" исходников. Предрекаю gpl4: "Сервис, сонованный на открытом коде, должен выложить сурсы", к этому RMS и катится. Чистейший, незамутненный маразм!
> Предрекаю gpl4: "Сервис, сонованный на открытом
> коде, должен выложить сурсы", к этому RMS и катится. Чистейший, незамутненный маразм!Заметь, твой личный маразм.
Поздно пить боржоми детка! :) Я про то что AGPL существует и даже пользуется :)
> AGPLЧорт, всю жизнь думал что она про другое. А полезность прекрасно подтверждается списком проектов, они или подкреплены деньгами или прозябают, и что характерно — сторонних сервисов на их основе никто не делает.
> GeoIP? Нет, не слышал. Открытые исходники крымнашам не помогут, инфа 100%.А какое дело какой-нибудь ни разу не американской убунте или там вообще общественному дебиану крым или не крым? :)
Ну и что? Это ещё не значит, что не прав
> Ну и что? Это ещё не значит, что не правОн конечно может пальцем в небо попадать, только не в этом случае. Способ, которым поддержка LLDB вытесняет GDB из исходников емакса, может сложиться только в совсем воспаленном воображении.
Линус вот забил на его мнение.
> Линус вот забил на его мнение.Странно, а лицензию выбрал дедушкину. И что характерно - правильно сделал. А теперь бздюки GPLный код себе в норы понесли. Надо порадовать дедушку, пожалуй - старый партизан заценит удачную расстановку мин :)
> Странно, а лицензию выбрал дедушкину.Действительно странно, лицензию выбрал, а на дедушкино мнение забил. Когда лицензию обновлили, опять забил. И что характерно - правильно сделал.
> И что характерно - правильно сделал.конечно. линус же публично говорит, что не видит ничего плохого в тивоизации. всё правильно делает, малацца.
А по другому ядро linux в мире проприетарных драйверов не выживет. Счечас ещё что-то уже есть из свободных, но на заре точно бы не выжил.
> А по другому ядро linux в мире проприетарных драйверов не выживет. Счечас
> ещё что-то уже есть из свободных, но на заре точно бы
> не выжил.Времена меняются, сейчас уже особо борзых можно и нужно смело слать на ЙУХ. Ядро-то самое распространённое.
что самое смешное — «на заре» вообще с проприетарными драйверами всё очень плохо было. потому что проприетарщикам было наплевать — примерно до момента, когда линукс стал уже весьма заметной величиной. да и потом, в общем-то…но забавнее всего даже не это, а то, что персонаж вообще не знает, что такое «тивоизация», и почему она к «дровам» не имеет отношения.
> Времена меняются, сейчас уже особо борзых можно и нужно смело слать на
> ЙУХ. Ядро-то самое распространённое.Это могут _быстро_ исправить. Но ты то конечно думаешь что нет :-)
Или будут давать только на сеть и сторидж -> и линукс станет типа фряхи - _очень_ хорошим сервером. Хотя десктоп он и так паршивый :-\ А могут сделать _никаким_.
> Это могут _быстро_ исправить. Но ты то конечно думаешь что нет :-)Я думаю, что _быстро_ исправить нельзя. Медленно, конечно, нужно - нужно менять Linux на что-то значительно меньшее, более вылизанное.
> Или будут давать только на сеть и сторидж -> и линукс станет
> типа фряхи - _очень_ хорошим сервером.Десктоп уже сделан. Всё, что требуется - это не ломать его. А при наличии денежных потоков не ломать тяжело.
> Хотя десктоп он и так
> паршивый :-\ А могут сделать _никаким_.Над этим усиленно работают Wayland'о строители и наш любимый ЛП.
> А по другому ядро linux в мире проприетарных драйверов не выживет. Счечас
> ещё что-то уже есть из свободных, но на заре точно бы
> не выжил.i lold.
> конечно. линус же публично говорит, что не видит ничего плохого в тивоизации.
> всё правильно делает, малацца.Так он и трехглавых акул с боевыми лазерами запрещать не хочет.
А что до GPLv3 или чего там еще - извините, лицензия на линух никому единолично не принадлежит и сменить ее технически невозможно. Потому что невозможно опросить всех кто когда либо коммитил код. Их там легион. Торвальдс это понимает.
конечно, невозможно. лично линус — в том числе — и постарался сделать так, чтобы её было даже невозможно апгрейднуть до v3.
Дедушка всегда практически прав, но он не в состоянии из раба и потребляди сделать свободного человека.
> но он не в состоянии из раба и потpeбл яди сделать свободного человека.Но он оказался в состоянии показать что есть и иные опции. За что ему и спасибо, собственно.
Ну да, ну да... перепишем лисп на яваскрипте и всё, гнукапец.
кто-нибудь передайте дедушке, что LLVM появилась не потому что подлым корпорастам не нравится GPL, а потому что все устали от GCC с его кретинскими архитектурой, документацией и API
Тебе ответ от дедушки: не нравится -- можешь форкуть.
Дедушка уже ответил: "Я боюсь что поддержка LLDB будет круче GDB, поэтому ее быть не должно".http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg003...
Дедушка ответил: "We should do what is best for the GNU system's goal of
giving the users freedom. This means considering what is good for
Emacs and what is good for GDB, to make a decision. Then the whole
GNU Project should do what is best. That is the responsibility of
each GNU package maintainer. If GNU packages do not support each other, it will be easier
for many of them to fail."Грубо говоря: "Дубина, Emacs не единственный проект GNU. Проекты должны координироваться и друг друга поддерживать, иначе пропиерасты передавят по одному. Мейнтейнера нужно об этом помнить, а не мнить себя африканскими царьками."
Учи агглицкий, школие.
>[оверквотинг удален]
> Emacs and what is good for GDB, to make a decision.
> Then the whole
> GNU Project should do what is best. That is the responsibility
> of
> each GNU package maintainer. If GNU packages do not support each other,
> it will be easier
> for many of them to fail."
> Грубо говоря: "Дубина, Emacs не единственный проект GNU. Проекты должны координироваться
> и друг друга поддерживать, иначе пропиерасты передавят по одному. Мейнтейнера
> нужно об этом помнить, а не мнить себя африканскими царьками."А под всем этим читается: "Я знаю лучше, я верховожу GNU, я лучше всех вижу, поэтому моё мнение априори важнее".
Лично я не буду сожалеть о смерти GDB, если это произойдёт за счёт вытеснения его более качественным open source проектом. Столлману жалко GNU-софтину? - Ну, давайте погладим дедушку по голове, платочек поднесём.
Потому что дедушка как был лицемерным хамлом (не грубияном, а именно хамлом), так и остался. Политик он хороший, спору нет, там эти качества в цене - без шуток. Пиариться на открытом софте RMS умеет. Спроси любого, кто хоть что-то слышал про open source - назови любого деятеля - назовут Столлмана и Торвальдса. Но если второй не скрывает своих амбиций и выражается прямо, при этом реально работая над одним из ключевых продуктов для всего open source (да, я это как не любящий Linux человек говорю - одно дело любить или не любить, а другое - признавать влияние), то первый - посмотрите внимательно на его заслуги? Написаный им софт - кривой до жути, его потом десятилетиями от детских проблем лечили совсем другие люди. Кстати, очень напоминает подход тов. Поттеринга... Но RMS продолжает этим всем махать, он машет своим пониманием свободы; забывая, что свобода выбирать для себя границы личной свободы - это тоже свобода, и когда её навязывают, убеждая, что AGPL - верх совершенства - это ни разу не свобода.
RMS - ли-це-мер. Он заявляет, что вот-де они работают над "полностью открытым" компьютером, и вот уже GNU рекламирует такую разработку. Плевать, что в ней сетевые карты и другие контроллеры потенциально не подконтрольны хоть тысячу раз открытой и GPL-ной ОС. Столлман с чистой совестью объявляет такой компьютер полностью принадлежащим пользователю, хотя не видел, скорее всего, ни одной схемы ни одного микропроцессора в этой системе.
Да Столлман делает и благое - защищает в судах отдельных разработчиков open source. Иногда. Когда считает нужным. Но если это единственное, что реально полезного он делает - может, стоит это честно признать?
Но пока что, видимо, нимб не жмёт.
> Лично я не буду сожалеть о смерти GDB, если это произойдёт за
> счёт вытеснения его более качественным open source проектом.Я почему-то уверен, что лично ты gdb просто не используешь, и на
подобные "сожаления" можно оправданно "положить". В принципе, это
несложно доказать.> Столлману жалко GNU-софтину?
Да, как любому разумному человеку, целью которого является не "open
source" из альфа-версий для тестеров - а стабильная экосистема свободного ПО.> Но если второй не
> скрывает своих амбиций и выражается прямо, при этом реально работая над
> одним из ключевых продуктов для всего open sourceВообще-то - ни тот ни другой не пишут самостоятельно код в промышленных
мастшабах, как и положено людям их возраста. Разве совсем по-мелочи.> Написаный им софт - кривой до жути
Анонимные иксперды лор^Wopennet гарантируют вам это!
Хотя есть и ровно обратное мнение, очень многие коллеги Торвальдса
плевались от его архитектурных решений и качества кода. "Я считал и считаю его самовлюбленным малообразованным пингвином." (ц)Отака ****я малята!
,
> его потом десятилетиями от детских проблем лечили совсем другие люди.Все больше напоминает linux.
Напомни от каких проблем дизайна лечили Emacs или gdb? И, кстати, кто.
> RMS - ли-це-мер. Он заявляет, что вот-де они работают над "полностью открытым"
> компьютером, и вот уже GNU рекламирует такую разработку. Плевать, что в
> ней сетевые карты и другие контроллеры потенциально не подконтрольны хоть тысячу
> раз открытой и GPL-ной ОС. Столлман с чистой совестью объявляет такой
> компьютер полностью принадлежащим пользователю, хотя не видел, скорее всего, ни одной
> схемы ни одного микропроцессора в этой системе.Цитату пожалуйста. Или тапком в морду.
Прежде чем с чистой совестью рассуждать о том что кто-то объявляет - не худо
сперва познакомиться с этими объявлениями из первых уст, а не из пересказов
твоих однокласников и собственных фантазий на тему.
> RMS - ли-це-мер.Нет, он действительно делает то, что говорит.
gcc проще с нуля, чем форкать.
> gcc проще с нуля, чем форкать.llvm-овцы тоже так думали. пока что пыхтят где-то сзади в пыли.
По части количества поддерживаемых архитектур, разве что.asan, кстати, тоже небось изобретение gcc'овцев, например?
> По части количества поддерживаемых архитектур, разве что.вполне достаточно, а не «разве что». вот когда они догонят gcc по *всем* параметрам — вот тогда и следует посмотреть, проще ли было с нуля.
Зачем мне эти все параметры, если мне от компилятора C++ под x86_64 нужна поддержка C++ и x86_64? Тот же asan и C++14 мне куда важнее поддержки attiny какой-нибудь.Инструмент под задачу, и с рядом задач clang/llvm справляется куда лучше gcc.
> Зачем мне эти все параметрызатем, что если ты вдруг уже забыл, то напомню: речь шла про «проще с нуля», и в качестве примера я привёл llvm. который «с нуля», и пока что gcc не догнал никак, хотя пилится уже больше декады.
> затем, что если ты вдруг уже забыл, то напомню: речь шла про
> «проще с нуля», и в качестве примера я привёл llvm. который
> «с нуля», и пока что gcc не догнал никак, хотя пилится
> уже больше декады.Фигасе никак, язык он как минимум поддерживает лучше, для разработки удобнее (сообщения об ошибках адекватнее, например), и так далее. Ну да, для ряда архитектур есть только gcc, в этом он лучше. В другом (и важном мне, и, так получилось, значительному количеству разработчиков) - хуже.
Такое впечатление, что в этом ИТТ треде людям лицензионная чистота важнее, чем функциональность. Кстати, небольшой личный опыт показывает, что софт/либу под пермиссивной лицензией в корпоративном мирке возьмут куда охотнее, чем вирусный GPL. Зато и шанс возврата контрибьюшенов в апстрим выше, хотя бы для того, чтобы набор патчей не тянуть потом с собой всю жизнь.
да пофигу, что он там поддерживает лучше: у него нет всех фич, которые есть у gcc. вопрос не в том, кто лучше, а кто хуже, а в том, что с нуля «догнать и обогнать» gcc у llvm пока что не получилось. за более чем десять лет разработки. потому нет, ни разу не проще «бросить gcc и сделать с нуля».
> да пофигу, что он там поддерживает лучшеВообще-то не пофигу. Впрочем, если не использовать компилятор для компиляции, а диванно кукаретизировать о фичах, то да, тогда пофигу.
> у него нет всех фич,
> которые есть у gcc. вопрос не в том, кто лучше, а
> кто хуже, а в том, что с нуля «догнать и обогнать»
> gcc у llvm пока что не получилось. за более чем десять
> лет разработки. потому нет, ни разу не проще «бросить gcc и
> сделать с нуля».Ну ёпрст, по той же логике и gcc не догоняет clang, ибо у него нет всех фич, которые есть у clang/llvm. Ни один из них не является, как это там, proper subset'ом другого. Так как, будем выбирать инструмент под задачу (gcc собирать прошивки для avr'ок, шлангом собирать под линукс x86_64), или выбирать, где у gcc преимущество?
я всё ещё не теряю надежды вернуть беседу к исходному тезису: «проще с нуля».
> я всё ещё не теряю надежды вернуть беседу к исходному тезису: «проще
> с нуля».А теперь вспомним ещё
> потому что все устали от GCC с его кретинскими архитектурой, документацией и APIЧтобы это починить - проще с нуля. Нет?
>> я всё ещё не теряю надежды вернуть беседу к исходному тезису: «проще
>> с нуля».
> А теперь вспомним ещё
>> потому что все устали от GCC с его кретинскими архитектурой, документацией и API
> Чтобы это починить - проще с нуля. Нет?так вот я привёл пример, где начали с нуля и за >10 лет gcc ещё не догнали. совершенно неважно, есть ли у них что-то лучше, факт тот, что «с нуля» обозначает «умеет всё то же самое с тем же качеством». а если вдобавок что-то лучше умеет — ну ок, бонус.
тут, конечно, могут сказать, что llvm и не старался уметь всё, что умеет gcc. конечно. а если бы старался — был бы не менее уродливым монстром (он, правда, и сейчас не шибко на конкурс красоты пригоден), нежели gcc.
так вот, возвращаемся опять к началу: нет, с нуля не проще. делать кастрата — это да, возможно, проще. но интересует не кастрат.
> так вот, возвращаемся опять к началу: нет, с нуля не проще. делать
> кастрата — это да, возможно, проще. но интересует не кастрат.Так где ж он кастрат-то? Свою задачу выполняет, выполняет её хорошо. Задачи объять все поддерживаемые архитектуры нет, и славно, мне под обычные десктопы компилятор нужен.
От поддержки соляриса я бы не отказался, впрочем, но это так, специфика задач.
> Так где ж он кастрат-то?(вздыхает) умеет всё, что умеет gcc? нет? если брать за точку отсчёта gcc — получается кастрат.
> (вздыхает) умеет всё, что умеет gcc? нет? если брать за точку отсчёта
> gcc — получается кастрат.Ты под ответ подгоняешь, что ли?
> Ты под ответ подгоняешь, что ли?нет, это ты упорно пытаешься говорить не о том, о чём разговор идёт. а я не менее упорно пытаюсь тебя вернуть назад. а ты опять начинаешь про «меня устраивает», о чём речь вообще не шла.
Речь шла, раз уж на то пошло, о том, что у gcc кривое API, документация и архитектура. Всё это в llvm/clang не то чтоб починено, но значительно лучше, чем у gcc, да.Ну и да, если рассуждать формально, то чем заниматься бесконечным рефакторингом по готовой кодовой базе, пытаясь починить API и архитектуру, проще переписать с нуля, не так ли?
Так что кто тут ещё не о том.
> Речь шла, раз уж на то пошло, о том, что у gcc
> кривое API, документация и архитектура. Всё это в llvm/clang не то
> чтоб починено, но значительно лучше, чем у gcc, да.потому что llvm — кастрат. сравнивать «лучше/хуже» будет иметь смысл только когда llvm научится делать всё то же самое, что делает gcc, и как минимум не хуже. а до тех пор даже однозначно ответить на вопрос: «а может, потому и лучше, что фич меньше?» не выйдет — нет материала для полноценного сравнения.
апи и архитектура имеют свойство превращаться в навоз с возрастанием количества фич.
> Ну и да, если рассуждать формально, то чем заниматься бесконечным рефакторингом по
> готовой кодовой базе, пытаясь починить API и архитектуру, проще переписать с
> нуля, не так ли?пока что ни одного примера, подтверждающего это утверждение по отношению к gcc, нет. кастраты не считаются, потому что их невозможно сравнить по всем фичам.
> Так что кто тут ещё не о том.
в основном — ты. потому что упорно пытаешься свернуть на «лучше/хуже» и «мне хватает», а речь совсем о другом. о том, что доказательства утверждения «проще переделать с нуля» — нет. самый ближайший собрат gcc — за десять лет не смог получить все фичи, которые есть у gcc, и поэтому в сравнении проиграл ещё на старте.
> потому что llvm — кастрат. сравнивать «лучше/хуже» будет иметь смысл только
> когда llvm научится делать всё то же самое, что делает gcc,
> и как минимум не хуже.Почему? Если зафиксировать критерии сравнения, то прекрасно можно сравнивать. Можно сравнивать размер и скорость сгенерированного кода под arm или x86, можно сравнивать поддержку новых стандартов, можно сравнивать скорость компиляции, можно сравнивать качество и удобство ошибок компиляции, можно сравнивать встраиваемость, можно сравнивать поддержку различных архитектур, в конце концов. Зачем сравнивать всё вместе и сразу-то? Как правило, редко когда из этого списка нужно всё и сразу.
> апи и архитектура имеют свойство превращаться в навоз с возрастанием количества фич.
Время покажет.
> в основном — ты. потому что упорно пытаешься свернуть на «лучше/хуже» и
> «мне хватает», а речь совсем о другом. о том, что доказательства
> утверждения «проще переделать с нуля» — нет. самый ближайший собрат gcc
> — за десять лет не смог получить все фичи, которые есть
> у gcc, и поэтому в сравнении проиграл ещё на старте.Я утверждаю, что такой критерий некорректен и не имеет смысла.
> Почему? Если зафиксировать критерии сравнения, то прекрасно можно сравнивать.можно, конечно. можно даже сравнивать квадратное и синее. желательно — в присутствии хаскелистов, пусть помучаются.
> Зачем сравнивать всё вместе и сразу-то?
потому что иначе сравнение правильно называется «читерство». самоочевидно, что мой компилятор, умеющий только компилировать «приветмир» — будет иметь намного более понятный API, намного более быстрый код и так далее. именно за счёт того, что он окромя «приветмира» другие фичи не реализует.
сравнивать же — если нет охоты читерить — имеет смысл только когда проект помоложе догонит проект постарше по количеству фич. иначе — как я уже писал — невозможно ответить на вопрос, лучше ли архитектура потому, что делали с нуля и вдумчиво, или просто потому, что она не умеет всех фич и потому не обросла навозом.
а без ответа на последний вопрос невозможно ответить и на основной — проще и лучше ли просто начать с нуля.
> Как правило, редко когда из этого списка нужно всё и сразу.
а это в данном случае неважно. важно то, что в разрезе данного разговора llvm попросту выпадает из сравнений, потому что не умеет всё то, что умеет gcc. при этом совершенно неважно, умеет ли он некоторые вещи, которые умеет, лучше gcc, и имеет ли он вещи, которых нет в gcc. попросту несравним — потому что ещё не догнал.
> Я утверждаю, что такой критерий некорректен и не имеет смысла.
тогда то же самое относится и к утверждению из #87 — потому что ты заведомо откидываешь всё, что мешает ему быть истиной, настаивая на том, что мой игрушечный компилятор «приветмир» можно сравнивать с llvm, например, и на этом основании утверждать, что llvm — куча тормозного уродливого гуано.
> можно, конечно. можно даже сравнивать квадратное и синее. желательно — в присутствии
> хаскелистов, пусть помучаются.
> зафиксировать критерии
> зафиксировать критерииТип с обоих сторон оператора правильный будет, нормально.
А я уже сегодня с хаскелем намучался по поводу отсутствия нормальных модулей, спасибо, мне хватит.
>> Зачем сравнивать всё вместе и сразу-то?
> потому что иначе сравнение правильно называется «читерство». самоочевидно,
> что мой компилятор, умеющий только компилировать «приветмир» — будет
> иметь намного более понятный API, намного более быстрый код и так
> далее. именно за счёт того, что он окромя «приветмира» другие фичи
> не реализует.О, ну вот уже пошёл относительно конструктивный диалог на втором десятке комментариев в ветке.
Компиляторы приветмиров тоже хороши (см. DSL), однако, чем более близкие предметы мы сравниваем, тем проще. При этом предметы быть равными не обязаны, и кланги всякие с гцц этому вполне удовлетворяют, ИМХО.
А что до читерства - ну это как школьники в онлайн-стрелялках, право дело. Как только тебя чуть убили или ещё что, сразу кричи про читерство.
> сравнивать же — если нет охоты читерить — имеет смысл только когда
> проект помоложе догонит проект постарше по количеству фич. иначе — как
> я уже писал — невозможно ответить на вопрос, лучше ли архитектура
> потому, что делали с нуля и вдумчиво, или просто потому, что
> она не умеет всех фич и потому не обросла навозом.Нет, нет, и ещё раз нет.
Во-первых, тогда давай рассматривать не такие фичи, как «поддержка ATTiny23 и S/390», а просто «кроссплатформенность». Для ответа на вопрос выше о том, лучше ли архитектура потому, что руки и мозги у разработчиков прямее, этого хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не столь принципиально, если он вообще способен генерировать код под более чем одну платформу.
А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем в случае gcc, это вот хороший и позитивный знак, например. И в ряде приложений это куда важнее.
> а без ответа на последний вопрос невозможно ответить и на основной —
> проще и лучше ли просто начать с нуля.
>> Как правило, редко когда из этого списка нужно всё и сразу.
> а это в данном случае неважно. важно то, что в разрезе данного
> разговора llvm попросту выпадает из сравнений, потому что не умеет всё
> то, что умеет gcc. при этом совершенно неважно, умеет ли он
> некоторые вещи, которые умеет, лучше gcc, и имеет ли он вещи,
> которых нет в gcc. попросту несравним — потому что ещё не
> догнал.Хорошо, llvm с gcc сравнивать нельзя, а gcc-то с llvm можно хоть? Или вообще ни один компилятор ни с каким другим сравнивать нельзя, и вообще ничего сравнивать нельзя?
Это, если что, ирония над тем, что твои слова звучат как «если вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?
>> Я утверждаю, что такой критерий некорректен и не имеет смысла.
> тогда то же самое относится и к утверждению из #87 — потому
> что ты заведомо откидываешь всё, что мешает ему быть истиной, настаивая
> на том, что мой игрушечный компилятор «приветмир» можно сравнивать с llvm,
> например, и на этом основании утверждать, что llvm — куча тормозного
> уродливого гуано.Нет. Сначала надо определиться с задачами и критериями оценки. Вот что этого сразу не было сделано, это да, это проблема всего треда.
> О, ну вот уже пошёл относительно конструктивный диалог на втором десятке комментариев
> в ветке.mea culpa. забыл, что телепаторы ещё не изобрели.
> При этом предметы быть равными не обязаны, и
> кланги всякие с гцц этому вполне удовлетворяют, ИМХО.если сравнивать, скажем, как реализована поддержка некоего языка, или насколько хорош кодогенератор — вполне. а вот если сравнивать архитектуру — то сначала надо доказать, что архитектура gcc (ну да, мягко говоря, не образец красоты) стала такой только и исключительно потому, что хреново спланирована. а чтобы это доказать, надо реализовать в другом проекте всё то же самое, что умеет gcc, и как минимум на том же уровне (в том числе и кодогенератор, который должен быть по всем параметрам как минимум не хуже, чем у gcc). «теоретически оно может и ничего не препятствует, и особо менять ничего не надо» — не катит. теоретически много чего можно, а на практике начинают лезть подводные камни, из-за которых, в том числе, в архитектуре иногда появляется хтонический ужас.
> А что до читерства - ну это как школьники в онлайн-стрелялках, право
> дело. Как только тебя чуть убили или ещё что, сразу кричи
> про читерство.так вопрос же не в том, кто победит, вопрос в том, что иначе сравнение не имеет смысла: нечто с обрезаным фичсетом почти всегда можно сделать лучше и понятней, чем с необрезаным.
> Во-первых, тогда давай рассматривать не такие фичи, как «поддержка ATTiny23 и S/390»,
> а просто «кроссплатформенность».нет. именно поддержка *всех* платформ, которые умеет gcc.
> Для ответа на вопрос выше о том, лучше
> ли архитектура потому, что руки и мозги у разработчиков прямее, этого
> хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не
> столь принципиально, если он вообще способен генерировать код под более чем
> одну платформу.принципиально. тут пример с VLIW уже приводили. штука в том, что разные архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот так использовать можно, а так нельзя — и опа! в регистровом аллокаторе появляется костыль для этой архитектуры. у кого-то вот такая последовательность команд работает медленней, чем вот нетакая — и опа! в кодогенераторе появляется костыль со специальным случаем. и так далее.
вот именно потому я и говорю, что сначала надо реализовать всё, в полной мере и как минимум не хуже — чтобы все эти костыли на место воткнуть. и тогда уже посмотреть, что осталось от изначально красивого и изящного API с кодом.
> А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем
> в случае gcc, это вот хороший и позитивный знак, например. И
> в ряде приложений это куда важнее.и это никак не отвечает на вопрос «лучше и проще ли было переделать gcc с нуля». потому что, например, запиливаться быстрее они могут именно потому, что у llvm местами обрезаный (по сравнению с gcc) фичсет. см. выше про всякие костыли.
> Хорошо, llvm с gcc сравнивать нельзя, а gcc-то с llvm можно хоть?
> Или вообще ни один компилятор ни с каким другим сравнивать нельзя,
> и вообще ничего сравнивать нельзя?
> Это, если что, ирония над тем, что твои слова звучат как «если
> вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?см. выше. одинаковые по выхлопу вещи можно делать разными путями. вот пути и есть смысл сравнивать. но чтобы эти пути сравнивать — сначала выхлоп должен быть одинаковый. в данном случае «одинаковый» — это все архитектуры, и на каждой у нового проекта код должен быть как минимум не хуже, чем у старого проекта. потому что если код хуже — опять не ясно: может, он хуже как раз потому, что в старом проекте всунули мегакостыль в оптимизатор, который уродливый, но зато делает код чуть лучше?
> если сравнивать, скажем, как реализована поддержка некоего языка, или насколько хорош кодогенератор
> — вполне. а вот если сравнивать архитектуру — то сначала надо
> доказать, что архитектура gcc (ну да, мягко говоря, не образец красоты)
> стала такой только и исключительно потому, что хреново спланирована.Кому надо? Условному контрибьютору это не надо. Условный контрибьютор пойдёт контрибьютить в clang с хорошей архитектурой, документацией и C++ везде, а не последний год, или сколько там.
Только тут и сравнивать не нужно, доказали — всё, чего тут ещё обсуждать.
Интересно, почему в ИСП РАН мой бывший сокурсник занимается всякими клёвыми ништяками над компиляторами на примере clang/llvm, а не gcc? Наверное, потому что первый лучше [для этой задачи]?
> а чтобы
> это доказать, надо реализовать в другом проекте всё то же самое,
> что умеет gcc, и как минимум на том же уровне (в
> том числе и кодогенератор, который должен быть по всем параметрам как
> минимум не хуже, чем у gcc)Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой архитектуры, но тогда, правда, и реализовывать ничего больше не придётся. Доказывать forall-утверждения позитивным примером вообще очень неблагодарное дело.
Прошу прощенья, если я «доказать» слишком серьёзно воспринимаю.
> так вопрос же не в том, кто победит, вопрос в том, что
> иначе сравнение не имеет смысла: нечто с обрезаным фичсетом почти всегда
> можно сделать лучше и понятней, чем с необрезаным.Максимум обрезанный там список платформ, а влияние его длины (при его нетривиальности) на архитектуру сильно неочевидно, мягко скажем.
>> Для ответа на вопрос выше о том, лучше
>> ли архитектура потому, что руки и мозги у разработчиков прямее, этого
>> хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не
>> столь принципиально, если он вообще способен генерировать код под более чем
>> одну платформу.
> принципиально. тут пример с VLIW уже приводили.Вот, разве что, VLIW, о котором я и думал, но их разных видов на рынке сейчас вроде не особо много. Могу ошибаться тут, впрочем.
> штука в том, что разные
> архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот
> так использовать можно, а так нельзя — и опа! в регистровом
> аллокаторе появляется костыль для этой архитектуры.А не должно быть никаких костылей для этого при нормальном планировании.
> у кого-то вот такая последовательность
> команд работает медленней, чем вот нетакая — и опа! в кодогенераторе
> появляется костыль со специальным случаем. и так далее.И тут.
>> А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем
>> в случае gcc, это вот хороший и позитивный знак, например. И
>> в ряде приложений это куда важнее.
> и это никак не отвечает на вопрос «лучше и проще ли было
> переделать gcc с нуля». потому что, например, запиливаться быстрее они могут
> именно потому, что у llvm местами обрезаный (по сравнению с gcc)
> фичсет. см. выше про всякие костыли.Если от фронтенда зависит кодогенератор, то я даже не знаю, что тут сказать. Как capture-init из C++14, или там, не знаю, расширенный noexcept оттуда же вообще относится к кодогенерации? Первая вещь разворачивается на этапе компиляции в обычную структурку, вторая вообще по определению компил-тайм.
>[оверквотинг удален]
>> Это, если что, ирония над тем, что твои слова звучат как «если
>> вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?
> см. выше. одинаковые по выхлопу вещи можно делать разными путями. вот пути
> и есть смысл сравнивать. но чтобы эти пути сравнивать — сначала
> выхлоп должен быть одинаковый. в данном случае «одинаковый» — это все
> архитектуры, и на каждой у нового проекта код должен быть как
> минимум не хуже, чем у старого проекта. потому что если код
> хуже — опять не ясно: может, он хуже как раз потому,
> что в старом проекте всунули мегакостыль в оптимизатор, который уродливый, но
> зато делает код чуть лучше?Локальные мегакостыли в оптимизаторе глобальную архитектуру трогать не должны, а в гцц, поговаривают, системные проблемы.
> Кому надо? Условному контрибьютору это не надо. Условный контрибьютор пойдёт контрибьютить
> в clang с хорошей архитектурой, документацией и C++ везде, а не
> последний год, или сколько там.или в gcc, где всё ещё нормальный C, а не C++ везде и дурацкий пакованый формат IR, например. дурацкие gimple и rtl, может, приятней окажутся.
> Только тут и сравнивать не нужно, доказали — всё, чего тут ещё
> обсуждать.ну, «доказали» — это если все ушли на фронт, пилить llvm, а gcc помер. я пока что этого не наблюдаю.
> Интересно, почему в ИСП РАН мой бывший сокурсник занимается всякими клёвыми ништяками
> над компиляторами на примере clang/llvm, а не gcc? Наверное, потому что
> первый лучше [для этой задачи]?потому что llvm умеет меньше гитик, и за счёт этого меньше оброс костылями, например?
> Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой
> архитектурыутверждение, что «лучше начать с нуля» — неявно это постулирует. потому что иначе никак не может быть лучше с нуля, ибо в конце получится то же самое по степени УЖОСА.
> Максимум обрезанный там список платформ, а влияние его длины (при его нетривиальности)
> на архитектуру сильно неочевидно, мягко скажем.однако возможно.
>> штука в том, что разные
>> архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот
>> так использовать можно, а так нельзя — и опа! в регистровом
>> аллокаторе появляется костыль для этой архитектуры.
> А не должно быть никаких костылей для этого при нормальном планировании.я тоже хотел бы жить в мире, где всё идеально. а на практике часто получается, что не должно — а есть.
> Если от фронтенда зависит кодогенератор, то я даже не знаю, что тут
> сказать. Как capture-init из C++14, или там, не знаю, расширенный noexcept
> оттуда же вообще относится к кодогенерации? Первая вещь разворачивается на этапе
> компиляции в обычную структурку, вторая вообще по определению компил-тайм.а так, что, например (абстрактный), при некоторых условиях и знании потрохов кодогенератора можно некоторые фичи сделать эффективней. преобразование в IR — это всё равно потеря некоторой части информации. которую кодогенератору иногда надо восстанавливать. а иногда можно — зная, как сделан кодогенератор — облегчить ему эту работу. там фичка, тут фичка — в итоге пользователи в выигрыше, потому что компилирует чуть быстрее, например, или делает код чуть лучше. а вот сам компилятор стал захламлённей.
> Локальные мегакостыли в оптимизаторе глобальную архитектуру трогать не должны, а в гцц,
> поговаривают, системные проблемы.см. выше. в идеале оно всё, конечно, так. а на практике *может* оказаться иначе. именно поэтому я настаиваю на двух вещах: полном списке платформ и сгенерированном коде как минимум не хуже. чтобы наглядно увидеть, зря ли костыли накостылили и можно ли было без них обойтись, сохранив весь фичсет. и чего это могло стоить в других местах (скорость, память, etc).
> или в gcc, где всё ещё нормальный C, а не C++ вездеКак будто что-то плохое (что C++).
> и дурацкий пакованый формат IR, например. дурацкие gimple и rtl, может,
> приятней окажутсяЧем дурацкий? Впрочем, не знаю, как у тебя, а у меня опыта о профитах IR перед гимплом вот так сходу рассуждать нет. Погуглю, пойму, перескажу, это да, но не сходу.
> ну, «доказали» — это если все ушли на фронт, пилить llvm, а
> gcc помер. я пока что этого не наблюдаю.Странные доказательства, конечно. Я к таким не привык.
> потому что llvm умеет меньше гитик, и за счёт этого меньше оброс
> костылями, например?Умеет меньше чего?
>> Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой
>> архитектуры
> утверждение, что «лучше начать с нуля» — неявно это постулирует.Нет, утверждение это постулирует лишь то, что проще всего изменить архитектуру переписыванием с нуля.
> потому
> что иначе никак не может быть лучше с нуля, ибо в
> конце получится то же самое по степени УЖОСА.Неочевидное утверждение.
>> Максимум обрезанный там список платформ, а влияние его длины (при его нетривиальности)
>> на архитектуру сильно неочевидно, мягко скажем.
> однако возможно.Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от его существования.
> я тоже хотел бы жить в мире, где всё идеально. а на
> практике часто получается, что не должно — а есть.Однако, чем лажи меньше, тем оно ближе к идеальности.
> а так, что, например (абстрактный), при некоторых условиях и знании потрохов кодогенератора
> можно некоторые фичи сделать эффективней. преобразование в IR — это всё
> равно потеря некоторой части информации. которую кодогенератору иногда надо восстанавливать.
> а иногда можно — зная, как сделан кодогенератор — облегчить ему
> эту работу. там фичка, тут фичка — в итоге пользователи в
> выигрыше, потому что компилирует чуть быстрее, например, или делает код чуть
> лучше. а вот сам компилятор стал захламлённей.Так это слегка так обратная задача допиливания кодогенератора под потребности фронтенда, не? Корректная реализация возможностей важнее, потом уже и оптимизировать можно.
> см. выше. в идеале оно всё, конечно, так. а на практике *может*
> оказаться иначе. именно поэтому я настаиваю на двух вещах: полном списке
> платформ и сгенерированном коде как минимум не хуже. чтобы наглядно увидеть,
> зря ли костыли накостылили и можно ли было без них обойтись,
> сохранив весь фичсет. и чего это могло стоить в других местах
> (скорость, память, etc).Насчёт платформ мы уже обобсуждались, а что до кода — когда дело не доходит до заточенных под gcc бенчмарков, опирающихся на его особенности, и до специфичных приложений (вроде openmp, с которым у clang по тем же лицензионным соображениям напряг), оба компилятора выдают в среднем одинаковый с точки зрения производительности код. И бенчи в среднем со мной согласны (см. http://www.phoronix.com/scan.php?page=news_item&px=MTgzNDE ), да и мой опыт это показывает, причём, с достаточно разными паттернами работы с процессором и памятью. Например, NLP-движок, активно дёргающий разные области среди пары сотен гигабайт памяти, или какой-нибудь градиентный спуск с многократным и хорошо векторизуемым вычислением всякого матана по ходу. Разница во времени в пределах статистической погрешности.
Впрочем, непосредственно в процессе разработки скорость самой компиляции и качество сообщений об ошибках куда важнее, как по мне.
Качество сообщений так вообще отличный индикатор костыльности архитектуры, спасибо плюсам — причиной ошибки может быть совсем другой контекст, чем тот, где она появилась. Надо уметь это сохранять, протаскивать по процессу компиляции и понимать ещё.
>> или в gcc, где всё ещё нормальный C, а не C++ везде
> Как будто что-то плохое (что C++).с моей точки зрения — однозначно плохое: я ненавижу c++ и не скрываю этого.
>> и дурацкий пакованый формат IR, например. дурацкие gimple и rtl, может,
>> приятней окажутся
> Чем дурацкий?тем, что пакованый. и поэтому есть кучка кода, которая занимается его упаковкой и распаковкой. зачем там в IR все эти битовые поля и хитрые форматы команд? нет, никогда не было и никогда не будет железа, исполняющего llvm'овский IR. тем не менее его зачем-то усердно моделировали как систему команд для какого-то странного камня, усердно пакуя. я лично оценочно и неаргументированно считаю это дурью.
>> ну, «доказали» — это если все ушли на фронт, пилить llvm, а
>> gcc помер. я пока что этого не наблюдаю.
> Странные доказательства, конечно. Я к таким не привык.ну так если llvm и лучше, и красивше — логично будет ожидать, что народ бросит кусок мамонтятины и пойдёт пилить новое, а с мамонтятиной останутся три инвалида и пёс барбос. однако пока что этого не наблюдается.
>> потому что llvm умеет меньше гитик, и за счёт этого меньше оброс
>> костылями, например?
> Умеет меньше чего?gcc — оно подразумевается в контексте обсуждения.
>>> Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой
>>> архитектуры
>> утверждение, что «лучше начать с нуля» — неявно это постулирует.
> Нет, утверждение это постулирует лишь то, что проще всего изменить архитектуру переписыванием
> с нуля.тогда я неверно его понял, видимо.
> Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от
> его существования.именно поэтому я и говорю на протяжении кучи постов, что вместо теорезирования нужно использовать практику. для чего llvm'у следует сначала научиться всем гитикам gcc.
>> я тоже хотел бы жить в мире, где всё идеально. а на
>> практике часто получается, что не должно — а есть.
> Однако, чем лажи меньше, тем оно ближе к идеальности.я подозреваю, что почти никто не делает проект с прицелом «а запихаем-ка побольше лажи!» лажа возникает в процессе адаптации идеала к неидеальному миру.
> Так это слегка так обратная задача допиливания кодогенератора под потребности фронтенда,
> не? Корректная реализация возможностей важнее, потом уже и оптимизировать можно.а потом может оказаться, что вариантов осталось примерно два: или полностью переделать кодоген, потому что упс… не учли кое-что. или добавить костылик. а перепись кодогена — куча человеко-лет.
новый проект, кстати, не факт, что учёл все шишки предшественника.
>[оверквотинг удален]
> не доходит до заточенных под gcc бенчмарков, опирающихся на его особенности,
> и до специфичных приложений (вроде openmp, с которым у clang по
> тем же лицензионным соображениям напряг), оба компилятора выдают в среднем одинаковый
> с точки зрения производительности код. И бенчи в среднем со мной
> согласны (см. http://www.phoronix.com/scan.php?page=news_item&px=MTgzNDE ), да и мой
> опыт это показывает, причём, с достаточно разными паттернами работы с процессором
> и памятью. Например, NLP-движок, активно дёргающий разные области среди пары сотен
> гигабайт памяти, или какой-нибудь градиентный спуск с многократным и хорошо векторизуемым
> вычислением всякого матана по ходу. Разница во времени в пределах статистической
> погрешности.я не говорил, что у llvm код хуже (или лучше). пока что это и неважно, потому что многого другого, необходимого для сравнения в рамках данного обсуждения, всё равно нет.
> Впрочем, непосредственно в процессе разработки скорость самой компиляции и качество сообщений
> об ошибках куда важнее, как по мне.ну, -O0 вполне себе быстрый. а сообщения об ошибках благодаря шаблонной магии в c++ всегда были какими-то заклинаниями на древнешумерском. когда D примерно по тем же причинам начинает просираться подобными заклинаниями, тоже хочется кого-то убить. или хотя бы спрятаться в бомбоубежище.
> Качество сообщений так вообще отличный индикатор костыльности архитектуры, спасибо плюсам
> — причиной ошибки может быть совсем другой контекст, чем тот, где
> она появилась. Надо уметь это сохранять, протаскивать по процессу компиляции и
> понимать ещё.вообще, я имею мнение, что это индикатор бардака в партитуре, а не в оркестре. но обосновать не могу, потому что дизайнер языков из меня никакой.
> с моей точки зрения — однозначно плохое: я ненавижу c++ и не
> скрываю этого.Сочувствую. А тред обещает стать ещё бессмысленнее и горячее.
На самом деле я тоже ненавижу C++, но все остальные императивные и/или сиподобные языки я ненавижу ещё больше.
> тем, что пакованый. и поэтому есть кучка кода, которая занимается его упаковкой
> и распаковкой.Занимается и занимается себе, кушать не просит, компилирует быстро.
> зачем там в IR все эти битовые поля и
> хитрые форматы команд? нет, никогда не было и никогда не будет
> железа, исполняющего llvm'овский IR. тем не менее его зачем-то усердно моделировали
> как систему команд для какого-то странного камня, усердно пакуя. я лично
> оценочно и неаргументированно считаю это дурью.Нормальное решение — рассуждать в терминах некоей абстрактной машины. Впрочем, опять же, на вливы на базе этого я бы посмотрел.
> ну так если llvm и лучше, и красивше — логично будет ожидать,
> что народ бросит кусок мамонтятины и пойдёт пилить новое, а с
> мамонтятиной останутся три инвалида и пёс барбос. однако пока что этого
> не наблюдается.По-моему, llvm вполне себе отлично пилится, в том числе и в институтах всяких, что является достаточно хорошим критерием.
> gcc — оно подразумевается в контексте обсуждения.
Это я понимаю. Что за гитики-то?
> тогда я неверно его понял, видимо.
Что тут понимать. Неважно, какая архитектура и как к такой жизни люди вообще пришли, проще исправить, переписав всё с нуля, получится быстрее и надёжнее.
>> Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от
>> его существования.
> именно поэтому я и говорю на протяжении кучи постов, что вместо теорезирования
> нужно использовать практику. для чего llvm'у следует сначала научиться всем гитикам
> gcc.На протяжении кучи постов не перестаю удивляться этому логическому переходу.
>>> я тоже хотел бы жить в мире, где всё идеально. а на
>>> практике часто получается, что не должно — а есть.
>> Однако, чем лажи меньше, тем оно ближе к идеальности.
> я подозреваю, что почти никто не делает проект с прицелом «а запихаем-ка
> побольше лажи!» лажа возникает в процессе адаптации идеала к неидеальному миру.Иногда лажа просто сама возникает вследствие сущности, которую требуется адаптировать. Прицел «а сделаем-ка фигак-фигак-и-в-продакш^Wдебиан, а там посмотрим» вполне себе имеет место быть.
> а потом может оказаться, что вариантов осталось примерно два: или полностью переделать
> кодоген, потому что упс… не учли кое-что.Опыт показывает, что такое бывает настолько исключительно редко при корректной изначальной архитектуре, что можно это не учитывать.
> новый проект, кстати, не факт, что учёл все шишки предшественника.
Ну с этим никто не спорит. Поэтому я когда-то давно уже и написал, что поживём — увидим.
> я не говорил, что у llvm код хуже (или лучше). пока что
> это и неважно, потому что многого другого, необходимого для сравнения в
> рамках данного обсуждения, всё равно нет.Да хватит уже цепляться к этим архитектурам. Давай уже рассматривать «компилятор для x86 и производных».
> ну, -O0 вполне себе быстрый.
А в clang быстрее.
> а сообщения об ошибках благодаря шаблонной магии
> в c++ всегда были какими-то заклинаниями на древнешумерском.На самом деле их даже у гцц можно читать вполне, если не упарываться по шаблонам серьёзно.
Но я вот, к сожалению, упарываться люблю.
> когда D примерно
> по тем же причинам начинает просираться подобными заклинаниями, тоже хочется кого-то
> убить. или хотя бы спрятаться в бомбоубежище.Нет чтоб фронтенд сделать к llvm!
> вообще, я имею мнение, что это индикатор бардака в партитуре, а не
> в оркестре. но обосновать не могу, потому что дизайнер языков из
> меня никакой.clang примером показывает, что можно сделать лучше.
>> с моей точки зрения — однозначно плохое: я ненавижу c++ и не
>> скрываю этого.
> Сочувствую.спасибо, я не страдаю.
> На самом деле я тоже ненавижу C++, но все остальные императивные и/или
> сиподобные языки я ненавижу ещё больше.я лично с удовольствием убежал на D: у него хотя бы метапрограммирование можно и писать без тяжёлых наркотиков, и читать без длительных медитаций.
> Нормальное решение — рассуждать в терминах некоей абстрактной машины.
до этого момента — да. а вот пытаться её эмулировать в том числе и битовой упаковкой команд — уже нет.
>> ну так если llvm и лучше, и красивше — логично будет ожидать,
>> что народ бросит кусок мамонтятины и пойдёт пилить новое, а с
>> мамонтятиной останутся три инвалида и пёс барбос. однако пока что этого
>> не наблюдается.
> По-моему, llvm вполне себе отлично пилится, в том числе и в институтах
> всяких, что является достаточно хорошим критерием.критерием чего? это утверждение не имеет никакой связи с моим.
>> gcc — оно подразумевается в контексте обсуждения.
> Это я понимаю. Что за гитики-то?архитектуры-с.
>> тогда я неверно его понял, видимо.
> Что тут понимать. Неважно, какая архитектура и как к такой жизни люди
> вообще пришли, проще исправить, переписав всё с нуля, получится быстрее и
> надёжнее.пока что ни у кого не получилось.
>>> Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от
>>> его существования.
>> именно поэтому я и говорю на протяжении кучи постов, что вместо теорезирования
>> нужно использовать практику. для чего llvm'у следует сначала научиться всем гитикам
>> gcc.
> На протяжении кучи постов не перестаю удивляться этому логическому переходу.тогда мы всё-таки возвращаемся к тому, что llvm — оверинжениреное гуано с невнятным апи и атомным говнокодом. потому что мой компилятор «приветмира» намного меньше, проще, быстрее, и для «приветмира» генерит почти идеальный код даже для 51-х.
> Иногда лажа просто сама возникает вследствие сущности, которую требуется адаптировать.
> Прицел «а сделаем-ка фигак-фигак-и-в-продакш^Wдебиан, а там посмотрим» вполне
> себе имеет место быть.причём практически везде.
>> а потом может оказаться, что вариантов осталось примерно два: или полностью переделать
>> кодоген, потому что упс… не учли кое-что.
> Опыт показывает, что такое бывает настолько исключительно редко при корректной изначальной
> архитектуре, что можно это не учитывать.хм. а мне мой многолетний опыт разработки JIT-ов показывает, что «как лучше» при разрастании проекта всё равно превращается в «как всегда». потому что начинали, например, на x86, а потом пришли армы с условными флажками в каждой инструкции — и кодоген оказался… ну, скажем так, не очень хорошим в новых условиях. ок, сделали по-новому… а тут тумбочки, зараза, пришли, на которые опять никто не рассчитывал.
нет, возможно, у тех, у кого есть неограниченое время, неограниченый бюджет и будущескоп — у тех всё сразу отлично получается.
> Да хватит уже цепляться к этим архитектурам. Давай уже рассматривать «компилятор для
> x86 и производных».нет, не давай. это ничем не отличается от моего предложения рассматривать мой компилятор «приветмира».
>> ну, -O0 вполне себе быстрый.
> А в clang быстрее.быстрее. не то, чтобы сильно намного, правда. по крайней мере C++ — быстрее. и тут я испытываю неудержимое желание тоже перейти на аргументы «но мне пофигу, потому что я не ребилдю весь проект после каждого изменения».
>> а сообщения об ошибках благодаря шаблонной магии
>> в c++ всегда были какими-то заклинаниями на древнешумерском.
> На самом деле их даже у гцц можно читать вполне, если не
> упарываться по шаблонам серьёзно.а без шаблонов там всё достаточно очевидно. ну за исключением когда gcc начинает рассказывать какие-то прохладные истории про vmt, например, что очень сильно помогает, если не знать, в каких случаях он так жалуется. правда, не знаю, что в тех же случаях clang говорит и воспроизводить лень.
>> когда D примерно
>> по тем же причинам начинает просираться подобными заклинаниями, тоже хочется кого-то
>> убить. или хотя бы спрятаться в бомбоубежище.
> Нет чтоб фронтенд сделать к llvm!кагбэ есть. и отдельный есть, и ldc есть, и gdc есть. все используют один и тот же официальный фронтэнд для своих бэкэндов.
>> вообще, я имею мнение, что это индикатор бардака в партитуре, а не
>> в оркестре. но обосновать не могу, потому что дизайнер языков из
>> меня никакой.
> clang примером показывает, что можно сделать лучше.ну да, даже хреновую партитуру можно научиться сносно играть. но партитура всё равно…
> я лично с удовольствием убежал на D: у него хотя бы метапрограммирование
> можно и писать без тяжёлых наркотиков, и читать без длительных медитаций.Я плюсы знаю достаточно хорошо для того, чтобы и читать без медитация, и наркотики синтезировать внутривенно.
А вообще, личная практика показывает, что любой инструмент после некоторого освоения и опыта использования начинает вызывать ненависть. Серебряной пули нет.
> критерием чего? это утверждение не имеет никакой связи с моим.
> ожидать, что народ ... пойдёт пилить новое
> llvm вполне себе отлично пилится
> утверждение не имеет никакой связи с моимЛадно.
> пока что ни у кого не получилось.
Как будто медленным и долгим рефакторингом получается, ага. Твоей же логикой, не с чем сравнивать.
> тогда мы всё-таки возвращаемся к тому, что llvm — оверинжениреное гуано с
> невнятным апи и атомным говнокодом. потому что мой компилятор «приветмира» намного
> меньше, проще, быстрее, и для «приветмира» генерит почти идеальный код даже
> для 51-х.Тебе важны архитектуры, но это, мягко скажем, не так и не всё. Зачем ты прикидываешься дурачком с приветмиром и доводишь до абсурда? Не, можно построить соответствующую формальную систему, чтобы всё разумно и соответствующе действительности, но, опять же, формально это делать больно трудоёмко для казуального спора на опеннете.
> хм. а мне мой многолетний опыт разработки JIT-ов показывает, что «как лучше»
> при разрастании проекта всё равно превращается в «как всегда». потому что
> начинали, например, на x86, а потом пришли армы с условными флажками
> в каждой инструкции — и кодоген оказался… ну, скажем так, не
> очень хорошим в новых условиях. ок, сделали по-новому… а тут тумбочки,
> зараза, пришли, на которые опять никто не рассчитывал.
> нет, возможно, у тех, у кого есть неограниченое время, неограниченый бюджет и
> будущескоп — у тех всё сразу отлично получается.Я, конечно, JIT'ы не пилил, но вот кодогенераторы делать приходилось, и не раз. Мой опыт, в общем, слегка с вышеприведённым не согласен.
> нет, не давай. это ничем не отличается от моего предложения рассматривать мой
> компилятор «приветмира».На самом деле отличается.
> быстрее. не то, чтобы сильно намного, правда. по крайней мере C++ —
> быстрее. и тут я испытываю неудержимое желание тоже перейти на аргументы
> «но мне пофигу, потому что я не ребилдю весь проект после
> каждого изменения».Я тоже, но темплейтомагия имеет плохое свойство находиться в хедерах.
> а без шаблонов там всё достаточно очевидно.
А без ошибок ещё очевиднее.
> ну за исключением когда gcc
> начинает рассказывать какие-то прохладные истории про vmt, например, что очень сильно
> помогает, если не знать, в каких случаях он так жалуется. правда,
> не знаю, что в тех же случаях clang говорит и воспроизводить
> лень.Это в каких, например? Я с непонятными прохладными на эту тему не сталкивался.
> ну да, даже хреновую партитуру можно научиться сносно играть. но партитура всё
> равно…Да какая разница, это уже менеджеру объяснять надо. От компилятора требуется выполнять поставленную задачу и, желательно, как можно больше помогать в этом. Ворнингами умными, скоростью компиляции, качеством диагностик, вот этим всем.
> Я плюсы знаю достаточно хорошо для того, чтобы и читать без медитация,
> и наркотики синтезировать внутривенно.да ты марсианин. или александреску. хотя это, наверное, одно и то же.
> А вообще, личная практика показывает, что любой инструмент после некоторого освоения и
> опыта использования начинает вызывать ненависть. Серебряной пули нет.вопрос в количестве ненависти. ну, и возможности поправить инструмент. D я таки ещё могу подпилить под свои нужды (ну да, я псих, я правлю компилятор, если там нет нужной мне фичи, и она не очень сложно добавляется). с C++ такое не прокатит: и компиляторы большие, и его таки используют «в продакшэне», в отличие от D.
> Ладно.
цитировать иногда полезно полностью, а то высказывание может волшебным образом изменить смысл.
>> пока что ни у кого не получилось.
> Как будто медленным и долгим рефакторингом получается, ага.а про это разговор и не шёл.
> Твоей же логикой, не с чем сравнивать.
так и не начинали.
> Тебе важны архитектуры, но это, мягко скажем, не так и не всё.
и опять не так. не «мне важны архитектуры», а «чтобы полноценно сравнивать, нужно иметь все фичи, в том числе и архитектуры». я уже кучу раз пояснял, почему.
> Зачем ты прикидываешься дурачком с приветмиром и доводишь до абсурда?
потому что ты упорно делаешь то же самое, предлагая сравнивать несравнимое.
>> нет, не давай. это ничем не отличается от моего предложения рассматривать мой
>> компилятор «приветмира».
> На самом деле отличается.ага. количеством вырезаных фич. не вижу, почему в контексте темы одни фичи вырезать можно, а другие нет.
>> ну за исключением когда gcc
>> начинает рассказывать какие-то прохладные истории про vmt, например, что очень сильно
>> помогает, если не знать, в каких случаях он так жалуется. правда,
>> не знаю, что в тех же случаях clang говорит и воспроизводить
>> лень.
> Это в каких, например? Я с непонятными прохладными на эту тему не
> сталкивался.уже не помню точно. помню, что сталкивался и был весьма озадачен — то ли разные декларации класса в разных хидерах, то ли ещё что-то такое. которое, в общем, имеет отношение к vmt, но из ошибки совершенно непонятно, что за фигня.
> вопрос в количестве ненависти. ну, и возможности поправить инструмент. D я таки
> ещё могу подпилить под свои нужды (ну да, я псих, я
> правлю компилятор, если там нет нужной мне фичи, и она не
> очень сложно добавляется). с C++ такое не прокатит: и компиляторы большие,
> и его таки используют «в продакшэне», в отличие от D.Ну фиг знает, мне инструменты нужны либо, собственно, в продакшене, либо один комбаен пилить, где язык уже фиксирован по большому счёту, либо как средство обеспечения вычислительных экспериментов во всяком матане, где нужны библиотеки, и вообще, не до допиливания языка уже.
> цитировать иногда полезно полностью, а то высказывание может волшебным образом изменить
> смысл.Да вроде б и не поменялось. Ломанулись пилить же, использовать, и так далее. Ну да, gcc по-прежнему развивается. Кто-то ненавидит плюсы, кто-то любит gcc, мало ли причин у людей. Может, стокгольмский синдром у кого.
> и опять не так. не «мне важны архитектуры», а «чтобы полноценно сравнивать,
> нужно иметь все фичи, в том числе и архитектуры». я уже
> кучу раз пояснял, почему.Нет, чтобы полноценно сравнивать нужно договориться о том, что такое полноценное сравнение. Почему ты отказываешься от критерия «рассматриваем все компиляторы современного языка C++14 под платформу x86»? А, ну да, из такого критерия же gcc выпадает :)
Кроме шуток, мне очень сильно кажется, что ты пытаешься притянуть решение к ответу.> потому что ты упорно делаешь то же самое, предлагая сравнивать несравнимое.
Как «компиляторы для платформы x86» отлично сравнимые. И туда же ещё какой-нибудь icc добавится отлично, и какое-нибудь гуано мамонта под AIX. Мне вот надо сравнивать и выбирать, что в CC вписывать в мейкфайле, например.
> ага. количеством вырезаных фич. не вижу, почему в контексте темы одни фичи
> вырезать можно, а другие нет.Потому что компилятор от этого перестаёт быть компилятором плюсов. Если мы рассматриваем не компиляторы плюсов, а компиляторы под avr или компиляторы под более чем 50 платформ, то да, тогда про llvm можно сразу забыть, но зачем?
> уже не помню точно. помню, что сталкивался и был весьма озадачен —
> то ли разные декларации класса в разных хидерах, то ли ещё
> что-то такое. которое, в общем, имеет отношение к vmt, но из
> ошибки совершенно непонятно, что за фигня.Ну так за нарушение ODR компиляторы больно бьют и вообще не обязаны это диагностировать. Можно было вообще без ошибок остаться и получить очень милые вещи в рантайме.
> Почему ты отказываешься от критерия «рассматриваем все компиляторы современного
> языка C++14 под платформу x86»?потому что невозможно редуцировать gcc до этого состояния, выяснив историю добавления каждой строки кода и убрав всё, что не относится к x86. единственная реальная возможность привести проекты в соответствие — добавить отсутствующие фичи в llvm.
мы про #87, не забыл? не про то, кто лучше для какой-то платформы, а про то, что создать проект, *полностью* заменяющий gcc, но с лучшей архитектурой — проще с нуля. ключевые слова — «полностью заменяющий». поэтому пока llvm не умеет всего, что умеет gcc, и как минимум с таким же качеством — сравнивать тупо нечего.
>> ага. количеством вырезаных фич. не вижу, почему в контексте темы одни фичи
>> вырезать можно, а другие нет.
> Потому что компилятор от этого перестаёт быть компилятором плюсов.а без поддержки архитектур — перестаёт быть аналогом gcc и выпадает из условия #87.
Подожди, давай проще. Вот смотри, вот clang/llvm, оно на плюсах всё. А gcc, оно ж сишное почти целиком, сколько там плюсокода-то сейчас? Давай просто скажем, что это всё из-за выбора языка, и чего тянуть. Тогда кланг не станет аналогом вообще никогда, профит!
> Подожди, давай проще. Вот смотри, вот clang/llvm, оно на плюсах всё. А
> gcc, оно ж сишное почти целиком, сколько там плюсокода-то сейчас? Давай
> просто скажем, что это всё из-за выбора языка, и чего тянуть.
> Тогда кланг не станет аналогом вообще никогда, профит!а это тут при чём? для сравнения необходимо, чтобы были реализованы все фичи gcc. именно для того, чтобы увидеть, как это изуродовало (или не изуродовало) архитектуру llvm. это в итоге вполне можно сравнивать в отрыве от того, си там или кресты.
Почему? Выбор языка влияет на архитектуру не меньше, чем количество поддерживаемых архитектур, разве нет?
> Почему? Выбор языка влияет на архитектуру не меньше, чем количество поддерживаемых архитектур,
> разве нет?нет, конечно. влияет на реализацию аспектов выбраной архитектуры. однако фундаментальной разницы между объявлениями классов конструкциями языка или обмазыванием сишными макросами нет, это чистая косметика.
> нет, конечно. влияет на реализацию аспектов выбраной архитектуры. однако фундаментальной
> разницы между объявлениями классов конструкциями языка или обмазыванием сишными макросами
> нет, это чистая косметика.Это-то да, а какие-нибудь там темплейты позволяют просто по-другому писать код. Костыли там вставлять не придётся, не знаю.
В качестве примера крайнего случая, на хаскеле и на плюсах я код пишу сильно по-разному, например.
Только с архитектурами ты почему-то это понимаешь, а с языком — нет.
> Только с архитектурами ты почему-то это понимаешь, а с языком — нет.э? O_O
> нет, конечно. влияет на реализацию аспектов выбраной архитектуры. однако фундаментальной
> разницы между объявлениями классов конструкциями языка или обмазыванием сишными макросами
> нет, это чистая косметика.Сложно поверить.
Вот если взять редуцированный вариант - ассеблер и хаскель. Ну, вроде, если будешь писать тетрис на этих двух языках, получится что-то кардинально разное. В том числе, вроде, и по архитектуре.
С другой стороны, если возьмёшь ассемблер и Паскакаль, напишешь сперва программу на Паскакале, то потом на ассемблере сделаешь, в целом, то же самое. Просто в развёрнутом виде. Т.о. программа на Паскакале будет просто прототипом.
> Сложно поверить.ну, если кто-то не способен разглядеть архитектуру за реализацией — то это никак не моя проблема.
> ну, если кто-то не способен разглядеть архитектуру за реализацией — то это
> никак не моя проблема.Я не знаю. С одной стороны, ты вроде и прав. Обычное ведь дело: создаём прототип на ЯВУ, потом пишем реализацию на Цэ. Разумеется, реализация имеет ту же самую архитектуру, что и прототип. С другой стороны, низкоуровневые языки сдерживают полёт фантазии. А это должно так или иначе влиять на архитектуру.
Видимо, всё несколько тоньше.
сдерживают. но не фатально, хоть и неприятно местами.
>так вот я привёл пример, где начали с нуля и за >10 лет gcc ещё не догналиво-первых, из этих >10 лет примерно половину LLVM пилилась одним человеком, причем студентом. О поддержке C++ (т.е. о clang) стали задумываться, только когда Латтнер закончил универ и устроился работать в Apple в конце нулевых.
во-вторых, по каким критериям не догнали? В поддержке стандартов C++ как бы не перегнали, в скорости работы кода разница в пределах погрешности, в поддержке кучи устаревших лет 20 назад архитектур - да, в этом не догнали и вряд ли догонят.
> asan, кстати, тоже небось изобретение gcc'овцев, например?Я вот видел как амдшники в этой СуперФигне два года пилили кодогенератор чтобы он вообще валидный поток команд мог начать генерить. Почему эта СуперШняга с МегаАрхитектурой не в курсе что в природе бывают VLIW, с заморочками по части зависимостей команд - загадка природы. Видимо не такие уж и суперские у яблока были архитекты - сделали шнягу под х86 и прочие армы нужные яблочку по бырому и успокоились. Никакого запаса и продуманности.
В результате амдшникам как-то однажды на голову свалилось невкусное мнение что они 2 года пыхтят без юзервизибл результатов, а входной барьер для разработчиков задран настолько что только их единственный Том Стеллард и понимает как вся эта хрень работает.
В результате большой вопорс что приобрели амдшники. После 3 лет долботни у них по прежнему 1 разработчик который в этом разбирается, куча глюков, плохая производительность и прочая. Совершенно не выглядит как EPIC WIN мегаархитектуры. А на х86 оно и по сей день не поддерживает OpenMP. Уже джва года обещают. А до тех пор imagemagic какой-нибудь по прежнему втыкает clang'у в разы. И не знаю кому как, а мне возможность прогрузить все 8 ядер моего компьютера вместо 1 ядра - очень даже в кассу.
Я тебе поясню, что он не говорил о причине появления LLVM, а о том почему LLVM/Clang продвигают пропретарасты. Всегда ваш, кэп.
LLVM продвигает LLVM Foundation, точно так же как Linux продвигает Linux Foundation.
Всегда ваш, кэп.
> LLVM продвигает LLVM Foundation, точно так же как Linux продвигает Linux Foundation.
> Всегда ваш, кэп.«Платиновые» партнёры Linux Foundation:
Citrix
Fujitsu
HP
IBM
Intel
NEC
Oracle
Qualcomm
SamsungСпасибо, кэп, именно это мы и называем проприерастами.
Причём рабочей альтернативы поделию этой кодлы нет и не будет.
Ну так он же и запретил сделать нормальную модульную архитектуру.
Поддержу Столмана. Сначала они дают "бесплатную" конфетку, подсаживают народ, а потом
"Как-то так незаметно мальчиш-плохиш стал жертвой пропаганды".
Если бы люди относились к несвободным лицензиям, как к взятию кредита, то такого гуманного отношения к копирастам не было бы.
Мускул и Мария являют хороший пример того, как привыкшие к бесплатной конфетке люди не захотели становиться жертвой.
Мускул и мария являют хороший пример того, как можно кинуть Оракл на кучу бабла, а потом сказать что пошутили и продолжить пилить под другим именем.Правда оно от этого не перестанет быть базой для домашних страничек Васи Пупкина, которому собственно по барабану что там стоит.
> Мускул и мария являют хороший пример того, как можно кинуть Оракл на кучу баблаМожно ссылку на иск оракла по поводу "кидалова"?
> а потом сказать что пошутили и продолжить пилить под другим именем.
И по этому поводу тоже никаких претензий нет и не предвидится.
Не, я понимаю что местные детишки понятия не имеют что значит "покупка компании", ну и чо?
Идиотизм. Что мешает форкнуть LLVM под GPLv3 лицензией и периодически синхронизировать с апстримом? Их лицензия это позволяет
> Идиотизм. Что мешает форкнуть LLVM под GPLv3 лицензией и периодически синхронизировать
> с апстримом? Их лицензия это позволяетФоркнуть можно. Но апстрим с BSD-подобной лицензией не может брать код из форка с лицензией GPL.
И что? :) если авторы патчей захотят, будут отправлять патчи под их лицензией, не захотят - будет форк круче оригинала. Разве не в этом суть Open Source? Откуда паника?
> И что? :) если авторы патчей захотят, будут отправлять патчи под их лицензией, не захотят - будет форк круче оригинала.LLVM занимает свою не GPL-ную нишу, и вне этой ниши он вряд ли будет развиваться. Другими словами, вряд ли кто-то будет писать патчи под GPL-ный форк LLVM-а.
А авторы будут заинтересованы отправлять патчи, ибо один раз отправить легче, чем при каждой синхронизации с апстримом налаживать 100500 патчей и фиксить то что отвалилось
> А авторы будут заинтересованы отправлять патчи, ибо один раз отправить легче, чем
> при каждой синхронизации с апстримом налаживать 100500 патчей и фиксить то
> что отвалилосьЛадно, уговорил. Форкай.
:D
GCC с его кретинскими архитектурой, это точно.
http://www.linuxfromscratch.org/lfs/view/stable/chapter05/gc...
с этим надо что то делать вобще, компилятор не должен быть таким чудовищным
А каким должен быть компилятор? У вас есть опыт разработки компиляторов?
У него, видимо, есть опыт работы с VC.
Пользователю продукта не обязательно быть разработчиком, чтобы его критиковать. Так вообще любую критику можно отвергать.
> GCC с его кретинскими архитектурой, это точно.
> http://www.linuxfromscratch.org/lfs/view/stable/chapter05/gc...
> с этим надо что то делать вобще, компилятор не должен быть таким
> чудовищнымВы точно на тот форум попали?
> GCC с его кретинскими архитектурой, это точно.LLVM с НеКретинской архитектурой амд пилили два года чтобы он вообще смог для их VLIW хоть как-то генерить код. Про оптимизацию и прочее речь даже не начинала еще идти. Просто чтобы оно вообще могло код генерить. И то ввинтили фееричный костыль - отдельную фазу компиляции, которая потом разруливает то что нагерерил шланг и переставляет команды, чтобы GPU хотя-бы колом не становился от некорректных сочетаний команд. Суперархитектура, ля, где надо так изгаляться...
нет смысла обращать внимание на подобных петушков: они вообще ничего не знают ни про внутренности llvm, ни про внутренности gcc, а просто бездумно повторяют нечто, однажды где-то увиденное. безмозглые дауны потому что.
И зачем пилили, если всё так плохо?
> И зачем пилили, если всё так плохо?Я пытаюсь придумать цензурный ответ но не могу. Там что-то про сказочных ... ну в общем синонимов раздолбая :)
А на самом деле - хотели упростить себе жизнь в всяких OpenCL и прочая, а других готовых решений на горизонте 3 года назад как-то и не было. Но насколько оно получилось именно упрощением - очень отдельный такой вопрос...
Хотя Столлман часто оказывается прав, тут уж он, ИМХО, перегибает. Кому был нужен Clang, те уже давно перешли на Clang. Его упорный саботаж развития GCC и всего, что связано с GCC, чтобы ни пяди земли проприетарщикам, большой пользы теперь не приносит.
GCC может умереть под давлением конкурентов, но никогда не сдастся проприетарщикам. И это хорошо.
Мы будем стрелять в своих, но шпионов не пропустим!
Не будешь перегибать — корпорасты верхом на потреблядях затопчут.
а сделать в виде отдельного плагина никак нельзя?
> а сделать в виде отдельного плагина никак нельзя?Там же написано "вот там у нас в репе lldb лежит". Но этим, верхом на которых, не достаточно - они "интеграции" реквестуют.
+++Давнентько в Бостоне покрышек не жгли.
> Никто специально не пытается придушить [...] и никто не выиграет от такого убийстваЭто новость об открытом ПО или о мафиозных разборках?
Заголовок новости слишком жёлтый, и не отражает мнения Столлмана.
> Заголовок новости слишком жёлтый, и не отражает мнения Столлмана.мнение rms про «неристриктивные лицензии», и особенно про компиляторы под такими лицензиями, давно и хорошо известно тем, кому это важно.
А как все хорошо начиналось...
При этом.> I don't know what LLDB is, or what it might do. I am going to find out.
RMS, такой RMS.
> следует начать с вырезанием из Emacs всего кода для обеспечения работы на платформе OS XИменно!
Это война!
> Это война!RMS, душечка, уже подложил вам мину. Но вы об этом пока еще не знаете :)
> Это война!Это гуманитарные бомбардировки.
>> Это война!
> Это гуманитарные бомбардировки.Причём по своим. Не сделай своё лучше, а не пущщай других. Дед - мёртв как идол свободы. АЗЪ!
Прoприерасты по сценарию systemd решили действовать и развалить теперь GNU.
Но с RMS такие фокусы не прокатят.
А если взглянуть с другой стороны? Столлман против LLVM, потому что тот, видите ли, под чересчур свободной лицензией. Гораздо свободнее, чем требуется. Под свободой я, в данном случае, подразумеваю меньшее количество ограничений.По-моему, так гораздо забавнее.
> По-моему, так гораздо забавнее.идиотам всё забавно.
GPL и была создана против свободы копирастов. Копирастам вообще место в тюрьме по-определению, они в принципе никакой свободы не заслуживают.
В земле им место
> GPL и была создана против свободы копирастов. Копирастам вообще место в тюрьме
> по-определению, они в принципе никакой свободы не заслуживают.... сказало нечто прихлёбывая мамкин борщ. :)
Сделай лучше чем у копираста! Вот так весь опен сорос и начинался.
А теперь - никто сделать лучше копираста не хочет, все хотят рулить, делить и управлять ...
> ... сказало нечто прихлёбывая мамкин борщ. :)Все проприерасы так забавно комплексуют. А вон автор gnupg получил за неделю больше денег чем тебе светит за год работы. Так что большой вопрос кто тут лох и кушает дoшиpaк.
> Сделай лучше чем у копираста! Вот так весь опен сорос и начинался.
Ну так что характерно сделали. GCC - спокойно воткнет большинству проприетары. И по качеству кодогенерации и по количеству поддерживаемых архитектур. А в шланге поддерживается полторы архитектуры. И линух вон проприетарным системам втыкает.
> А теперь - никто сделать лучше копираста не хочет,...потому что уже сделали :)
>под чересчур свободной лицензиейСвобода она не вообще, а всегда для кого-то и в чём-то. Назвать BSDL более свободной, чем GPL — это надо совсем с головой не дружить.
> Под свободой я, в данном случае, подразумеваю меньшее количество ограничений.Можно посмотреть Ваш лично нетривиальный код под "горазо более свободной лицензией"? Причина вопроса -- считаю, что перед попытками обсуждать лицензионную политику и далеко идущие последствия стоит начать с основ, бишь вложения собственного времени сообразно декларациям.
> подразумеваю меньшее количество ограничений.
> По-моему, так гораздо забавнее.Ну тогда вы наверное должны прийти в полный восторг от идеи что надо бы отменить запрет брать людей в рабство. Я бы с удовольствием вас захомутал в свою пользу, раз вы так заботитесь о моих свободах делать что угодно.
>> подразумеваю меньшее количество ограничений.
> Ну тогда вы наверное должны прийти в полный восторг от идеи что
> надо бы отменить запрет брать людей в рабство.У тебя истерика малыш :)
Давай теперь про фашистов, пол-пота, ГМО и зелёных человечков ...
> У тебя истерика малыш :)У меня капитанинг, чувак :)
идиоты как всегда не понимают, почему rms против. идиоты как всегда потом будут удивляться: «как же так получилось-то? ведь ничего не предвещало… только rms, который всегда прав, но мы же его традиционно не слушаем…»
Времена меняются, а Столман - нет. Это особенность большинства людей, и он исключением не оказался.
В плане лицензий и вредительского законодательства ничего не изменилось. если хотите лицензию соответствующую времени используйте GPL3.
BSD по-прежнему выгодна только копирастам и не выгодна сообществу. Её по прежнему не следует использовать тем кто уважает свою и чужую свободу. В этом смысле ничего не изменилось.
> BSD по-прежнему выгодна только копирастам и не выгодна сообществу.Вот-вот! Университетам вообще надо запретить писать код под страхом смертной казни, а факультеты прикладной математики разогнать!
А то совсем они с катушек сбрендили! Напридумывали BSD, MIT и прочую проприетарную ересь. Столман не одобряэ
> Вот-вот! Университетам вообще надо запретить писать код под страхом смертной казнитем, которые хоть копейку получают из госбюджета — запретить не-GPL писать, естественно. а тех, кто в подобном запачкался — как минимум уволить, а то и судить за хищение государственных денег.
>тем, которые хоть копейку получают из госбюджета — запретить не-GPL писать, естественно. а тех, кто в подобном запачкался — как минимум уволить, а то и судить за хищение государственных денег.Хорошая идея, здравая и правильная. Думаю буду ее продвигать, т.к. похоже у меня появляются реальные возможности это делать.
> Хорошая идея, здравая и правильная. Думаю буду ее продвигать, т.к. похоже у
> меня появляются реальные возможности это делать.Оопс! Опять кризис и бабла нет, опять Наполеонов выпустили ... :(
Согласен с arisu на все сто!!1
> Согласен с arisu на все сто!!1А вы муж с женой по очереди или как?
>> Вот-вот! Университетам вообще надо запретить писать код под страхом смертной казни
> тем, которые хоть копейку получают из госбюджета — запретить не-GPL писать, естественно.
> а тех, кто в подобном запачкался — как минимум уволить, а
> то и судить за хищение государственных денег.Очень хорошая идея, но…
Например, я получаю деньги из госбюджета, но чтобы пожертвовать что-нибудь в какой-нибудь там OpenRC или OpenSSL, я буду вынужден подстраиваться под лицензию upstream-а (которая не есть GPL). И что, потом следует меня судить за хищение гос. средств?
Или другой пример. Допустим, в институте внедрена какая-то проприетарная дрянь для которой необходимо написать модуль, чтобы была возможность интегрировать эту дрянь уже со свободными продуктами. Но твой подход запрещает писать сей модуль и вынуждает Институт тупо купить дополнительный проприетарный продукт (вместо свободных аналогов).
В результате, если введут ФЗ, запрещающий писать non-GPL гос. работникам, то сразу же появится список «исключающих обстоятельств». Но живя не первый день в России, сразу становится понятно, что в этот список будет легко проталкиваться что угодно, на чём можно будет сделать деньги. В результате не изменится ничего, кроме того, что:
- у чиновников будет _ещё один_ способ грести деньги;
- интегрироваться с проприетаром станет ещё сложнее.P.S.: Да и вообще, те кто действительно занимаются такого рода «хищением» всегда найдут способ организовать компанию «Рога и копыта», которая в свою очередь «будет писать проприетар» (и продавать обратно в те же гос. учреждения) якобы за счёт внебюджетных денег. Единственный реальный выход — это тупо запрет использование проприетара в гос. учреждениях.
> Например, я получаю деньги из госбюджета, но чтобы пожертвовать что-нибудь в какой-нибудь
> там OpenRC или OpenSSL, я буду вынужден подстраиваться под лицензию upstream-а
> (которая не есть GPL). И что, потом следует меня судить за
> хищение гос. средств?какого чёрта ты на работе занимаешься допиливанием чужих проектов? не отвлекайся, интегрировай! тебе за это деньги плотють.
> Или другой пример. Допустим, в институте внедрена какая-то проприетарная дрянь
почему все причастные ещё не расстреляны как расхитители госбюджета? переходите на частное обеспечение и хоть чёрта лысого в коробочке закупайте. а vendor lock-in за госденьги — расстрел.
> - интегрироваться с проприетаром
расстрел.
> P.S.: Да и вообще, те кто действительно занимаются такого рода «хищением» всегда
> найдут способ организовать компанию «Рога и копыта», которая в свою очередь
> «будет писать проприетар» (и продавать обратно в те же гос. учреждения)кто закупил — расстрел.
> Единственный реальный выход — это тупо
> запрет использование проприетара в гос. учреждениях.именно. использование проприетарного софта с закрытыми исходниками в государственных учреждениях — прямая диверсия против страны, ставящая её в зависимость от воли левой (и часто заграничной) конторы. у принявших такое решение — конфискация всего имущества и расстрел. если обнаруживается «записаное на жену или тётку» имущество, которым расстреляный пользовался — конфискация, расстрел тех, на кого было записано.
вообще, наказание за любой проступок любого госчиновника — вышеописаные конфискации и расстрелы. иначе их вразумить невозможно.
> вообще, наказание за любой проступок любого госчиновника — вышеописаные конфискации
> и расстрелы. иначе их вразумить невозможно.Ну как же! У вас же там мусорные люстрации самая тема! Ты гонишь волну против линии партии! Смотри - загремишь в мусорку :)
>> Например, я получаю деньги из госбюджета, но чтобы пожертвовать что-нибудь в какой-нибудь
>> там OpenRC или OpenSSL, я буду вынужден подстраиваться под лицензию upstream-а
>> (которая не есть GPL). И что, потом следует меня судить за
>> хищение гос. средств?
> какого чёрта ты на работе занимаешься допиливанием чужих проектов? не отвлекайся, интегрировай!
> тебе за это деньги плотють.IT-шная работа вполне может быть сопряжена с исправлением сторонних проектов. Ибо невыгодно (с точки зрения человеко-часов) тянуть за собой patchset-ы при каждом обновлении — лучше один раз push-нуть в upstream.
>> Или другой пример. Допустим, в институте внедрена какая-то проприетарная дрянь
> почему все причастные ещё не расстреляны как расхитители госбюджета? переходите на частное обеспечение и хоть чёрта лысого в коробочке закупайте. а vendor lock-in за госденьги — расстрел.Даже если сейчас ввести закон, по которому будет производится такой расстрел, то это никак не исправит ситуации, что проприетарная хрень _уже_ куплена и уже используется.
>> - интегрироваться с проприетаром
> расстрел.
>> P.S.: Да и вообще, те кто действительно занимаются такого рода «хищением» всегда
>> найдут способ организовать компанию «Рога и копыта», которая в свою очередь
>> «будет писать проприетар» (и продавать обратно в те же гос. учреждения)
> кто закупил — расстрел.Было бы здорово, конечно. Хотя расстрел — слишком жестоко. Достаточно просто сделать пожизненный запрет работать за счёт госбюджета.
>> Единственный реальный выход — это тупо
>> запрет использование проприетара в гос. учреждениях.
> именно. использование проприетарного софта с закрытыми исходниками в государственных
> учреждениях — прямая диверсия против страны, ставящая её в зависимость от
> воли левой (и часто заграничной) конторы. у принявших такое решение —
> конфискация всего имущества и расстрел. если обнаруживается «записаное на жену или
> тётку» имущество, которым расстреляный пользовался — конфискация, расстрел
> тех, на кого было записано.Опять же, расстрел — это слишком сурово.
В целом я согласен, и мне такой подход нравится, несмотря на то, что сам зарплату получаю из государственных денег :)
> Допустим, в институте внедрена какая-то проприетарная дрянь для которой необходимо написать модуль, чтобы была возможность интегрировать эту дрянь уже со свободными продуктами. Но твой подход запрещает писать сей модуль и вынуждает Институт тупо купить дополнительный проприетарный продукт (вместо свободных аналогов).Теоретически, он требует того, чтобы расширение пропиетарной дряни технически было организовано так, чтобы не нарушать GPL. Такое вполне возможно.
> В результате, если введут ФЗ, запрещающий писать non-GPL гос. работникам, то сразу
> же появится список «исключающих обстоятельств».Да ничего не появится. Полтора разработчика со всей России - какой еще там вклад в OpenSSL? Ну это уже лирика и местные реалии.
Просто не трогай OpenSSL - есть ведь аналогичные проекты под GPL, как почти в любой области.
>> Допустим, в институте внедрена какая-то проприетарная дрянь для которой необходимо написать модуль, чтобы была возможность интегрировать эту дрянь уже со свободными продуктами. Но твой подход запрещает писать сей модуль и вынуждает Институт тупо купить дополнительный проприетарный продукт (вместо свободных аналогов).
> Теоретически, он требует того, чтобы расширение пропиетарной дряни технически было организовано
> так, чтобы не нарушать GPL. Такое вполне возможно.Если модуль линкуется (и никак иначе), то это невозможно. Или я уже плохо помню GPL?
>> В результате, если введут ФЗ, запрещающий писать non-GPL гос. работникам, то сразу
>> же появится список «исключающих обстоятельств».
> Да ничего не появится. Полтора разработчика со всей России - какой
> еще там вклад в OpenSSL? Ну это уже лирика и
> местные реалии.Ну не надо так. Лишь даже в моём отделе люди постоянно что-то куда-то contrib-ютят. А по всей стране, думается мне, таких людей вообще дохрена.
> Просто не трогай OpenSSL - есть ведь аналогичные проекты под GPL, как
> почти в любой области.Например? Да и толку-то? Если в проекте уже используется OpenSSL, в нём обнаружилась проблема и известно как её устранить, то что делать? Бросать OpenSSL и искать замену (согласно вашему подходу)?
> Вот-вот! Университетам вообще надо запретить писать кодВы бы поинтересовались хоть отличием грантовой разработки под всякие USDoD и общественной.
Ну или для начала историей возникновения этих самых BSDL/MIT license и им подобных.
> Вы бы поинтересовались хоть отличием грантовой разработки под всякие USDoD и общественной.В правильную сторону глядите, Михаил. Я именно про это и говорил. И поскольку грантованые государством разработки обязаны по закону если открываться, то под пермиссивной лицензией, то наилучшим выходом будет их запретить вообще. Во имя святого Столмана!
>> BSD по-прежнему выгодна только копирастам и не выгодна сообществу.
> Вот-вот! Университетам вообще надо запретить писать код под страхом смертной казни, аДа, однозначно же -- рассадники проприерасии, копирастии, тивоизации и коррупции.
> факультеты прикладной математики разогнать!
Можно Просто(тм) отделить от них вышеперечисленное, пусть прикладывают "как положено", а не как "плохо лежит".
очень сильно напоминает историю с другим разработчиком, который был против чего-то там, что собирались делать с его проектом.
напоминте ка - чем история закончилась? ;)
автору сделали пинка под зад, сказали делай форк и меняй имя проекта - а этот проект останеться достоянием...напомните ка или дайте ссылку на новость, если кто помнит.
почему RMS в данном случае играет не по общим правилам для всех?! ;)
по существующему прецеденту - пусть RMS делает форк и меняет имя Emacs!
Слабо?! - Тогда это всё только игры на публику! Фальшиво и пошло.Спасибо за внимание.
Столлман не играет по правилам навязанным копирастами.
Столлман навязывает копирастам свои правила. За это и любим.
> Столлман не играет по правилам навязанным копирастами.
> Столлман навязывает копирастам свои правила. За это и любим.Да - но он сам их же и нарушает. Пост выше.
> Да - но он сам их же и нарушает. Пост выше.Он их не нарушает. Он проводит терраформинг.
Было время когда софт был свободным - программеры никогда в своей среде жлобством не страдали. Потом запахло баблом и корпорасы стали наглеть. И однажды Столлману достался принтер, драйвер к которому был без сорцов.
Ну вот он видел тенденцию и понял что дальше будет больше. Поэтому он поступил как настоящий мегамозг. Он запустил самоходный алгоритм оформленный как лицензия. Этот алгоритм работает. И в целом постепенно проприерасам закатили неплохой терраформинг. Можно долго пиндеть про Столлмана, но зажимать сорц становится уже просто неприлично и портит репутацию, а открытые проекты - самые перспективные. А проприерасы в панике пытаются сделть ну хоть что нибудь. Ну хоть пермиссивно! Чтоб зажать можно было! Ну хоть потом! Правда, фокус в том что никакого "потом" у них не будет :-).
>напомните ка или дайте ссылку на новость, если кто помнит.
>>напомните ка или дайте ссылку на новость, если кто помнит.
> https://www.opennet.ru/opennews/art.shtml?num=41146Спасибо, но не это :)
> очень сильно напоминает историю с другим разработчиком, который был против чего-то там, что собирались делать с его проектом.
> напоминте ка - чем история закончилась? ;)
> автору сделали пинка под зад, сказали делай форк и меняй имя проекта - а этот проект останеться достоянием...На что разработчик ответил "ребята, а вы не ах*ели? Название проекта — зарегистрированная торговая марка вообще-то. Сами форкайте и переименовывайте". И форкнули и переименовали. А оригинальный проект в ответ взялся за ум и теперь и свои новшества пилит, и новшества новоявленного форка заимствует. А форк не новшеств предшественника не заимствует, но еще и API коверкает от релиза к релизу так, что все дистрибутивы, кроме демьяна сотоварищи, уже давно плюнули на форк и продолжают использовать оригинальный проект.
> по существующему прецеденту - пусть RMS делает форк и меняет имя Emacs!
Ты сначала уместный прецедент приведи, а потом умничай. Или ты не про ffmpeg и libav говорил? Тогда не выделывайся и скажи, о каких проектах говоришь. В угадайку с тобой никто играть не собирается.
>[оверквотинг удален]
> зарегистрированная торговая марка вообще-то. Сами форкайте и переименовывайте". И форкнули
> и переименовали. А оригинальный проект в ответ взялся за ум и
> теперь и свои новшества пилит, и новшества новоявленного форка заимствует. А
> форк не новшеств предшественника не заимствует, но еще и API коверкает
> от релиза к релизу так, что все дистрибутивы, кроме демьяна сотоварищи,
> уже давно плюнули на форк и продолжают использовать оригинальный проект.
>> по существующему прецеденту - пусть RMS делает форк и меняет имя Emacs!
> Ты сначала уместный прецедент приведи, а потом умничай. Или ты не про
> ffmpeg и libav говорил? Тогда не выделывайся и скажи, о каких
> проектах говоришь. В угадайку с тобой никто играть не собирается.не бурей, чудик! я лично тебя не звал со мной во что-либо играть - усмери свою бурную фантазию.
я забыл.
найду ссылку кину сюда.
> бурей,
> усмери
> я забыл.Конкретно у него бомбануло...
вот оно https://www.opennet.ru/opennews/art.shtml?num=35681"В ответ на шаг Никоса Ричард Столлман заявил, что GnuTLS не личная разработка Никоса, а проект, развиваемый сообществом, поэтому так просто увести его из-под контроля Фонда СПО не получится. Несмотря на все свои заслуги, Никос добровольно согласился управлять разработкой и развивать GnuTLS под эгидой проекта GNU, на что проектом GNU ему были даны соответствующие полномочия. Никос волен основать форк под другим именем и продолжить его развитие, или прекратить своё участие в разработке, но отобрать проект GNU невозможно. Так как при передаче кода разработчики подписывают соглашение с Фондом СПО, Фонд является владельцем имущественных прав на код и использует эти права чтобы гарантировать, что проект всегда останется свободным. Если Никос передумает, Ричард выразил готовность обсудить возвращение к сотрудничеству с проектом GNU. "
в данном случае - смотрелось бы так:
"В ответ Ричард Столлман заявил, что Emacs уже давно не личная его разработка, а проект, развиваемый сообществом, поэтому так просто увести его из-под контроля Фонда СПО не получится. Несмотря на все свои заслуги, RMS добровольно согласился управлять разработкой и развивать Emacs под эгидой проекта GNU, на что проектом GNU ему были даны соответствующие полномочия. RMS волен основать форк под другим именем и продолжить его развитие, или прекратить своё участие в разработке, но отобрать проект GNU невозможно. Так как при передаче кода разработчики подписывают соглашение с Фондом СПО, Фонд является владельцем имущественных прав на код и использует эти права чтобы гарантировать, что проект всегда останется свободным. Если RMS передумает, RMS выразил готовность обсудить возвращение к сотрудничеству с проектом GNU. "
> напомните каТео с NetBSD поперли и он создал OpenBSD
>> напомните ка
> Тео с NetBSD поперли и он создал OpenBSDя говорю в контексте GPLXXX, Фонда СПО и RMS
ниже я уже дал ответ, нашелл ссылку.
> следует начать с вырезанием из Emacs всего кода для обеспечения работы на платформе OS XХорошая идея, Стефан!
И вообще, пора вырезать из Емакс поддержку несвободных клавиатур. А то, понимаешь, расплодились проприетарные разработчики клавиатур...
> LLVM/Clang поставляется не под копилефт-лицензией активно используется компанией Apple в качестве основы для создания несвободных компиляторов, т.е., любое участие в разработке LLVM непосредственно помогает развитию проприетарного ПО.Ну так отлично, нужно только прямо везде вещать что bsd-like софт не является СПО.
Нельзя, засмеют.
> Ну так отлично, нужно только прямо везде вещать что bsd-like софт не является СПО.Это было бы неправдой; другое дело, что этот вид СПО получается обычно или "на выброс", или как полуфабрикат для закрытых продуктов.
(кто вздумает возмущаться и размахивать университетами -- потрудитесь выяснить историю этих грантовых разработок хотя бы так же поверхностно, как я)
> другое дело, что этот вид СПО получается обычно
> или "на выброс", или как полуфабрикат для закрытых продуктов.И тем забавнее наблюдать как ты стоя аплодируешь когда GPL продукт делают походя
таким полуфабрикатом, используя CLA типа каноникаловского.
> Стефан Монье (Stefan Monnier), майнтейнер Emacs, не согласился с такой позицией и намерен принять патч для поддержки LLDB.Модераст, подтвердивший новость, а слабо перевести
http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg004...
*дословно* и ткнуть в место, где там намерение принять код?
"Thanks, Andrew. I'd be happy to incorporate such a patch."
http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg002...
> "Thanks, Andrew. I'd be happy to incorporate such a patch.""Спасибо, Андрей. Я буду рад включить такого типа патч."
Еще бесплатные уроки перевода на opennet?
Разницу с "намерен принять патч" видим?
>Еще бесплатные уроки перевода на opennet?В самом деле, давай проведем урок по прагматике, то есть по пониманию не только того, что дословно сказано, но и того, что имелось в виду. Совершенно очевидно, что мейнтейнер намерен включить этот код, как только все авторы подпишут бумаги о передаче копирайта FSF, хотя он его еще досконально не изучил, поэтому возможны исправления.
И легким движением "clear the copyright status of this code" превращаются в> как только все авторы подпишут бумаги о передаче копирайта FSF
А ну как не подпишут?
> И легким движением "clear the copyright status of this code" превращаются вТы прочитай следующий параграф. IOW = In other words = другими словами. Он точно объяснил, что значит "clear the copyright status"
IOW, we need to know who is/are the author(s) (contributors of less than
about 15 lines of code don't need to be accounted for), and then make
sure they have signed a copyright assignment.
Как только авторов найдут и ...
А по всем ссылкам слабо пройти? https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
Господи, как всё тяжело. Почему бы не писать код под public domain? Я серьёзно. У меня есть такая задумка.
задумка — это отлично. а код-то, код — есть?
Лично у меня нет и не будет, так как я не программист. Но есть идея организовать бизнес, связанный с...(интрига)
удачи, чо. но это точно не будет бизнес типа «берём PD код и продаём как проприетарный продукт»? а то подобных есть уже, не инновация.
И PD код ведь от этого кончается, да?
> И PD код ведь от этого кончается, да?Кончается talent pool, публикующий свой код под PD. // один из, когда "три строчки"
Нет. Люди будут писать код с нуля и не заморачиваться насчёт лицензий, так как им будет платиться достаточно хорошая зп. Код будут дорабатывать все, кому не лень, но права на продукт будут принадлежать компании. В смысле ту версию, которую мы разрабатываем. То есть, то что мы разрабатываем - мы в ответе за это и должны нести ответственность только мы, а уже остальные версии и даже 100% копии - будут не в нашей юрисдикции. По крайней мере, пока мне видится всё так. Естественно, все, кто участвовал в разработке - будут упомянуты в исходниках. Сам продукт будет, как бы формировать наш имидж и будет эталонным. Пока, конечно, фантазиии:) Как говориться - мечтать не вредно.
(задумчиво) я всякую наглоту, конечно, видел, но наглоту, заявляющую права собственности на public domain, и ещё считающую это не просто не порицаемым, а доблестью…
Ты меня не так понял. Только на нашу версию продукта, и то не права собственности(я не так выразился видимо), а чисто условно, именно эта версия будет закреплена за нашей компанией и мы будет разрабатывать её как хотим. С самим кодом люди могут делать, что угодно, нам будет всё равно. Пусть даже в коммерческих целях. Я, скорее всего, ещё многого не знаю, но это не помешает мне реализовать эту идею, когда наберусь знаний и придёт нужное время.
> По крайней мере, пока мне видится всё так.Если вкратце, то это и есть одно из обычных применений BSDL. О граблях консультировать не стану, в том числе и возмездно.
Мы же просто разговариваем. В консультациях не нуждаюсь, но было бы интересно узнать твоё мнение.
> Но есть идея организовать бизнес, связанный с...(интрига)В смысле, ты хочешь отжимать с лохов код под PD, закрывать и продавать? Извини, но программисты не очень глупые и поэтому с мало-мальски ценным кодом этот номер не пройдет :)
Нет. Описал свои мысли - выше по треду.
И под какими лицензиями будут распространяться производные?
Под любыми, public domain разрешает всё кроме плагиата.
RMS прав. Впрочем, как всегда. И что характерно, омские линуксоиды разделяют его точку зрения.
ну я бы слушался старшее поколение, тк в большинстве случаев пророк, да
Столлман слишком маргинален, он маргинален до неадекватности, к тому же он стареет и окончательно выживает из ума, тоже будет и с Линусом через 12 лет, с этим ничего не поделаешь и мир не стоит на месте, старые идеологии наряду со старыми технологиями, должны выбрасываться на свалку истории.Нам нужен новый герой и новые идеи!
Я написал это сообщение ещё не прочитав новость, писал по прошлым событиям, но сейчас прочитал и мне хочется просто бежать из сообщества с таким идеологом.
Если он будет продолжать в таком же духе, он похоронит всю проделанную работу за эти десятилетия. Я бы не стал этого дожидаться. Либо ты меняешь систему, перебегая в другую, либо меняешь руководство, на то, которое тебя устраивает.
Все мы прекрасно знаем, что Столлман всегда был со странностями, но сейчас возраст уже откровенно берёт своё. Думаю, нужно отпустить человека на пенсию, он её заслужил, как никто другой, внеся огромный вклад в развитие открытого ПО.И мир между прочим не двухполюсный, как нам это постоянно пытался изобразить Столлман, может быть в его голове и так (а сейчас он ещё больше откровенно съехал в эту сторону и разочаровался в реальном мире) мир же у нас - многополюсный. Игроков, даже крупных, многие тысячи. Коммерческие компании всё чаще используют и развивают открытое ПО в бизнесе наряду с проприетарным, полно выгодных схем. И открытое ПО от такого сотрудничества только в плюсах.
А Столлман говорит: НЕТ, либо это, либо это, либо ты правый, либо левый, либо ты с нами, либо ты против нас. А как насчёт того, что не хочу быть закабалён вашей идеологией, но и враждовать с вами тоже не хочу и почему я должен быть обязательно правым или левым, когда я могу быть демократом? - Извините, Ричард, мне с Вами больше не по пути.Мир меняется, и отрытое ПО должно меняться вместе с ним, пора бы уже.
> Коммерческие компании всё чаще используютЭто да, это они могут.
> и развивают открытое ПОА вот тут по-моему, нужно дополнение, типа "если их регулярно пинать!".
http://opensource.com/law/14/12/gplv2-court-decisions-versata
https://fsfe.org/news/2013/news-20130626-01.en.html
http://electronics360.globalspec.com/article/4895/allwinner-...
Лицензии - штука сложная, иногда нарушишь и не заметишь.
Лицензия хоть сразу видна, а с патентами полная шляпа.
> Лицензия хоть сразу виднаДа вон бздюки надергали GPLного кода из пингвина себе в ядро но не видят. Читать то что копипастим? Ну что вы, как можно.
>>старые идеологии наряду со старыми технологиями, должны выбрасываться на свалку истории.
>> Нам нужен новый герой и новые идеи!
>и мне хочется просто бежать из сообщества с таким идеологом."Тому не надо чёрта искать, укого он за спиной." В смысле, как безать "из", частью чего никогда не был? <нет, не отвечай>
>Столлман всегда был со странностями
> открытого ПО.Пройтите с ESR-ом, ...
>как нам это постоянно пытался изобразить Столлман
>мир же у нас - многополюсный.
>Коммерческие компании всё чаще используют
> обязательно правым или левым, когда я могу быть демократом?
>- Извините, Ричард, мне с Вами больше не по пути.
> Мир меняется, и отрытое ПО должно меняться вместе с ним, пора бы уже....в компанию http://thebaffler.com/past/the_meme_hustler О'Райли.
Полное совпадение.
И потрудитесь говорить _за _себя, не за мифических "нас". Спасибо.
> Мир меняется, и отрытое ПО должно меняться вместе с ним, пора бы уже.Да-да -- и природа, и церковь, и сами понятия добра и зла.
У меня есть веские претензии к столмановской этике (которые как-то высказал ему), но он лучше и честнее многих, давно продавших _любую_ этику ради "ешь, пей, веселись".
Не путайте полюсность мира и всё такое же отсутствие нейтральной грани между правдой и ложью.
>> Мир меняется, и отрытое ПО должно меняться вместе с ним, пора бы уже.
> Да-да -- и природа, и церковь, и сами понятия добра и зла.И природа, и общество, и любые общественные объединения, и моральные
категории. Объективная реальность.Так что это аргумент. И позиция FSF тоже меняется, что отражается даже на уровне изменения лицензии.
> У меня есть веские претензии к столмановской этике
Ну какие у подлеца могут быть претензии к этике? Это смешно.
При слове GCC мухи летать начали...
http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg004...Speking as the original author of GUD, I'm in favor of it supporting
LLVM and everything else imaginable. But I hadn't been planning to
weigh in on the question until I realize that Richard and everyone
else may be carrying around a false premise: namely, that GCC's
dominance in its functional category *can* be preserved.I'm pretty sure this is not true. If the clang/LLVM people decide
they want to eat GCC's lunch, they *will* do it. The reason has
nothing to do with any philosophical issue but merely the fact that
compiler technology has advanced significantly in ways that GCC is not
well positioned to exploit. The clang/LLVM people have both a
clean-sheet technology advantage and Apple's money to fund a
high-quality implementation with; FSF cannot match either.Already my own experiments suggest that LLVM is a superior compiler,
by every metric I know of, at least in deployments that don't require
bug-for-bug compatibility with GCC. If GCC were to vanish from
existence tomorrow I'm not sure I myself would be even seriously
inconvenienced. CC=clang in one dotfile; problem solved, done.
а, esr известная вражина и демагог.
> а, esr известная вражина и демагог.Он давно подстилкой для проприерасов подрабатывает.
(ц) Eric S. RaymondЧья бы, в общем, корова мычала.
> При слове GCC мухи летать начали...А при слове "llvm" начали летать _исключительно бабочки! </ночные>
"может нанести GDB и свободе пользователей."Ога. Свобода от Столлмена она такая. Все что наносит вред GDB наносит вред пользователю. А свобода выбора она и не свобода вообще.
Нет, ну Вы конечно свободны пользовать любой отладчик. Но если это отладчик GDB.
> Ога. Свобода от Столлмена она такая.Да вообще, напринимали тут законов. Ни вам грабить нельзя, ни убивать. Ни даже в рабство брать. Никакой свободы блин.
На всякий случай. Использование LLDB GPL даже приблизительно не нарушает. Даже в больная фантазия не родила такого вывода. Просто BSD like она "нЭкошерна" и вообще нефиг создавать конкуренцию GDB.И вообще.
Поздравляю! Вы долбонулись!
Кстати о законах и больной фантазии (навеяло): http://uri71.livejournal.com/18454.html
Михаил, не расстраивайте меня. Приводить ссылки на желтую политоту и провоцировать хохлосрач в дискуссии о GPL на ТЕХНИЧЕСКОМ ресурсе... Вы же еще и модератор, если я правильно помню.
Не портите о себе мнение, уберите пост.
> Михаил, не расстраивайте меня.И не собирался, но несколько слов в Вашем сообщении уж очень срезонировали.
Текст же ни разу не жёлтый, ни разу не политота -- и имеет прямое отношение к лицензионному вопросу; если хотите, перечитайте в районе слова "законодательство" в этом ключе и припоминая да хоть и ту былину о ксероксовском принтере, которым зацепило Столмана: http://www.oreilly.com/openbook/freedom/ch01.html (разобрано обстоятельно, можно сориентироваться на слово proprietary в завершении, если неохота читать достаточно интересные узкому кругу ограниченных инженеров подробности).
>> Михаил, не расстраивайте меня.
> И не собирался, но несколько слов в Вашем сообщении уж очень срезонировали.У Вас на "больная фантазия" срезонировало?
Странные асоциации.> Текст же ни разу не жёлтый, ни разу не политота -- и
> имеет прямое отношение к лицензионному вопросу; если хотите, перечитайте в районе
> слова "законодательство" в этом ключеЧто не отменяет провокационность вброса. Поверьте, я могу "к слову" накидать подобных ссылок с противоположной вашему восприятию стороны хохлосрача. Вы же первый посты тереть будете.
Давайте все же обойдемся без левых вбросов.> и припоминая да хоть и ту
> былину о ксероксовском принтере, которым зацепило Столмана: http://www.oreilly.com/openbook/freedom/ch01.html
> (разобрано обстоятельно, можно сориентироваться на слово proprietary в завершении, если
> неохота читать достаточно интересные узкому кругу ограниченных инженеров подробности).Былину о принтере, каюсь, не осилил. Времени прямо сейчас нету.
Но касательно топика все же напомню: У меня ограничение свободы для свободы вызывает некий когнетивный диссонанс. Это уже тот случай что "Що занадто то не здраво (укр.)".Эпоха ИТ мечтателей проходит, увы. А для новых людей со стороны Столлмен выглядит диковато. Да и для старых людей со стороны тоже.
А впрочем. Ваша песочница- делайте что хотите.
> У Вас на "больная фантазия" срезонировало? Странные асоциации.По сумме. Да, сам удивился слитности.
> Что не отменяет провокационность вброса.
Текста по ссылке или моего упоминания? Знаете, недавно перечитывал (именно чтоб внимательно) "Песню о сумасшедшем доме" Высоцкого -- об этом сказать хоть ещё не провокация?
> Давайте все же обойдемся без левых вбросов.
Стараюсь, но у истерики с лицензиями неожиданно нашлось общее с истерикой в результате очередного "разделяй и властвуй"; сам этот факт счёл интересным.
> Эпоха ИТ мечтателей проходит, увы. А для новых людей со стороны Столлмен
> выглядит диковато. Да и для старых людей со стороны тоже.Да он и тогда для коллег быстро стал "маргиналом".
> А впрочем. Ваша песочница- делайте что хотите.
Не так -- см. "Статус модераторов" на http://wiki.opennet.ru/ForumHelp
> Да он и тогда для коллег быстро стал "маргиналом".Интересное свойство: Вроде как и нормальные вещи в совокупности могли бы получаться. Но подход и фанатизм... ИМХО популяризатор по нынешним временам так себе :/
>> А впрочем. Ваша песочница- делайте что хотите.
> Не так -- см. "Статус модераторов" на http://wiki.opennet.ru/ForumHelpЯ не о сайте. Я о поклонниках GPL. Мотивы "GPL сообщества" это сугубо личное дело. ИМХО первичен код и его применимость. Мое мнение со стороны: лишний фанатизм вреден. Но это только мнение со стороны.
Поддержка LLVM ведет к процветанию закрытого софта. Значит в GCC тоже надо запретить компилировать закрытый софт, а то он тоже способствует развития не копилефт проектов. :D