Comments 50
это невозможно хотя бы потому, что кто-то должен оказаться вверху списка загрузок, а кто-то — внизу
Можно сделать список с рандмоным порядком, заново генерирующийся при каждом заходе на сайт.
Wordpressэто всё действительно так полезно для статического сайта с 1й страницей?
базу
образы контейнеров
Github pages выглядит намного логичнее, тем более там вся возможность по коллективному редактированию и pull requests из коробки.
Гитхаб можно использовать как коллективный редактор, чтобы потом синхронизировать с Вордпрессом. В таком варианте Гитхаб в любой момент можно оторвать и заменить на что угодно другое. Но синхронизатор — это непросто и небыстро (надо изучить Wordpress API, либы для работы с Гитхабом, написать синхронизацию). Поэтому со вторым приоритетом. Сейчас бы главное сделать.
<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>
apt install openjdk-13-jre
apt install openjdk-13-jdk
А виндузятники да, ищут и находят.
на Mac тоже не шибко сложнее:
"brew cask install java
" — сейчас для 12
"brew cask install java-beta
" — сейчас для 13
Я знаю. 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.
Я очень извиняюсь, но у той же ubuntu есть вполне себе платная поддержка, если хочется. У RHEL тоже есть.
Зачем какие-то сторонние компании со своими сборками?
Вы убиваете на корню всю драму :) Люди тут понимаешь героически преодолевают, а вы взяли и apt-get install.
$ 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 (печатать же из джавы надо как-то), ну и конечно браузер чтобы было чем апплеты смотреть!
Я говорил, что на свежеустановленной 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. И ручками же обновлять.
Т.е. с точки зрения банка, если в java критическая ошибка из-за которой можно проводить любые операции без лимитов, к моменту, когда этот баг дойдёт до девелопера, банка уже не будет.
Опыт общения с точки зрения высокоприоритетного заказчика (банк, биржа, важная соцсеть, итп) с каким-то из мажорных вендоров JDK из списка выше по вопросам критических багов в JDK? С каким?
А проблема обычно выясняется на этапе разработки. Но это не значит, что она ничего при этом не стоит. Представьте, что у вас виртуалка падает в корку при запуске — это критично. Как минимум, каждый день, когда фича не выведена в прод — стоит прибылей, которые получили бы за эти дни.
Это вы в эпоху электрона 500Мб сэкономили? Не уверен, что для вас найдётся подходящая ачивка.
убунтовские сборки не сертифицированы и формально не могут называться Java compatible
И чо? Вам шашечки или ехать? А glibc или ядро которые будут использоваться при работе хоть четырежды сертифицированой сборки у вас кем сертифицированы? А компилятор которым это всё добро собрали кто-то сертифицировал? Толку от сертифицированности jvm если вы её установили не в то окружение в котором её сертифицировали и из-за которого она может вести себя иначе?
Для Windows есть ojdkbuild — https://github.com/ojdkbuild/ojdkbuild
Не работает в Ubuntu 18.04 LTS. Там 11 только через полгода после выхода появилась.
Например, уже сейчас Namecheap вынудил меня перейти на их платный DNS, потому что бесплатный работал не очень хорошо.www.cloudflare.com/dns/#free-modal
и домен к ним перенесите…
Хорошо бы табличку, какой вариант выбрать.
Где поддержка лучше? Где есть Deb/Rpm? Где какие опции включены/выключены? Я пока поставил openjdk 11 при помощи apt install (а 12 ещё нет в Ubuntu LTS). Но вот прочитал комменты сверху и не знаю, то ли так и оставить, то ли ставить один из этого списка — но придется долбаться с tar.gz и путями.
Если вам не гонять сервера на проде и не разрабатывать на джаве, а джавовый десктопный софт изредка запускать — можно и на убунтовых жить :)
"Долбаться" не надо :-) Если это тупо машина для разработки, то это в ~/.bashrc две строчки — про JAVA_HOME и про PATH.
Огромное преимущество такого решения — оно простое. Сильно проще, чем пакеты с alternatives. Если сломается — есть всего 1 место, где смотреть и чинить — эти несчастные две строчки.
Плюс такое решение хорошо масштабируется, когда у вас несколько [десятков] сборок JDK одновременно, в особенности — если вы их сами из исходников и собираете. В баше можно написать функции для переключения между сборками, флагами и патчами, и сделать там все как вам удобно
Впрочем, у линуксоидов есть sdkman
Например, я слышал критику в сторону Саймона Риттера уже за то, что он имел несчастье попытаться публично объяснить фичи новой джавы.
А где можно об этом подробнее почитать, что-то прям заинтриговало как-то как можно ЭТИМ навлечь на себя гнев общественности)
Как скачать JDK 12? Объяснение длиной в 7 символов