Я говорю о главе "SoA и AoS" которая является полным бредом где вы разбиваете x y z на отдельные массивы и утверждаете что так быстрее, при этом ссылаетесь на статью в которой написано СТРОГО НАОБОРОТ. В статье по ссылке описывается Hot/cold splitting и основываясь на этом нужно было разбить так как я описал выше,т.к. x y z в 99.99999% случаев используются вместе поэтому их нужно группировать в одну структуру, а не разбивать по разным уголкам оперативной памяти чтобы потом собирать их отовсюду насилуя кэш процессора.
Незнаю что вы имете ввиду, но например в OpenGL загрузка координат идет массивом структур x,y,z, поэтому в том виде который указал автор их невозможно загрузить без предварительной обработки. Т.е. сплошной кусок памяти должен содержать по переменно x y z x2 y2 z2..., а не x x2...y y2..z z2 как у автора
Про "SoA быстрее AoS" это полный бред. Автор даже не понял суть статьи на которую он ссылается. Там весь упор был сделан не на SoA vs AoS, а на то что данные нужно группировать с умом и комбинировать ОБА подхода, а не тупо использовать только один из них как написал автор. Согласно указанной статье нужно было сделать структуру с x, y, z и потом сделать 3 вектора этих структур, а не 9 векторов с отдельными значениями. 9 векторов это ХУДШИЙ вариант, потому что для обработки ЛЮБОЙ величины (позиции, скорости или ускорения) одной точки нужно загружать данные как минимум из трех очень удаленных адресов (x любой величины лежит ооочень далеко от y и z), а их в 99% случаев обрабатывают вместе.
Ну а у в случае если вообще ничего не писать, так и вообще поддерживать легко...нет кода - нет проблем. Но мы же все таки пишем код и используем интерфейсы. Хотите реальный пример - есть у меня небольшой проект на Go - стриминг сервер, который раздает MPEGTS/HLS/SRT и т.п. Если бы я его писал на C++ то я бы сделал базовый класс входного потока и потом бы уже наследовался от него и реализовывал на его основе отдельно MPEGTS/HLS/SRT и т.п. Но в Go нет наследования и поэтому чтобы не плодить copy-paste реализуя все через интерфейс я переворачиваю эту модель задом наперед и делаю базовый класс входного потока финальным, а реализации MPEGTS/HLS/SRT через композицию в этот класс указателя на интерфейс имплементации конкретных протоколов,с неизбежными кросслинками между имплементацией и базовым классом. Вы думаете это упростило мне жизнь? да нихрена. Да все работает, нет copy-paste, но реализация в прямом смысле через зад - задом на перед. Это необходимые костыли, которые усложнили код и его поддержку.
Композиция это не частный случай наследования, это совсем другое
Не надо вытаскивать слова из контекста, я писал " есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования". Если не верите, то возмите на с++ и напишите наследование и композицию для структур без методов и вы увидите что результат будет одинаковый. Я это лично проверял как разные компиляторы c++ располагают классы, структуры и таблицы виртуальных методов в памяти еще 30 лет назад.
Приведите, пожалуйста, реальную ситуацию, не изолированный воображаемый пример, когда наследование однозначно выгоднее
Выгоднее чего? Copy-paste реализации через интерфейсы. Так это аксиома что Copy-paste это плохо, а по другому там никак. Если вам нужны примеры, так откройте любую библиотеку на с++ где есть наследование и попробуйте подумать как это реализовать без наследования, а только композицией..да это будет возможно написать, но код будет намного сложнее чем через наследование.
Прелесть Го в том, что никто не передаст в функцию непойми что, что не нужно разбираться какая функция в реальности вызывается у класса и что кто-то в дочернем классе переопределил её на бог знает что
В каком смысле "не нужно разбираться какая функция в реальности вызывается у класса"??? Если функция в Go принимает ссылку на интерфейс то как раз нужно разбиратся что за немойми что это за экземпляр и кто реализует этот интерфейс и какая в реальности функция вызывается. и вполне возможно что что кто-то в дочернем классе реализовал вместо интерфейся бог знает что
А зачем вам вообще может понадобиться сразу отсортированный список везде? Что это за реальная задача, где это нужно?
Это не контр аргумент, а демогогия. И почему везде? То то и оно что где то нужен обычный список в котором не надо тратить время на сортировку, а где то нужен отсортированный. Задача хоть и упрощенная но вполне проецируется на реальные задачами. Суть это примера не в конкретной задаче, а в необходимости переопределить небольшое количество методов которым требуется доступ к внутренним данным класса.
можно использовать те же интерфейсы.
Да можно, но наследование изящние (если оно есть в языке) и почему это плохо,а композиция хорошо мне так никто и не сказал.
Так это всегда нужно делать, если вы меняете интерфейс, то все функции, что используют этот интерфейс должны быть изменены.
Да неужели? Если я добавляю 25 новых функций в базовый класс то я могу вообще не менять ни одного наследника и все будет рабоать. А в случае с интерфейсом я ОБЯЗАН менять ВСЕХ наследников причем в большинстве случаев с композицией это будет copy-paste.
Прелесть композиции и запрета наследования в Go в том, что Go гарантирует, что если у вашей функции есть 3 аргумента - структура, int и массив интов, то туда можно передать только структуру, int и массив интов, никаких дочерей, пасынков, родственников и друзей, только эти типы данных
А в чем прелесть то, со стороны разрабочика на Go (если вы конечно не мазахист и каждое ограничение вызывает у вас восторг)? То что это проще для разработчиков языка, да, но для разрабочика на Go это ограничение. В таком случае вам понравится писать на чистом ассемблере...абсолютная прелесть. Да и для справки, в Go вооще нет классических классов, так что о каком наследовании классов вообще идет речь это загадка.Там есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования.
Вот тут вы полностью правы, вы НЕ так велики чтобы выдавать свое мнение за мнение разработчиков вышеупомянутых языков и не вам решать почему они приняли те или иные решения.
Так вы еще и читать не умеете? Я вас разве спрашивал о списке языков в которых есть "расширенная диспетчеризация вызовов без классического ООП"? Нет. Я утверждаю что композиция это НЕ альтернатива наследованию если язык поддерживает наследование. Использование композиции в качестве альтернативы наследованию это костыли которые приводят к меннее наглядному, менее качественному и создают сложности с поддержкой кода. Если вы не согласны с моим утверждением, то жду ваших АРГУМЕНТОВ, а не списка языков и учебников.
Мда, конкретика и аргументы достойны несостоявшегося программиста. Неужели все так плохо и такой теоретик не может даже аргумент сформулировать, раз уж код не получается. Вот вам ссылка что такое аргумент https://ru.wikipedia.org/wiki/Аргумент_(логика)
Мало букв, ноль знаний. Сразу видно "господина" теоретика, который не написал ни одной реальной строчки кода в своей жизни. В мире есть много чего (кроме конечно ваших знаний, вот чего нет так уж нет...даже больше нескольких предложений воды не осилили). Вы можете извращатся как хотите, это ваше дело как эмулировать наследование, но проще и лучше от этого не становится ни код ни его поддержка. Для начала автор хотябы должен разъяснить чем по его мнению композиция лучше наследования и как он использует эту "альтернативу" в конкретном примере. Ну от ответить лучше с аргументами, а не ссылками на wiki про мультиметоды пытаясь сойти за умного. Ум проявляется в делах, а не ссылках на чужие слова. Давайте пример как вы обходите наследование композицией с переписыванимем методов в месте со статьей как вы потом будете это поддерживать, если конечно вас раньше не сожгут на костре за такое издевательство. А потом и сравним что проще и кому промыли что то. Только делайте это на языке который поддерживает и наследование и композицию, а дальше хоть мультиметодами, хоть корягами, главное чтобы проще, нагляднее и понятнее чем наследование. Вот мы тут посмеемся.
Вы наверное не понимаете что такое композиция и чем она отличается от наследования.Композиция работает когда вы хотите использовать готовый функционал готового класса и ему не нужен доступ к вашему классу потому что он уже полностью готов и самодостаточен. Вы не можете переопределить ничего при композиции не меняя интерфейсам взаимодействия с классом, который используете при композиции. А наследование подразумевает что родительский класс имеет полный доступ к наследнику и вы можете менять логику родительского класса БЕЗ изменения интерфейса взаимодействия. Возмем простой пример. У вас есть класс который реализует список (list) чисел вы ходите сделать класс который его расширяет и делает его упорядоченным списком. При наследовании я просто наследуюсь от него и переопредяляю метод добавления чтобы он вставлял не в конец, а в нужное место согласно нужному порядку....все, переопределил 1 метод и готово. А теперь сделайте тоже самое композицией чтобы я мог передать любой из этих классов одному методу. В лучшем случае для этого надо будет определить интерфейс, потом сделать класс заготовки списка с доступом ко всем его элементам, и только после этого вы сможет включить этот класс в композицию финальных классов где уже реализуете интерфейс используя copy-paste для обоих классов. И при каждом изменении интерфейса вы должны менять все где он упоминается и реализован. И что будет проще поддерживать и использовать?
А может быть это с вами что то не так раз вам проще 100 раз сделать Copy-Paste вместо наследования? Я люблю наследование, более того...бывает что в языках, отличных от С++ мне не хватает множественно наследования. И у меня никогда небыло проблем с поддержкой проектов с множественным наследованием. Если же язык не поддерживает классы и наследования, то все равно их концепция может быть реализована, просто будет намного более не красиво и сложнее в поддержке, но вы все равно тем или иным способом будете это использовать потому что альтернатива это copy-paste
Как можно сравнивать Go и Java ? Java это тормозное корпоративное болото в котором никто не считает никакие ресурсы...ни машинные, ни человеческие. Go программа будет работать на 90% target машин сразу,а Java вы сначала замучаетесь искать нужную версию,а потом все бросите и пойдете переустанавливать новую систему потому что нужной версии java нет даже для не старой версии системы. Вот как раз недавно имел занимательное развлечение с UniFi network server который вдруг решили обновить Java 17 на Java 25, только эти "эффективные" программисты забыли что рекомендуемая ими Debian 12 Bookworm (вышедшая всего 2 года назад) НЕ ИМЕЕТ Java25 headless. Т.е. теперь все клиенты должны или обновить систему до Debian 13 или поставить гигабайты X11+ вместе с полной версией Java25 , чтобы просто работал простенький web server. Думаю что если бы они писали на Go, то все уместилось бы в десяток мегабайт и работало бы на системах 20 летней давности. Вот поэтому люди и выбирают Go, а не потому что в Java тоже НЕТ горутин.
Я так и не понял что не так с первым примером тем более в статье с названием "Почему программисты стали писать медленный код". Во-первых, непонятно зачем автор предлагает анализировать на уровне CPU если там и на уровне C++ видно что большая часть времени уйдет на работу с памятью, а не на ЕДИНСТВЕННУЮ математическую операцию. Во-вторых, задача решена оптимально потому что современный компилятор С++ проведет векторизацию циклов и сделает оптимальный код с 128 битным доступом к памяти и использованием SSE регистров. Поэтому если что то в этом коде и не оптимально, так это постановка задачи, а не ее реализация программистом. И какое это имеет отношение к смыслу статьи непонятно. А приложение заметок жрет столько памяти и медленно работает не потому что кто то написал медленный код на С++, а наоборот...потому что кто то поленился написать это на С++ и использовал громозкие фреймворки на каком нибудь новомодном языке которые вместо программ на 10 строк сгенераровали 100 мегабайт кода и заняли пол гигабайта памяти.
Ну даже если 7 статей, все равно это мало чтобы быть первым в рейнинге.Причем разница между первым и вторым местом почти 1400...т.е. его рейтинг в 4 раза больше чем у следующего. Явно он "взломал" систему рейтинга Хабра и активно накручивал его себе. Пару дней назад я как раз оставил об этом комментарий к его статье про симуляцию экономики. Там было 56 комментариев из которых 80% в стиле какая хорошая статья и только 2 в которых люди отмечали нарушенную логику статьи.
Это реальная новость про EDAC, а в статье автор прощается с 440BX и в выводах прямо врет что на 440BX новый линукс не запустится и что на обычных пользователей это не повлияет потому что чипсет старый, а не потому что на 440BX все продолжит работать, а убрали никому не нужный драйвер EDAC
То то и оно что EDAC для 440BX никому не нужен и удаление этого драйвера вообще ни на что не влияет в плане поддержки самого чипсета 440BX. А автор специально поставил такой заголовок, который вводит в заблуждение.
Статья кликбейтная и заголовок совершенно не корректный. Поддержку чипсета 440BX никуда не убрали и новый Linux 7.0 должен нормально продолжать на нем работать. А почему это важно в 2026 году? Да потому что 440BX и его предшественник 440FX это железо, которое по умолчанию эмулируется многими гипервизорами типа QEMU, и если новый Linux перестанет загружатся на этих чипсетах, то полетит куча виртуальных машин. Но автор статьи даже незнает об этом и пишет всякую хрень.
Я говорю о главе "SoA и AoS" которая является полным бредом где вы разбиваете x y z на отдельные массивы и утверждаете что так быстрее, при этом ссылаетесь на статью в которой написано СТРОГО НАОБОРОТ. В статье по ссылке описывается Hot/cold splitting и основываясь на этом нужно было разбить так как я описал выше,т.к. x y z в 99.99999% случаев используются вместе поэтому их нужно группировать в одну структуру, а не разбивать по разным уголкам оперативной памяти чтобы потом собирать их отовсюду насилуя кэш процессора.
Незнаю что вы имете ввиду, но например в OpenGL загрузка координат идет массивом структур x,y,z, поэтому в том виде который указал автор их невозможно загрузить без предварительной обработки. Т.е. сплошной кусок памяти должен содержать по переменно x y z x2 y2 z2..., а не x x2...y y2..z z2 как у автора
Про "SoA быстрее AoS" это полный бред. Автор даже не понял суть статьи на которую он ссылается. Там весь упор был сделан не на SoA vs AoS, а на то что данные нужно группировать с умом и комбинировать ОБА подхода, а не тупо использовать только один из них как написал автор. Согласно указанной статье нужно было сделать структуру с
x, y, zи потом сделать 3 вектора этих структур, а не 9 векторов с отдельными значениями. 9 векторов это ХУДШИЙ вариант, потому что для обработки ЛЮБОЙ величины (позиции, скорости или ускорения) одной точки нужно загружать данные как минимум из трех очень удаленных адресов (x любой величины лежит ооочень далеко от y и z), а их в 99% случаев обрабатывают вместе.Orange Pi Zero 3W забыли. http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3W.html
Ну а у в случае если вообще ничего не писать, так и вообще поддерживать легко...нет кода - нет проблем. Но мы же все таки пишем код и используем интерфейсы. Хотите реальный пример - есть у меня небольшой проект на Go - стриминг сервер, который раздает MPEGTS/HLS/SRT и т.п. Если бы я его писал на C++ то я бы сделал базовый класс входного потока и потом бы уже наследовался от него и реализовывал на его основе отдельно MPEGTS/HLS/SRT и т.п. Но в Go нет наследования и поэтому чтобы не плодить copy-paste реализуя все через интерфейс я переворачиваю эту модель задом наперед и делаю базовый класс входного потока финальным, а реализации MPEGTS/HLS/SRT через композицию в этот класс указателя на интерфейс имплементации конкретных протоколов,с неизбежными кросслинками между имплементацией и базовым классом. Вы думаете это упростило мне жизнь? да нихрена. Да все работает, нет copy-paste, но реализация в прямом смысле через зад - задом на перед. Это необходимые костыли, которые усложнили код и его поддержку.
Не надо вытаскивать слова из контекста, я писал " есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования". Если не верите, то возмите на с++ и напишите наследование и композицию для структур без методов и вы увидите что результат будет одинаковый. Я это лично проверял как разные компиляторы c++ располагают классы, структуры и таблицы виртуальных методов в памяти еще 30 лет назад.
Выгоднее чего? Copy-paste реализации через интерфейсы. Так это аксиома что Copy-paste это плохо, а по другому там никак. Если вам нужны примеры, так откройте любую библиотеку на с++ где есть наследование и попробуйте подумать как это реализовать без наследования, а только композицией..да это будет возможно написать, но код будет намного сложнее чем через наследование.
В каком смысле "не нужно разбираться какая функция в реальности вызывается у класса"??? Если функция в Go принимает ссылку на интерфейс то как раз нужно разбиратся что за немойми что это за экземпляр и кто реализует этот интерфейс и какая в реальности функция вызывается. и вполне возможно что что кто-то в дочернем классе реализовал вместо интерфейся бог знает что
Это не контр аргумент, а демогогия. И почему везде? То то и оно что где то нужен обычный список в котором не надо тратить время на сортировку, а где то нужен отсортированный. Задача хоть и упрощенная но вполне проецируется на реальные задачами. Суть это примера не в конкретной задаче, а в необходимости переопределить небольшое количество методов которым требуется доступ к внутренним данным класса.
Да можно, но наследование изящние (если оно есть в языке) и почему это плохо,а композиция хорошо мне так никто и не сказал.
Да неужели? Если я добавляю 25 новых функций в базовый класс то я могу вообще не менять ни одного наследника и все будет рабоать. А в случае с интерфейсом я ОБЯЗАН менять ВСЕХ наследников причем в большинстве случаев с композицией это будет copy-paste.
А в чем прелесть то, со стороны разрабочика на Go (если вы конечно не мазахист и каждое ограничение вызывает у вас восторг)? То что это проще для разработчиков языка, да, но для разрабочика на Go это ограничение. В таком случае вам понравится писать на чистом ассемблере...абсолютная прелесть. Да и для справки, в Go вооще нет классических классов, так что о каком наследовании классов вообще идет речь это загадка.Там есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования.
Вот тут вы полностью правы, вы НЕ так велики чтобы выдавать свое мнение за мнение разработчиков вышеупомянутых языков и не вам решать почему они приняли те или иные решения.
Так вы еще и читать не умеете? Я вас разве спрашивал о списке языков в которых есть "расширенная диспетчеризация вызовов без классического ООП"? Нет. Я утверждаю что композиция это НЕ альтернатива наследованию если язык поддерживает наследование. Использование композиции в качестве альтернативы наследованию это костыли которые приводят к меннее наглядному, менее качественному и создают сложности с поддержкой кода. Если вы не согласны с моим утверждением, то жду ваших АРГУМЕНТОВ, а не списка языков и учебников.
Мда, конкретика и аргументы достойны несостоявшегося программиста. Неужели все так плохо и такой теоретик не может даже аргумент сформулировать, раз уж код не получается. Вот вам ссылка что такое аргумент https://ru.wikipedia.org/wiki/Аргумент_(логика)
Мало букв, ноль знаний. Сразу видно "господина" теоретика, который не написал ни одной реальной строчки кода в своей жизни. В мире есть много чего (кроме конечно ваших знаний, вот чего нет так уж нет...даже больше нескольких предложений воды не осилили). Вы можете извращатся как хотите, это ваше дело как эмулировать наследование, но проще и лучше от этого не становится ни код ни его поддержка. Для начала автор хотябы должен разъяснить чем по его мнению композиция лучше наследования и как он использует эту "альтернативу" в конкретном примере. Ну от ответить лучше с аргументами, а не ссылками на wiki про мультиметоды пытаясь сойти за умного. Ум проявляется в делах, а не ссылках на чужие слова. Давайте пример как вы обходите наследование композицией с переписыванимем методов в месте со статьей как вы потом будете это поддерживать, если конечно вас раньше не сожгут на костре за такое издевательство. А потом и сравним что проще и кому промыли что то. Только делайте это на языке который поддерживает и наследование и композицию, а дальше хоть мультиметодами, хоть корягами, главное чтобы проще, нагляднее и понятнее чем наследование. Вот мы тут посмеемся.
Вы наверное не понимаете что такое композиция и чем она отличается от наследования.Композиция работает когда вы хотите использовать готовый функционал готового класса и ему не нужен доступ к вашему классу потому что он уже полностью готов и самодостаточен. Вы не можете переопределить ничего при композиции не меняя интерфейсам взаимодействия с классом, который используете при композиции. А наследование подразумевает что родительский класс имеет полный доступ к наследнику и вы можете менять логику родительского класса БЕЗ изменения интерфейса взаимодействия. Возмем простой пример. У вас есть класс который реализует список (list) чисел вы ходите сделать класс который его расширяет и делает его упорядоченным списком. При наследовании я просто наследуюсь от него и переопредяляю метод добавления чтобы он вставлял не в конец, а в нужное место согласно нужному порядку....все, переопределил 1 метод и готово. А теперь сделайте тоже самое композицией чтобы я мог передать любой из этих классов одному методу. В лучшем случае для этого надо будет определить интерфейс, потом сделать класс заготовки списка с доступом ко всем его элементам, и только после этого вы сможет включить этот класс в композицию финальных классов где уже реализуете интерфейс используя copy-paste для обоих классов. И при каждом изменении интерфейса вы должны менять все где он упоминается и реализован. И что будет проще поддерживать и использовать?
А может быть это с вами что то не так раз вам проще 100 раз сделать Copy-Paste вместо наследования? Я люблю наследование, более того...бывает что в языках, отличных от С++ мне не хватает множественно наследования. И у меня никогда небыло проблем с поддержкой проектов с множественным наследованием. Если же язык не поддерживает классы и наследования, то все равно их концепция может быть реализована, просто будет намного более не красиво и сложнее в поддержке, но вы все равно тем или иным способом будете это использовать потому что альтернатива это copy-paste
Как можно сравнивать Go и Java ? Java это тормозное корпоративное болото в котором никто не считает никакие ресурсы...ни машинные, ни человеческие. Go программа будет работать на 90% target машин сразу,а Java вы сначала замучаетесь искать нужную версию,а потом все бросите и пойдете переустанавливать новую систему потому что нужной версии java нет даже для не старой версии системы. Вот как раз недавно имел занимательное развлечение с UniFi network server который вдруг решили обновить Java 17 на Java 25, только эти "эффективные" программисты забыли что рекомендуемая ими Debian 12 Bookworm (вышедшая всего 2 года назад) НЕ ИМЕЕТ Java25 headless. Т.е. теперь все клиенты должны или обновить систему до Debian 13 или поставить гигабайты X11+ вместе с полной версией Java25 , чтобы просто работал простенький web server. Думаю что если бы они писали на Go, то все уместилось бы в десяток мегабайт и работало бы на системах 20 летней давности. Вот поэтому люди и выбирают Go, а не потому что в Java тоже НЕТ горутин.
Я так и не понял что не так с первым примером тем более в статье с названием "Почему программисты стали писать медленный код". Во-первых, непонятно зачем автор предлагает анализировать на уровне CPU если там и на уровне C++ видно что большая часть времени уйдет на работу с памятью, а не на ЕДИНСТВЕННУЮ математическую операцию. Во-вторых, задача решена оптимально потому что современный компилятор С++ проведет векторизацию циклов и сделает оптимальный код с 128 битным доступом к памяти и использованием SSE регистров. Поэтому если что то в этом коде и не оптимально, так это постановка задачи, а не ее реализация программистом. И какое это имеет отношение к смыслу статьи непонятно. А приложение заметок жрет столько памяти и медленно работает не потому что кто то написал медленный код на С++, а наоборот...потому что кто то поленился написать это на С++ и использовал громозкие фреймворки на каком нибудь новомодном языке которые вместо программ на 10 строк сгенераровали 100 мегабайт кода и заняли пол гигабайта памяти.
Ну даже если 7 статей, все равно это мало чтобы быть первым в рейнинге.Причем разница между первым и вторым местом почти 1400...т.е. его рейтинг в 4 раза больше чем у следующего. Явно он "взломал" систему рейтинга Хабра и активно накручивал его себе. Пару дней назад я как раз оставил об этом комментарий к его статье про симуляцию экономики. Там было 56 комментариев из которых 80% в стиле какая хорошая статья и только 2 в которых люди отмечали нарушенную логику статьи.
А никого не удивляет что автор меньше полугода на Хабре,а уже в рейтинге ПЕРВЫЙ с 5ю статьями?
Это реальная новость про EDAC, а в статье автор прощается с 440BX и в выводах прямо врет что на 440BX новый линукс не запустится и что на обычных пользователей это не повлияет потому что чипсет старый, а не потому что на 440BX все продолжит работать, а убрали никому не нужный драйвер EDAC
То то и оно что EDAC для 440BX никому не нужен и удаление этого драйвера вообще ни на что не влияет в плане поддержки самого чипсета 440BX. А автор специально поставил такой заголовок, который вводит в заблуждение.
Статья кликбейтная и заголовок совершенно не корректный. Поддержку чипсета 440BX никуда не убрали и новый Linux 7.0 должен нормально продолжать на нем работать. А почему это важно в 2026 году? Да потому что 440BX и его предшественник 440FX это железо, которое по умолчанию эмулируется многими гипервизорами типа QEMU, и если новый Linux перестанет загружатся на этих чипсетах, то полетит куча виртуальных машин. Но автор статьи даже незнает об этом и пишет всякую хрень.