Как по мне, выделение хомяку /60 - уже достаточно щедро. Давать хомяку столько же адресов, сколько есть у Telegram - банальное разбазаривание.
Даже если операторам выделяют небольшой диапазон, то всё равно резервируют адреса под его расширение.
Вы констатируете какой-то сомнительный факт. Вот появилась у NASA /48 в 2013 . Стало не хватать и в 2016 они получили ещё одну /48. Как так? Почему не расширили до /44 /40 /32 ?
Адреса выделяются именно так, чтобы ни у кого не было затруднений в будущем.
Сколько лет существует IPv6? Какие, пусть даже теоретические, затруднения могут возникнуть у двухкомнатного хомяка с подсетью /60 ?
Такую же доработку софта требует внедрение IPv6. Что выберете?
Есть все основания полагать, что если разбазаривание 2000::/3 продолжиться текущими темпами, то в обозримом будущем адреса закончатся, а новые не смогут выделять по тем же причинам, по которым сейчас не выделяют адреса из 240.0.0.0/4. Типа много оборудования сможет поддерживать новую маршрутизацию.
продолжать пользоваться костылями в виде NAT или полностью решить проблему с нехваткой адресов?
В IPv6 костылей тоже хватает, а именно отсутствие upnp. И что лучше: настраивать файрвол (IPv6) или пробрасывать порты (IPv4) чтобы сделать доступными извне устройства локальной сети - пока не очевидно.
Хотите, чтобы адреса экономили и потом столкнулись снова с чем-то подобным, с чем столкнулись с IPv4?
Как экономия ресурсов может привести к истощению? Я за рациональное использование: если бы IPv4 не разбазаривали, их бы хватало и не пришлось бы костылить IPv6.
Сначала бездумно разбазаривали IPv4, далее встала проблема нехватки ресурсов и закостылили IPv6. Но политика разбазаривания продолжается - посмотрим, надолго ли хватит 2000::/3 и как скоро выделят следующий диапазон (~20% из выделенного уже израсходовано).
Под устройствами вы имели ввиду роутеры? - Мне сложно представить домашнего пользователя у которого дома более 3 роутеров. Если вы имели ввиду любые таки любые устройства после домашнего роутера, то как это должно работать? - Пользовательский роутер получает /64 PD и далее раздаёт эту подсеть всем устройствам в локальной сети. Функционала нарезания /56 подсети на /64 так, чтобы каждому устройству досталась своя собственная /64, в soho сегменте не наблюдается. Даже OpenWRT так не умеет.
Пфф.... Я думал что цифровой рубль может стать аналогом налички. А если это банковская система 2.0 где средства также могут быть заблокированы по бредовым причинам - смысла в ЦР не наблюдаю.
Что именно вы считаете "слишком многими телодвижениями"?
Всё то, что перечислено у вас в п 3.2: создание рендерера, конфигурирование пространства имён, создание экземпляра менеджера представлений, регистрация пространства имён моделей, определение модели и т.п. Ради чего всё это? Ради автоматического экранирования (которое может и не понадобится)? Какой порог входа в эти нагромождения абстракций?
А в случае с шаблонизатором ему как раз надо будет знать только его примитивный синтаксис.
Юзеркейс: верстальщик в гробу видал этот ваш SSR и желает всё отрендерить на Vue.js. И тут оказывается что использование {{ }} вызывает конфликт; прописать параметр nonce для <script> без того, чтобы лезть в вышестоящий код, невозможно; даже создание JSON объекта из всех переменных шаблона может привести к неожиданным сбоям:
The Blade templating is based on regular expressions and attempts to pass a complex expression to the directive may cause unexpected failures.
У меня одного чувство, что для банальной вставки переменных в шаблон как-то слишком уж много телодвижений? Особенно учитывая то, что верстальщик как бы не обязан обладать знаниями всех этих PHP премудростей.
Несмотря на кажущуюся мощь, под капотом вызов всех слушателей происходит весьма примитивным способом:
foreach ($listeners as $listener) {
if ($stoppable && $event->isPropagationStopped()) {
break;
}
$listener($event, $eventName, $this);
}
И если вдруг какой-то из слушателей умрёт в процессе выполнения, то остальные не дождутся своей очереди. Получаем весьма странную архитектуру: можно закодить 100500 слушателей, но нет никакой гарантии что все они отработают. Даже логов не останется.
Если отбросить свисто-перделку приоритета, то подобные события вполне можно реализовать всего одной глобальной функцией:
Чувак изобрёл какую-то деталь, которая позволяет запускать игры без ограничений. А потом решил эту деталь продать в составе консоли... И в чем тут принципиальная разница от кастомной прошивки?
Как по мне, выделение хомяку /60 - уже достаточно щедро. Давать хомяку столько же адресов, сколько есть у Telegram - банальное разбазаривание.
Вы констатируете какой-то сомнительный факт. Вот появилась у NASA /48 в 2013 . Стало не хватать и в 2016 они получили ещё одну /48. Как так? Почему не расширили до /44 /40 /32 ?
Сколько лет существует IPv6? Какие, пусть даже теоретические, затруднения могут возникнуть у двухкомнатного хомяка с подсетью /60 ?
Есть все основания полагать, что если разбазаривание 2000::/3 продолжиться текущими темпами, то в обозримом будущем адреса закончатся, а новые не смогут выделять по тем же причинам, по которым сейчас не выделяют адреса из 240.0.0.0/4. Типа много оборудования сможет поддерживать новую маршрутизацию.
В IPv6 костылей тоже хватает, а именно отсутствие upnp. И что лучше: настраивать файрвол (IPv6) или пробрасывать порты (IPv4) чтобы сделать доступными извне устройства локальной сети - пока не очевидно.
Юзеркейс, так понимаю, придумать не смогли?
Как экономия ресурсов может привести к истощению? Я за рациональное использование: если бы IPv4 не разбазаривали, их бы хватало и не пришлось бы костылить IPv6.
Тут нужны подробности: как в домашних условиях в рамках одной WiFi вы планируете раздать каждой лампочке свою собственную /64 подсеть?
Даже если предположить, что каждому контейнеру нужна своя /64, сколько таких контейнеров планируется дома у хомяка?
Откуда информация? Scope: Internet. Reserved for future use
Опишите, пожалуйста, юзеркейс когда хомяку может не хватить /56?
Сначала бездумно разбазаривали IPv4, далее встала проблема нехватки ресурсов и закостылили IPv6. Но политика разбазаривания продолжается - посмотрим, надолго ли хватит 2000::/3 и как скоро выделят следующий диапазон (~20% из выделенного уже израсходовано).
Даже интересно, какие такие могут появиться потребности у хомяка в двухкомнатной квартире?
А могут и не добавить, как это произошло с 240.0.0.0/4
Под устройствами вы имели ввиду роутеры? - Мне сложно представить домашнего пользователя у которого дома более 3 роутеров.
Если вы имели ввиду любые таки любые устройства после домашнего роутера, то как это должно работать? - Пользовательский роутер получает /64 PD и далее раздаёт эту подсеть всем устройствам в локальной сети. Функционала нарезания /56 подсети на /64 так, чтобы каждому устройству досталась своя собственная /64, в soho сегменте не наблюдается. Даже OpenWRT так не умеет.
Это какой-то urban legend. Можно ссылку на источник где бы рекомендовалось банить пользователей сразу подсетями, причем большими чем /64?
Можете привести хоть 1 реальную причину, зачем домашнему пользователю выдавать что-то большее, чем /60 ?
Если деньги на счёту - это уже не наличка. Классическую крипту можно майнить. Майнинг ЦР предусмотрен?
А справку от психиатра?
Пфф.... Я думал что цифровой рубль может стать аналогом налички. А если это банковская система 2.0 где средства также могут быть заблокированы по бредовым причинам - смысла в ЦР не наблюдаю.
А у цифрового рубля будет иммунитет от блокировок / заморозок по надуманным причинам? Можно ли его отнести к неблокируемвм активам?
mb_ucfirst уже завезли (в PHP 8.4).
А есть какие-то официальные ограничения по использованию домашней электроэнергии? А если электроэнергия своя (получаемая от солнца) - тоже нельзя?
Всё то, что перечислено у вас в п 3.2: создание рендерера, конфигурирование пространства имён, создание экземпляра менеджера представлений, регистрация пространства имён моделей, определение модели и т.п. Ради чего всё это? Ради автоматического экранирования (которое может и не понадобится)? Какой порог входа в эти нагромождения абстракций?
Юзеркейс: верстальщик в гробу видал этот ваш SSR и желает всё отрендерить на Vue.js. И тут оказывается что использование
{{ }}вызывает конфликт; прописать параметрnonceдля<script>без того, чтобы лезть в вышестоящий код, невозможно; даже создание JSON объекта из всех переменных шаблона может привести к неожиданным сбоям:У меня одного чувство, что для банальной вставки переменных в шаблон как-то слишком уж много телодвижений? Особенно учитывая то, что верстальщик как бы не обязан обладать знаниями всех этих PHP премудростей.
Несмотря на кажущуюся мощь, под капотом вызов всех слушателей происходит весьма примитивным способом:
И если вдруг какой-то из слушателей умрёт в процессе выполнения, то остальные не дождутся своей очереди. Получаем весьма странную архитектуру: можно закодить 100500 слушателей, но нет никакой гарантии что все они отработают. Даже логов не останется.
Если отбросить свисто-перделку приоритета, то подобные события вполне можно реализовать всего одной глобальной функцией:
И чем оно хуже?
Чувак изобрёл какую-то деталь, которая позволяет запускать игры без ограничений. А потом решил эту деталь продать в составе консоли... И в чем тут принципиальная разница от кастомной прошивки?