Провайдеру и не надо его маршрутизировать, бытовой роутер подключен к нему напрямую, провайдер может просто взять и отправить пакет непосредственно в Ethernet-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
Если я попрошу провайдера попасть на 192.168.0.168 даже со шлюза, то как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?
А что должно помешать пролезть? Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168, и я не вижу ничего, что остановило бы роутер от совершения такого действия (собственно, его ничего и не останавливает — повторюсь ещё раз, я ПРОВЕРЯЛ описанное вами действие на практике)
Если «снаружи» это провайдер — попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки, и при отключенном на роутере межсетевом экране вы вполне обнаружите эти пакеты в своей локальной сети
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки (я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет), а даже если каким-то чудом смогут, то их отфильтрует межсетевой экран провайдера (а попросить провайдера отключить его собственный межсетевой экран вы уже вряд ли сможете)
Защищает не роутер, а межсетевой экран. Если его отключить или криво настроить, роутер всё отроутит и даст доступ к лампочкам даже без проброса портов — я проверял это на практике
То, что в языке программирования этого нет и нужна сторонняя утилита — уже проблема языка программирования
То, что запрет паник возможен (согласно вашим утверждениям) только с добавлением обработки несуществующих ошибок — тоже проблема языка программирования, я не желаю тратить кучу своего времени на обработку того, что не может произойти даже теоретически
Я хочу написать vec[idx] так, чтобы компилятор подтвердил, что я доказал корректность индекса и паники здесь быть не может, или чтобы компилятор сказал мне, что ничего не доказалось и паника возможна — ближе всего к этому подходит крейт no_panic, но он тоже кривой и имеет ложноположительные срабатывания (потому что работает через костыли)
И он бесполезен, потому что вынуждает перегружать код обработкой несуществующих ошибок и всё равно не способен отлавливать паники из сторонних библиотек
Собственно в статье уже упоминается один раздражающий меня пример — получение элемента массива по индексу (без специальных функций вроде get) — программист может захотеть использовать это, когда уверен, что индекс корректный и нет смысла перегружать код обработкой ошибок, которые никогда не случатся
С одной стороны, программист может доказать компилятору, что индекс корректный (например, проверив длину массива) — компилятор учтёт это и сгенерирует код, который никогда не будет выдавать ошибок (собственно в статье это показано)
С другой стороны, Rust не заставляет программиста доказывать это, или он может накосячить в доказательстве — в таком случае компилятор добавит свою проверку корректности индекса, которая может выплюнуть панику
И проблема тут в том, что программист НИКАК не может узнать, будет ли тут выплёвываться паника или нет, и он никак не может запретить компиляцию кода с паниками, отчего у меня сильно пригорало, когда я пытался написать код без паник
Вообще, к unwrap это тоже отчасти относится, потому что он может оказаться спрятан где-то глубоко внутри сторонней библиотеки — и программист об этом никак не узнает, пока не прочитает код этой самой библиотеки (или документацию, если создатель библиотеки оказался достаточно ответственный и упомянул наличие unwrap)
Если программист целенаправленно захотел заставить программу упасть явным написанием unwrap — это безопасно по всем параметрам, потому что всё работает в точности как задумано программистом и не имеет незапланированных побочных эффектов
Вы бы лучше вспомнили про паники, которые могут вываливаться в неожиданных местах — вот это реальная проблема Rust, на которую даже Линус ругался
Во-первых, речь тут не про unwrap, а во-вторых, всё равно не должен, потому что падение не является небезопасным для памяти событием (самое страшное, что может случиться, это утечка, но Rust на данный момент считает утечки безопасными)
После того, как я зарепортил в ejabberd крах, вызванный использованием строки там, где должно быть число — я считаю эрланг ненадёжной хренью. Блин, даже питон уже научили отлавливать такие детские ошибки
а так ли велика выгода за те ограничения, которые вводятся Растом?
После того, как мне неоднократно приходилось дебажить утечки в сишечных программах, ответственно заявляю — да, достаточно велика, «prevents most leaks» всё ещё намного лучше чем «prevents no leaks»
100% кода Rust зависят от библиотек, которые используют unsafe, потому что стандартная библиотека
Одна из фишек unsafe в том, что при поломке он сужает круг подозреваемых. Не надо вычитывать тонны кода почти всей программы, достаточно пробежаться по unsafe-фрагментам, которые выполнялись перед поломкой
Так что тут надо не заявлять категоричное «используют unsafe хотя бы один раз», а посчитать, какой конкретно процент кода является unsafe (без учёта и с учётом стандартной библиотеки), и этот процент примерно покажет, на сколько проще отлаживать поломки по сравнению с условными сишечками
Ради интереса выполнил для default и для всех интерфейсов на своём кинетике — получил сплошные нули. Это плохо?)
Провайдеру и не надо его маршрутизировать, бытовой роутер подключен к нему напрямую, провайдер может просто взять и отправить пакет непосредственно в Ethernet-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
Прекрасно понимаю, но это всё ещё не делает фразу «защита NAT» корректной
Ну то есть вся «защита NAT» держится лишь на вере в отсутствие заинтересованных злых людей ¯\_(ツ)_/¯
Это, конечно, хорошо работает на практике и я ничего против такого общественного блага не имею, но называть это «защитой», пожалуйста, не надо
А что должно помешать пролезть? Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168, и я не вижу ничего, что остановило бы роутер от совершения такого действия (собственно, его ничего и не останавливает — повторюсь ещё раз, я ПРОВЕРЯЛ описанное вами действие на практике)
Если злые люди завелись у провайдера — никакой NAT уже не поможет
До вашего роутера они вообще не дойдут, потому что не смогут найти маршрут, ваш роутер не имеет никакого отношения к этой защите
Для начала определитесь, что такое «снаружи»
Если «снаружи» это провайдер — попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки, и при отключенном на роутере межсетевом экране вы вполне обнаружите эти пакеты в своей локальной сети
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки (я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет), а даже если каким-то чудом смогут, то их отфильтрует межсетевой экран провайдера (а попросить провайдера отключить его собственный межсетевой экран вы уже вряд ли сможете)
Защищает не роутер, а межсетевой экран. Если его отключить или криво настроить, роутер всё отроутит и даст доступ к лампочкам даже без проброса портов — я проверял это на практике
Звучит не очень круто для языка, стремящегося быть blazingly fast )
То, что в языке программирования этого нет и нужна сторонняя утилита — уже проблема языка программирования
То, что запрет паник возможен (согласно вашим утверждениям) только с добавлением обработки несуществующих ошибок — тоже проблема языка программирования, я не желаю тратить кучу своего времени на обработку того, что не может произойти даже теоретически
Я хочу написать
vec[idx]так, чтобы компилятор подтвердил, что я доказал корректность индекса и паники здесь быть не может, или чтобы компилятор сказал мне, что ничего не доказалось и паника возможна — ближе всего к этому подходит крейт no_panic, но он тоже кривой и имеет ложноположительные срабатывания (потому что работает через костыли)И он бесполезен, потому что вынуждает перегружать код обработкой несуществующих ошибок и всё равно не способен отлавливать паники из сторонних библиотек
Собственно в статье уже упоминается один раздражающий меня пример — получение элемента массива по индексу (без специальных функций вроде get) — программист может захотеть использовать это, когда уверен, что индекс корректный и нет смысла перегружать код обработкой ошибок, которые никогда не случатся
С одной стороны, программист может доказать компилятору, что индекс корректный (например, проверив длину массива) — компилятор учтёт это и сгенерирует код, который никогда не будет выдавать ошибок (собственно в статье это показано)
С другой стороны, Rust не заставляет программиста доказывать это, или он может накосячить в доказательстве — в таком случае компилятор добавит свою проверку корректности индекса, которая может выплюнуть панику
И проблема тут в том, что программист НИКАК не может узнать, будет ли тут выплёвываться паника или нет, и он никак не может запретить компиляцию кода с паниками, отчего у меня сильно пригорало, когда я пытался написать код без паник
Вообще, к unwrap это тоже отчасти относится, потому что он может оказаться спрятан где-то глубоко внутри сторонней библиотеки — и программист об этом никак не узнает, пока не прочитает код этой самой библиотеки (или документацию, если создатель библиотеки оказался достаточно ответственный и упомянул наличие unwrap)
Если программист целенаправленно захотел заставить программу упасть явным написанием unwrap — это безопасно по всем параметрам, потому что всё работает в точности как задумано программистом и не имеет незапланированных побочных эффектов
Вы бы лучше вспомнили про паники, которые могут вываливаться в неожиданных местах — вот это реальная проблема Rust, на которую даже Линус ругался
Во-первых, речь тут не про unwrap, а во-вторых, всё равно не должен, потому что падение не является небезопасным для памяти событием (самое страшное, что может случиться, это утечка, но Rust на данный момент считает утечки безопасными)
После того, как я зарепортил в ejabberd крах, вызванный использованием строки там, где должно быть число — я считаю эрланг ненадёжной хренью. Блин, даже питон уже научили отлавливать такие детские ошибки
Если программист хочет падать, он должен явно прописать намерение упасть в коде, иначе о какой надёжности вообще может идти речь
После того, как мне неоднократно приходилось дебажить утечки в сишечных программах, ответственно заявляю — да, достаточно велика, «prevents most leaks» всё ещё намного лучше чем «prevents no leaks»
100% кода Rust зависят от библиотек, которые используют unsafe, потому что стандартная библиотека
Одна из фишек unsafe в том, что при поломке он сужает круг подозреваемых. Не надо вычитывать тонны кода почти всей программы, достаточно пробежаться по unsafe-фрагментам, которые выполнялись перед поломкой
Так что тут надо не заявлять категоричное «используют unsafe хотя бы один раз», а посчитать, какой конкретно процент кода является unsafe (без учёта и с учётом стандартной библиотеки), и этот процент примерно покажет, на сколько проще отлаживать поломки по сравнению с условными сишечками