Pull to refresh

Comments 50

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


Можно сделать список с рандмоным порядком, заново генерирующийся при каждом заходе на сайт.
UFO just landed and posted this here
I'm Feeling Lucky, как в Гугле. Да, хорошая кнопка, надо будет запилить.
Простите за оффтопик, но
Wordpress
базу
образы контейнеров
это всё действительно так полезно для статического сайта с 1й страницей?

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

В дальнейшем это будет сильно больше, чем одна страничка. Если этого не произойдет — то можно и Github Pages. Думаете, я не люблю звездочки? Но пока не стоит завязывать на то, на что можно не завязываться. Как там говорится — «нет никаких облаков, есть твои данные на чужих серверах».

Гитхаб можно использовать как коллективный редактор, чтобы потом синхронизировать с Вордпрессом. В таком варианте Гитхаб в любой момент можно оторвать и заменить на что угодно другое. Но синхронизатор — это непросто и небыстро (надо изучить Wordpress API, либы для работы с Гитхабом, написать синхронизацию). Поэтому со вторым приоритетом. Сейчас бы главное сделать.
У вас как-то странно ссылка на RedHat JDK разрезана на две части.

<li><a href="https://developers.redhat.com/products/openjdk/overview/">Red Hat build of </a><a href="https://developers.redhat.com/products/openjdk/overview/?utm_source=jdkdev&utm_medium=download">O</a><a href="https://developers.redhat.com/products/openjdk/overview/">penJDK</a> </li>
Набирал дрожащими руками :) Исправлено.
Если повесить счетчик переходов в разделе «Major Binary Distributions», было бы красиво имхо

apt install openjdk-13-jre
apt install openjdk-13-jdk


А виндузятники да, ищут и находят.

на Mac тоже не шибко сложнее:
"brew cask install java" — сейчас для 12
"brew cask install java-beta" — сейчас для 13

Там еще и инсталлера лишили, грусть

Как в случае с пакетами ты собираешься выбирать вендора? Ты вообще знаешь, какая именно контора собрала твой пакет?


Для линуксоидов есть SDKMAN!, а для виндузятников я скоро свой велосипед выложу.

Я знаю. apt show openjdk-13-jre


Ubuntu:
Maintainer: OpenJDK Team openjdk@lists.launchpad.net


Debian:
Maintainer: OpenJDK Team openjdk@lists.launchpad.net
Uploaders: Matthias Klose doko@ubuntu.com


Список патчей:
https://sources.debian.org/patches/openjdk-11/11.0.3+1-1/ (для 11ой версии, т.к. 13 нет в buster).


Это reproducable build, так что если взять ту же среду сборки и те же сырцы (всё доступно) получится тот же самый бинарный файл.


100% provenance.

Сборки основных провайдеров отличаются в основном опциями поддержки, в том числе — платной. Если я правильно помню, то у Оракла поддержка стоит по 25$ в месяц за процессор. В чём там разница между этими подписками — это уже не моё дело тебе их продавать. Но смысл в том, что на какой-то случайный пакет никто из основных вендоров тебе саппорта не предоставит, так тебе всё равно придётся идти и подключать всякие кастомные репозитории. Узнать о которых ты сможешь как раз с перечисленных на сайте сайтов компаний.

Я очень извиняюсь, но у той же ubuntu есть вполне себе платная поддержка, если хочется. У RHEL тоже есть.


Зачем какие-то сторонние компании со своими сборками?

Вы убиваете на корню всю драму :) Люди тут понимаешь героически преодолевают, а вы взяли и apt-get install.

Ты тролишь, я на такое отвечать не стану.
Затем, что дефолтные пакеты в Ubuntu, Debian, RHEL и CentOS далеко не самые удачные. Во-первых, они слишком жирные:
$ sudo apt install openjdk-11-jdk
...
Need to get 270 MB of archives.
After this operation, 666 MB of additional disk space will be used.

Для сравнения, Liberica JDK 11 lite в установленном виде занимает менее 100 MB.

Во-вторых, при всей своей объёмности в этих пакетах не хватает нужных символов для продвинутых Java профайлеров вроде async-profiler или perf-map-agent (на мой взгляд, обязательных для современного Java разработчика). Символы эти авторы решили вынести в отдельный пакет с кучей другого отладочного барахла, которое занимает ещё 200+ MB. Кстати, можете с ходу вспомнить, как этот пакет называется?

Я уж не говорю о том, что убунтовские сборки не сертифицированы и формально не могут называться Java compatible.

Не забывайте про депенденсы. apt приносит не только jre/jdk, но и все системные (Си) библиотеки, которые нужны.


Насчёт "не сертифицированы" — RH предоставляет аж три варианта: GPL, Oracle и IBM. Всё из коробки.

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

Самодостаточны? noway. Кто им syscall'ы обслуживает? А libc?

Да там в эти 100 мегабайт и иксы и альсу запихали, и инит, и глибц, и ядро, и cups (печатать же из джавы надо как-то), ну и конечно браузер чтобы было чем апплеты смотреть!

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

Я говорил, что на свежеустановленной Ubuntu 18.04 apt install предложил поставить пакетов на 666 MB (либо 637 MB с --no-install-recommends), в то время как другая сборка, занимающая 96 MB, без проблем запускала все те же Java приложения.

Кроме того, в дефолтном пакете openjdk-11-jdk из бинарников удалены debug символы, из-за чего нормально не работает профайлер в IntelliJ IDEA. Чтобы это исправить, требуется дополнительно установить пакет openjdk-11-dbg ещё примерно на 200 MB.

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

Если у нас уже есть операционная система, то нам не надо "сборки", потому что в ОС уже есть jdk. Используйте apt для установки.


Если же ОС нет, то да, кто-то должен сделать libc, xserver, ядро и другие няшности.

Вначале я рекомендую помедетировать вот над этим: Oracle Java (JDK) 8 Installer PPA (DISCONTINUED).


"Oracle Java downloads now require logging in to an Oracle account to download Java updates"


Я вижу это так: "сборки" разные по коду — везде есть кастомные патчи. Они когда-нибудь попадут в апстрим, но не сразу, как минимум только в конце "отчетного периода". У всех такие патчи разные. Получилось так в том числе благодаря процессу "поддержки" — у какого-то кастомера что-то сломалось, и разрабы поправили, но пока только в своей "сборке". Если патч покажет себя состоятельным — его потом вольют в апстрим, конечно, но не сразу.


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


Вот таблица created/resolved за последние пять лет. Статистика примерная, потому что точный отчет очень тормозит. Здесь видно что, например, за 2015 год разница — 20345-18627=1718 тикетов. Бюджет дальнейших лет всё так же дефицитный, так что эти 1718 никуда не делись. В 2019 году пока поменьше дефицита наплодили — всего 5238-5212=26. Но это общий трекер, а ведь есть ещё у всех и свои внутренние.



Конечно, если ты не разработчик и не организация, и тебе норм перезапускать джава торрент-клиент Azureus каждый раз когда он падает раз в два дня — ничего этого не нужно и неинтересно, ставь первое что в голову придёт.


А вот всем остальным очень важно, кто именно делает сборку, как ее поддержка и выкладка работает, и если это платная поддержка — сколько это стоит. Способ оформления релиза очень важнен для IoT и прочих девайсов, которым нужно организовать автоматическое обновление. Очевидно, что самое большое количество топовых специалистов работает в компаниях, выкладывающих основные сборки. Например, это Oracle, потом RedHat и BellSoft (это компания, у которогой 100% производства — бывшие сотрудники Oracle).


Так что, даже если у тебя Ubuntu (на серверах, в IoT и эмбеддеде — о десктопах речи не идёт), выбирать сборку нужно в первую очередь по вендору, с которым ты собираешься связываться. И если ты например, решил что ничто меньшее чем Oracle JDK с OTN лицензией тебе не подходит, то придётся — да, ручками качать её с сайта Oracle. И ручками же обновлять.

Мой опыт общения с вендорами говорит, что даже если саппорт с 1h guarantee, то это время эскалации бага. А фикс будет как только будет.

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

Опыт общения с точки зрения высокоприоритетного заказчика (банк, биржа, важная соцсеть, итп) с каким-то из мажорных вендоров JDK из списка выше по вопросам критических багов в JDK? С каким?


А проблема обычно выясняется на этапе разработки. Но это не значит, что она ничего при этом не стоит. Представьте, что у вас виртуалка падает в корку при запуске — это критично. Как минимум, каждый день, когда фича не выведена в прод — стоит прибылей, которые получили бы за эти дни.

Это вы в эпоху электрона 500Мб сэкономили? Не уверен, что для вас найдётся подходящая ачивка.

Это всё нужно не для десктопа, а для серверов и контейнеров, для IoT всякого. Скорость копирования и разворачивания нового образа очень-очень важна
Не пробовали языки с компиляцией в нативный код? Go, Rust там? Сначала тащить феерического размера JRE, а потом хвалиться как его всего в 100Мб ужали — это какая-то неконсистентность в аргументации.

У меня есть подозрение, что вы не Java-разработчик, потому что ответы на подобные вопросы знают все.

убунтовские сборки не сертифицированы и формально не могут называться Java compatible

И чо? Вам шашечки или ехать? А glibc или ядро которые будут использоваться при работе хоть четырежды сертифицированой сборки у вас кем сертифицированы? А компилятор которым это всё добро собрали кто-то сертифицировал? Толку от сертифицированности jvm если вы её установили не в то окружение в котором её сертифицировали и из-за которого она может вести себя иначе?

Интересно — что значит «сертифицирован»? На какой версии ядра, на каком дистрибутиве и процессоре? Где гарантия того, что .tar.gz будет работать на моей Ubuntu 18.04 и на моем процессоре? Сборка под конкретный дистрибутив собирается из тех же исходников, плюс удобство apt install.
Зачем нужны какие-то велосипеды, если есть brew/apt?

Не работает в Ubuntu 18.04 LTS. Там 11 только через полгода после выхода появилась.

UFO just landed and posted this here

Запрет на оригинальные исследования. А тут весь сайт будет — оригинальное исследование.

Ну что за мода делать первый экран абсолютно бесполезным и прятать всё нужное за скроллингом?

Хорошо бы табличку, какой вариант выбрать.
Где поддержка лучше? Где есть Deb/Rpm? Где какие опции включены/выключены? Я пока поставил openjdk 11 при помощи apt install (а 12 ещё нет в Ubuntu LTS). Но вот прочитал комменты сверху и не знаю, то ли так и оставить, то ли ставить один из этого списка — но придется долбаться с tar.gz и путями.

Если вам не гонять сервера на проде и не разрабатывать на джаве, а джавовый десктопный софт изредка запускать — можно и на убунтовых жить :)


"Долбаться" не надо :-) Если это тупо машина для разработки, то это в ~/.bashrc две строчки — про JAVA_HOME и про PATH.


Огромное преимущество такого решения — оно простое. Сильно проще, чем пакеты с alternatives. Если сломается — есть всего 1 место, где смотреть и чинить — эти несчастные две строчки.


Плюс такое решение хорошо масштабируется, когда у вас несколько [десятков] сборок JDK одновременно, в особенности — если вы их сами из исходников и собираете. В баше можно написать функции для переключения между сборками, флагами и патчами, и сделать там все как вам удобно


Впрочем, у линуксоидов есть sdkman

Я про сервер. На десктопе есть brew.


У нас два варианта — либо контейнер, либо ansible.
apt install / yum install сильно упрощают дело.


В чем конкретно проблема apt, не могу понять. Только в абстрактной "сертификации"?

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

А где можно об этом подробнее почитать, что-то прям заинтриговало как-то как можно ЭТИМ навлечь на себя гнев общественности)
Sign up to leave a comment.

Articles