Видео отчёт одного американца об этом месте: https://www.youtube.com/watch?v=Lngf0N8OrN0

Само это место на спутниковых фотографиях: https://www.google.com/maps/@37.2207712,-109.9582289,192m/data=!3m1!1e3?entry=ttu

Каким образом горная порода разрезалась на большие блоки на столько правильной формы? При этом, когда некоторые блоки срываются и раскалываются, раскол совсем неровный. Например, если остановить ролик на 6:30 или на 14:15, это прекрасно видно. То есть строением кристаллической решётки или чем-то подобным правильность формы блоков не объяснить, иначе они и дальше раскалывались бы так же правильно.

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

И чтобы два раза не вставать хочу высказать ещё одну гипотезу - ответ на вопрос, откуда и почему у древних пришельцев взялись технологии и инструменты для обработки именно камня. Вспомним шкалу Кардашёва, которая определяет степень развития цивилизации. Она определяет это развитие через количество энергии, которое цивилизация способна использовать для своих нужд. Если мы говорим о пришельцах, которые ушли далеко в своём развитии и опережают наш нынешний уровень на столько, что способные прилететь на нашу планету из дальнего космоса и начать её осваивать, то их энергетический уровень явно превышает наш собственный на порядки. Но космические путешествия в дальнем космосе сопряжены не только с большим расходом энергии, но и с необходимостью надёжной защиты от всевозможных опасностей, начиная с космической пыли и метеоритов и до жёсткой космической радиации. То есть просто в металлических банках с двигателями безопасно летать на такие расстояния и с такими скоростями не получится. Но располагая достаточно большой энергией можно взять небольшую каменистую планету с остывшим ядром и превратить её в космический корабль. При этом возникнет необходимость в обработке больших объёмов каменной породы как на этапе строительства, так и во время эксплуатации такого каменного корабля. Примерно как у древних мореплавателей всегда были инструменты для обработки древесины.

Дополнение: Нашёл ещё один ролик, на этот раз русскоязычного автора, со съёмками из того же самого места https://www.youtube.com/watch?v=KNrbvXRgTlg Особенно интересен момент на 3:32.

Испанец Тони Саро решил написать свою реляционную базу данных с нуля, не используя никаких сторонних библиотек. В результате получился интересный видео ролик с теорией и проект на языке Rust:

https://www.youtube.com/watch?v=5Pc18ge9ohI (видео)

https://github.com/antoniosarosi/mkdb (проект)

Говорят, что это AI поёт и играет.

https://www.youtube.com/watch?v=A2pzAH0V8Gs

Прошу зрительный зал ЛОР-овских физиков и прочих специалистов по всему прокомментировать опыт, показаный в следующем ролике:

https://www.youtube.com/shorts/n8WxkqMRgS4

Разработчик Debian Лука Боккасси анонсировал переход Debian к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру по умолчанию, начиная с Debian 13 “Trixie”.

В новых системах файлы в /tmp будут либо исчезать вместе с прежним экземпляром tmpfs в памяти после рестарта, либо будут удаляться ежедневно по таймеру, если они старше 10 дней, а файлы в /var/tmp будут удаляться только ежедневно по таймеру, если они старше 30 дней. Пакеты openssh и tmux были модифицированы с целью сохранения своих временных файлов в /var/tmp в качестве исключения. В системах, которые будут обновляться до Debian 13 “Trixie”, старое поведение /var/tmp сохранится.

В то время, как в большинстве других дистрибутивов давно перешли на использование tmpfs в /tmp, в Debian не спешили этого делать. Сейчас разработчики Debian (Michael Biebl и Luca Boccassi) возобновили одну из таких дискуссий 2020 года, в которой разработчик из Canonical (Eric Desrochers) пожаловался на проблему несоответствия тогдашней реализации /var/tmp в Debian тому, как работает systemd, несмотря на то, что патч был опубликован ещё в 2012 году. Таким образом, было принято решение привести поведение системы при работе с этими директориями к общепринятому в systemd и в большинстве других дистрибутивов.

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

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

Инженер из 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

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