> А чего хром не умеет по сравнению с ФФ?

zotero и прочие _большие_ XUL-приложения. Плюс у него нет (пока) xclear/clearfields плагина. Opera тоже, впрочем, не умеет zotero, и вообще, создавать на юзерскрипте что-то сравнимое, по-моему, затруднительно...

BSD> конечному пользователю срать на код.

Речь сейчас не о конечных пользователях в частности. Так что не неси ахинею.

BSD> Может я могу не нарушив лицензии использовать RHEL?

Можешь. Исходники открыты. И из них собирают CentOS.

BSD> Или ты начнешь сейчас нести херню про поддержку?

Это не нужно, то не нужно... Теперь техподдержка оказывается ненужной... Бздуны - такие бздуны... Вот потому, что техподдержка у FreeBSD практически никакая - её почти никто и не использует. Гарантий FreeBSD не даёт. Энтерпрайз срал на BSD.

BSD> Да срал я на Centos, я про RHEL спросил.

Тебе шашечки или ехать?

RHEL - торговая марка. Конкретно RHEL как торговую марку тебе не дадут использовать. И GPL тут ни при чём. Но фактически CentOS - это RHEL с другим брендом.

Так что если ты срал на CentOS, и тебе шашечки подавай - это твои личные половые трудности.

Я же точно так же и про OS X могу спросить. Вот только OS X проприетарна насквозь благодаря BSDL.

>Да легко. Автор имеет право быть в в курсе судьбы своего кода, имеет право получать все изменения, которые с ЕГО кодом проворачивают. Такую свободу автора обеспечивают гпл-подобные лицензии. Даже lgpl.

Закрытием исходников результата. в котором был использован код, распространяемый под BSDL.

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

>Есть возможность закрыть код.

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

> С GPL можно сделать тоже самое и никого не будет колышить, что в ней написано

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

> А так - Coverity, который уже несколько лет в эксплуатации.

Coverity, как я понимаю, OS-версии не имеет?

Количество страниц флейма и длина моего скора ВНЕЗАПНО! сократились :)

Посмотрите на первое сообщение в треде. Это BSD-шник?

>Ну это будет посложнее сделать верно? Ну, вот поэтому какая то лицензия еще обязательно нужна, пусть не GPL, но одной BSD ограничиваться глупо. Впрочем, как и одной GPL. Бздуны, кажется, этого не понимают.

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

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

>GPL замечательная академическая лицензия. Офигенно просто подходит для групп энтузиастов и науки. Но, блин, не во все щели же её пихать!

А тебе её RMS силком в зад засунул? Бедненький ты...

GPL не нужна Apple - вот llvm&Co её и не используют. Кто куда её пихает? Каждый использует то, что считает нужным. И только на лоре вой как от весеннего обострения батхерта...

А в _текущем_ своём состоянии llvm нужна только для узкого круга специфических задач. Поэтому под линуксом она действительно _практически_ не нужна. Да и активное комьюнити там - полтора десятка человек. Но проект интересный. Пристально слежу за pure (кстати - под GPLv3) - ни как не дождусь добавления тредов =)

> Не один здоровый в админ не поставит на сервак не сертифицированную, без вменяемой поддержки ОС.

Ой, бедный дебиан.

> Вобще- то GPL замечательная академическая лицензия.

А вот как раз и нет, Berkeley и MIT не согласны. Да и RMS занялся GPL, покинув академическую среду.

>Ой, бедный дебиан.

+1, лол :)

>>GPL замечательная академическая лицензия. Офигенно просто подходит для групп энтузиастов и науки. Но, блин, не во все щели же её пихать!

А тебе её RMS силком в зад засунул?

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

GPL не нужна Apple - вот llvm&Co её и не используют. Кто куда её пихает? Каждый использует то, что считает нужным.

Ну дык и я о чем!

А в _текущем_ своём состоянии llvm нужна только для узкого круга специфических задач. Поэтому под линуксом она действительно _практически_ не нужна.

А что, я говорил что линуксоидам нужна llvm?

Блин, ну сколько ж повторять. FreeBSD хочет иметь БАЗОВУЮ СИСТЕМУ под одной лицензией. Да хотя бы уменьшить contrib/ в сорцах. Ну какой профит BSD сообществу пилить GPL софтину? Все равно под фрю ее пилить. А пилить ее все сложнее. И закономерно на каом- то этапе становится проще свое сделать.

ClangBSD самособирается и скоро наконец-то начнёт убивать всех человеков. Нужны тестеры ^^

>И закономерно на каом- то этапе становится проще свое сделать.

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

Ну и одно дело - базовая система на clang-е, а другое - llvm-gcc _пока_ ещё остаётся _базовым_ для llvm.

И как уже заметили, сравнивать clang и gcc - это даже не моська со слоном... А llvm относится к clang-у точно так-же, как и к llvm-gcc

> Coverity, как я понимаю, OS-версии не имеет?

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

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

Сладко когда на просторах морских разгуляются волны

С твёрдой земли наблюдать за бедою постигшей другого

Не потому, что нам чьи либо беды приятны

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

Нихрена себе сказочку сократили. *ВИМ.

>>И закономерно на каом- то этапе становится проще свое сделать.

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

Ну, допустим, какашек с обеих сторон полетело достаточно. Я привел одни из множества обьективных причин замены gcc. ИМХО религиозность тут непричем совершенно. К тому же, когда я его (clang) пробовал (хеловорд, ничего больше) то он мне как- то удобнее показался (шустрее компилит, более внятно показывает ошибки). АСЕМБЛЕРНЫЙ КОД Я НЕ ПРОВЕРЯЛ.

Вы же СВОБОДНОЕ сообщество. Вы же за альтернативу. Но, блин, как только появляется альтернатива православному ГЦЦ или линуксу как тут же летят какахи. «Ненужно», «Велосипед», и т.д.

Ну и одно дело - базовая система на clang-е, а другое - llvm-gcc _пока_ ещё остаётся _базовым_ для llvm.

А никто из РАЗРАБОТЧИКОВ FreeBSD и не говорил ни о чем большем нежели base system. Это в форумах уже бурления.

И как уже заметили, сравнивать clang и gcc - это даже не моська со слоном... А llvm относится к clang-у точно так-же, как и к llvm-gcc

А нафига нужен комбайн для сборки ядра и мира? Там и С++ вобще- то явление крайне редкое. Помоему нормальная штука - собирать ядро + мир более шустрым clang (кстате, билдсервер, думаю, обрадуется), а софт из портов по прежнему gcc там где это нужно. Единственное «но»- это поддержка ARM/MIPS, но думаю со временем допилят.

4.2

Ой, бедный дебиан.

Само собой, http://www.debian.org/support.ru.html
Если интересует коммерческая поддержка, то http://www.debian.org/consultants/

А также:
http://www.linuxcenter.ru/shop/debian/#cat_lc1071
http://ossupport.ru/debian.html

С небольшой натяжкой:
http://www.businesslinux.ru/

Так что сабж.

http://www.freebsd.org/commercial/

>FreeBSD для красноглазых дрочеров которые любят городить велосипеды на коленках!

Yahoo?

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

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

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

«The 'clang' driver is designed to work as closely to GCC as possible to maximize portability. The only major difference between the two is that Clang defaults to gnu99 mode while GCC defaults to gnu89 mode. If you see weird link-time errors relating to inline functions, try passing -std=gnu89 to clang.»

«By December 2009: Clang C++ is able to parse GCC 4.2 libstdc++ and generate working code for non-trivial programs»

Но есть нюансы :)

> Погугли новости о busybox и тех, кто пытался его использовать, нарушая GPL.

Погугли новости о МСВС, ОС «Атликс-2» и СКЗИ «Атликс». После этого можешь начинать жаловаться в FSF, и посмотри, что будет.

>Погугли новости о МСВС

Ты уже легально приобрёл МСВС? Нет? Иди в пень, боярин.

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

1. Программа, написанная по стандарту, будет компилиться любым компилятором, соответствующим стандарту. Программа, компилирующаяся gcc, msvc и icc, скорее всего скомпилируется любым другим (нормальным) компилятором. Т.е. если clang будет поддерживать стандарт, править сорсы придется только там, где их действительно надо править (двусмысленности в коде, пропускаемые gcc)

2. Совместимость на уровне бинарников, флагов компиляции, прагм. Это уже более сложная задача, однако решаемая (icc например, почти полностью совместим)

>Ты уже легально приобрёл МСВС? Нет? Иди в пень, боярин.

yyk

а в это время, в замке у шефа...

http://www.linux.org.ru/news/kernel/4794115?lastmod=1271673703499

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

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

>> Отладчик не использовал, так что не знаю.

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

И что, в нем тоже можне скрипты на руби писать?

>>Джеймс Ботомли (James Bottomley) - мантейнер SCSI подсистемы ядра Linux, заметил, что подобная ситуация довольно распространена. Очень часто производители встраиваемых систем делают форк ядра, продолжая его обособленное развитие, не возвращая своих наработок в ядро Linux. Google - первая компания, предавшая огласке этот факт.

То, что они не возвращают в ядро не означает, что они закрывают исходники.

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

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

>Да? А то, что на icc ядро можно собрать - это из параллельной реальности что-ли? Ясное дело, что ядро не ванильное в этом случае, но раз уж смогли в кратчайшие сроки доработать до сборки на icc - значит ядро гвоздями к GCC не прибито.

А тут в icc костыликов наставили, чтобы он местами gcc прикидывался

>Ясное дело, что ядро не ванильное в этом случае

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

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

Вообще-то сертификация BSD-админов уже есть, коммерческая поддержка FreeBSD тоже есть, насчет сертификации железа под FreeBSD не знаю

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

Ставим Windows парниша и поддерживаем поддерживаем...

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

Тебе уже с казали на счёт возврата. И на счёт судебных преследований тех, кто не открывал исходники тоже.

Хочешь сказать, что GPL _не гарантирует_, что производные работы будут открыты? Так ни одна лицензия ничего не гарантирует - они только описывают легитимные условия использования, кэп.

Хочешь сказать, что кто-то «плевал на лицензию с высокой башни»? Ну так приведи пример _выигранного в суде_ дела против FSF/производителя СПО из-за нежелания открыть исходники. А так и я могу напомнить про судьбу «ЕУЛы» на просторах екс-СССР ;)

> Само собой, http://www.debian.org/support.ru.html

Но сертификатов, сертификатов-то нету! Ох, бяда-огорчение!

что я хотел сказать - то и написал

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

отсюда лично я делаю вывод: разница в текстах GPL и BSD не так сильно влияет на развитие open source продуктов, как это кажется большей части местных завсегдатаев

Да что же вы там курите-то? Сравнивал на своих проектах. Visual C++ в студии вплоть до 2008.

Visual C++ - на Windows, естественно. Проблема 1: Довольно часто корректный C++ код не компилируется, приходится править. Проблема 2: Распределенная компиляция требует отдельного продукта, за отдельные деньги. Проблема 3: Эквивалент valgrind - отдельный продукт и требует дополнительных и немаленьких денег, при этом тормозит как there's no tomorrow. Проблема 4: Библиотеки вроде sqlite, openssl, etc откомпилировать и слинковать - это отдельная работа.

GCC на Linux, тоже естественно. Проблема 1 не существует как класс, gcc как компилятор C++ намного более корректен. Проблема 2 не существует: установка distcc требует одной команды в любом Linux, и не ограничивает в кол-ве используемых машин для параллельной компиляции. Проблема 3 не существует: valgrind ставится одной командой, и предоставляет как memcheck, так и проверку race conditions в helgrind, и profiler, который хоть и тормозит, но гораздо меньше чем в Windows. Проблема 4 не существует: либы ставятся одной командой.

Сравнение одного и того же кода проект, декодирующего xls и скомпилированного под VC++ и gcc, на spreadsheet размером 25Mb, показало: 1) Программа на GCC требует примерно на 40% меньше памяти 2) Программа на GCC выполняется на 30% быстрее

После пары дней оптимизации кода под VC++, выяснилось: основные проблемы на операциях с потоками IO и захвате-освобождении памяти. После драконовской переделки всего на обычный buffered IO и переделки захвата памяти на большие блоки ускорились обе версии. GCC-шная ускорилась еще где-то на 5%, и VC++-ная на 25%. Даже после этого программа, скомпилированная GCC, была на ~10% быстрее.

Вывод: VC++ - редкостное говно. Супер-оптимизаций там нет. Скорость компиляции там может и выше, но на одном процессоре. При увеличении числа процессоров до 4х GCC уже заметно быстрее. Кол-во глюков в C++ типа падения компилятора без объяснимых причин слишком велико.

Так что давайте сравнивать компиляторы в родных средах. И все встанет на свои места.

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

И что? УК тоже сплошь и рядом нарушают.

(Мачтательно) Найти бы только аналог VisualAssist...

А вобще, под виндой GCC использовать неудобно. Со сторонними бинарными либами гемор. Под Линукс VC++, ну понятно... Так что ИМХО каждому свое. Универсального инструмента как небыло так и нет (да и не будет, наверное).

>> Это всё равно, что сравнивать Firefox и Chrome. Chrome маленький и шустрый, но нифига не умеет. Firefox кушает ощутимо побольше, но работает вполне приемлемо, и при этом позволяет использовать кучу расширений, а также предоставляет много возможностей, которых нет в Chrome.

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

На канале в 12Mbit: Firefox и Chromium открывают страницы примерно за одно и то же время. А вот функция Back реализована в FF более корректно (возвращает не в начало предыдущей страницы, а в место, откуда открыта текущая) и работает быстрее. Вчера попробовал на 256Kbit: Chromium не может даже GMail открыть - timeout, а FF нормально работает.

Как обычно: в распиаренном «быстром» Chromium не работают базовые функции.

А про Оперу и говорить не стоит. Комбайном обычно называют предопределенную коллекцию низкокачественных компонент (если не вдаваться в сельское хозяйство). Я всегда удивлялся - зачем лесорубы в IRC-chat еще и браузер вставили?

>что я хотел сказать - то и написал

отсюда лично я делаю вывод: разница в текстах GPL и BSD не так сильно влияет на развитие open source продуктов, как это кажется большей части местных завсегдатаев

И каким хером я должен догадываться что ты там глаголишь?!!!! «разница в _текстах_ GPL и BSD» - мать, они различны _текстом_ на 98%, если не больше. «разница в текстах GPL и BSD ... влияет на развитие open source продуктов» - как «разница в текстах» влияет на развитие проектов? и как? и каких именно проектов?

Или всё-же ты хотел сказать, что принципиальные различия GPL и BSD _лицензий_ не так сильно влияет на развитие проектов под этими лицензиями? Так и здесь с тобой не согласятся, причём не согласятся с обоих сторон :)

>И что? УК тоже сплошь и рядом нарушают.

УК не годится на аналогию, потому что:
1) в самих США недавно была бурная радость представителей FSF: «ура! первый прецендент в судебной системе, доказавший силу GPL!» То есть, даже в США применимость американского текста GPL и её обязательность была под вопросом долгое время. Про другие страны и говорить нечего.
2) С другой стороны УК в каждой стране свой, родной, и его обязательность и применимость доказывается гос.органами каждый день. Так что не надо распространять силу УК на GPL.

Я согласен, что текст лицензии требует соблюдать некие правила, и правильные ребята должны соблюдать эти условия, но на практике влияние лицензий GPL и BSD на развитие OSS не сильно различается: в обоих случаях компании могут не вернуть код, в обоих случаях компании предпочитают вливать свои изменения в основную ветку разработки для оптимизации своих издержек.

>И каким хером я должен догадываться что ты там глаголишь?!!!!

Любым подходящим, какой найдешь. И не кричи так громко.

Прочитай так: «разница в текстах лицензий GPL и BSD...»
стало легче?

>кто же из приличных IDE для С++ не тормозит

Geany :)

>Вчера попробовал на 256Kbit: Chromium не может даже GMail открыть

чего вы там курите, у меня дома 128кбит и все браузера работают