Amber достаточно существенный (это var, records, новый switch expressions, pattern matching в switch и instanceof). Будет очень приятно если оно успеет побольше въехать в 21 (следующая lts с уменьшением времени между lts с 3 до 2 лет). Но по большей части воспринимается как синтаксический сахар пока valhalla для нормальных adt не приехала.
Кому-то loom (virtual threads, tail call optimization) будет очень кстати. Не помню structured concurrency (scoped threads) делалась в рамках него или нет. Но не сдвиг парадигмы, конечно.
Valhalla (value types, user-defined primitives, hidden classes) вполне возможно будет прорывом сопоставимым с добавлением дженериков или лямбд.
Ну и panama -- новое ffi и offheap. К сожалению не очень скоро. Очень важно для баз данных, вычислительного барахла и т.п. Для некоторой узкой части пользователей это вполне сопоставимо с фичами 1.8.
Вот упомянутый jpms/jigsaw принёс пользователям куда меньше фич (и больше проблем с необходимостью добавлять --add-opens, вечно ломающимся lombok и развлечением с кодогенерацией во фреймворках). Кому надо было до этого сидели с osgi, jboss modules и, вероятно, другими подобными вещами.
Дополню спустя почти полтора года. 17 живёт и здравствует, для части вещей типа netty нужно либо чуток переписывать код, либо добавлять add-opens, но ничего сверхестественного. По большей части всё живёт кроме представителей/поделий enterprise спецолимпиады сильно завязанных на 8.
JPMS у нас так и не взлетел. Тулинг подтягивается, фреймворки -- тоже (spring boot 3.х требует 17, quarkus 3.х -- 11, но рекомендует 17). На zgc/shenondoah пока не перебегали, много где живём на g1.
Сколько разных case/rad/low-code/no-code было за последние три десятилетия.. И все упирались в одну простую вещь: написать спецификацию для чего-либо нетривиального и/или мало-мальски нестандартного и довести до состояния когда тул выдает что-то близкое к тому что хотелось получить существенно сложнее и дороже (и объемнее) чем сразу код с использованием нормальных инструментов.
Меня недавно позабавил сайт очередного js-фреймворка astro, который пищит про то что они самые быстрые, но их лэндинг в фф тормозит при прокрутке будто я открыл гугл-таблицу на 10к строк на celeron d и 1g ram со своим несмотря на то что реальная машинка -- i7-10875h+32g. В браузерах на блинке этого ужаса не наблюдается, на удивление.
Другой прекрасный опыт был когда нужно было нарисовать тривиальную страничку с таблицей на сотню-другую строк с парой кнопкой на строчку. Я, как простой бэкендер, взял babel (для ts) и обычный bootstrap 5. На машине с i7 и 32g ram сборка webpack'ом проходила за "разумные" 5-10 секунд (все конфиги из документации соотв. проектов). Когда пришлось запустить эту сборку на чужом macbook air 13 с 8g ram выяснилось что комбинация из webpack, babel и bootstrap/sass не лезет в память от слова совсем.. Учитывая что дело было в лесу с хорошим интернетом уровня edge, огромным потерями и пирогами до секунды -- был очень удивлен. Статически собранный bootstrap и отключеный babel с переключением на tsc решили проблему, но впечатления остались.
Для сравнения, у меня при меньшем количестве памяти спокойно собираются проекты типа Gradle (2M cloc), Apache Tika (200k cloc), Quarkus (800k cloc)
Имеет смысл выбросить устаревшее барахло типа SSLv3/TLSv1/TLSv1.1 и использовать разумный набор ciphersuites. Есть хорошие рекомендации и генератор конфигов под популярный софт от Мозилла.
Например, intermediate (TLSv1.2+TLSv1.3, ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384) -- это поддержка Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9, куда уж древнее лезть.
TLSv1 -- это Firefox 1, Android 2.3, Chrome 1, Edge 12, IE8 on Windows XP, Java 6, OpenSSL 0.9.8, Opera 5, and Safari 1..
Если про сервера с k8s -- давно containerd+runc (или crun и другие CRI engines), докер последнее время под капотом его сам использует. Из k8s dockershim (который позволял запускать pod'ы через docker) уже выкинули 3 версии как (в 1.24, начало 2022), а deprecated он был с 1.19 (~2.5 лет назад).
Если для локальной машины/CI -- docker или podman/buildah (под капотом containerd+crun).
Пока да, но они стремились всех перевести на cloud версию (не только Jira, но и OpsGenie) и народ влетел на полторы недели недоступности, если правильно помню без какой-либо разумной обратной связи кроме "мы работаем над этим" и без озвучивания сроков восстановления. И они в какой-то момент заявляли о том что планируют избавиться от on-prem варианта совсем..
может легко разломать систему: во-первых лишний пробел перед ro, во-вторых лейбл может оказаться не /boot (или отсутствовать вообще). Лучше уж использовать человеческий UUID
Особенно хорошо когда этот трекер -- это JIRA в Atlassian Cloud, как сейчас модно xD На те же грабли можно влететь с sms-gateway'ями, сервисами типа PagerDuty..
Про конфиг postfix'а: из того что бросилось в глаза smtp_use_tls = yes при выставленном smtp_tls_security_level не нужен.
Зачем вы ставите certbot через snap (которому, по хорошему не место на сервере) вместо пакета из репозитория или venv+pip -- не понятно. Избегание стандартного пакета из репозитория может быть понятно, если уже нарывались как некоторые доп репозитории типа powertools умеют разваливать certbot.
Никогда так не делайте, тем более на сервере. Для такого способа установки сначала скрипт сохраняется в файл, внимательно просматривается и только потом запускается. Это, кстати, известный вектор для атаки, т. к. скачивание и отправка в pipe легко различимы со стороны сервера и в curl ... | bash -s может быть выполнен совсем другой код.
chmod -R go+r /etc/gitlab/ssl/
И вы пошарили приватные ключи со всеми пользователями системы. Не надо так.
setenforce 0
Может лучше выполнить первым пунктом RTFM, а вторым проставить/восстановить нужные контексты?
Ещё проверьте наличие
UseDNS yesв конфиге, один из существенных кандидатов для тормозовAmber достаточно существенный (это var, records, новый switch expressions, pattern matching в switch и instanceof). Будет очень приятно если оно успеет побольше въехать в 21 (следующая lts с уменьшением времени между lts с 3 до 2 лет). Но по большей части воспринимается как синтаксический сахар пока valhalla для нормальных adt не приехала.
Кому-то loom (virtual threads, tail call optimization) будет очень кстати. Не помню structured concurrency (scoped threads) делалась в рамках него или нет. Но не сдвиг парадигмы, конечно.
Valhalla (value types, user-defined primitives, hidden classes) вполне возможно будет прорывом сопоставимым с добавлением дженериков или лямбд.
Ну и panama -- новое ffi и offheap. К сожалению не очень скоро. Очень важно для баз данных, вычислительного барахла и т.п. Для некоторой узкой части пользователей это вполне сопоставимо с фичами 1.8.
Вот упомянутый jpms/jigsaw принёс пользователям куда меньше фич (и больше проблем с необходимостью добавлять
--add-opens, вечно ломающимся lombok и развлечением с кодогенерацией во фреймворках). Кому надо было до этого сидели с osgi, jboss modules и, вероятно, другими подобными вещами.Дополню спустя почти полтора года. 17 живёт и здравствует, для части вещей типа netty нужно либо чуток переписывать код, либо добавлять add-opens, но ничего сверхестественного. По большей части всё живёт кроме представителей/поделий enterprise спецолимпиады сильно завязанных на 8.
JPMS у нас так и не взлетел. Тулинг подтягивается, фреймворки -- тоже (spring boot 3.х требует 17, quarkus 3.х -- 11, но рекомендует 17). На zgc/shenondoah пока не перебегали, много где живём на g1.
Не следует. Посмотрите таблицу истинности импликации, что-ли
Сколько разных case/rad/low-code/no-code было за последние три десятилетия.. И все упирались в одну простую вещь: написать спецификацию для чего-либо нетривиального и/или мало-мальски нестандартного и довести до состояния когда тул выдает что-то близкое к тому что хотелось получить существенно сложнее и дороже (и объемнее) чем сразу код с использованием нормальных инструментов.
Меня недавно позабавил сайт очередного js-фреймворка astro, который пищит про то что они самые быстрые, но их лэндинг в фф тормозит при прокрутке будто я открыл гугл-таблицу на 10к строк на celeron d и 1g ram со своим несмотря на то что реальная машинка -- i7-10875h+32g. В браузерах на блинке этого ужаса не наблюдается, на удивление.
Другой прекрасный опыт был когда нужно было нарисовать тривиальную страничку с таблицей на сотню-другую строк с парой кнопкой на строчку. Я, как простой бэкендер, взял babel (для ts) и обычный bootstrap 5. На машине с i7 и 32g ram сборка webpack'ом проходила за "разумные" 5-10 секунд (все конфиги из документации соотв. проектов). Когда пришлось запустить эту сборку на чужом macbook air 13 с 8g ram выяснилось что комбинация из webpack, babel и bootstrap/sass не лезет в память от слова совсем.. Учитывая что дело было в лесу с хорошим интернетом уровня edge, огромным потерями и пирогами до секунды -- был очень удивлен. Статически собранный bootstrap и отключеный babel с переключением на tsc решили проблему, но впечатления остались.
Для сравнения, у меня при меньшем количестве памяти спокойно собираются проекты типа Gradle (2M cloc), Apache Tika (200k cloc), Quarkus (800k cloc)
Прям дрожь пробовала пока не перечитал и не предположил что имелся ввиду csv, а не cvs..
А так такого на perl'е было написано предостаточно
Это начало касаться и простых пользователей облачных платформ. Тот же Hetzner начал хотеть денег за публичный IPv4
Имеет смысл выбросить устаревшее барахло типа SSLv3/TLSv1/TLSv1.1 и использовать разумный набор ciphersuites. Есть хорошие рекомендации и генератор конфигов под популярный софт от Мозилла.
Например, intermediate (TLSv1.2+TLSv1.3,
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384) -- это поддержка Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9, куда уж древнее лезть.TLSv1 -- это Firefox 1, Android 2.3, Chrome 1, Edge 12, IE8 on Windows XP, Java 6, OpenSSL 0.9.8, Opera 5, and Safari 1..
Если про сервера с k8s -- давно containerd+runc (или crun и другие CRI engines), докер последнее время под капотом его сам использует. Из k8s dockershim (который позволял запускать pod'ы через docker) уже выкинули 3 версии как (в 1.24, начало 2022), а deprecated он был с 1.19 (~2.5 лет назад).
Если для локальной машины/CI -- docker или podman/buildah (под капотом containerd+crun).
Почему для однонодового k8s был выбран metallb?
А что с flannel не так? Не считая отсутствия сетевых политик
Ну и с record'ами людям периодически нужны
@With/@Builder. Плюс, иногда нужны полноценные древние java beans, там либо руками, либо@Data// removed
Пока да, но они стремились всех перевести на cloud версию (не только Jira, но и OpsGenie) и народ влетел на полторы недели недоступности, если правильно помню без какой-либо разумной обратной связи кроме "мы работаем над этим" и без озвучивания сроков восстановления. И они в какой-то момент заявляли о том что планируют избавиться от on-prem варианта совсем..
Более того, использование
может легко разломать систему: во-первых лишний пробел перед
ro, во-вторых лейбл может оказаться не/boot(или отсутствовать вообще). Лучше уж использовать человеческий UUIDсложна и тяжела эта русска языка, но есть в ней слово "публикация"
Особенно хорошо когда этот трекер -- это JIRA в Atlassian Cloud, как сейчас модно xD
На те же грабли можно влететь с sms-gateway'ями, сервисами типа PagerDuty..
Про конфиг postfix'а: из того что бросилось в глаза
smtp_use_tls = yesпри выставленномsmtp_tls_security_levelне нужен.Зачем вы ставите certbot через snap (которому, по хорошему не место на сервере) вместо пакета из репозитория или venv+pip -- не понятно. Избегание стандартного пакета из репозитория может быть понятно, если уже нарывались как некоторые доп репозитории типа powertools умеют разваливать certbot.
Никогда так не делайте, тем более на сервере. Для такого способа установки сначала скрипт сохраняется в файл, внимательно просматривается и только потом запускается. Это, кстати, известный вектор для атаки, т. к. скачивание и отправка в pipe легко различимы со стороны сервера и в
curl ... | bash -sможет быть выполнен совсем другой код.И вы пошарили приватные ключи со всеми пользователями системы. Не надо так.
Может лучше выполнить первым пунктом RTFM, а вторым проставить/восстановить нужные контексты?
Спасибо, посмеялся. Вы так будете по одному адресу руками банить сотню-тысячу адресов в месяц? Не проще настроить fail2ban?
Напомнило:
How much watch?
No so much..
MGIMO finished?
Ask!