Купил с пол года назад классическу гейзерную кофеварку Биаллетти из алюминия на три итальянские «чашки». Всё бы хорошо, но на дне нижней части начали появляться следы окисления, которые не вымываются. Видимо гранулы кофе как-то реагируют с покрытием металла. Есть версия этой кофеварки для индукционной печи, тоже от Биаллетти, сделанная из нержавеющей стали. Мне вот интересно, будет ли стальная кофеварка более устойчивой к окислению и если будет, то почему продолжают выпускать классические кофеварки из алюминия, причём не только Биаллетти? Да, теплопроводность алюминия лучше, но разве она тут важна? Когда кипящая вода устремится пройти сквозь кофейную таблетку металл вокруг уже по-любому достаточно хорошо нагреется.

Инженер из Intel, Ноах Голдштейн, оптимизировал функцию memset() в библиотеке glibc. Данная оптимизация даёт прирост в производительности порядка 7.5% на десктопных версиях процессоров архитектур Skylake-X и Ice Lake. У серверных версий прирост в производительности немного ниже, прежде всего из-за более низкой общей производительности одиночного ядра.

В прежней реализации функции memset() использовалась ассемблерная инструкция rep stosb. До недавнего времени эта инструкция работала достаточно быстро, за счёт внутрипроцессорной оптимизации zero-over-zero writeback. Однако в этой оптимизации была найдена потенциальная уязвимость, которая может привести к атаке по побочному каналу. В результате оптимизация zero-over-zero writeback была отменена, что и привело к ухудшению производительности rep stosb. В новой версии memset() инструкция rep stosb всё ещё используется, но при выполнении более строгих условий.

Что именно изменилось, можно понять по изменению следующего комментария в коде, который описывает подробности реализации memset()

Прежняя версия описания:

/* memset is implemented as:
   1. Use overlapping store to avoid branch.
   2. If size is less than VEC, use integer register stores.
   3. If size is from VEC_SIZE to 2 * VEC_SIZE, use 2 VEC stores.
   4. If size is from 2 * VEC_SIZE to 4 * VEC_SIZE, use 4 VEC stores.
   5. On machines ERMS feature, if size is greater or equal than
      __x86_rep_stosb_threshold then REP STOSB will be used.
   6. If size is more to 4 * VEC_SIZE, align to 4 * VEC_SIZE with
      4 VEC stores and store 4 * VEC at a time until done.  */

Новая версия описания:

/* memset is implemented as:
   1. Use overlapping store to avoid branch.
   2. If size is less than VEC, use integer register stores.
   3. If size is from VEC_SIZE to 2 * VEC_SIZE, use 2 VEC stores.
   4. If size is from 2 * VEC_SIZE to 4 * VEC_SIZE, use 4 VEC stores.
   5. If size is more to 4 * VEC_SIZE, align to 1 * VEC_SIZE with
      4 VEC stores and store 4 * VEC at a time until done.
   6. On machines ERMS feature, if size is range
	  [__x86_rep_stosb_threshold, __x86_memset_non_temporal_threshold)
	  then REP STOSB will be used.
   7. If size >= __x86_memset_non_temporal_threshold, use a
	  non-temporal stores.  */

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

Агентство по кибербезопасности и защите инфраструктуры (U.S. Cybersecurity and Infrastructure Security Agency (CISA)) добавило в свой каталог активно используемых уязвимостей недавно найденную проблему в ядре Linux: CVE-2024-1086 Linux Kernel Use-After-Free Vulnerability.

Речь идёт о компоненте nf_tables, внутри встроенного в ядро фаервола netfilter, которая может быть эксплуатирована для эскалации локальных привилегий. Ошибка связана с неправильным взаимодействием функций nft_verdict_init() и nf_hook_slow(), которое приводит к двойному освобождению памяти.

Рекомендовано срочно обновиться или откатить ядро до версии перед коммитом f342de4e2f33e0e39165d8639387aa6c19dff660

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

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

Прошу помощи зрительного зала в оценке перспективности смены карьеры с Java Backend разработчика на Go или Kotlin Backend. Да, я знаю, что Kotlin - это больше Android, но вот прямо сейчас наклёвывается новая работа именно на Kotling и именно в Backend. Причём компания - вовсе не стартап переросток с тремя разрабами. Что бы вы выбрали?

1. Отказались бы от Kotlin backend и продолжили искать Go backend
2. Согласились бы на Kotlin backend
3. Остались бы на теряющей популярность, но всё ещё жирной Java backend
4. Попробовали бы что-то другое (в комментах укажите что)

И да, я считаю, что Java неуклонно движется в сторону COBOL номер два. Со временем популярность Java продолжит падать и дальше, вплоть до выхода из первой десятки популярных языков. По моим ощущениям на это понадобится не более десяти лет. При этом новых и интересных проектов на Java будет всё меньше и меньше, вплоть до полного исчезновения.

Недавно узнал, что Kotlin не привязан к JVM так сильно, как я до сих пор думал. Речь идёт о Kotlin Multiplatform.

В мире Go существует уникальная возможность перехода, которая закроется через 3 - 4 года. В подавляющем числе Go ориентированных компаний нет требования какого либо прошлого опыта разработки на Go и достаточно лишь опыта разработки на других ЯП, в числе которых обычно упоминают и Java. Если сейчас не запрыгнуть на этот поезд, можно опоздать и не запрыгнуть уже никогда. Уже сейчас начали появляться компании, где требуют хотя бы 2 - 3 года опыта на Go. Их пока мало, но будет больше. 2 - 3 года назад таких компаний не было вообще.

Почитал тут немного про новую архитектуру X86S и задумался, а как там будет осуществляться загрузка системы? Классические загрузчики из MBR работать не будут, поскольку они расчитаны на 16-и битный режим, которого в X86S не будет. А вот интересно, в GPT такой загрузчик вообще предусмотрен? Сам я до сих пор пользуюсь исключительно MBR где только можно и он меня полностью устраивает, поэтому про загрузку в GPT не знаю.

В теории загрузчик из MBR/GPT можно просто переписать для 64-х битного режима, но кто его в X86S вообще вызовет? Я имею в виду загрузку без Secure Boot, UEFI и всего такого. Будет ли некое подобие старого доброго BIOS, который просто загружает в память код из boot record в MBR/GPT на диске и дальше уже этот код продолжает загрузку? Очень не хочется переходить на UEFI, прежде всего из-за вероятности появления материнок с неотключаемой Secure Boot и залочеными сертификатами или из-за требования держать Secure Boot включённым в винде. Не знаю есть ли в винде такое требование, но история с требованием к железу в Windows 11 изначально и их дальнейшее устрожение в 24H2 вызывает некоторые беспокойства в отношении UEFI.

Перемещено hobbit из general

Подскажите пожалуйста, существует ли стандартный Bootstrap GNU Toolchain которым пользуются сами разработчкики основных GNU проектов? Я имею в виду стандартный набор команд для сборки как минимум gcc, glibc, binutils, make и autotools на любой адекватной Linux системе, без привязки к тому и без перезаписи того, что там уже установлено и желательно с бинарно воспроизводимой сборкой. В дальнейшем этот минимальный GNU Toolchain будет использоваться для сборки ядра и остальных компонентов системы.

Да я знаю про LFS, но это нестандартный путь. Не думаю, что разработчики GNU собирают свои компоненты именно так.

Наблюдаю сейчас затянувшийся спор разработчика загрузчика системы Limine с разработчиком binutils по поводу какого-то изменения в ld, а конкретнее в Binary File Descriptor library (BFD). Это изменение приводит к настандартному (по мнению разраба Limine) поведение ld. Конкретнее если слинковать static-pie kernel при помощи ld тип получаемого ELF файла может быть разным: ET_DYN если адрес загрузки начинается с нуля или ET_EXEC в противном случае. При этом ld.lld и ld.gold в обоих случаях генерируют только ET_DYN. В ходе спора выяснилось, что это нестандартное поведение появилось в ld около десяти лет назад, как хак какой-то проблемы с тогдашним ядром Linux. Разработчик Limine просит изменить это поведение или хотя бы добавить возможность изменить его на более стандартное при помощи дополнительного параметра запуска ld. Разработчик ld не хочет этого делать и вместо этого закрыл баг после небольшой правки документации:

--- a/ld/ld.texi
+++ b/ld/ld.texi
@@ -2694,7 +2694,10 @@ Same as @option{--section-start}, with @code{.bss}, @code{.data} or
 @item -Ttext-segment=@var{org}
 @cindex text segment origin, cmd line
 When creating an ELF executable, it will set the address of the first
-byte of the text segment.
+byte of the text segment.  Note that when @option{-pie} is used with
+@option{-Ttext-segment=@var{org}}, the output executable is marked
+ET_EXEC so that the address of the first byte of the text segment will
+be guaranteed to be @var{org} at run time.

https://sourceware.org/bugzilla/show_bug.cgi?id=31795

Как по-вашему, кто из них прав и почему?