Так, я нигде не говорю про IPv8. Я говорю об "IPv4 с более длинным адресом". Можно назвать это хоть IPv4.1.
IPv8 не нужен по той же причине, по которой не нужен IPv6 - он предоставляет фичи, о которых никто не просил и логику, которую никто не знает. Нужен просто IPv4 с более длинными адресами. Ни больше, ни меньше
Ничего подобного. IPv6 фундаментально другой протокол. С другой логикой адресации, с другой логикой резолва имён и полученния адресов на интерфейсах.
Добавив поддержку новых DNS записей и увеличить размер адреса несравненно более простая задача, чем реализация и отладка нового способа общения с сетью
И надо ещё всех сетевиков мира научить IPv6. И домохозяек. И много кого. Научить полностью новой логике значительно сложнее, чем просто научить что в адресе теперь, ну, скажем, 6-8 октетов)
Ну, это конечно так, но есть разница) Дополнительный октет в адресе не вводит дополнительных видов адресов, не меняет логику работы ARP и DHCP. Оставляет широковещательнын адреса, фрагментацию пакетов и прочее.
Т.е. формально это новый протокол, но не надо ничего переделывать и все будет просто работать и настраиваться привычным образом. Да, IPv4 не идеален и имеет кучу проблем на уровне протокольной логики, но все эти проблемы так или иначе уже решены в оборудовании. Всё что нужно - это побольше октетов в адресе и всё.
Минимальные затраты на переобучение людей и перенастройку оборудования. Минимальные затраты на правку логики в прошивках. Минимальные изменения в UI интерфейсов. И, что главное, ноль новых уязвимостей из-за неверной конфигурации.
Я не пишу ничего не Rust, но так уж вышло, что более или менее его знаю.
В чем проблема с unsafe? Ничего страшного в unsafe нет)
В сущности, это просто маркер мест в коде, которые могут покорраптить память и просто упрощают отладку этого класса проблем.
Почти любой unsafe можно спрятать за safe API, просто обеспечив гарантию инвариантов, делающих unsafe - безопасным) Это же главная задача и смысл unsafe блоков)
Что бездоказательного в том, что доверяя владение другому лицу, ты больше ничего не можешь гарантировать? Внешние ссылки склонны умирать, устаревать и просто бесследно исчезать
Я знаю, почему так делать не надо) Так уж вышло, что я и сам немало времени провел в работе над этими бедами с зависимостями, я бы может и написал даже об этом статью, если бы она не сводилась к тому, что собственные велосипеды неизбежны, а чужие велосипеды вам не подойдут и зря вы читали эту статью)
Комментарием я просто хотел сказать, что выбор небольшой. Хранить рецепты централизованно больно, а распределенно нельзя, ибо результат будет эквивалентен отсутствию пакетного менеджера.
Если их не собирать в одном месте, то и гарантий собираемости не обеспечить. А если не обеспечить, то и зачем оно тогда нужно, просто банально проще идти старым путём
Выбор-то небольшой) Мы или пилим централизованно и одинаково, или оставляем всё как было)
Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)
Кто забыл? Я буквально вторым делом пишу "man <cmd>" при любой непонятке) Первым делом я спрашиваю ИИ :) Но они так часто врут и выдумывают флаги, что man всё ещё мой лучший друг)
Я сам лично писал на asm ещё 3 года назад, но я был такой один на всю компанию в 1500 человек. Ну, позже мне выдали ещё джуна и нас стало двое) Но в итоге вы вернулись к интринсикам, т.к. поддержка asm слишком неудобна оказалась.
И я пока не вижу зачем эти 5% продолжают писать на asm)
Я не припомню где бы си не справился) В этом мире даже самая распоследняя ручка имеет компилятор на Си)
Я помнится какой-то температурный датчик программировал, у него даже ассемблера не было, а компилятор на Си был) Компилировал он сразу в unsigned char массив, который ты хоть азбукой морзе загоняй по SPI внутрь этого контроллера)
Я вроде и не говорил, что существует. Но 100% наблюдаемых жалоб на IPv4 - это нехватка адресов.
Но вместо нормального и простого решения, происходит типичная разработка комитетом и появляются всякие IPv6 и IPv8
Так, я нигде не говорю про IPv8. Я говорю об "IPv4 с более длинным адресом". Можно назвать это хоть IPv4.1.
IPv8 не нужен по той же причине, по которой не нужен IPv6 - он предоставляет фичи, о которых никто не просил и логику, которую никто не знает. Нужен просто IPv4 с более длинными адресами. Ни больше, ни меньше
Под домохозяйками я подразумеваю всех, кто хоть раз бытовой роутер настраивал.
Переписать весь софт для поддержки более широких адресов ЗНАЧИТЕЛЬНО проще, чем переписать весь софт для поддержки новой логики. Это очевидно.
Ничего подобного. IPv6 фундаментально другой протокол. С другой логикой адресации, с другой логикой резолва имён и полученния адресов на интерфейсах.
Добавив поддержку новых DNS записей и увеличить размер адреса несравненно более простая задача, чем реализация и отладка нового способа общения с сетью
И надо ещё всех сетевиков мира научить IPv6. И домохозяек. И много кого. Научить полностью новой логике значительно сложнее, чем просто научить что в адресе теперь, ну, скажем, 6-8 октетов)
Ну, это конечно так, но есть разница) Дополнительный октет в адресе не вводит дополнительных видов адресов, не меняет логику работы ARP и DHCP. Оставляет широковещательнын адреса, фрагментацию пакетов и прочее.
Т.е. формально это новый протокол, но не надо ничего переделывать и все будет просто работать и настраиваться привычным образом. Да, IPv4 не идеален и имеет кучу проблем на уровне протокольной логики, но все эти проблемы так или иначе уже решены в оборудовании. Всё что нужно - это побольше октетов в адресе и всё.
Минимальные затраты на переобучение людей и перенастройку оборудования. Минимальные затраты на правку логики в прошивках. Минимальные изменения в UI интерфейсов. И, что главное, ноль новых уязвимостей из-за неверной конфигурации.
Да никому не нужен IPv6. Всем нужен IPv4 с дополнительными адресами. Всё)
C++ Core Guidelines: просто существуют
Я не пишу ничего не Rust, но так уж вышло, что более или менее его знаю.
В чем проблема с unsafe? Ничего страшного в unsafe нет)
В сущности, это просто маркер мест в коде, которые могут покорраптить память и просто упрощают отладку этого класса проблем.
Почти любой unsafe можно спрятать за safe API, просто обеспечив гарантию инвариантов, делающих unsafe - безопасным) Это же главная задача и смысл unsafe блоков)
Что бездоказательного в том, что доверяя владение другому лицу, ты больше ничего не можешь гарантировать? Внешние ссылки склонны умирать, устаревать и просто бесследно исчезать
Чем плох debian 13? Там свежие достаточно пакеты, свежее 24.04 убунты) Можно род "мятным соусом", есть Mint основанный на Debian
Я знаю, почему так делать не надо) Так уж вышло, что я и сам немало времени провел в работе над этими бедами с зависимостями, я бы может и написал даже об этом статью, если бы она не сводилась к тому, что собственные велосипеды неизбежны, а чужие велосипеды вам не подойдут и зря вы читали эту статью)
Комментарием я просто хотел сказать, что выбор небольшой. Хранить рецепты централизованно больно, а распределенно нельзя, ибо результат будет эквивалентен отсутствию пакетного менеджера.
Если их не собирать в одном месте, то и гарантий собираемости не обеспечить. А если не обеспечить, то и зачем оно тогда нужно, просто банально проще идти старым путём
Выбор-то небольшой) Мы или пилим централизованно и одинаково, или оставляем всё как было)
Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)
Но... Conan так умеет. А если чего-то не умеет, он довольно легко расширяется (ибо питончик).
Рецепты хранятся вместе с кодом, registry можно зеркалировать и поднимать свои
Ах если бы) ещё надо эту библиотеку в свою систему сборки вкорячить)
И слава богу! И пускай никогда не будет! Худшая фича С++! Сколько от неё страданий)
Сделали бы перегрузки допустимыми только для операторов - цены бы им не было.
И зачем они?
В том виде в котором она есть в С++ - нет. Но процедурные макросы ничем не хуже, а даже лучше.
Ну и С++26 ещё не приняли, в значит и в плюсах её тоже нет.
Кто забыл? Я буквально вторым делом пишу "man <cmd>" при любой непонятке) Первым делом я спрашиваю ИИ :) Но они так часто врут и выдумывают флаги, что man всё ещё мой лучший друг)
Я сам лично писал на asm ещё 3 года назад, но я был такой один на всю компанию в 1500 человек. Ну, позже мне выдали ещё джуна и нас стало двое) Но в итоге вы вернулись к интринсикам, т.к. поддержка asm слишком неудобна оказалась.
И я пока не вижу зачем эти 5% продолжают писать на asm)
Я не спорю, что всегда есть такое местечко, где ну вот вообще никак, хоть убей, но 300 строчек на асме надо написать)
Но сколько таких мест? И сколько надо программистов для них? И не справится ли LLM с этой задачей?)
Вопросы для меня не имеющие очевидного ответа, я просто не живу в мире настолько низкоуровневого программирования и не знаю никого, кто бы жил
Я не припомню где бы си не справился) В этом мире даже самая распоследняя ручка имеет компилятор на Си)
Я помнится какой-то температурный датчик программировал, у него даже ассемблера не было, а компилятор на Си был) Компилировал он сразу в unsigned char массив, который ты хоть азбукой морзе загоняй по SPI внутрь этого контроллера)