Комментируем все строки интерфейса по умолчанию ens3
А приведёт ли комментирование к тому, что хостинг перестанет принимать пакеты на этот IP-адрес и перенаправлять их в VDS? Если нет, то утверждение «это исключает какое-либо внешнее воздействие» становится неверным
Ну например в бэкендах веб-сайтов тяжёлых вычислений особо нету, а тормоза обычно возникают из-за этой самой врождённой тормознутости питона. Если JIT может помочь их ускорить, это было бы классно
RSS-Bridge заявляет поддержку Дзена (и ещё с полтысячи других сервисов). Если лень поднимать свой инстанс, можно использовать какой-нибудь чужой публичный (но ссылок специально не дам, чтобы случайно не захабраэффектить)
То есть вы намекаете, что feelamee несёт чушь и его фраза «В плюсах сделаете { }» не имеет смысла? Ну, вы там сами друг с другом разберитесь тогда, я просто мимо проходил)
Принципиальное отличие раста от сишечек в том, что для написания небезопасного кода нужно СПЕЦИАЛЬНО, находясь в здравом уме и твёрдой памяти, приложить усилия и осознанно написать в коде слово «unsafe» — а «токсичное» Rust-сообщество ещё и заставит написать рядом «SAFETY:» комментарий с доказательством, почему этот unsafe не нарушит безопасность.
В сишечках можно написать небезопасный код СЛУЧАЙНО — по недосмотру, по невнимательности, по забывчивости, по неаккуратному рефакторингу. Так и появляется большинство багов и уязвимостей от простых сегфолтов до heartbleed.
Так всё-таки что будет, если СЛУЧАЙНО не выспаться и забыть "сделать { }"?
Ну, от языка это уже не зависит, в сишечках будет то же самое, только сишечный компилятор уже не проконтролирует корректность кода.
Если очень хочется, можно проверить длину динамического массива один раз перед работой с ним, тогда, как описано в том посте, компилятор скорее всего сможет понять, что проверка уже выполнена, и свои проверки добавлять не будет.
Если очень-очень хочется, можно использовать unsafe-методы для обращения к массиву без проверки — только вот скорее всего не нужно
это защита стоит процессорного времени, причем при каждом обращении к массиву.
Если компилятор сможет убедиться, что код в принципе не может выйти за пределы массива, то рантаймовые проверки будут выкинуты за ненадобностью. Вот целый пост был об этом https://habr.com/ru/companies/otus/articles/718012/
Как я уже написал, HttpOnly-куку прочитать не получится, поэтому украсть refresh-токен через XSS не получится (только временно попользоваться в рамках доступности XSS). И CSRF для refresh-токена, кажется, тоже неприменим: даже если злоумышленник сможет каким-то образом отправить refresh-запрос со стороннего сайта, прочитать ответ с присланным access-токеном он не сможет уже никак — браузер не даст доступ, если вы сами не налажаете в настройках CORS
В нём есть трейты, для многих задач этого хватает
К счастью, до создателей Go дошло, что писать тонны бойлерплейта на каждый тип это на самом деле сложнее чем дженерики)
(осталось только с убогим
if err != nilчто-нибудь сделать, и получится нормальный язык)Что значит выбросили, вот они сразу же в хелловорлде торчат https://go.dev/tour/basics/4
Сразу видно новичка, который не в курсе про аннотации типов
В тех областях, где питон обычно используется, это не имеет почти никакого значения
А вы не допускаете вариант, что расширение было (или стало) вредоносным?
От такого по идее должен спасать userns-remap
У
docker execесть опция--userА приведёт ли комментирование к тому, что хостинг перестанет принимать пакеты на этот IP-адрес и перенаправлять их в VDS? Если нет, то утверждение «это исключает какое-либо внешнее воздействие» становится неверным
Ну например в бэкендах веб-сайтов тяжёлых вычислений особо нету, а тормоза обычно возникают из-за этой самой врождённой тормознутости питона. Если JIT может помочь их ускорить, это было бы классно
Во многих линуксах по умолчанию уже включен zswap, и включать zram скорее всего не нужно (а включать его одновременно с zswap вообще вредно)
Ну как минимум можно посмотреть список роутов в том же rsshub (правда, не все из них именно что перестали, но некоторые наверно всё-таки переставшие)
А из переставших, на что нарвался лично я — ИА «Панорама» )
RSS-Bridge заявляет поддержку Дзена (и ещё с полтысячи других сервисов). Если лень поднимать свой инстанс, можно использовать какой-нибудь чужой публичный (но ссылок специально не дам, чтобы случайно не захабраэффектить)
«какой-то недотепа» в принципе не станет использовать unsafe в своём Rust-коде, потому что нафиг оно ему надо?
Вы тут сами unsafe зачем-то приплели, хотя вас всего лишь про «сделать { }» спросили
То есть вы намекаете, что feelamee несёт чушь и его фраза «В плюсах сделаете { }» не имеет смысла? Ну, вы там сами друг с другом разберитесь тогда, я просто мимо проходил)
Нельзя.
Принципиальное отличие раста от сишечек в том, что для написания небезопасного кода нужно СПЕЦИАЛЬНО, находясь в здравом уме и твёрдой памяти, приложить усилия и осознанно написать в коде слово «unsafe» — а «токсичное» Rust-сообщество ещё и заставит написать рядом «SAFETY:» комментарий с доказательством, почему этот unsafe не нарушит безопасность.
В сишечках можно написать небезопасный код СЛУЧАЙНО — по недосмотру, по невнимательности, по забывчивости, по неаккуратному рефакторингу. Так и появляется большинство багов и уязвимостей от простых сегфолтов до heartbleed.
Так всё-таки что будет, если СЛУЧАЙНО не выспаться и забыть "сделать { }"?
Не скомпилится, компилятор заявит, что значение не живёт достаточно долго
Ну, от языка это уже не зависит, в сишечках будет то же самое, только сишечный компилятор уже не проконтролирует корректность кода.
Если очень хочется, можно проверить длину динамического массива один раз перед работой с ним, тогда, как описано в том посте, компилятор скорее всего сможет понять, что проверка уже выполнена, и свои проверки добавлять не будет.
Если очень-очень хочется, можно использовать unsafe-методы для обращения к массиву без проверки — только вот скорее всего не нужно
Дыру в Rust-компиляторе найдут и исправят, фикс автоматически применится для всех Rust-программ, собранных новым компилятором.
Миллионы выходов за пределы массива, use-after-free и прочих UB в миллионах сишных программ не найдут и не исправят никогда.
Если компилятор сможет убедиться, что код в принципе не может выйти за пределы массива, то рантаймовые проверки будут выкинуты за ненадобностью. Вот целый пост был об этом https://habr.com/ru/companies/otus/articles/718012/
Как я уже написал, HttpOnly-куку прочитать не получится, поэтому украсть refresh-токен через XSS не получится (только временно попользоваться в рамках доступности XSS). И CSRF для refresh-токена, кажется, тоже неприменим: даже если злоумышленник сможет каким-то образом отправить refresh-запрос со стороннего сайта, прочитать ответ с присланным access-токеном он не сможет уже никак — браузер не даст доступ, если вы сами не налажаете в настройках CORS