Оставлять unsafe — значить писать как на C. А зачем, если есть С?
Чтобы в остальных местах использовать zero-cost safe, где компилятор на стадии компиляции ловит за тебя ошибки (или сразу показывает что твоя архитектура не работает). C таких гарантий не дает просто из-за своей структуры.
Ставить safe — разменивать скорость на безопасность
Ну вообще далеко не всегда. Те же массивы если обращаться к конкретному элементу — да, будет по умолчанию проверять границы, но если через итератор то этих проверок не будет. Далеко не весь safe дорогой, я бы сказал даже наоборот. Обычно если идет какой то оверхед то для этого уже конкретный тип применяется (условный Rc/Arc) и это явно видно.
Впрочем я сам наверное junior в расте, как и в системном программировании в общем.
Больше того, для кода с safe никто не обещает гарантированного времени выполнения
Ничем не отличается от unsafe кода. У вас либо на уровне логики все хорошо, либо вы вводите дополнительные примитивы для той же многопоточной синхронизации, что в safe что в unsafe. Просто в safe вам никто не даст забыть такой примитив.
вторые кричат что безопасность — это мастерство водителя
огромное количество CVE состоящие из банальных buffer overflow довольно красноречиво говорит о том что лучше бы эти дела ловил компилятор. Особенно во всяких сложных случаях где структуры завязаны друг на друга. Условно говоря в Rust вам не страшно взять лишний раз ссылку и не бояться что вы забудете что то синхронизировать или освободить, а в C вы бы для страховки сделали лишнюю копию, или того хуже — не сделали бы и получили use after free. Просто потому что в большой программе сложнее следить за целостностью между разными частями.
В принципе Rust позволяет делать тоже что и C, поэтому C может понадобиться только в таких частных случаях как у вас например, где хочется чтобы компилятор как можно стабильнее генерировал одни и те же инструкции. Или платформа где кроме обрезанного C компилятора ничего и нету.
В прочем это обычное перечисление плюсов и минусов, каждый сам для себя выбирает. Мне например, (как начинающему «системщику») полезно когда компилятор за ручку держит, да и в целом ощущение почти как в скриптовых языках (удобно и приятно), только без пенальти по производительности (zero-cost).
Ну а по поводу железок, да, пока что в Rust экосистема не так развита под embeded (хотя есть working group под это дело), да и для конкретной платформы микроконтроллера поддержка может быть Tier3 поддержка (если вообще присутствовать). Это не значит что не получится скомпилировать под нужную архитектуру, но однозначно придется плясать на каждом шагу.
Не очень понятно зачем стабильное ABI для железок. Зерокостная сериализация/десериализация и без ABI делается, .so/.dll там вроде как не юзаются, а для чего еще — непонятно. Хотя вы видимо говорите про перфоманс получающегося кода, если он часто меняется то может незаметно просесть, верно?
Апишка в std устоялась, а вот в сам язык просто добавляют полезные фичи. Можно и без них обойтись. Еще по части асинхронных библиотек все очень бурно идет на данный момент (из-за только что стабилизировавшегося async/await), но пользоваться уже можно (люди еще в 2016-2017 на нестабильном в проде сидели вполне успешно). В принципе работа по части embeded вполне себе ведется сообществом, и есть no_std крейты под некоторые микроконтроллеры. Сам не занимаюсь поэтому точно сказать не могу.
В отличие от C/C++ тут можно локализировать unsafe и работать на безопасных обертках, что снижает количество потенциальных ошибок. Для меня например C и особенно C++ страшны именно количеством UB на каждом шагу.
По поводу тактов и прочего — тут также как и с C надо просто бенчмаркать, профилировать и следить за тем какой код получается, особых отличий наверное нету?
Тут дело в другом, если переписывать библиотеку какого то ПО на Rust, значит что придется следить за всеми изменениями и вносить правки в свою версию. В случае биндингов — только за актуальностью биндингов. Кроме того в большом софте реально много кода, это просто непрактично переписывать.
можно просто переписать, чтобы избавиться от исторических наслоений
Так не лучше ли переписать сразу на безопасном Rust чем продолжать страдать с C?
но с точки зрения инженерии в общем случае энергию лучше было бы направить написание и тестирование приложений
По мне так проще системно перейти на то что тебя страхует чем жрать кактус. Это я про новые проекты или полные переписывания. Понятно что огромную кодовую базу C/C++ крайне сложно/мало реально/практично переписывать на что то еще.
Правда, open source часто держится на идеалистах
Тут можно привести альтернативную точку зрения что бизнес думает локально, только здесь и сейчас потому что завтра он закроется. В будущее он крайне редко смотрит. А здесь и сейчас это корыто как то работает.
Особенно в случае Раста, где количество компетентных желающих на нём писать существенно больше, чем количество желающих за это платить
В этом в том числе и апологеты C/C++ не помогают кстати.
Там автор репозитория всех коментирующих занес в свой личный блок лист вместо лока дискуссии и как я понял некоторые из-за этого стали забанены в некоторых организациях которыми он владел, вроде http-rs и другие.
с правами на файлы:
— в Dockerfile: ARG USERID=1000
— в docker-compose.yml USERID: $USERID
— В папке с докером надо сделать export USERID=$UID (баш подставляет в UID юзерайди. direnv у меня подхватывает конфиг с env)
— Дальше в Dockerfile useradd с нужным UID, USER название_юзера
И контейнер начинает делать файлы с тем же uid что и хостовой пользователь. Если не хочется заморачиваться то в Dockerfile ручками ARG менять. В такой схеме еще и контейнер не от рута работает, что поидее безопаснее (при подтягивании зависимостей, например).
Забавно, ловил себя на той же мысли. Запускаешь факторию, менеджеришь все как будто код пишешь по которым данные текут, делаешь низкую связность по возможности и т.д. После чего понимаешь что это таже работа с тем же планированием и желание играть теряется.
В ноябре стабильно будет вроде. В бете уже доступно без фича-гейта. Экосистема массово перепиливается под него с момента как оно в найтли стало доступно.
Это «неминуемо» потому что люди так думают, а не потому что оно так на самом деле.
Сейчас полно технологий и ресурсов чтобы это изучать, только это подавляющему большинству не интересно )
Очевидная глупость. Провайдер который меня обслуживает таким никогда не занимался и не будет. Если захочет вставить рекламу на ресурсах — он ее просто возьмет и поставит в коде или попросит сделать рассылкой, однако там рекламы в принципе нет.
Пока не придет очередной эффективный менеджер или не продадутся условному билайну.
А вдруг китаец собирающий вашу конкретно клавиатуру решил встроить кейлоггер?
То что некоторые провайдеры вмешиваются в траффик это давно известный факт.
А рандомный или приближенный человек в лест-энкрипт вдруг захочет в автоскрипт генерирования сертификата вставить его отсылку приватного и открытого ключей на сервер АНБ.
А у них места то хватит? Startssl тоже вроде бесплатные церты выдавали.
Может быть у вас есть сети где работают раздолбаи, у нас не так и такое нарушение будет сразу выявлено.
Кем? провайдером? который этим и занимается?
был фулскрин об опасности при переходе на страницу с загрузками
Значит кто то пожаловался на сайт как не безопасный.
Это ресурсы провайдера, предназначенные для абонентов этого провайдера
И этот провайдер (билайн например) подмешает вам рекламу.
Если плохой человек решит устроить mitm в такой сети — ему надо будет физически менять коммутатор провайдера на свой для изоляции
Если человек — сотрудник провайдера то не придется.
ему надо будет физически менять коммутатор провайдера на свой для изоляции
Это будет большой проблемой для скажем, обиженного бывшего сотрудника провайдера? Или рандомного приближенного (к знанию о моделях и устройстве конкретной сети) человека?
Думаю что в такой ситуации вопрос про сертификат даже не встанет на повестку дня
Думаю при такой атаке никто не заметит подмены.
А вот фиг там. Будет квест «дополнительно — перейти на сайт (небезопасно)», как сейчас делают для всяких narod.ru.
И отлично, пенсионеры это как раз та ЦА которая находится в зоне повышенного риска. При красной плашке — появятся вопросы. Кстати про красную плашку на narod первый раз слышу.
Суть в том что он покажет то что планировал автор без вмешательств по каналу, вы таких гарантий дать не можете. То что у вас в локалке все работает всего лишь систематическая ошибка выжившего.
Ну вообще далеко не всегда. Те же массивы если обращаться к конкретному элементу — да, будет по умолчанию проверять границы, но если через итератор то этих проверок не будет. Далеко не весь safe дорогой, я бы сказал даже наоборот. Обычно если идет какой то оверхед то для этого уже конкретный тип применяется (условный Rc/Arc) и это явно видно.
Впрочем я сам наверное junior в расте, как и в системном программировании в общем.
Ничем не отличается от unsafe кода. У вас либо на уровне логики все хорошо, либо вы вводите дополнительные примитивы для той же многопоточной синхронизации, что в safe что в unsafe. Просто в safe вам никто не даст забыть такой примитив.
огромное количество CVE состоящие из банальных buffer overflow довольно красноречиво говорит о том что лучше бы эти дела ловил компилятор. Особенно во всяких сложных случаях где структуры завязаны друг на друга. Условно говоря в Rust вам не страшно взять лишний раз ссылку и не бояться что вы забудете что то синхронизировать или освободить, а в C вы бы для страховки сделали лишнюю копию, или того хуже — не сделали бы и получили use after free. Просто потому что в большой программе сложнее следить за целостностью между разными частями.
В принципе Rust позволяет делать тоже что и C, поэтому C может понадобиться только в таких частных случаях как у вас например, где хочется чтобы компилятор как можно стабильнее генерировал одни и те же инструкции. Или платформа где кроме обрезанного C компилятора ничего и нету.
В прочем это обычное перечисление плюсов и минусов, каждый сам для себя выбирает. Мне например, (как начинающему «системщику») полезно когда компилятор за ручку держит, да и в целом ощущение почти как в скриптовых языках (удобно и приятно), только без пенальти по производительности (zero-cost).
Ну а по поводу железок, да, пока что в Rust экосистема не так развита под embeded (хотя есть working group под это дело), да и для конкретной платформы микроконтроллера поддержка может быть Tier3 поддержка (если вообще присутствовать). Это не значит что не получится скомпилировать под нужную архитектуру, но однозначно придется плясать на каждом шагу.
Апишка в std устоялась, а вот в сам язык просто добавляют полезные фичи. Можно и без них обойтись. Еще по части асинхронных библиотек все очень бурно идет на данный момент (из-за только что стабилизировавшегося async/await), но пользоваться уже можно (люди еще в 2016-2017 на нестабильном в проде сидели вполне успешно). В принципе работа по части embeded вполне себе ведется сообществом, и есть no_std крейты под некоторые микроконтроллеры. Сам не занимаюсь поэтому точно сказать не могу.
В отличие от C/C++ тут можно локализировать unsafe и работать на безопасных обертках, что снижает количество потенциальных ошибок. Для меня например C и особенно C++ страшны именно количеством UB на каждом шагу.
По поводу тактов и прочего — тут также как и с C надо просто бенчмаркать, профилировать и следить за тем какой код получается, особых отличий наверное нету?
<% image_tag 'picture.raw' %> который будет сразу нужные форматы генерировать.
По мне так проще системно перейти на то что тебя страхует чем жрать кактус. Это я про новые проекты или полные переписывания. Понятно что огромную кодовую базу C/C++ крайне сложно/мало реально/практично переписывать на что то еще.
Тут можно привести альтернативную точку зрения что бизнес думает локально, только здесь и сейчас потому что завтра он закроется. В будущее он крайне редко смотрит. А здесь и сейчас это корыто как то работает.
В этом в том числе и апологеты C/C++ не помогают кстати.
Ну ну
www.reddit.com/r/rust/comments/biq864/giving_up_on_wlrootsrs
Там автор репозитория всех коментирующих занес в свой личный блок лист вместо лока дискуссии и как я понял некоторые из-за этого стали забанены в некоторых организациях которыми он владел, вроде http-rs и другие.
— в Dockerfile: ARG USERID=1000
— в docker-compose.yml USERID: $USERID
— В папке с докером надо сделать export USERID=$UID (баш подставляет в UID юзерайди. direnv у меня подхватывает конфиг с env)
— Дальше в Dockerfile useradd с нужным UID, USER название_юзера
И контейнер начинает делать файлы с тем же uid что и хостовой пользователь. Если не хочется заморачиваться то в Dockerfile ручками ARG менять. В такой схеме еще и контейнер не от рута работает, что поидее безопаснее (при подтягивании зависимостей, например).
В ноябре стабильно будет вроде. В бете уже доступно без фича-гейта. Экосистема массово перепиливается под него с момента как оно в найтли стало доступно.
Сейчас полно технологий и ресурсов чтобы это изучать, только это подавляющему большинству не интересно )
Сами же про пенсионеров говорите и прекрасно понимаете что им плевать.
То что некоторые провайдеры вмешиваются в траффик это давно известный факт.
А у них места то хватит? Startssl тоже вроде бесплатные церты выдавали.
Кем? провайдером? который этим и занимается?
Значит кто то пожаловался на сайт как не безопасный.
и http даже не помог?
Если человек — сотрудник провайдера то не придется.
Это будет большой проблемой для скажем, обиженного бывшего сотрудника провайдера? Или рандомного приближенного (к знанию о моделях и устройстве конкретной сети) человека?
Думаю при такой атаке никто не заметит подмены.
И отлично, пенсионеры это как раз та ЦА которая находится в зоне повышенного риска. При красной плашке — появятся вопросы. Кстати про красную плашку на narod первый раз слышу.
Безусловно. Поэтому там просто будет висеть плашка что сайт небезопасен, только и всего.
Потому что дорвей вам покажет то что хотел автор дорвея, а ваш сайт покажет вообще все что угодно. Или не покажет. Или накачает пользователя вирусами.