Ну а у в случае если вообще ничего не писать, так и вообще поддерживать легко...нет кода - нет проблем. Но мы же все таки пишем код и используем интерфейсы. Хотите реальный пример - есть у меня небольшой проект на 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 перестанет загружатся на этих чипсетах, то полетит куча виртуальных машин. Но автор статьи даже незнает об этом и пишет всякую хрень.
Естественно, так как я был уже достаточно взрослым в те годы и знал, что все ВУЗы обязывают брать шефство над кружками и специализированными школами.
Естественно где? В вашем дурдоме или где? Для меня совершенно не естественно, что человек из Львова ни разу не бывавшый в Волжском спорит с Волжанином о доступности компьютеров для школьников до 1985 года. Если у вас нет фактов, то все ваши подростковые размышления оставте при себе.
Вы явно не могли знать, какими путями можно было практически заниматься программированием в конце 70-х и начале 80-х.
Да, я незнаю как можно было заниматься программированием во Львове и никогда этого не писал, но я точно знаю как это было у нас и в отличии от вас никогда это не распространял на уровень страны или континента. Если у вас проблемы с пониманием русского, то читайте по несколько раз пока не поймете. Кроме того, прочитайте еще раз статью и особенно циферки начинающиеся с 19...Странно, что такой программист не может понять что 1976-1991 это не только о "конце 70-х и начале 80-х".
А Наири-2 и Наири-К появились в 1966 году, к концу 70-х уже считались устаревшими, что и обеспечило доступ к ним школьникам.
Похоже у вас большие проблемы с пониманием русского. Вот я вижу в статье упоминание Агата, но совершенно не вижу Наири. Я рад что у вас в школе был доступ к Наири и я этого не оспариваю, и я совершенно не понимаю почему вы спорите со мной что в Волжском такого небыло и первый класс информатики появился только в 1985 году, когда производство Агатов наладили на местном заводе ЭВТ и подшевный завод решил подарить компьютерный класс школе.
У Вас в Волжском были филиалы трёх университетов. И очень странно, на уровне откровенной демагогии, выглядит сравнение доступности образования и сливочного масла в СССР.
Жители Волжского могут толко позавидовать вашей осведомленности о нашей жизни в 80х годах, но я не могу припомнить ничего кроме формального присутствия ВГУ что совершенно ни как не связанно с доступностью компьютеров в это время. Даже в МГТУ им. Баумана куда я поступил в 1992 году это был только третий год набора на ИУ-7 (Программное обеспечение ЭВМ и информационные технологии) и доступ к компьютерам вне классных занятий был только по спец пропускам от декана. О каких школьниках в университетах может идти речь? Да, были отдельные очаги распространения обучения школьников программированию, но они держались на личном этнузиазме отдельных людей, а не на системе образования СССР. Даже в нашем городе все компьютерные классы были подарками заводов подшефным школам, но учить программированию было некому.
Я имел ввиду 1985+ года. Так я на это и обратил внимание.
Ну так и в статье разговор идет примерно об этом времени, потому что Агат появился только 1984 году. Тем более что комментарий на который я отвечал упоминает разработку игр школьниками и сразу переходит к персональным PC, так что явно разговор шел даже не про конец 80х, а про начало 90х.
Реально. Если не в своём городе, то хотя бы в областном центре.
Ну конечно же вам лучше знать что было реально, а что нет в моем городе и вокруг. Наверное именно поэтому у нас было так много школьников увлеченных компьютерами, что именно я, а не тысячи других увлеченных, 5 лет (начиная с 7 класса) был городским (город с населением 400 тыс) победителем олимпиады по программированию среди старшеклассников. Остальные наверное просто застряли в автобусе по пути в Волгоград где все было, но нам просто забыли об этом рассказать, а вот на Украину все сообщили и они уж точно знают что у нас все было. P.S. А еще, москвичи утверждают что колбасу можно было купить в магазине, а у нас в Волгоградской области сливочное масло было по талонам с середины 70х годов.
Судя по его описанию очень легко - он эмулирует UART через USB и дальше используйте как обычный модуль с UART портом. Для MCU он не очень подходит потому что проще взять модуль с нормальным UART портом, а для линукса как раз то что надо.
Ну а у в случае если вообще ничего не писать, так и вообще поддерживать легко...нет кода - нет проблем. Но мы же все таки пишем код и используем интерфейсы. Хотите реальный пример - есть у меня небольшой проект на 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 перестанет загружатся на этих чипсетах, то полетит куча виртуальных машин. Но автор статьи даже незнает об этом и пишет всякую хрень.
Естественно где? В вашем дурдоме или где? Для меня совершенно не естественно, что человек из Львова ни разу не бывавшый в Волжском спорит с Волжанином о доступности компьютеров для школьников до 1985 года. Если у вас нет фактов, то все ваши подростковые размышления оставте при себе.
Да, я незнаю как можно было заниматься программированием во Львове и никогда этого не писал, но я точно знаю как это было у нас и в отличии от вас никогда это не распространял на уровень страны или континента. Если у вас проблемы с пониманием русского, то читайте по несколько раз пока не поймете. Кроме того, прочитайте еще раз статью и особенно циферки начинающиеся с 19...Странно, что такой программист не может понять что 1976-1991 это не только о "конце 70-х и начале 80-х".
Похоже у вас большие проблемы с пониманием русского. Вот я вижу в статье упоминание Агата, но совершенно не вижу Наири. Я рад что у вас в школе был доступ к Наири и я этого не оспариваю, и я совершенно не понимаю почему вы спорите со мной что в Волжском такого небыло и первый класс информатики появился только в 1985 году, когда производство Агатов наладили на местном заводе ЭВТ и подшевный завод решил подарить компьютерный класс школе.
Жители Волжского могут толко позавидовать вашей осведомленности о нашей жизни в 80х годах, но я не могу припомнить ничего кроме формального присутствия ВГУ что совершенно ни как не связанно с доступностью компьютеров в это время. Даже в МГТУ им. Баумана куда я поступил в 1992 году это был только третий год набора на ИУ-7 (Программное обеспечение ЭВМ и информационные технологии) и доступ к компьютерам вне классных занятий был только по спец пропускам от декана. О каких школьниках в университетах может идти речь? Да, были отдельные очаги распространения обучения школьников программированию, но они держались на личном этнузиазме отдельных людей, а не на системе образования СССР. Даже в нашем городе все компьютерные классы были подарками заводов подшефным школам, но учить программированию было некому.
Ну так и в статье разговор идет примерно об этом времени, потому что Агат появился только 1984 году. Тем более что комментарий на который я отвечал упоминает разработку игр школьниками и сразу переходит к персональным PC, так что явно разговор шел даже не про конец 80х, а про начало 90х.
Ну конечно же вам лучше знать что было реально, а что нет в моем городе и вокруг. Наверное именно поэтому у нас было так много школьников увлеченных компьютерами, что именно я, а не тысячи других увлеченных, 5 лет (начиная с 7 класса) был городским (город с населением 400 тыс) победителем олимпиады по программированию среди старшеклассников. Остальные наверное просто застряли в автобусе по пути в Волгоград где все было, но нам просто забыли об этом рассказать, а вот на Украину все сообщили и они уж точно знают что у нас все было. P.S. А еще, москвичи утверждают что колбасу можно было купить в магазине, а у нас в Волгоградской области сливочное масло было по талонам с середины 70х годов.
Я имел ввиду 1985+ года, а до этого времени у нас в городе школьнику вообще было не реально получить доступ хоть к какой то ЭВМ..
Судя по его описанию очень легко - он эмулирует UART через USB и дальше используйте как обычный модуль с UART портом. Для MCU он не очень подходит потому что проще взять модуль с нормальным UART портом, а для линукса как раз то что надо.