Когда мы что-то перемещаем, то в исходном месте это что-то исчезает, правильно?
Нет, не правильно, конечно. Вы думаете есть какой-то способ "переместить" байты в памяти? :)
Разница именно в интерпретации копирования. "Копирование" - это копирование после которого обеими копиями можно пользоваться как эквивалентными. "Перемещение" - это копирование после которого исходным объектом пользоваться нельзя (при этом занимаемая им память осталась на месте но теперь считается свободной).
Используем casbin — по сути единственный фреймворк, если у вас не actix. Защищаем доступ к GraphQL API на уровне отдельных точек доступа. В качестве веб-фреймворка warp.
Работает, но появились следующие проблемы:
описание политик действительно чудовищно повторяющееся. У нас не супер-большое API, но файл контроля доступа к нему уже требует больших усилий по его поддержке;
как следствие, нужно специально следить, не забыл ли автор точки доступа вставить проверку на авторизацию. По хорошему, тут нужно допиливать интеграцию с warp, чтобы авторизация была частью типа, но этого пока не делали.
В сфере проектирования ЯП тоже есть прогресс и моральное устаревание. И на мой взгляд, это куда более простое объяснение, чем поддержка или написание нового кода.
По современным стандартам безопасности, выразительности и удобства кандидат из списка любимых даст прикурить своей альтернативе из списка нелюбимых.
Да, это реально работает. По крайней мере первый и третий пункт — постановку задач с вечера я не пробовал.
Также хочу отметить, что интервалы для помидоров индивидуальны. Можно начать с классики 25/5 и посмотреть, насколько хочется увеличить. То, что предлагает автор — это ближе к 2 склеенным помидорам.
Главной проблемой, по его мнению, является потенциальная возможность “паники ядра” в некоторых ситуациях. Это может быть нехватка памяти, когда операции динамического распределения памяти могут завершаться ошибкой. Торвальдс заявил, что такой подход в ядре принципиально недопустим.
Он говорит не о панике ядра, а о панике Раста. Это поведение функций, выделяющих память на куче в юзерспейсе, в стандартной библиотеке.
При этом довольно очевидно, что стандартная библиотека Раста в ядре и не нужна. Так было бы и с любым другим языком. В Linux не используется стандартная библиотека Си и в частности тот же самый malloc. Там свои специализированные аллокаторы.
Вообще да, если посмотреть на статистику нахождения там багов и уязвимостей, в т.ч. вызванных проблемами небезопасной работы с памятью.
Например, вот относительно недавнее исследование. Оно не блещет полнотой, но достаточно репрезентативно.
В отличие от Си, в Расте аудит UB требуется только в unsafe коде. Которого очень мало — в т.ч. учитывая текущую практику разработки системных компонентов или операционных систем.
Например, в сетевом стеке Fuchsia:
Но это практически не важно в условиях, когда сетевая задержка доминирует над задержкой вывода на дисплей. Задержка от ввода до прихода это как минимум 2 RTT — от 20 мс до, допустим, 150 мс. На 60 Гц уже кадр выводится всего на 16,7 мс.
Учитывая распределённость организации, на эти деньги можно нанимать людей по всему миру. И тогда их хватит далеко не на трёх разработчиков компаний, которые пылесосят перегретый рынок.
Эхо-сервер gRPC в статье на 6 минут с пометкой "Сложный"?) Я не понимаю эту категоризацию сложностей материалов
Нет, не правильно, конечно. Вы думаете есть какой-то способ "переместить" байты в памяти? :)
Разница именно в интерпретации копирования. "Копирование" - это копирование после которого обеими копиями можно пользоваться как эквивалентными. "Перемещение" - это копирование после которого исходным объектом пользоваться нельзя (при этом занимаемая им память осталась на месте но теперь считается свободной).
->
Как вы советуете решать ту же проблему?
Ну что же, прощай, лицемерный DDG.
Подвижки в сторону "ещё одной корпорации" были давно.
Используем casbin — по сути единственный фреймворк, если у вас не actix. Защищаем доступ к GraphQL API на уровне отдельных точек доступа. В качестве веб-фреймворка warp.
Работает, но появились следующие проблемы:
В сфере проектирования ЯП тоже есть прогресс и моральное устаревание. И на мой взгляд, это куда более простое объяснение, чем поддержка или написание нового кода.
По современным стандартам безопасности, выразительности и удобства кандидат из списка любимых даст прикурить своей альтернативе из списка нелюбимых.
Да, это реально работает. По крайней мере первый и третий пункт — постановку задач с вечера я не пробовал.
Также хочу отметить, что интервалы для помидоров индивидуальны. Можно начать с классики 25/5 и посмотреть, насколько хочется увеличить. То, что предлагает автор — это ближе к 2 склеенным помидорам.
Я думаю, что консервативность кодовой базы линукса недооценена. Сомневаюсь, что в mainline возьмут.
Никто и не предполагал, что в ядре будет "обычный Раст". В Redox тоже "не обычный". И в Fuchsia.
Какой serde в ядре?..
Он говорит не о панике ядра, а о панике Раста. Это поведение функций, выделяющих память на куче в юзерспейсе, в стандартной библиотеке.
При этом довольно очевидно, что стандартная библиотека Раста в ядре и не нужна. Так было бы и с любым другим языком. В Linux не используется стандартная библиотека Си и в частности тот же самый malloc. Там свои специализированные аллокаторы.
Я знаю о нём. Он не на любой кодобазе работает. В частности, в Fuchsia код на Расте без Cargo.toml — такое cargo-geiger не умеет.
Вообще да, если посмотреть на статистику нахождения там багов и уязвимостей, в т.ч. вызванных проблемами небезопасной работы с памятью.
Например, вот относительно недавнее исследование. Оно не блещет полнотой, но достаточно репрезентативно.
В отличие от Си, в Расте аудит UB требуется только в unsafe коде. Которого очень мало — в т.ч. учитывая текущую практику разработки системных компонентов или операционных систем.
Например, в сетевом стеке Fuchsia:
К сожалению, именно число строк посчитать уже сложно. Но порядок и так видно, если на 300 тысяч строк кода 300 мест, где могут быть проблемы.
Но это практически не важно в условиях, когда сетевая задержка доминирует над задержкой вывода на дисплей. Задержка от ввода до прихода это как минимум 2 RTT — от 20 мс до, допустим, 150 мс. На 60 Гц уже кадр выводится всего на 16,7 мс.
На мой взгляд это неадекватно. Такие разговоры допустимы на кухне в кругу друзей, а не в публичном пространстве, когда у тебя тысячи подписчиков.
Ты почитал что она твитила?
Ого, не знал такого про Эшли.
Спасибо за перевод. Одно место резануло глаз.
Я думаю, всё-таки не
а что-то типа "колбасить без страха". Hack — быстро писать код, ломая всё вокруг.
Учитывая распределённость организации, на эти деньги можно нанимать людей по всему миру. И тогда их хватит далеко не на трёх разработчиков компаний, которые пылесосят перегретый рынок.