Видео отчёт одного американца об этом месте: 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

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

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

Прошу помощи зрительного зала в оценке перспективности смены карьеры с 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

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