Rust умеет паниковать при внезапном переполнении в отладочной сборке, а также предоставляет функции типа overflowing_add и saturating_add для случаев когда точно нужно вполне конкретное поведение сложения

И как раз на Rust уже можно кодить драйвера для линукса)

По-моему вы слишком хорошего мнения об админах таких серверов

Контейнеры разумеется в отдельной сети, но проброс-то портов всё равно придётся делать, и они с какого-то перепуга по умолчанию пробрасываются сразу в интернет. Я конечно почитал доку и перебиндил всё на 127.0.0.1, только вот вообще-то с точки зрения безопасности наоборот всё должно биндиться на 127.0.0.1 по умолчанию хотя бы в качестве «защиты от дурака» — и уж точно не должно быть никакого постороннего вмешательства в фаервол (опять же, в доках написано как его отключить, но блин, оно должно быть отключено по умолчанию!)

Не удивлюсь, если такое кривое поведение по умолчанию является причиной половины утечек всяких баз

Все рассуждения BugM в этой ветке исходят из допущения, что фаервол по умолчанию отключен или криво настроен (насколько такое допущение верно — сами разбирайтесь)

Потому что фаервол включен, очевидно

прохождение по сети провайдера

Ну так я то же самое и написал:

дропнутся ещё где-то на уровне интернет-провайдеров

А при отправке такого запроса напрямую на роутер его уже ничего не остановит, кроме фаервола. Проверял на кинетике, в котором фаервол включен по умолчанию  — запросы не идут, выключаю фаервол — идут

Любая домохозяйка получает безопасную сеть дома просто так.

Как я уже пояснил в этом и предыдущем комментариях, данное утверждение ложно

То, что вы называете «безопасностью» — не безопасность, а череда случайностей, которые мешают напакостить (не сошлись дырки в швейцарском сыре)

NAT без фаервола не блокирует доступ к локальным устройствам: если извне прилетит запрос к локальному IP — роутер его без проблем отроутит (я проводил реальный эксперимент на практике — это действительно работает)

Вся ваша хвалёная «безопасность» держится лишь на той случайности, что такие запросы просто не дойдут до роутера — дропнутся ещё где-то на уровне интернет-провайдеров

При этом сам интернет-провайдер, имея прямое подключение к домашнему роутеру, сможет просканировать всю локальную сеть, если захочет и если его не остановит фаервол

И опять же:

И веронятно есть какая-то админка с доступом admin/admin.

А что, в IP-камерах с UPnP принципиально не бывает админок с доступом admin/admin?

Если бы я как простой пользователь не знал про UPnP, я бы мог решить не менять стандартный пароль, думая, что камера останется в пределах локальной сети и это не страшно

(к счастью, я не совсем простой и у меня есть привычка периодически прогонять себя через nmap с целью выявления каких-нибудь ошибок конфигурации)

(кстати здесь ещё можнно припомнить Docker, который в конфигурации по умолчанию !!!!!В ОБХОД ФАЕРВОЛА!!!!! выставляет себя голыми контейнерами в интернет — спасибо что хоть без UPnP)

А что, в IP-камерах с UPnP принципиально не может существовать RCE?

Ну например ровно в том же, в чём и причина вашей боязни доступа к лампочке?

Не лампочка, но мне попадалась IP-камера, которая автоматически без моего ведома выставила себя в интернет через UPnP. Непонятно, почему вы решили, что для этого нужно что-то заражать

Мне надо

Firefox, да

Что ещё раз подтверждает, что это сложнейшая проблема компьютерных наук ¯\_(ツ)_/¯

Хабр:

Вот вроде статья про самые основы, описанные в растбуке, но почему-то тут плохо почти всё

4 самых частых вопросов

Даже заголовок не вычитали. И дальше по тексту навалом опечаток, упоминать которые не буду

Это предотвращает утечки памяти

Тем не менее, важно понимать, что Rust не предотвращает все утечки памяти

только одна изменяемая ссылка может существовать в данный момент времени.

Упущен крайне важный нюанс: в этот же момент времени не может существовать неизменяемых ссылок

// println!("r: {}", r); // ошибка: x не живёт достаточно долго

Чушь: если раскомментировать первый println (но не второй), то код успешно компилируется и запускается

// функция, которая ... возвращает ссылку с длиннейшей жизнью

Просто чушь, даже не знаю как прокомментировать

типы, реализующие трейт Drop, обязаны определить специальное поведение при удалении, так как они не могут быть скопированы автоматически.

Опять набор слов какой-то. Возможно, автор хотел сказать, что нельзя реализовать трейты Copy и Drop одновременно, но он почему-то не смог

Юзаем Option ... без использования нулевых указателей

Если речь про собеседование, то, вероятно, где-то тут стоит упомянуть null pointer optimization

Mutex в Rust гарантирует, что только один поток может получить доступ к защищаемым данным в любой момент времени.

А как расшарить-то мьютекс другим потокам, если в растовой системе владения владелец может быть только один, а ссылка не проживёт достаточно долго? Без упоминания хотя бы Arc пример является бессмысленным

Попробовал докинуть zram-своп перед установкой — вроде установилось

Кстати насчёт свопа — во время второй попытки установки обратил внимание, что версия ядра 6.8.0, а там были какие-то проблемы, из-за которых у меня зависал арч. Проблемы вроде пофиксили примерно к 6.8.3, но если вдруг разрабы убунты поленились портировать фиксы, то, может, проблемы тут так и остались (правда, у меня зависало именно сочетание шифрования + zswap, а в убунте из коробки ни того ни другого нет, но мало ли чего)

Ну вообще в системых требованиях написано таки 4 гига

Попытка установки на 2 гига в виртуалбоксе зависла тут

если надо KV - то почему не redis?

Вы видимо не следили за новостями https://www.opennet.ru/opennews/art.shtml?num=60820

Пару недель назад ставил krfb на арче, и он крашился сразу же после попытки нажать Shift. Причём не просто крашился, а ещё и оставлял Shift зажатым, и после краха приходилось всю графику перезапускать, чтобы отжать его

(наверно надо забагрепортить, но мне пока что лень)