Только что услышал в новостях об этом. Как вы думаете, Intel продастся и если да, как это отразится на развитии процессоро- и чипсетстроения для PC или что будет с Intel ME?

Ссылка для Ъ https://www.cnbc.com/video/2024/09/20/report-qualcomm-has-approached-intel-about-a-takeover.html

С момента выхода первой версии блокнота прошёл 41 год и вот наконец-то…

https://www.theregister.com/2024/07/08/it_only_took_41_years/?td=keepreading

Под современным C++ обычно подразумевают C++11. Вышедшие после него C++14 и C++17 обычно называют минорными обновлениями стандарта. И вот, с появлением C++20, а недавно и C++23 появился современно современный C++. Тавтология по аналогии с long long.

Так вот, читаю сейчас совсем свежую книгу Beginning C++23 From Beginner to Pro, седьмое издание, авторы Ivor Horton и Peter Van Weert. Книга учит программированию на C++23 и довольно неклассическим образом. Вот самая первая программа из неё:

// Ex1_01.cpp - A complete C++ program
import std;          // This line makes the entire Standard Library available,
                     // including the std::println() functionality used below

int main()
{
  int answer {42};   // Defines the variable answer with value 42
  std::println("The answer to life, the universe, and everything is {}.", answer);
  return 0;
}

Классического Hello World нет, но его написание предлагается в качестве домашнего задания и тут же намекают каков должен быть код:

exercise 1-1. Create, compile, link, and execute a program that will display the text «Hello World» on your screen.

exercise 1-2. Create and execute a program that outputs your name on one line and your age on the next line. define a variable to hold your age first.

exercise 1-3. the following program produces several compiler errors. Find and correct these errors so the program compiles cleanly.

#import std
Int main
{
  std:printn("Holla Mundo!")
)

Так же в первых главах авторы написали:

As of C++23, the preferred mechanism for outputting text to the computer’s screen is through functions such as std::println() and std::print(). We will use these in nearly every example in this book.

Короче C++23 начинает напоминать Java. Но эту тему я открыл не поэтому. Мне вот стало интересно, а как воспримут обучившегося по такой книге джуна или мидла матёрые си плюс плюснутые дядьки из реальных проектов? Вот придёт такой свежеобученный программист в реальный проект и начнёт проталкивать C++ модули везде и всюду. Что скажут старшие товарищи? Побьют или они уже и сами перешли на модули и пишут свой код так, как описано в этой книге?

Не поймите меня неправильно, в книге рассказывают и о классических стримах ввода/вывода, но даже там говорят, что std::print() и std::println() предпочтительнее:

Streams

Input and output in C++ are, as a rule, performed using streams. To output data, you write it to an output stream, and to input data, you read it from an input stream. A stream is an abstract representation of a source of data or a data sink. When your program executes, each stream is tied to a specific device that is the source of data in the case of an input stream and the destination for data in the case of an output stream. The advantage of having an abstract representation of a source or sink for data is that the programming is then the same regardless of the device the stream represents. You can read a disk file in essentially the same way as you read from the keyboard.

std::print() and std::println() are little more than thin layers on top of streams. In essence, the std::println() statement in the main() function of Ex1_01 is analogous to either one of these statements:

std::cout << std::format("The answer to life, the universe, and everything is {}.", answer) << std::endl;
std::cout << "The answer to life, the universe, and everything is " << answer << std::endl;

The standard output and input streams in C++ are called std::cout and std::cin, respectively, and by default, they correspond to your computer’s screen and keyboard. You’ll be reading input from std::cin in Chapter 2 and later chapters.

std::format() is similar to std::print(), except that instead of streaming directly to the standard output stream, std::format() returns the formatted character sequence encapsulated in a std::string object (see Chapter 7). This is why std::print() is effectively analogous to streaming the result of std::format() to std::cout, as we did in the first line of our example.

<<, finally, is the stream insertion operator that transfers data to a stream. In Chapter 2, you’ll meet the stream extraction operator, >>, which similarly reads data from a stream. Whatever appears to the right of each << is transferred to std::cout. You can insert as many strings or other values in one statement as you want (we’ll clarify how this works exactly in Chapter 13). Inserting std::endl to std::cout causes a new line to be written to the stream and the output buffer to be flushed. Flushing the output buffer ensures that the output appears immediately.

Compared to working directly with std::cout, working with std::print() and std::println() is generally both more elegant and efficient (see the next chapter for more convincing evidence). This is why we won’t use output streams that often anymore as of this edition of the book. But because output streams remain an important concept in C++ in general, we’ll briefly return to working with streams at the end of the next chapter to introduce the basic principles.

Разумеется, большинство настоящих проектов на C++ заняты вовсе не вводом/выводом в консоль. Но переход на модули наверняка меняет устоявшиеся привычки в программировании на C++ ещё во множестве других мест. Мне интересно, как это будет воспринято синьёрами помидорами? Помню как я сам начинал программировать на Java в 2006 году. Во время обучения я использовал Java 6, в которой был новый синтаксис цикла for. На собеседовании у меня был лайв кодинг и когда я начал писать такой цикл и написал двоеточие интервьюирующий меня груплид воскликнул: «это же не Pascal!» В тогдашнем проекте той конторы использовали Java 5, в которой for-each только появился.

Мой основной браузер - Firefox, но захотелось попробовать Chromium. С удивлением обнаружил, что у Chromium нет официальных сборок релизов, а есть лишь сборки разной степени протухлости и пропатчености от каких-то левых чуваков вот тут:

https://chromium.woolyss.com/

Ещё есть ночные сборки вот тут:

https://download-chromium.appspot.com/

Но там светлосерым по тёмносерому написано: «This is a raw build of Chromium for Windows x64, right off the trunk. It may be tremendously buggy».

И ещё есть снапшот, то есть тоже не релиз, сборки, последняя из которых доступна тут:

https://chromium.woolyss.com/download/

Неужели это всё и нормального релиза не найти? Хромофилы, как вы с этим живёте?

ГуглоХром ставить не хочу в связи с сильной личной неприязнью к зондам. Да, его можно назвать официальной сборкой, но это не Chromium.

Наткнулся сейчас на новость о том, что в Debian приехал curl 8.0.0 с поддержкой протокола HTTP3, которой там раньше не было. Подумал, радость то какая и может быть новость запостить, а затем посмотрел какая версия curl сейчас последняя и рассмеялся. По-моему это яркий пример одной из основных проблем Linux - его фрагментирования. Не будь фрагментирования, авторы curl сами собирали бы бинарные сборки своей программы и они были бы доступны абсолютно всем пользователям Linux в день релиза. Конкретно curl 8.0.0 был бы доступен марте прошлого года.

В Java есть ключевое слово final и в C++ есть похожее ключевое слово const. В Java со всеми объектами работают только через ссылки на них, в C++ это является лишь одной из возможностей. В Java final ссылка на объект означает лишь то, что нельзя менять саму ссылку, но если объект мутабельный, можно менять его состояние. По наивности я думал, что в C++ всё примерно так же, но оказалось, что совсем не так.

Для начала простой пример на Java

public class MainClass {
    private static void foo(final StringBuilder stringBuilder) {
        stringBuilder.append("#foo()");
        System.out.println(stringBuilder);
    }

    public static void main(String[] args) {
        foo(new StringBuilder("Hello from MainClass"));
    }
}

Этот код изменяет содержимое stringBuilder и после этого печатает Hello from MainClass#foo()

Теперь перейдём к коду на C++

#include <iostream>
#include <string>

void foo(std::string& str) {
	str.append("foo()");
	std::cout << str << std::endl;
}


int main() {
	std::string str{"Hello from "};
	foo(str);
	return 0;
}

В этом коде функция foo() так же получает ссылку на стринговый объект, изменяет содержимое этого объекта не меняя саму ссылку и печатает результат: Hello from foo(). Но стоит добавить ключевое слово const перед объявлением этой ссылки в аргументах функции foo() и код перестаёт компилироваться из-за неожиданного отсутствия append().

Среди Java разработчиков попадаются и бывшие сишники. Обычно их можно обнаружить по некоторым привычкам из C/C++. Например по 5 == n, что для Java совершенно бесполезно, поскольку int не кастится в boolean и соответственно ошибочно написанное if (n = 5) приведёт к ошибке компиляции, как и if (5 = n) в C/C++. Так вот в некоторых компаниях Java разработчиков заставляют (например через maven-checkstyle-plugin) объявлять все аргументы публичных методов как final, что совершенно глупо и только раздражает. Сейчас у меня появилось предположение, что это пришло от покусанных C++ бывших сишников.

Так от какого же языка травма?

Читаю книгу Beautiful C++. Там рассматривается вопрос о правильной инициализации полей класса и в качестве начального примера используется следующий код:

class piano
{
public:
  piano();
private:
  int number_of_keys;
  bool mechanical;
  std::string manufacturer;
};

piano::piano()
{
  number_of_keys = 88;
  mechanical = true;
  manufacturer = "Yamaha";
}

На самом деле конструктор здесь не инициализирует, а перезаписывает значения полей класса, поскольку на момент запуска его кода все поля класса будут уже проинициализированы значениями по умолчанию. И хотя компилятор может иметь оптимизацию такого кода, неявно преобразуя его именно в инициализацию, полагаться на это, по мнению автора книги, никогда не следует. Далее но приводит более правильную версию кода конструктора:

piano::piano()
  : number_of_keys(88)
  , mechanical(true)
  , manufacturer("Yamaha")
{}

Мне более привычен немного другой стиль написания:

piano::piano() :
    number_of_keys(88),
    mechanical(true),
    manufacturer("Yamaha")
{}

А вот ещё нашёл документ, описывающий гугловский стиль написания кода на C++ https://google.github.io/styleguide/cppguide.html#Constructor_Initializer_Lists и в нём этот код выглядел бы вот так:

piano::piano()
    : number_of_keys(88),
      mechanical(true),
      manufacturer("Yamaha") {
}

Какой стиль инициализации в конструкторе вы предпочитаете?

P.S. на этом разбор инициализации в книге не заканчивается, но меня заинтересовал стиль написания кода.

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

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