Отчёты это хорошо, правда контейнерный образ немного страный. Сделан поверх убунту, занимает 777 Мб на диске. При этом забандлен адоптовский старый JDK прямо в /opt/Archi/jre.
Игра теперь такая: можете бесплатно мигрировать каждые 6 месяцев на открытые сборки или каждые 2 года на закрытые. А если не получилось, то вот счёт по количеству vcpu.
Кошмар. Это примерно как исключить из пайплайна staging, и после девелоперского тестирования отдавать сразу код в прод. За то платные сборки джавы и платные, чтобы они собирались при необходимости в контролируемом окружении разработчиками, которые занимаются этим как основной работой. И тестировались. И это думаю в среднем дешевле, чем занимать этим девопса.
Кстати о бэкпортах в разрезе open source. У Оракла свои планы по бэкпортам (не только security), и не все бэкпорты сразу попадают в open. Таким образом в разрезе LTS-версий легко может возникать vendor lock.
Исходники можете использовать, а если бинарный дистрибутив используете, внимательно изучайте лицензию под которой он распространяется. Ну и конечно не устаю повторять: дистрибутива с названием "OpenJDK" не существует.
Есть отличный доклад Александра Белокрылова на тему того, почему и как делаются дистрибутивы OpenJDK. Вкратце на простом примере: вы взяли не ту версию компилятора C++, и один из многочисленных woraround-ов в коде HotSpot-а для багов компилятора не сработал. В результате несколько тестов из огромного набора TCK или jtreg будут падать. Но если эб этом никто не знает, то есть счастливая вероятность огрести именно эти грабли в своём уютном проде.
Ежемесячно апдейтится RHEL (который по-хорошему платный). И насколько я понимаю, в эти апдейты идут апдейты пакетов, которые за это время случились. Релизный цикл обновений редхатовской openjdk такой же, как у других вендоров (квартальные обновления).
И есть предусмотрительные, которые переключаются на поддержку ДО того, как случается первый инцидент. Как говорится, есть 2 вида людей: те, кто делает бэкапы, и те, кто пока ещё нет.
Тут есть интересный момент. У кода OpenJDK есть не только лицензии, но и Copyright-ы. Примеры возможного двойного лицензирования - это Oracle JDK времён, когда было много closed-кода (например JFR в Oracle JDK 8), или GraalVM EE.
Script friendly URLs - это явно ответ на Discovery API от других вендоров. Примерно как Эпплл или Гугл, которые подсматривают фичи у разработчиков приложений и оболочек.
Возвращение ARM64 сборок некоторое время назад - тоже такой пример. Там правда корни ещё и другие есть, т.к. в Oracle Cloud есть Ampere Altra, в который они к тому же вложились.
У оракловой джавы кстати по-прежнему набор платформ остаётся весьма ограниченным. Тот же компактный Apline Linux, который мы так для Либерики любим, так и не добавили. Отсюда и ресурсы чаще выпускать LTS-релизы.
Бесплатность это одно, но лицензия вполне конкретная (NFTC):
You comply with all U.S. and applicable export control and economic sanctions laws and regulations that govern Your use of the Programs (including technical data);
Очень странно. Особенно с учётом того, что конфиг по абсолютному пути читается. Больше похоже на то, что у корневых процессов шелла и джавы разные права в итоге получаются. По идее где-то тогда должно быть видно AccessDeniedException или что-то в таком духе.
Такого дистрибутива не существует :-) Но скорее всего это стоит читать как пакет из репозитория ОС.
А интерес в целом к тем самым "высоким требованиям к защите корпоративных данных", и к тому, какие альтернативы Либерике используются, и почему.
Отчёты это хорошо, правда контейнерный образ немного страный. Сделан поверх убунту, занимает 777 Мб на диске. При этом забандлен адоптовский старый JDK прямо в /opt/Archi/jre.
Чем-то сильно напоминает сотовую связь, так скоро M2M соцсеть вещей увидим.
Jitsi небось активно JNI использует, как это сказывается на задержках?
ZGC ещё не молодец?
Выбирали ли системный аллокатор?
Игра теперь такая: можете бесплатно мигрировать каждые 6 месяцев на открытые сборки или каждые 2 года на закрытые. А если не получилось, то вот счёт по количеству vcpu.
Кошмар. Это примерно как исключить из пайплайна staging, и после девелоперского тестирования отдавать сразу код в прод. За то платные сборки джавы и платные, чтобы они собирались при необходимости в контролируемом окружении разработчиками, которые занимаются этим как основной работой. И тестировались. И это думаю в среднем дешевле, чем занимать этим девопса.
Как-то сумбурно. Всё-таки Oracle JDK (любой версии) идёт не под лицензией GPL. А свежие апдейты Oracle JDK 8 идут под коммерческой лицензией.
Кстати о бэкпортах в разрезе open source. У Оракла свои планы по бэкпортам (не только security), и не все бэкпорты сразу попадают в open. Таким образом в разрезе LTS-версий легко может возникать vendor lock.
В правильном саппорт-контракте прописаны SLA до ответа инженера и сроки выпуска билдов с патчем.
Всё так и есть. И лицензии, и полный цикл тестирования для каждой платформы.
Исходники можете использовать, а если бинарный дистрибутив используете, внимательно изучайте лицензию под которой он распространяется. Ну и конечно не устаю повторять: дистрибутива с названием "OpenJDK" не существует.
Есть отличный доклад Александра Белокрылова на тему того, почему и как делаются дистрибутивы OpenJDK. Вкратце на простом примере: вы взяли не ту версию компилятора C++, и один из многочисленных woraround-ов в коде HotSpot-а для багов компилятора не сработал. В результате несколько тестов из огромного набора TCK или jtreg будут падать. Но если эб этом никто не знает, то есть счастливая вероятность огрести именно эти грабли в своём уютном проде.
Ежемесячно апдейтится RHEL (который по-хорошему платный). И насколько я понимаю, в эти апдейты идут апдейты пакетов, которые за это время случились. Релизный цикл обновений редхатовской openjdk такой же, как у других вендоров (квартальные обновления).
И есть предусмотрительные, которые переключаются на поддержку ДО того, как случается первый инцидент. Как говорится, есть 2 вида людей: те, кто делает бэкапы, и те, кто пока ещё нет.
Кстати и сейчас никто исходники для Oracle JDK не обещает. Т.е. это closed source (не foss как минимум) на основе open source (OpenJDK).
Тут есть интересный момент. У кода OpenJDK есть не только лицензии, но и Copyright-ы. Примеры возможного двойного лицензирования - это Oracle JDK времён, когда было много closed-кода (например JFR в Oracle JDK 8), или GraalVM EE.
Script friendly URLs - это явно ответ на Discovery API от других вендоров. Примерно как Эпплл или Гугл, которые подсматривают фичи у разработчиков приложений и оболочек.
Возвращение ARM64 сборок некоторое время назад - тоже такой пример. Там правда корни ещё и другие есть, т.к. в Oracle Cloud есть Ampere Altra, в который они к тому же вложились.
У оракловой джавы кстати по-прежнему набор платформ остаётся весьма ограниченным. Тот же компактный Apline Linux, который мы так для Либерики любим, так и не добавили. Отсюда и ресурсы чаще выпускать LTS-релизы.
Бесплатность это одно, но лицензия вполне конкретная (NFTC):
You comply with all U.S. and applicable export control and economic sanctions laws and regulations that govern Your use of the Programs (including technical data);
Очень странно. Особенно с учётом того, что конфиг по абсолютному пути читается. Больше похоже на то, что у корневых процессов шелла и джавы разные права в итоге получаются. По идее где-то тогда должно быть видно AccessDeniedException или что-то в таком духе.
Не расскажете, что это значит в вашем случае?
Такого дистрибутива не существует :-) Но скорее всего это стоит читать как пакет из репозитория ОС.
А интерес в целом к тем самым "высоким требованиям к защите корпоративных данных", и к тому, какие альтернативы Либерике используются, и почему.
А что под капотом у https://cloud.yandex.ru/services/data-proc?
Для Yandex Cloud есть готовые VM-образы с Либерикой https://cloud.yandex.ru/marketplace?type=compute&search=Liberica но там вроде не они