Ну где я такое писал? Переписать придется, но эти изменения минимальные. Их легко реализовать, их легко протестировать. Изменения всех конфигов легко автоматизировать.
Если сравнивать сколько придется сделать для IPv6 - это вообще ни о чём.
Ну, обычно лозунг "никакой свободы врагам свободы" применяют в дискуссиях вида "вы тут говорите про свободу слова, а сами нам запрещаете высказать мнение, суть которого запретить высказывать мнение кому-то ещё".
И как бы контраргумент в том, чтобы дать желающим прочувствовать на себе последствия того, к чему они призывают.
А дальше схема очень простая: кого больше, тот и прав) В этом смысле ни левая, ни правая идеологии не отличаются. Побеждает тот, у кого больше власти.
Мой комментарий был лишь про бессмысленность риторики построенной на "никакой свободы врагам свободы", ведь принцип чрезвычайно самосогласован.
Так, я нигде не говорю про 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 будет никакой)
Прибыльность? Ну, т.е. конечно прекрасно когда на альтруистических началах проект некоторое время держится, но очевидно это не успех)
Переделывать в плане логики развертывания и настройки. Возможно стоило мне чуть больше мысль развернуть.
Ну где я такое писал? Переписать придется, но эти изменения минимальные. Их легко реализовать, их легко протестировать. Изменения всех конфигов легко автоматизировать.
Если сравнивать сколько придется сделать для IPv6 - это вообще ни о чём.
Ну, обычно лозунг "никакой свободы врагам свободы" применяют в дискуссиях вида "вы тут говорите про свободу слова, а сами нам запрещаете высказать мнение, суть которого запретить высказывать мнение кому-то ещё".
И как бы контраргумент в том, чтобы дать желающим прочувствовать на себе последствия того, к чему они призывают.
А дальше схема очень простая: кого больше, тот и прав) В этом смысле ни левая, ни правая идеологии не отличаются. Побеждает тот, у кого больше власти.
Мой комментарий был лишь про бессмысленность риторики построенной на "никакой свободы врагам свободы", ведь принцип чрезвычайно самосогласован.
Это очень логичный принцип.
Кто-то выступает, что существует признак, при котором надо дискриминировать людей
Нет проблем. Принимаем эту логику.
Объявляем, что люди выступающие против свободы - должны быть дискриминированв
Примпнчем против врагов свободы - правило несвободы
Всё вернулось на круги своя
Так что "никакой свободы врагам свободы" чрезвычайно логичный принцип, мы просто применяем предложение "врагом свободы" на них самих.
Я вроде и не говорил, что существует. Но 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 можно зеркалировать и поднимать свои
Ах если бы) ещё надо эту библиотеку в свою систему сборки вкорячить)