Сообщество

krufter_multiclet wrote:

Но мнение по LLVM нам тоже очень интересно. Так как сейчас запущен процесс проработки стыковки с LLVM.

В неравной схватке gcc и llvm победил последний
Удачи! :-) (без сарказма)

Здравствуйте.

Думаю, что на данном этапе виртуальная JAVA машина будет лишней тратой ресурсов (пока не достигните хотя бы 1 Ггц).

Может лучше пока сделать демку для вашей отладочной платы, чтобы на экранчике при старте было действие, а то см. "видео первого включения" в статье Существует ли отечественный процессор Мультиклет?

krufter_multiclet wrote:

Но мнение по LLVM нам тоже очень интересно. Так как сейчас запущен процесс проработки стыковки с LLVM.

LLVM для исследователей раздел "Использование прохода для решения более сложных задач" -> "IRBuilder" вам не помог в реализации работы коммутатора?
Как у вас сейчас реализована ссылка на ячейку в коммутаторе из инструкции в конечном коде?

По Java машине согласен.
Сейчас и занимаюсь оформлением примера работы с экраном. Некрасиво выкладывать код без оформления.
Поэтому пришлось написать полную библиотеку для работы с pll и утилитку на javascript для расчета коэффициентов.
Осталось дописать библиотеку для работы с spi, конфигурационный файл в котором пользователь сможет указать какой таймер он отдает для библиотеки с реализацией задержек по таймеру. А также реализовать некоторые функции libc. Очень надеюсь, что на следующей неделе пример будет доступен на сайте.

LLVM пока прорабатываем на предмет того сможем ли его прикрутить к нам. Сейчас есть только lcc работающий.

Aha wrote:

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

А я скажу вам, что все ваши примеры по поводу патентов -- пустая трата времени и глупость и вот по какой причине:

Допустим Мультиклет поддерживает АОТ-компиляцию, то какие патентные притензии к этому могут быть ?
А никаких не может быть, т.к. они её не будут использовать, но такая поддержка нужна для их клиентов.

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

Таким образом Мультиклет будет терять клиентов.

А теперь приведу вам другой пример -- знаете, например, фирму qualcom ? Она производит АРМ процессоры. Все её АРМ процессоры поддерживают АОТ-компиляцию. Не уж-то вы думаете, что она покупает лицензии на соответствующие патенты ?
А не покупает она их, потому что эти лицензии должны покупать производители конечных устройств, которые используют соответствующие технологии, т.е. например, производители смартфонов, которым qualcom продаёт свои процессоры.

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

Yaisis wrote:

Aha wrote:

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

А я скажу вам, что все ваши примеры по поводу патентов -- пустая трата времени и глупость и вот по какой причине:

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

Против Ваших примеров я не буду возражать, примеры как примеры...

Но вот зря я это только что прочитал... ;-)
цитирую исключительно just for fun ;-)
"...'Нарушение патента' означает воплощение одной или нескольких патентных формул этого патента без лицензии..."
"...Можно отвечать за нарушение патента без прямого нарушения этого патента..."
"...'Склонение к нарушению' означает активное убеждение кого-то ещё нарушить патент. Для наступления ответственности требуются доказательства того, что обвиняемая сторона намеренно добилась того, что третья сторона нарушила патент."
Не принимайте близко к сердцу, в контексте данного треда это просто весело :-)

Aha wrote:

"...'Нарушение патента' означает воплощение одной или нескольких патентных формул этого патента без лицензии..."

И к чему вы это ?
Если будет возможность клиентам Мультиклета реализовать без проблем АОТ-компиляцию, то сама такая возможность не является нарушением.
"воплощение одной или нескольких патентных формул этого патента без лицензии" -- это означает использование запатентованных технологий, т.е. АОТ-компиляция должна использоваться, тогда и надо покупать лицензию, если же в Мультклете просто создадут все условия для лёгкого воплощения данной технологии, то это не будет являться её использованием без её задействования. Чтобы её задействовать, клиент должен её ещё установить/включить или сам реализовать с помощью соответствующих инструментов, предоставляемых разработчиками, если же он это сделает, то должен сам осознавать, что необходимо покупать лицензию, т.к. он её использует, а не кто-то другой.

"...'Склонение к нарушению' означает активное убеждение кого-то ещё нарушить патент. Для наступления ответственности требуются доказательства того, что обвиняемая сторона намеренно добилась того, что третья сторона нарушила патент.

И кто и кого склоняет нарушать патенты ?
А главное как ?
Я думаю, что прежде чем писать эту ерунду про патенты на АОТ-компиляцию Андроида, надо вначале было разобраться по каким условиям он распространяется. Если вы получили право на установку Андроида, то не будет у вас никаких проблем с АОТ-компиляцией, включённой в него. А так же есть свободная и открытая прошивка cyanogenmod с соответствующей лицензией на её использование и которая тоже включает в себя АОТ-компилятор. Под соответствующими лицензиями Андроид выпускает Гугл и патент на АОТ-компиляцию её-же. Если в лицензии написано, что вы можете использовать Андроид, как хотите, то значит эта лицензия даёт вам такое право и эту лицензию можно использовать в суде, т.к. Гугл под ней распространяет данные исходники.
Если же там будет какое-то нарушение патентов, то виноват в этом будет тот, кто устанавливает данные прошивки, а не разработчики процессора и средств разработки в виде LLVM, они не виноваты в том, как LLVM используется.
Реализовывать же АОТ-компиляцию без Андроида пока не вижу смысла.

sprin wrote:

Как у вас сейчас реализована ссылка на ячейку в коммутаторе из инструкции в конечном коде?

Тут можно посмотреть полную структуру http://multiclet.com/community/projects/examples/wiki/R1_ISA
Если кратко, то используется 6-ти битное поле в котором указывается сколько инструкций назад был результат нужный текущей команде в качестве аргумента из коммутатора.

Статью нашему сотруднику, занимающемуся сейчас анализом LLVM я высылал ранее(читаю иногда Хабр). Но если появятся какие-то мысли или советы по портированию LLVM, то всегда рады их услышать.

Yaisis wrote:

Aha wrote:

"...'Нарушение патента' означает воплощение одной или нескольких патентных формул этого патента без лицензии..."

И к чему вы это ?

Повторяю еще раз:
"Цитирую исключительно just for fun ;-)"

"...'Склонение к нарушению' означает активное убеждение кого-то ещё нарушить патент. Для наступления ответственности требуются доказательства того, что обвиняемая сторона намеренно добилась того, что третья сторона нарушила патент.

И кто и кого склоняет нарушать патенты ?

И тут тоже я могу повторить только то, что уже написал:
"В контексте данного треда это просто весело :-)"

Aha wrote:

"В контексте данного треда это просто весело :-)"

Может вам и весело, вам же всё понятно, что вы пишите.

Ну ладно, не будем больше захламлять ветку патентами, а с Явой вроде уже всё итак понятно.

krufter_multiclet wrote:

... Но если появятся какие-то мысли или советы по портированию LLVM, то всегда рады их услышать.

Вам надо разобраться, как создать генератор кода под вашу архитектуру. Там можно описывать регистры и инструкции в специальных файлах, но чувствую, что вам это не подойдёт. И так же можно ещё на С++ создавать специальный код по обработке.
Я не вникал в эти тонкости, но думаю, что вам лучше при этом советоваться с разработчиками LLVM, у них на сайте(http://llvm.org/) есть адрес IRC канала, возможно там можно с ними пообщаться. Так же у вас могут возникнуть трудности(вы о них уже знаете), но когда разработчики LLVM узнают о вашей новой архитектуре, то, возможно, будут дорабатывать механизм описания генераторов LLVM (если конечно сейчас он не подходит для неё).

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

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

Yaisis wrote:

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

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

К примеру, в данный момент в багтрекере llvm поддержку clang-om С++ всех версий стандарта зарегистрировано более 1100 багов.
Да, можно сказать, что поддержка С++ во фронтенде есть и это "просто баги", тогда останется только придумать "отмазку" перед заказчиком, если он за свои деньги наткнется на один из этих чужих багов, если вдруг не получится их пофиксить своими силами (С++ - это <censored> для имплементации)
В условиях органиченности ресурсов это лучший выход для небольшой перспективной компании

krufter_multiclet wrote:

Портирование виртуальной машины JAVA для Мультиклета. Кто, что думает об этом, есть ли смысл это реализовать?
........
Но если появятся какие-то мысли или советы по портированию LLVM, то всегда рады их услышать.

А какая OS у вас "официальная"? FreeRTOS, судя по документации? Или что-то еще появилось "поддерживаемое" "портированное"?
Это я к тому, что тот же C++ потребует runtime-поддержку, которая будет, возможно, OS-зависимой
Не говоря уж о платформо-зависимой имплементации JVM (если и когда JVM случится)
(просто интересно)

Сейчас мы ориентируемся на FreeRTOS, в ближайшем будущем появится обновленный пример и FreeRTOS под R1. Об этом будет указано в разделе "Новости".
С llvm сейчас активно продолжаем разбираться.

Aha wrote:

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

Это отличная идея и правильная.
Clang -- это открытый проект, никто не мешает проверять его код и исправлять самим баги в нём.
Clang`ом пользуются намного больше людей, чем собственным компилятором Мультиклета, поэтому Clang более оттестирован и в нём больше известно о количестве багов в нём, что является плюсом.
В собственном компиляторе Мультиклета будет багов не меньше, а неизвестных багов, которые ещё не проявились будет ещё больше -- не бывает программистов, не допускающих ошибок.

К примеру, в данный момент в багтрекере llvm поддержку clang-om С++ всех версий стандарта зарегистрировано более 1100 багов.

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

Да, можно сказать, что поддержка С++ во фронтенде есть и это "просто баги", тогда останется только придумать "отмазку" перед заказчиком, если он за свои деньги наткнется на один из этих чужих багов

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

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

Ну и в третьих -- clang поддерживают такие крупные и известные конторы, как Google и Apple, и сами его использует в своих продуктах. Они не краснеют перед заказчиками, а Мультиклет начнёт ? Они платят за развитие clang`a, значит Мультиклет может не платить...

если он за свои деньги наткнется на один из этих чужих багов

Баги -- это привычное дело в программировании. Наткнётся он, сообщит, в Мультиклете исправят -- ничего страшного. Тоже самое произойдёт и с их собственным компилятором -- у них в нём будут баги не лучше и не хуже, чем в clang`е. Клиентам же всё-равно свои там баги или чужие, для них лучше было бы, если бы их не было.
И в clang`е по понятным причинам уж явно должно быть меньше багов, чем в собственном компиляторе.

В условиях органиченности ресурсов это лучший выход для небольшой перспективной компании

Это лучший выход для всех компаний -- крупные и богатые конторы типа Apple, Google, IBM, Samsung и т.д. -- все они не пилят велосипеды, а дорабатывают открытые проекты и приспосабливают их к своим нуждам. Но у них есть при этом деньги на развитие своего. Они своё не развивают, если есть то, что можно взять и доработать, потому что они тратят свои ресурсы с умом. Создавать компилятор известного языка с нуля -- вот это худший выход. Сколько лет пройдёт, прежде чем они достигнут того же уровня качества, что и clang и того же уровня поддерживаемого стандарта языка ? Вышеназванные конторы так долго ждать не хотят и именно поэтому дорабатывают уже готовое. А будут ли клиенты Мультиклета так долго ждать ?

Точно так же можно было бы взять за основу например GCC.

Yaisis wrote:

Это лучший выход для всех компаний -- крупные и богатые конторы типа Apple, Google, IBM, Samsung и т.д. -- все они не пилят велосипеды, а дорабатывают открытые проекты и приспосабливают их к своим нуждам. Но у них есть при этом деньги на развитие своего. Они своё не развивают, если есть то, что можно взять и доработать, потому что они тратят свои ресурсы с умом. Создавать компилятор известного языка с нуля -- вот это худший выход. Сколько лет пройдёт, прежде чем они достигнут того же уровня качества, что и clang и того же уровня поддерживаемого стандарта языка ? Вышеназванные конторы так долго ждать не хотят и именно поэтому дорабатывают уже готовое. А будут ли клиенты Мультиклета так долго ждать ?

А таие крупные конторы, как Microsoft, PathScale, Oracle, Intel? Что с ними не так, почему они собственные компиляторы разрабатывают?!?

Aha wrote:

А таие крупные конторы, как Microsoft, PathScale, Oracle, Intel? Что с ними не так, почему они собственные компиляторы разрабатывают?!?

Потому что никто им этого не запрещает и начали они этим заниматься задолго до появления LLVM.

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

Так же Майкрософт позже сделала .NET, тогда ни одна свободная технология не поддерживала похожих решений. Ява принадлежала Ораклу и была несвободна, как и сейчас. Плюс Майкрософт на тот момент создала решение лучше, чем Явовское.
Сейчас же она могла бы делать на базе LLVM, но сейчас уже нет смысла, т.к. есть своё, а вот реализацию Моно делают на базе LLVM (но сначала тоже своё делали), как уже писал выше.
Майкрософт уже брала некоторые открытые проекты за основу под лицензиями BSD, которые позволяют коммерческое использование(точно не помню, какие именно проекты это были).

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

PathScale - я не знаю такой конторы.
Вот об ней из Википедии:
"...В начале 2003 года с успехом процессоров AMD Opteron компания переключила усилия на другие продукты, в том числе высокопроизводительные компиляторы для 64-битных систем, а в конце 2003 года сменила название на PathScale, которое должно было напоминать о том, что изначально компания разрабатывала решения для кластеров."

Возможно, у неё компиляторы уже были и до 2003 года, но именно в этом году она решила на них сделать ставку. Если компиляторы хорошие, то почему бы на них не зарабатывать ?
Первый выпуск LLVM вышел в 2003 году и тогда это был продукт с неизвестной перспективой и ещё сырой.
Может быть сейчас LLVM ещё отстаёт по производительности от их компиляторов, т.к. ещё не догнала. А если их целью было именно создание высокопроизводительных компиляторов, а другие имеющиеся их не устраивали, то был смысл этим заниматься. И так же можно было дорабатывать LLVM до соответствующего уровня, но как я уже говорил, тогда LLVM -- это было не понятно что, просто одна из технологий. Это сейчас она уже пользуется большой популярностью. А GCC не подходил для коммерческого использования.

Я не могу за всех говорить об их причинах к созданию чего-либо и в данной ветки речь идёт только об Мультиклете.
Сейчас им надо думать не об высокопроизводительном компиляторе(просто производительного достаточно), а об поддержке, как можно большего количество технологий и LLVM им в этом поможет.
У них нет столько ресурсов, как у PathScale, Майкросовт, Интел, Оракл и т.д.
А высокопроизводительный компилятор можно создать и на базе LLVM -- никто не запрещает там добавлять новые стадии оптимизации, но кучу из уже реализованного им не придётся реализовывать заново.
Основная проблема -- это состыковать это всё с ихней архитектурой, если это не удастся, то это и будет причиной для дальнейшего развития своего компилятора.

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

Yaisis wrote:

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

На любой например найдется свой контрнапример

Жила-была фирма Sun Microsystems (предыдущий владелец Java) и решила она однажды поиграть в OpenSource: открыла исходный код - и Java под GPL, и OS Solaris под более commercial-frendly CDDL.
Внимание вопрос! И где теперь та компания Sun Microsystems!?! Нет её, RIP...

Ее наследие теперь принадлежит Oracle следующим образом
- OS Solaris продолжает развиваться, но уже не под CDDL, а в closed-source виде, распространяется бесплатно в бинарном виде
- Java продолжает развиваться, но вот распространяемая в бинарном виде имеет лицензию (как и все Oracle-продукты) с неизменной фразой "you may not modify, decompile, or reverse engineer Software"
Игры в open-source закончились
Вряд ли кто может упрекнуть Oracle, что компания не умеет "делать деньги"...

PS. Я ничего не предлагаю. Я просто говорю, что open-source - это не всегда однозначно хорошо. И скорблю по "безвременно почившей"...

Aha wrote:

Жила-была фирма Sun Microsystems (предыдущий владелец Java) и решила она однажды поиграть в OpenSource: открыла исходный код - и Java под GPL, и OS Solaris под более commercial-frendly CDDL.
Внимание вопрос! И где теперь та компания Sun Microsystems!?! Нет её, RIP...

Т.е. переход на открытую модель разработки -- это единственная причина неудач фирмы Sun.
Плохие выводы делаете или намекаете на плохие выводы -- Sun разрабатывала не только ПО, а ещё процессоры, сервера, графические решения и т.д. Если она потерпела неудачу, значит её подделки никому не нужны стали и не надо всё сваливать на новые лицензии на ПО.
В истории можно найти кучу фирм, которые обанкротились и при этом не переходили на открытую модель разработки.
Так же я вам могу привести в пример фирму Самсунг -- она тоже хочет перейти на полностью открытую модель разработки ПО, но разве она обанкротится после этого ? Конечно нет, потому что её успех зависит не от этого, точно так же, как и успех SUN зависел не от этого.

Это было во-первых, а во вторых -- фирмы которые я вам привёл могут делать и закрытое ПО, т.к. лицензия LLVM это позволяет, но в этом нет смысла, т.к. в открытой модели разработки они решают проблемы общими ресурсами, а зарабатывают совсем не на этом ПО, а на других продуктах. А данное ПО -- это лишь инструмент для достижения их целей.

Я ничего не предлагаю. Я просто говорю, что open-source - это не всегда однозначно хорошо. И скорблю по "безвременно почившей"...

Как я уже говорил -- вы делаете неверные выводы. Я бы даже назвал их глупыми.
Если SUN решила переходить на открытую модель разработки, то значит уже были причины для этого. А если она потерпела неудачу, то данный переход просто не помог решить её проблемы.
Как я уже говорил, она кучу всего остального делала.
Вопрос, где это всё теперь ?
Кто ей мешал сделать ОС типа Андроида ? Никто, просто Гугл её опередил.
Кто ей мешал зарабатывать на своей ОС точно так же, как Red Hat ? Никто не мешал. Возможно её ОС стала другим не интересна ?
Где её процессоры UltraSPARC ? Может все просто на Интелы перешли ?
Где её графические сервера ? Может у конкурентов просто сервера лучше оказались ?
И задайте себе вопрос -- каким образом открытие исходников может снизить популярность её серверов и процессоров ?
Да никаким.
Она просто не выдержала конкуренции и поэтому ушла в историю, а не по каким-то другим причинам.

Тоже самое касается и Оракла, которая подала на Гугл в суд и типа якобы этот Гугл является причиной снижения популярности к Яве, как к самостоятельной платформе. Если бы Гугл выбрал не Яву, то он выбрал, что-то другое(например он вполне мог выбрать .NET или LLVM), а судьба Оракла была бы такой же. Это прогресс и Оракл за ним не успевает, делая не то, что пользуется спросом. Наоборот Гугл повысил популярность Явы, а Оракл просто хочет получить с этого деньги и он их получил.
И тут также мы видим пример, как Гугл не стал разрабатывать свой велосипед, а взял готовую Яву и на её базе создал отличный продукт.

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

Не задумывались ли вы, что SUN могла открыть исходники для того, чтобы её продукты быстрее распространились под другие платформы ? Ведь явно сама она не сможет поддерживать их все.
Она не может поддерживать все модели телефонов, планшетов и т.д.

И повторю ещё раз -- все её неудачи, не из-за смены лицензии.

Я просто говорю, что open-source - это не всегда однозначно хорошо.

Это может быть не хорошо только для тех, кто зарабатывает на ПО и то это к LLVM не относится, т.к. её лицензия позволяет скрывать код, т.е. использовать LLVM -- это хорошо, т.к. не надо писать всё с нуля. Можно сэкономить кучу денег.

Может Мультиклет собирается зарабатывать на ПО ?
По-моему нет. Я так понял, что на процессорах и устройствах.
И даже если всё ПО будет у них отрыто, то конечный успех будет зависеть только от качества и цены их продукции по сравнению с конкурентами.

Yaisis wrote:

Aha wrote:

Жила-была фирма Sun Microsystems (предыдущий владелец Java) и решила она однажды поиграть в OpenSource: открыла исходный код - и Java под GPL, и OS Solaris под более commercial-frendly CDDL.
Внимание вопрос! И где теперь та компания Sun Microsystems!?! Нет её, RIP...

Т.е. переход на открытую модель разработки -- это единственная причина неудач фирмы Sun.

Нет, конечно

Плохие выводы делаете или намекаете на плохие выводы

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

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

И опять это Ваши домыслы, фирма Sun не обанкротилась, ни в коем случае. Вы не поймали нить моего сообщения, которая на самом дел такова, если в двух словах и без красивостей:

Sun открывает исходники -> происходит объединение с Oracle -> Oracle закрывает исходники -> Oracle зарабатывает деньги
Все, там ничего больше не было, кроме моего собственного вывода в самом конце

Никто не банкротился

Я ничего не предлагаю. Я просто говорю, что open-source - это не всегда однозначно хорошо. И скорблю по "безвременно почившей"...

Как я уже говорил -- вы делаете неверные выводы. Я бы даже назвал их глупыми.

Если вы считаете opensource безусловно полезным в любой ситуации, а closesource безусловно вредным в любой ситуации, то мне кажется, что Вы не правы, на чем и расстанемся каждый при своем мнении

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

У Oracle, все осталось на своих местах, насколько мне известно. Из закрытых направлений после объединения я знаю только экспериментальный язык Fortress, и StarOffice отдали Apache

Кто ей мешал сделать ОС типа Андроида ?

Зачем?!? Sun - это в основном Enterprise уровень. Был, конечно, период, когда Sun ставил Солярку на ноутбуки, проводил инсталлфесты, ездил по городам России с лекциями перед студентами, но позже это было приостановлено. Ну и некоторое количество десктопных решений тоже есть, да. Но Sun не про это

Кто ей мешал зарабатывать на своей ОС точно так же, как Red Hat ? Никто не мешал. Возможно её ОС стала другим не интересна ?

Oracle зарабатывает на Солярке и никто не мешает ему это делать

Где её процессоры UltraSPARC ? Может все просто на Интелы перешли ?

Oracle объединялся с Sun ради Java и серверов на Sparc и Intel (в том числе). После объединения у Оракла девизом стало "Sun|Oracle Software|Hardware Complete"
Все это живее всех живых.

Где её графические сервера ? Может у конкурентов просто сервера лучше оказались ?

Простите, "графические"?!? Ах, ну да, тенденции 15-летней давности... Sun как компания основана в 1982 году, за это время вектор развития уже раз 10 поменялся, в этом году только у Java 20 летие справили

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

Увы и ах, не ушла, она растворилась в Oracle в 2010 году. Как говорят шутники в "этих ваших инторнетах" - "просто восстановили справедливость: серверное подразделение Оракл теперь просто тоже стало называться Оракл": софт Оракл всегда работал лучше всего на серверах Sun под управлением Solaris.

Тоже самое касается и Оракла, которая подала на Гугл в суд и типа якобы этот Гугл является причиной снижения популярности к Яве, как к самостоятельной платформе.

Это пусть суд разбирается, это не интересно, это пища для адвокатов

Не задумывались ли вы, что SUN могла открыть исходники для того, чтобы её продукты быстрее распространились под другие платформы ? Ведь явно сама она не сможет поддерживать их все.
Она не может поддерживать все модели телефонов, планшетов и т.д.

Была причина - открыли, пришел Оракл - закрыл. Да и то, кстати, не все: VirtualBox и MySQL все еще opensource, а вот Solaris - да, закрыта. Кстати и чип UltraSparc T2 (Niagara 2), открытый в 2007, все еще доступен под GPL (фиг закроешь), но новые разработки уже не выкладываются в opoensource

И повторю ещё раз -- все её неудачи, не из-за смены лицензии.

Я этого не утверждал, я же специально написал в конце своего того сообщения "Не всегда opensource однозначно полезен". Если Вы не согласны, ну тады "Ой"

Aha wrote:

Для начала, в цитируемом сообщении я не делаю никаких выводов, выводы делаете за меня Вы и уже не в первый раз

Потому что иначе для чего было приводить это сообщение ?
Если нет выводов, что переход SUN к open source является причиной её неудач, то зачем было вообще упоминать об этом ?

Вы сами прочитайте своё сообщение:

Жила-была фирма Sun Microsystems (предыдущий владелец Java) и решила она однажды поиграть в OpenSource: открыла исходный код - и Java под GPL, и OS Solaris под более commercial-frendly CDDL.
Внимание вопрос! И где теперь та компания Sun Microsystems!?! Нет её, RIP...

"...и решила она однажды поиграть в OpenSource: открыла исходный код..." "И где теперь та компания Sun Microsystems!?! Нет её, RIP..."
Какой ещё из него можно сделать вывод, кроме того, что сделал я ?
Если вы ни на что не намекаете, то просто не пишите бесполезные фразы, от которых получается нет никакого толка.

Внимание вопрос! И где теперь та компания Sun Microsystems!?! Нет её, RIP...

Оракл её купил, причём тут открытые исходники ?

Если вы считаете opensource безусловно полезным в любой ситуации, а closesource безусловно вредным в любой ситуации, то мне кажется, что Вы не правы, на чем и расстанемся каждый при своем мнении

Я разве такое писал где-нибудь ?
Это вы считаете, что я так считаю, но не я.
У нас тут речь идёт в основном о LLVM и как я уже говорил много раз, лицензия на LLVM позволяет скрывать её исходники(я так понял), т.е. можно вполне взять за основу LLVM и сделать из неё что-то своё закрытое.
Если бы я был только за open source, то я бы предлагал GCC, т.к. из неё нельзя сделать закрытый продукт.

И опять это Ваши домыслы, фирма Sun не обанкротилась, ни в коем случае.

Я нигде не писал, что фирма SUN обанкротилась, а написал, что потерпела неудачу, если бы было не так, то Оракл её бы не купила, т.к. SUN стоила бы дорого. Именно её неудача привела к снижению стоимости её активов.
А пример с банкротством -- это про другие фирмы, которые не открывали исходники.

Вы не поймали нить моего сообщения, которая на самом дел такова, если в двух словах и без красивостей:
Sun открывает исходники -> происходит объединение с Oracle -> Oracle закрывает исходники -> Oracle зарабатывает деньги

А вы хотя бы сами его поймали и поняли для чего вы его написали ?

Sun открывает исходники -> происходит объединение с Oracle -> Oracle закрывает исходники -> Oracle зарабатывает деньги

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

Увы и ах, не ушла, она растворилась в Oracle в 2010 году.

Т.е. просто так без причин взяла и растворилась ?
Именно не выдержала конкуренцию, её продукты стали меньше покупать, активы стали обесцениваться и данная фирма подешевела, после чего её решила купить Оракл. -- Обычно не покупают успешную развитую фирму, потому что это слишком дорого и покупают или перспективных фирм новичков или развитых фирм терпящих неудачу, но с достаточно перспективными технологиями.

Была причина - открыли, пришел Оракл - закрыл.

Вот и я об том же -- ваш пример с SUN лишён всякого смысла.

Yaisis wrote:

Вот и я об том же -- ваш пример с SUN лишён всякого смысла.

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

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

krufter_multiclet wrote:

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

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

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

Спасибо за терпение

Aha wrote:

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

Я вас глупым не считаю.
Возможно я вас неправильно понял.

Думаю, продолжение дискуссии останется таким же контрпродуктивным.

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

Yaisis wrote:

Ну ладно, не будем больше захламлять ветку патентами, а с Явой вроде уже всё итак понятно.

В Android N (7.0) Google решила сменить Java на OpenJDK.
Некоторое время назад также циркулировали слухи, что Google думает о замене Java в Android на другой язык программирования, в качестве преемника назывались Go и Dart.

Кстати, если говорить о преимуществе в скорости, то вот, к примеру, тест нативного и Java приложений в Андроид: http://freepascal.ru/article/freepascal/20140310080000/
По мне, так плата за кроссплатформенность - высоковата и чуть быстрее выполнять Яву не даст ровным счётом ничего, ну разьве что на волне ожиатажа все будут кричать супер, а по большому счёту никаких реальных преимуществ там не выбить - она сама по себе тормозная.

VaalKIA wrote:

Yaisis wrote:

Ну ладно, не будем больше захламлять ветку патентами, а с Явой вроде уже всё итак понятно.

В Android N (7.0) Google решила сменить Java на OpenJDK.
Некоторое время назад также циркулировали слухи, что Google думает о замене Java в Android на другой язык программирования, в качестве преемника назывались Go и Dart.

Кстати, если говорить о преимуществе в скорости, то вот, к примеру, тест нативного и Java приложений в Андроид: http://freepascal.ru/article/freepascal/20140310080000/
По мне, так плата за кроссплатформенность - высоковата и чуть быстрее выполнять Яву не даст ровным счётом ничего, ну разьве что на волне ожиатажа все будут кричать супер, а по большому счёту никаких реальных преимуществ там не выбить - она сама по себе тормозная.

Ну лично я был не за Java, а за LLVM.
И что бы Google там не внедрила, она это будет делать на базе LLVM, т.к. ей нет смысла тратить лишние свои ресурсы на выдумывание чего-то нового, а в развитии LLVM она вроде принимает участие.
Go вроде тоже на базе LLVM сделан.
Точно так же читал где-то, что существующая сейчас AOT-компиляция в Андроиде создана на базе LLVM.

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

Кстати по поводу теста -- там используется Андроид 4, в котором ещё нет AOT-компиляции. С AOT-компиляцией Ява должна работать быстрей, но уверен, что будет всё-равно медленней, чем FreePascal.

По мне, так плата за кроссплатформенность

Я думаю, что это касается Явы в данном случае, ведь можно осуществлять кроссплатформенность и другими способами, без соответствующей траты, например компилируя под устройство или из исходников, или из биткода LLVM (что лучше).
Вот c помощью AOT-компиляции Google и хочет реализовать компилирование программ под каждое устройство.