LINUX.ORG.RU

Компилятор Clang теперь пригоден для сборки Linux-ядра

 , ,


0

3

В блоге разработчиков Clang появилась информация о том, что с помощью Clang удалось собрать работоспособное ядро Linux версии 2.6.36 с поддержкой многопроцессорных систем (SMP). Несмотря на то, что некоторые компоненты ядра пока не поддаются компиляции, это событие приближает тот момент, когда Clang превратится в полноценный аналог GCC.

Немного технической информации:

  • В качестве основного стенда использовался Macbook 5.1 на базе Intel Core 2 Duo (не стоит забывать, что разработку Clang поддерживает в первую очередь компания Apple). На этой конфигурации удалось запустить ядро с работоспособным X-сервером, а также ядро в среде Qemu
  • В качестве второго стенда использовалась microATX-платформа на базе Intel Atom. В этом случае ядро также функционировало, однако разработчики не пытались запускать X-сервер
  • В системе на базе собранного ядра компилятор успешно собирает сам себя, а также новое ядро. Разработчики докладывают об успешной работе кода, полученного в ходе четвертого цикла самосборки.

Работоспособны следующие компоненты ядра:

  • Базовый код ядра, файловые системы, поддержка шин, в том числе и PCI, ACPI
  • SMP, SMT, SysV, pThreads и POSIX IPC
  • NUMA, управление памятью и SWAP
  • Сетевой стек IPv4, за исключением IPSec
  • Некоторые драйверы и прошивки

Пока не удалось добиться работы следующих подсистем:

  • CryptoAPI, а следовательно, и SELinux, Posix ACLs, IPSec, eCrypt
  • Стека IPv6 и код Netfilter/Router из-за зависимости от CryptoAPI
  • Виртуализации (поддержки гипервизора Xen)
  • Поддержки загружаемых модулей

Разработчики намерены и дальше улучшать совместимость между Clang и GCC и добиваться сборки с помощью Clang полностью работоспособного ядра.

>>> Подробности



Проверено: anonymous_incognito ()
Последнее исправление: Dmitry_Sokolowsky (всего исправлений: 3)

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

>> Функции поиска в приложениях кде4,

Вот чем она вам не нравится?

Не могу сейчас заскриншотить, нахожусь в другом дистре, если нужно, могу это сделать в другой раз. Разрешение 1024х768, шрифты крупные, чтобы глаза не утомлять. Юзаются kwrite и konsole, в 3 кедах при поиске выскакивало новое окошко и всё было прекрасно. В kde 4.4.5 в имеющемся окне добавляется новая строка. Ширина каждой кнопки зависит от размера шрифтов + большие пробелы по краям кнопки. Если кнопки не помещаются в окно, они не переносятся на новую строку, как это сделано в меню оперы, нет - расширяется окно так что не влезает в экран, а после отключения поиска нужно вручную изменять размер окна. Что здесь может нравиться? По этой же причине в кде4 не использую kaffeine - окно не влезает в экран из-за дурных кнопок по вертикали и горизонтали. Вместо него пришлось задействовать qmmp - там размер окна не зависит от размеров системных шрифтов.

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

>А сейчас там не помойка?

Да не совсем, настоящая помойка в маздайном секторе.

Зоопарк и почти везде ситуация, аналогичная 12309.

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

Законы рынка не действуют в этом секторе. Спрос на аналог Adobe Flash ничего толкового не родил. И не родит без тех, кого Вы выше назвали «хомячками», т.к. ради 1% никто особенно стараться не будет. Даже для Mac OS X далеко не всё есть, хотя их доля - выше и даже некий ореол «элитарности» привит.

Толковый аналог флеша потому и не появился, что уже есть флеш, второй аналогичный делать лениво. Закон рынка такой: если тебе нужен флеш, то никого не волнуют твои желания, чеши на платформу на которой он есть. А вот если его не было бы, игроделы придумали бы что-то другое для небольших броузерных игр. Фактически так и было, адоб купил уже готовую технологию. При большом спросе на какой-то из платформ, по законам рынка, возникает продукт, а после «рынок сделал своё дело, рынок может уходить». Если бы что-то случилось с виндовыми разработчиками флеша, то рано или поздно он появился бы на другой платформе в несколько урезанном варианте. Просто там многие вещи появляются чуть раньше и перекрывают кислород появлению аналогов. Вот есть гиф, хоть он не идеален, а внедрение apng затормозил надолго. Кто успел тот и съел, поэтому кривые беты и рулят.

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

столлмановская «защита gpl» явно противоречит юниксовой идеологии

Ахренеть. Каким образом? GPL не заражает через pipe'ы.

Не совсем про pipes, но про них скорее всего тоже самое было бы:

Matt Mackall

This is the hypothetical I reach for when considering how linking can be abused:

Developer X writes an extension eval.py that exposes eval() in the Mercurial process over a socket to his application UltraSCM. Now application UltraSCM can exploit Mercurial in any and all possible ways at runtime and proceeds to do so including adding new proprietary functionality like improved compression and performance.

Developer X claims that UltraSCM is not a derived work because a) it's not linking, and b) makes no changes to the source code and c) all the «derived work» bits are in a separate 10-line eval.py file with a GPL on it that could «just as well have been written by a third party».

I think Developer X will almost certainly find himself mistaken in a court of law and thus the idea that you can isolate yourself from «derived work» claims with a GPL proxy is also generically mistaken. All that actually matters is, oddly enough, if you're a «derived work».

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

> Там речь только о клавиатурных командах.

я же тебе тут, прямо в треде, предъявил команды «seek 60 2»; эти команды *параметризованы* аргументами (которые записаны цифрами) — этого достаточно, чтобы назвать выполнение этих команд интерпретацией

что значит «клавиатурных командах»? и что это меняет, если меняет?

чтение команд из файла не мешает параллельно читать кейпрессы с клавиатуры, и интерпретация кейпрессов будет *отличаться* от интерпретации строчек из файла; так, кейпресс e сам по себе есть команда «increase pan-and-scan range», и мплеер не будет ждать, пока ты сложишь из него слово seek, а выполнит его немедленно

(впрочем, кейпрессы у меня запрещены с помощью -noconsolecontrols)

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

>> События «нажатие клавиши PrtSc» интерпретируются виндой, а не прикладной программой.

Какой еще вендой? У меня нет венды. И ты можешь посылать не PrtSc, а клавишу, которая делает скриншот именно в плейере.

А у меня НЕТ генерации клавиш или команд, которые посылают команду «сделать скриншот». У меня выхлоп в джипег заказан аргументами командной строки, и промежуточные (между якобы скриншотами) кадры мплеер не только не показывает, но и *не генерит*.

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

А по твоим оценкам, во сколько раз решение приведенной выше задачи наложения фильтров будет короче в случае xine-libs? Возможно ли вообще решение такой задачи через командный интерфейс MPlayer?

как вариант (я не пробовал)

mplayer input.file -vo yuv4mpeg:file=/mplayer input.file -vo yuv4mpeg:file=/path/to/pipe &

my_proprietary_filter /path/to/pipe | mplayer ....

идиотизм подход, подобный Столлмановскому, тут бы вылился в добавление в лицензию определения «Eligible Film Playing Process», в котором бы это запрещалось

Ахренеть. Каким образом? GPL не заражает через pipe'ы.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

а никому не хочется доказывать в суде, что ты не верблюд; а при наличии «Eligible Film Playing Process» исход суда вполне очевиден — виновен.

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

че-то дважды скопипастилось, так что поправка:

mplayer input.file -vo yuv4mpeg:file=/path/to/pipe &
my_proprietary_filter /path/to/pipe | mplayer ....

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

>Я сам пользуюсь программами с BSD-like лицензией, но если у меня возникнет потребность в какой-то библиотеке, то глазом не моргну — изменения не отдам.

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

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

> This is the hypothetical I reach for when considering how linking can be abused:

Developer X writes an extension eval.py that exposes eval() in the Mercurial process over a socket to his application UltraSCM.

Это тупо другой сценарий - developer X взял GPL-программу и попытался сделать из нее библиотеку. Здравый смысл говорит, что лицензия нарушена.

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

>Ну, допустим, запрещать портировать они не будут. А вот сделать как в айфоне — вполне могут.

пусть делают, тебе жалко? Ты пользуешь АйФоном и АппСтором?

осталось запретить устанавливать софт не из него

не пойдут они на это.

1) Необходимость платить за средства разработки отпугнет инди-разработчиков программ для АппСтора

2) некоторые производители серьезного софта не согласятся ложиться под требования Яббла (например, Матлаб использует Яву, т.е. автоматом не проходит в АппСтор)

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

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

> я же тебе тут, прямо в треде, предъявил команды «seek 60 2»; эти команды *параметризованы* аргументами (которые записаны цифрами) — этого достаточно, чтобы назвать выполнение этих команд интерпретацией

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

что значит «клавиатурных командах»? и что это меняет, если меняет?

Это значит, что тебе представлен негибкий высокоуровневый интерфейс.

А по твоим оценкам, во сколько раз решение приведенной выше задачи наложения фильтров будет короче в случае xine-libs? Возможно ли вообще решение такой задачи через командный интерфейс MPlayer?

как вариант (я не пробовал)

На эту тему больше вопросов нет.

But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

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

tailgunner ★★★★★
()

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

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

>пусть делают, тебе жалко?

Жалко, что freebsd-шники тратят на похоти эппла своё время и силы, которые они бы могли потратить на написание того СПО, которого ещё нету.

Необходимость платить за средства разработки отпугнет инди-разработчиков программ для АппСтора


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

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

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

Не отдам. Проблем не возникнет. Целенаправленная, организованная и проплаченная деятельность по развитию кода отделом смышленных сотрудников будет куда эффективнее работы волонтеров, которые что-то там добавляют, когда у них есть время. Коммерческий продукт просто выкинет открытый код на обочину. Особенно красиво получится, когда над закрытой версией будут за деньгу пахать бывшие контрибуторы открытого проекта. В открытый проект, понятное дело, они уже свой код отдавать не смогут.

Ты пользователю будешь предлагать пользоваться открытый продукт, а он спросит: «А эта фишка есть? А такие файлы корректно открывает? А это он умеет? А вот закрытая версия умеет — поработали над этим». Открытый продукт оказывается убитым.

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

>А в аппсторе для айфона разве не полно поделий инди-разработчиков?

Полно, но сейчас за Xcode и iPhone SDK платить не надо. А пока Xcode бесплатен, опенсорс на Маке будет жить припеваюче, пофиг, банально модифицированный там компилятор/линкер или нет

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

>Жалко, что freebsd-шники тратят на похоти эппла своё время и силы, которые они бы могли потратить на написание того СПО, которого ещё нету.

Решение об остановке на GCC 4.2 действительно странно, мотивация Яббла мне более понятна. Но собирать систему GCC > 4.2 никто не запрещает :)

А если FreeBSDшники добьются того, что хотя бы 50% мира будет собирать Clang - низкий им поклон от меня. Несоответствие кода стандартам вызывает проблемы даже при портировании программ с одной версии GCC на другую

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

> Это тупо другой сценарий - developer X взял GPL-программу и попытался сделать из нее библиотеку.

А использование GPL mplayer как библиотеки через IPC это не то же самое? Например, smplayer мог быть написан под лицензией отличной от GPL?

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

>> Это тупо другой сценарий - developer X взял GPL-программу и попытался сделать из нее библиотеку.

А использование GPL mplayer как библиотеки через IPC это не то же самое?

Нет. Программа изначально сделана для этого.

Например, smplayer мог быть написан под лицензией отличной от GPL?

Насколько я понимаю, да.

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

> Ты пользователю будешь предлагать пользоваться открытый продукт, а он спросит: «А эта фишка есть? А такие файлы корректно открывает? А это он умеет? А вот закрытая версия умеет — поработали над этим». Открытый продукт оказывается убитым.

-- и значит так *лучше* для всех. Ведь не все продукты должны быть открыты.

А про другой сценарий ты умолчал.

«Что? С кучей фич, но без исходников??? И пропатчить я его сам не смогу??? И дыры вы будете фиксить хорошо если через 3 месяца (как Адобе), а за срочность брать несусветные деньги???

Нет, спасибо. Я лучше возьму открытый, без этой фишки, с частичной поддержкой вот этих файлов, но с возможностью пропатчить для небольшой, но необходимой нам фичи, и с возможностью сделать workaround и прикрыть дыру за 3 часа.»

hint: Acrobat Reader

Адобовский поддерживает кучу фич, но большей частью мне они нафиг не сдались. Так что пользуюсь открытым ридером, НЕСМОТРЯ на бесплатность Супер Пупер Закрытого Мега Продукта.

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

>и значит так *лучше* для всех. Ведь не все продукты должны быть открыты.

Мы говорим о свободных продуктах, если мы говорим об свободных лицензиях. А раз мы допускаем, что сценарий закрытия «*лучше* для всех», то больше и спорить не о чем. Мои аргументы на этом закончились. Ты победил. Я признаю поражение. BSD — хорошая лицензия, так как лучше для всех, а GPL — говно.

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

> Мы говорим о свободных продуктах, если мы говорим об свободных лицензиях. А раз мы допускаем, что сценарий закрытия «*лучше* для всех», то больше и спорить не о чем. Мои аргументы на этом закончились. Ты победил. Я признаю поражение. BSD — хорошая лицензия, так как лучше для всех, а GPL — говно.

Мне вот например кажется, что наилучшие результаты показывает LGPL и примерно равные ей лицензии — типа лицензии линукса (GPL c загрузкой бинарных модулей).

BSD похоже отстает от LGPL, хотя PostgreSQL заставляет задуматься; думаю clang вырвется вперед, но будь gcc под LGPL — думаю этого бы не случилось

А чистая GPL для программ больших, чем cat/tail/ls, при отсутствии встроенного в программу хотя бы примитивного интерпретатора — действительно говно, за исключением случаев явного двойного лицензирования (GPL + че-то-еще).

Кстати, если не ошибаюсь, ls не имеет опции -0 (типа как у xargs), и поэтому тоже говно.

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

ну ведь должны же быть какие-то основания типа «общего блага», или просто верить в Божественную Открытость Только В Форме GPL?

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

>> А использование GPL mplayer как библиотеки через IPC это не то же самое?

Нет. Программа изначально сделана для этого.

А что значит «изначально» в мире GPL и легкой возможности форков?

Программу под GPL можно улучшить и добавить специально то, для чего она изначально не была сделана. Эта улучшенная версия тоже под GPL будет, но использовать ее как библиотеку через IPС будет куда проще.

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

> Программу под GPL можно улучшить и добавить специально то, для чего она изначально не была сделана. Эта улучшенная версия тоже под GPL будет, но использовать ее как библиотеку через IPС будет куда проще.

Последний раз, медленно и печально: если программа была сделана под GPL, это значит, что автор намеревался заражать другие программы. Если ты внесешь изменения, направленные на то, чтобы препятствовать заражению - ты нарушишь лицензию. Это понятно? Впрочем, даже если и непонятно, </thread>.

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

>ну ведь должны же быть какие-то основания типа «общего блага»

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

в Божественную Открытость Только В Форме GPL?


Да никто не говорит, что все программы должны быть обязательно под GPL. По крайней мере официальная позиция FSF такая.

но будь gcc под LGPL — думаю этого бы не случилось


libgcc и так фактически под LGPL.

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

Авторы mplayer сделали хорошие возможности для IPC, хотя они тоже «намеревались заражать другие программы». А если бы кто-то другой добавил эти возможности (и оставил результат под GPL), то их использование в не GPL уже бы нарушало лицензию (в отличии от того, что сейчас получается с mplayer). Немного странно, видимо самой по себе лицензии GPL недостаточно и нужно обязательно выяснять намерения у изначальных авторов.

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

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

Это не значит, что автор собрался заражать все, что т.Столлман и адвокаты считают «производной работой».

Рассмотрим пример ядра линукса.

Сначало оно было под GPL, и закрытые модули эту лицензию очевидно нарушали. Тем не менее

Nonetheless, we all know that there are a large number of such modules and their existence is tolerated or even to some degree encouraged by the kernel maintainers, and I take that to mean that as an indication that there is some exception for those modules.

http://lwn.net/Articles/147070/

короче, мейнтейнеры были нормальными людьми с мозгами, и не принимали всерьез идиотское ограничение gpl на линковку

так же и линус не хочет заставлять людей заражаться gpl:

Especially if they were actually originally written for Linux, I consider it a bit dodgy to not use the GPL (they can potentially be considered derived works, even if you don't actually link them into the kernel, per se).

But I do not want to force it on people that arguably are not doing derived work.

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

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

> короче, мейнтейнеры были нормальными людьми с мозгами, и не принимали всерьез идиотское ограничение gpl на линковку

Это всего лишь твое мнение. Столлман, например, считает тебя идиотом. С чего ты взял, что прав ты, а не он?

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

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

линус, в отличие от юристов и столлмана, не считает сам факт линковки фактом появления «derived work» — это весьма разумная позиция по этому поводу:

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

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

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

>> короче, мейнтейнеры были нормальными людьми с мозгами, и не принимали всерьез идиотское ограничение gpl на линковку

Это всего лишь твое мнение. Столлман, например, считает тебя идиотом. С чего ты взял, что прав ты, а не он?

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

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

его лицензия нихрена не способствует зарабатыванию денег на свободном софте — кто заработал на GPL? зарабатывают либо на двойной лицензии, либо на линуксе (фактически LGPL)

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

> Это всего лишь твое мнение. Столлман, например, считает тебя идиотом. С чего ты взял, что прав ты, а не он?

притом, кстати, я идиотом его не считаю — идиотскими являются:

1. понимание линковки как «derived work» независимо от обстоятелств

2. использование этого идиотского понимания для заражения программ лицензией GPL

а допустим судебные процессы с фирмами, пропатчившими гнутый софт и зажавшими исходники — это явно разумно

борьба с тивоизацией и патентным преследованием в GPL3 тоже разумно

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

>1. понимание линковки как «derived work» независимо от обстоятелств

Я, честно говоря, не совсем понял, зависимо ли от обстоятельств, или нет. Если я взял проприетарную библиотеку с собственным API и написал под неё программу, то эта программа считается производной от этой несвободной библиотеки и не может распространяться под GPL. Если я разработал библиотеку специально для конкретной программы под GPL, то библиотека является производной, и она должна распространяться под GPL. С этим всё понятно. А вот если я беру независимо разработанную проприетарную библиотеку каким-либо стандартным API (например, NPAPI) и распространяю её вместе с программой под GPL, то здесь есть нарушение GPL?

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

>2. использование этого идиотского понимания для заражения программ лицензией GPL

Тебе не нравится то, что вообще программы, которые линкуются с программами под GPL, должны быть свободными, или же только то, что они должны быть именно под GPL?

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

>А если FreeBSDшники добьются того, что хотя бы 50% мира будет собирать Clang - низкий им поклон от меня. Несоответствие кода стандартам вызывает проблемы даже при портировании программ с одной версии GCC на другую

Собрали. Ядро и мир целиком.http://wiki.freebsd.org/BuildingFreeBSDWithClang#head-cbb323ee8b7a6486f1fd12d...

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

yurkis
()

Где можно посмотреть сравнительные тесты производительности сгенерированного кода?

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

>>Аргументы есть. Посмотрите на капитализацию Apple и сравните с Red Hat, к примеру.

Господи, все бздуны такие, или ты особенный? Эппл зарабатывает на проприетарном софте, на бсдл она не зарабатывает. На ней разве что пиар заработаешь, да немного сэкономишь на разработке некоторых отдельных моментов. А весь бизнес Ред Хат построен на ГПЛ-софте. Никакой проприетарщины. Разницу чувствуешь? Можешь привести аналогичный пример компании, бизнес которой построен исключительно на бсд-лицензии? То-то. Потому что ГПЛ самодостаточен, а бсд без проприетарщины не может. Всего делов-то. Более того строить свободную ОС исключительно на БСД - тупизм. Просто потому, что она в принципе не может быть лучше коммерчесского проприетарного софта. Любая киллер-фича, появившаяся в бсд тут же доступна для проприетарщиков, поэтому бсд всегда будет пасти задних(что мы и видим на примере бсд-семейства). Также, как вайн никогда не догонит винду(но по другим причинам). Это закон природы. А гпл-софт вполне может быть лучше проприетарного. Просто потому, что его нельзя сделать проприетарным.

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

>>Наши моральные принципы - свобода

Кто тебе сказал такую чушь? Ты путаешь тёплое с мягким. Типичная подмена понятий. Ваши моральные принципы таковы:

1. Анархия. Что хочу, то ворочу. 2. Живём последний день. Бздуны не думают о будущем, что типично для анархистов. Если проект ГНУ работает, чтобы однажды человек мог пользоваться качественным, СВОБОДНЫМ ПО, превосходящим проприетарные аналоги, для чего и сделал лицензию ГПЛ вирусной, то бздунам насрать свободным или проприетарным софтом они пользуются. И будет ли в будущем возможность пользоваться свободным ПО или нет их ни капли не волнует. Так что могу отвественно заявить, что моральных принципов у них нет. Не считать же пофигизм моральным принципом?

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

>>Анонимус не читатель, анонимус - писатель.

Чтож, почитаем-поцитируем.

Только число тех, кого может прокормить GPL - намного меньше, чем число тех, кого может прокормить BSDL.

Аргументы есть? Или газометание в действии?

Аргументы есть. Посмотрите на капитализацию Apple и сравните с Red Hat, к примеру

Аргументы: ГПЛ кормит большое число компаний: РетХат, Новелл, Альт Линукс, куча фирм-внедренцев и тд и тп. Их кормит исключительно ГПЛ-софт. Их бизнес построен на ГПЛ. А твои аргументы-г"вно, так как Эппл делает деньги на проприетарщине. Ссылку на более-менее крупную контору, которая делает бизнес на бсд в студию! Только таких нет.

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

Эппл делает деньги на проприетарщине. Ссылку на более-менее крупную контору, которая делает бизнес на бсд в студию!

Успокойтесь и прочтите, что Вы написали. Может быть, тогда поймёте, что «проприетарщина» может быть и BSD.

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

>>Может быть, тогда поймёте, что «проприетарщина» может быть и BSD.

Не, то что бздуны - это проприетарщики я понял уже давно. К «свободе» они имеют такое же отношение, как США к демократии. Только на бумаге. Хотелось бы, чтобы это и другие уяснили. Бсд - это костыль для проприетарщины. Самостоятельно в бизнесе она существовать не может. Этакий паразит. Так что ни одного человека ваша бсд не кормит. Кормит Эппл, который зарабатывает на проприетарщине. Ни одна контора не зарабатывает на бсд. Это факт.

Успокойтесь и прочтите, что Вы написали

По теме есть, что сказать? Я таки всё надеюсь услышать, кого кормит бсд.

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

Моё утверждение: с помощью продуктов под лицензией BSD-типа многие компании зарабатывают деньги. Это и Apple, и тот же RedHat (Apache, x11 - не GPL, а лицензия - BSD-типа), и другие. Я не говорил об открытости или закрытости продуктов вообще.

Вы же приписали мне свои слова о том, что зарабатывают именно на продуктах с окртытым кодом. И хоть такие компании привести в пример не сложно (да тот же RH на Apache, postgres, x11, в том числе, зарабатывает деньги), я не намереваюсь отстаивать приписанное мне Вами утверждение.

maxkit
()

объясните мне, зачем оно нужно

tazhate ★★★★★
()

BSD -> GPL:

Redistristribution... source code or in binary form... is permitted, providing that the following conditions are met: 1. 2. 3. [DISCLAIMER] ---------------

GNU General Public License version X, [date]

blabla 1. 2. .. X. ---------------

А теперь делай eval по этим лицензиям в порядке их появления в файле (потому что иной порядок является прямой сменой лицензии, что запрещено самой BSDL - при eval GPL-then-BSDL будет совсем другой результат)

Итак: Упомянули авторов Вбросили текст BSDL из исходника (короче, оставили, как есть) Выполнили рекламное условие (если есть) Сопроводили disclaimer'ом. Собственно, появление в тексте disclaimer означает конец списка тех самых following conditions.

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

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