LINUX.ORG.RU

Oracle отменяет лицензию по распространению Java с дистрибутивами

 ,


0

1

Короткой новостной строкой компания Oracle заявила о прекращении действия «Лицензии распространителя Java в операционных системах» (DLJ), которая была создана Sun в 2006 году. Эта лицензия не является свободной, но позволяет разработчикам различных дистрибутивов создавать собственные установочные пакеты JRE и JDK, а также распространять их через репозитории. Лицензия появилась после того, как в 2006 году были открыты исходные тексты Java с целью предоставить пользователям простой доступ к проверенным технологиям, используя OpenJDK.

Дэлибод Топик (Dalibod Topic) из Oracle в своем блоге ответил на вопросы Сильвестра Ледру (Sylvestre Ledru), одного из разработчиков дистрибутива Debian, в частности занимающегося поддержкой пакета sun-java6-jre. Позиция Oracle, согласно словам первого, состоит в том, что теперь пользователям вряд ли требуется новая реализация Java, ведь уже давно существует OpenJDK6, проверенный, надежный и, вследствие чего являющийся стандартным пакетом Java-машины и инструментов разработчика в большинстве дистрибутивов Linux. К тому же недавно стала доступна и OpenJDK 7. Основная критика такого шага со стороны разработчика Debian заключалась в том, что многие проекты жёстко привязаны к бинарной сборке Java от Oracle, и поэтому поголовный переход на OpenJDK приведёт к программным ошибкам, на что представитель Oracle заявил, что о всех подобных проблемах следует сообщать разработчикам OpenJDK.

Кроме того Дэлибод подчеркнул, что все пользователи могут по своему желанию загрузить бинарные сборки Oracle Java с официального сайта и использовать их в соответствии с лицензией Oracle Binary.

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

★★★★★

Проверено: JB ()
Последнее исправление: JB (всего исправлений: 2)

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

> Значит реальное приложение на сферическом jboss в вакууме нельзя разворачивать методом «скопировать war в директорию», потому что как минимум jboss надо предварительно настроить:

Реальное приложение на сферическом дебиане в вакууме тоже нельзя развернуть методом «dpkg -i», потому что сначала надо набрать песочка, сварить из него монокристалл кремния, вытравить на нём процессор, обрезать, корпусировать, вставить в материнскую плату, плату вставить в корпус, снабдить блоком питания и память, которые тоже делаются из песочка, привезти всё это в дата-центр, подключить, развернуть дебиан, настроить на нём ssh доступ, подключить репозитарии, закинуть туда каким-то способом этот deb-файл, и потом уже можно будет делать dpkg -i.

Приведёшь реальную инструкцию?

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

> еще раз - я нигде и никогда не говорил, что RoR готова для замены J2EE, я лишь говорю, что Вы намеренно или ненамеренно недоговариваете, сравнивая деплой в J2EE с чем-то другим.

Я говорю о том, что в J2EE есть деплой и этот деплой работает без перезагрузки, в отличие от RoR, собственные механизмы деплоя у которой таких возможностей не предоставляют. Остальное частности.

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

Не передергивайте, я же не предлагаю вам инструкцию начинать с установки RHEL и jboss на него.

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

> Я говорю о том, что в J2EE есть деплой и этот деплой работает без перезагрузки, в отличие от RoR, собственные механизмы деплоя у которой таких возможностей не предоставляют. Остальное частности.

На Rails есть Redmine, и он работает, в отличие от J2EE. Остальное частности.

Фактически ни у кого при использовании связки Debian + Redmine никаких проблем не происходит, оно просто работает, просто устанавливается, просто удаляется и просто обновляется... Кроме тебя, по причине того, что нормальным способом ты пользоваться не хочешь.

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

>Я говорю о том, что в J2EE есть деплой и этот деплой работает без перезагрузки, в отличие от RoR, собственные механизмы деплоя у которой таких возможностей не предоставляют. Остальное частности.

Если у вас основная идея была в отсутствии перезагрузки, то зачем было распинаться про то что надо брать что-то из scm, про то что руками надо лезть в базу и вообще про то что инструкция длинная, если в J2EE все то же самое, только вы про это решили забыть?

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

> На Rails есть Redmine, и он работает, в отличие от J2EE.

J2EE не работает? Проверь статус соединения себя с реальностью, там линк упал.

Фактически ни у кого при использовании связки Debian + Redmine никаких проблем не происходит

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

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

> Т.е. до момента «скопировать war в директорию» надо руками залезть в базу и создать там таблицы?

Ты тоже никогда не пользовался hot-deploy? И не в курсе, что war может содержать database beans?

Куда я попал…

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

В J2EE не то же самое. В J2EE можно сделать нормально, в RoR пока что нет.

Aceler ***** (04.09.2011 13:23:58)

Второй вопрос — в какой инструкции у тупого админа, сидящего на Сахалине, больше вероятность совершить тупую ошибку? Сколько будет стоить восьмичасовой простой Сахалинского офиса вашей компании из-за того, что где-то он опечатался и после рестарта RoR не поднялся?

Как в J2EE решается вопрос опечаток администратора (мы же не рассматриваем сферический хелловорд в вакууме, а нормальное приложение)? Как в J2EE решается вопрос кривых скриптов для обновления базы? Что в J2EE положено делать, если после обновления базы и редеплоя новой версии war приложение не работает?

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

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

> Как в J2EE решается вопрос … (поскипано)

Отличный вопрос! Решается этот вопрос просто — сначала мы тестируем на центральной машине, затем рассылаем полученный оттестированный файл в регионы. В отличие от репозитариев, это даёт предсказуемый результат, а предсказуемость тут самое важное.

Лично я не один раз наблюдал, что в энтерпрайзе из-за кучи посредников war до администраторов доходил не той версии, что высылали разработчики.

Главное, чтобы до всех администраторов доходило одно и то же, потому что исправить одинаковый глюк на 10000 серверов куда проще, чем исправить 10000 глюков на 10000 серверов :)

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

database beans

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

Ты тоже никогда не пользовался hot-deploy?

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

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

А, т.е. для вас энтерпрайз - это куча разрозненных филиалов, в каждом из которых сидит эникейщик и деплоит на местный jboss J2EE приложение?

Никогда не пытались написать написать скрипт, который вместо 10000 эникейщиков будет выполнять эту работу?

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

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

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

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

Именно, что умеет, а RoR пока нет. Я может, не теми словами говорю какими-то? Почему люди яростно убеждают меня в том, что я прав?

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

Не вижу там ничего про скрипт, автоматически деплоящий что-либо на 10000 ваших серверов. Вижу только про тупого админа, сидящего в Сахалинском офисе, а значит автоматизации нет.

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

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

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

> Еще раз - я не знаю ничего про RoR, я говорю лишь что вы намеренно или ненамеренно недоговариваете о проблемах, которые существуют в J2EE

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

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

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

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

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

Это я все к чему:
J2EE это круто и энтерпрайзно, потому что для него есть готовая автоматизация деплоя, но у вас она не используется, а сидят админы в филиалах и руками копируют приложения.
Если вместо J2EE в вашу инфрастуктуру добавить anything - админам придется высылать инструкции по установке и обновлению anything.
Только вот кто мешает админам высылать sh-скрипт со встроенным в него архивом проверенной версии anything (sh ведь работает в RHEL, в отличие от deb)?

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

> Я говорю о том, что в J2EE есть деплой и этот деплой работает без

перезагрузки, в отличие от RoR, собственные механизмы деплоя у которой

таких возможностей не предоставляют. Остальное частности.



RoR под JRuby деплоится точно также как и любоe JavaEE приложение. На Jboss тоже.

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