LINUX.ORG.RU

Атака на пакет arrayref Rust

 , , ,


0

5

Атака на цепочку поставок: вредоносный код в crates.io через пакет arrayref

20 августа 2026 года Команда безопасности Rust (Rust Security Response Team) сообщила об обнаружении вредоносных пакетов в реестре crates.io, связанных с популярной библиотекой arrayref.

Что произошло

20 августа 2026 года в 7:15 UTC команда получила сообщение о том, что пакет proc-macro1 является вредоносным. После проверки выяснилось, что его build-скрипт загружал вредоносное ПО.

Пакет proc-macro1, а также связанные с ним proc-macro-en, aovine, arone, aronenao и tinymember были удалены из реестра.

Дальнейшее расследование показало, что широко используемый пакет arrayref был недавно перевыпущен с добавленной зависимостью от вредоносного proc-macro1, при этом последние версии были помечены как yanked. Команда удалила вредоносную версию и восстановила ранее ошибочно отозванные версии.

Аналогичным образом пострадали другие пакеты того же автора — internment и append-only-vec. По ним были приняты те же меры. Аккаунт автора заблокирован в качестве меры предосторожности. По имеющимся данным, сам автор arrayref не действовал злонамеренно — вероятнее всего, были скомпрометированы его компьютер или учётные данные. Команда пытается связаться с ним.

Что нужно сделать пользователям

Рекомендуется проверить локальные зависимости на предмет использования следующих вредоносных версий, удалённых с crates.io:

  • append-only-vec@0.1.9
  • arrayref@0.3.10
  • internment@0.8.7
  • proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (любые версии)

Проверить наличие этих пакетов в локальном кэше можно следующей командой:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Благодарности

Команда Rust поблагодарила исследователей Nextron Systems GmbH за первоначальное обнаружение проблемы и сообщение о ней, а также сотрудников, участвовавших в устранении инцидента.

>>> Источник



Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от Gordon

синтаксис неплох

Вот это … ну, спорно (о вкусах).

Концептуально, да, понятно, зачем это всё нужно, и явное прослеживание программистом, на уровне контрактов, времени жизни того или иного объекта сильно облегчает жизнь.

А вот на уровне конкретной синтаксической реализации, ну, не нравится. Да, вкусовщина.

AlexM ★★★★★
()
Ответ на: комментарий от dynamic_cast

Откуда узнаете, что перехватили всё то, что дóлжно обработать на этом уровне?

Откуда узнаете, что при эволюционном изменении поведения библиотеки (по тем или иным причинам притащили новую версию) не нужно пойти и поправить/дополнить клиентский код, который обращается к этой библиотеке?

Если разрабы хорошие, аккуратные, то по логам перехваченного на верхнем уровне std::exception и …? Или как обычно — из вдумчивого чтения логов сервиса на проде, завершившегося по SIGABRT из-за необработанного исключения?

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

Откуда узнаете, что перехватили всё то, что дóлжно обработать на этом уровне?

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

dynamic_cast
()
Последнее исправление: dynamic_cast (всего исправлений: 1)
Ответ на: комментарий от dynamic_cast

это плохая затея..

Это, в общем случае, невозможная затея. Не нужно и невозможно предусмотреть изменение поведения в будущем.

Но. Вынос набора unhappy-path-ов в контракт метода заставляет пользователя этого метода подумать, а что из этих unhappy-path-ов нужно обработать в точке вызова, а что — скинуть на код выше по стеку, возможно, с добавлением необходимого контекста. При изменении этого набора в новой версии заставит при сборке вернуться к этому месту и адаптировать своё прошлое решение к новым реалиям.

Конечно, подобное явное проговаривание загромождает код. Достаточно поглядеть на типичное go-шное приложение, где unhappy-path-ы — это не «исключения», а «штатные ошибки». Но оно предоставляет хоть какие-то инструменты обнаружения изменения контракта ещё на этапе компиляции. Понятное дело, что любым инструментом надо пользоваться вдумчиво и ответственно.

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от Gordon

обилию CVE в сишном мире

Посмотрим, что будет с Растом, через 35 лет. Обилие CVS в сишном мире говорит лишь о том, что подавляющее количество софта написано на Си\Си++. Вы в статистику не умеете.

vvb333007
()
Ответ на: комментарий от peregrine

А это когда каждый простой на час в твоём софте начинается от миллиона долларов убытков

С таким определением согласен, для этих 0.001% индустрии есть смысл рассмотреть переход на раст, специальную ОС и даже спецжелезо. Но для остальных-то 99.999% совершенно излишне.

Я понимаю, что большинство тут либо вообще не из IT, либо имеют сайт своей чебуречной, где всех убытков 2000 рублей в месяц

Вот именно! Многие апологеты раста этого не учитывают, по-моему. Совершенно нишевую штуку пытаются пропихнуть как язык общего назначения для ширнармасс. Отсюда и все споры. Язык-то может и неплохой для своей ниши.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 6)
Ответ на: комментарий от Saakx

Что плохого в том, что используется Rc? Мог вообще Arc исплользоваться, и это было бы хуже.

А ведь мог бы и шашкой :)

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от sena

А что, сайты чебуречной нынче пишут на плюсах или на расте?

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

AlexM ★★★★★
()
Ответ на: комментарий от sena

Пример гипертрофированный, нужен двусвязный список, реализуешь его на unsafe с сырыми указателями, оставляя снаружи безопасный интерфейс, или берешь готовое решение. Хочешь гарантии компилятора - делаешь как в сообщении на которое ссылаешься со всякими Rc<RefCell<_>>.

Но сначала нужно придумать реальный кейс для такого контейнера, нужен ли он вообще. У него плохая локальность, узлы разбросаны по всей памяти, обход списка почти всегда приводит к кеш-промаху. Поэтому на реальном железе оно проигрывает даже тогда когда по асимптотике должна быть более оптимальной. Короче, на практике почти всегда можно обойтись Vec/VecDeque + HashMap.

Gordon
()
Ответ на: комментарий от F457

Эта небольшая часть примерно равна 70%

Это же у корпораций, на всей кодовой базе, написанной за 50+ лет. Да, верю в принципе. Современный код на с++, написанный с учётом вопросов безопасности - сомневаюсь.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от AlexM

Человек же образно писал про чебуречные. В область «час простоя стоит от мегабакса» попадает 0.001% софта, всё остальное - мимо, а не только сайты чебуречных.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Ответ на: комментарий от dynamic_cast

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

Gordon
()
Ответ на: комментарий от vvb333007

Хочешь сказать что в новом сишном коде больше не промахиваются мимо буфера? Не тыкаются по уже дропнутому ресурсу?

Gordon
()
Ответ на: комментарий от sena

И что там непонятного? Да, несколько многословно, но это следствие гарантии того, что ты случайно не выстрелишь себе в ногу. Ну а то что сосед смотрит на простой код как баран на новые ворота, так это не кода проблема, а барана.

WatchCat ★★★★★
()
Ответ на: комментарий от AlexM

Хз как там на плюсах сейчас, но на расте есть и фреймворки, и ормки, и все что хочется сайту чебуречной. Так что накидать на расте будет не сильно дольше чем накидать на условном питоне.

Gordon
()
Ответ на: комментарий от firkax

Тогда не понимаю столь воинствующего сопротивления расту, он же помогает этим 95% (я в их числе) писать корректный код, не отстреливая себе части тела.

Gordon
()
Ответ на: комментарий от vvb333007

Зато боров доволен. Мне что-то подсказывает что у них не только списки через жопу в угоду борову сделаны.

ckotctvo
()
Ответ на: комментарий от Gordon

Он помогает прятать своё слабоумие тем, кого нельзя допускать до программирования вообще. В Си они быстро палятся, устраивая битьё памяти, и это хорошо. Всмысле, хорошо что палятся. Битьё памяти - побочный эффект, но поскольку их продукцией пользоваться всё равно нежелательно, то список её дефектов уже не важен.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от WatchCat

несколько многословно

«несколько многословно»???

Ты серьёзно или шутишь? Это же элементарная задача, базовая. А если действительно что-то сложное понадобится реализовать? Я повидал в своей жизни говнокода, но это нечто. Если ты этого не понимаешь, то не знаю о чём говорить.

сосед смотрит на простой код как баран на новые ворота, так это не кода проблема, а барана.

Если ты не работаешь в команде и пишешь один для себя, то да. Иначе, опять же в 99% случаев - нет. Такая переусложнённость, кстати, отрицательно влияет и на безопасность косвенным образом.

sena ★★★
()
Ответ на: комментарий от Gordon

Вы знаете, если вы разрабатываете софт на Си, то со временем вы все меньше и меньше делаете таких ошибок. Это называется - набрался опыта. Бывают удивительные ошибки с указателями. Но это одна на миллион. А чаще - malloc() + strcpy() без проверки результата. И прочее. Это н проблема языка, это проблема программиста. И показатель его опытности.

Когда я последний раз своими руками устраивал sigsegv - я уже не вспомню. Для меня как-то дико «обратиться по освобожденному уазателю» или «повисший указатель». Вы ведь когда проектируете - именно это и обдумываете - время жизни, кто удаляет, кто хранит, а сколько задач туда лезут, а есть ли мутекс или там все лучше атомиками обмазать и CAS-циклами.

Вот недавний пример. ESP32, типа, системный софт:

const char *getSupportedCpuFrequencyMhz(uint8_t xtal) {
  char *supported_frequencies = (char *)calloc(256, sizeof(char));
  int pos = 0;

#if TARGET_CPU_FREQ_MAX_400
#if CONFIG_IDF_TARGET_ESP32P4 && CONFIG_ESP32P4_REV_MIN_FULL < 300
  pos += snprintf(supported_frequencies + pos, 256 - pos, "360");
#else
  pos += snprintf(supported_frequencies + pos, 256 - pos, "400");
#endif
#elif TARGET_CPU_FREQ_MAX_240
#if CONFIG_IDF_TARGET_ESP32
  if (!REG_GET_BIT(EFUSE_BLK0_RDATA3_REG, EFUSE_RD_CHIP_CPU_FREQ_RATED) || !REG_GET_BIT(EFUSE_BLK0_RDATA3_REG, EFUSE_RD_CHIP_CPU_FREQ_LOW)) {
    pos += snprintf(supported_frequencies + pos, 256 - pos, "160, 80");
  } else
#endif
  {
    pos += snprintf(supported_frequencies + pos, 256 - pos, "240, 160, 80");
  }
#elif TARGET_CPU_FREQ_MAX_160
  pos += snprintf(supported_frequencies + pos, 256 - pos, "160, 120, 80");
#elif TARGET_CPU_FREQ_MAX_120
  pos += snprintf(supported_frequencies + pos, 256 - pos, "120, 80");
#elif TARGET_CPU_FREQ_MAX_96
  pos += snprintf(supported_frequencies + pos, 256 - pos, "96, 64, 48");
#else
  free(supported_frequencies);
  return "Unknown";
#endif

  // Append xtal and its dividers only if xtal is nonzero
  if (xtal != 0) {
    // We'll show as: , <xtal>, <xtal/2>[, <xtal/4>] MHz
    pos += snprintf(supported_frequencies + pos, 256 - pos, ", %u, %u", xtal, (uint8_t)(xtal / 2));

#if CONFIG_IDF_TARGET_ESP32
    // Only append xtal/4 if it's > 0 and meaningful for higher-frequency chips (e.g., ESP32 40MHz/4=10)
    if (xtal >= RTC_XTAL_FREQ_40M) {
      pos += snprintf(supported_frequencies + pos, 256 - pos, ", %u", (uint8_t)(xtal / 4));
    }
#endif
  }

  pos += snprintf(supported_frequencies + pos, 256 - pos, " MHz");
  return supported_frequencies;
}

И что, язык плохой, а программист хороший? Или все-таки программист не на своем месте сидит в этой конторе? Вызывалась функция выше вот так: printf("%s\r\n", getSupportedCpuFrequencyMhz(xtal));

Ах да, программист норм, просто вот ужо был бы нормальный язык, ужо тогда да… А как по мне - гнать программиста надо ссаными тряпками.

vvb333007
()
Последнее исправление: vvb333007 (всего исправлений: 3)
Ответ на: комментарий от unC0Rr

Самая бесполезная вещь, которую только можно было придумать.

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

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

shell-script ★★★★★
()
Ответ на: комментарий от firkax

Быстро палятся?

Вот что нагуглил/наджипетил:

Cишечка:

  • CVE-2021-4034 - Polkit / PwnKit - out-of-bounds read/write. Прожила 12+ лет.
  • CVE-2015-0235 - glibc / GHOST - heap buffer overflow. Около 14 лет до обнаружения.
  • CVE-2024-1086 - Linux Kernel / nf_tables - use-after-free / double free. Почти 10 лет.
  • CVE-2023-4911 - glibc / Looney Tunables - buffer overflow. Около 2,5 лет.
  • CVE-2023-4863 - libwebp - heap out-of-bounds write / heap buffer overflow.
  • CVE-2024-6387 - OpenSSH / regreSSHion - race condition с повреждением heap. Почти 4 года после повторного внесения бага.

Cиплюсплюсушка:

  • CVE-2022-22620 - WebKit / Safari - use-after-free. Ошибку исправили в 2013-м, повторно внесли в 2016-м и обнаружили как эксплуатируемый 0-day только в 2022-м, ещё примерно 6 лет.
  • CVE-2021-4102 - Google Chrome / V8 - use-after-free с повреждением heap; эксплуатировалась в реальных атаках.
  • CVE-2021-30633 - Google Chrome / IndexedDB - use-after-free, позволявшая потенциальный sandbox escape после компрометации renderer.

Сколько же еще таких быстро обнаруженных? И смотри какие крупные серьезные проекты и компании. Хочешь сказать что там профнепригодные работают?

Gordon
()
Последнее исправление: Gordon (всего исправлений: 1)
Ответ на: комментарий от LightDiver

Или под каждую ситуацию свой антивирус, который на серверах?

На нормальные сервера никто не тащит код, вышедший полтора часа назад. И на нормальных серверах нет компилятора, если говорить про конкретно эту уязвимость. Чтобы что- что-то новое прилетело на сервер, это что-то сначала посмотрят разработчики, потом посмотрят мантейнеры RHEL/Debian/Ubuntu/etc, потом посмотрят админы/DevOps'ы сервера, причём, как глазами, так и в автоматике на этапе CI/CD, а если компания чуть покрупнее, ещё и всякие специально обученные DevSecOps'ы и прочие Sec. И на нормальных серверах обычно запрещено настройками выполнять код откуда не надо и/или не давать коду ходить в сеть куда неположено(whitelist) и многие другие. Так, например, 99% руткитов на сервере не запустятся, просто потому что запрещено использовать непредусмотренные вызовы на уровне sysctl/параметров ядра/etc.

Конечно, бывали случаи, когда и через такую цепочку что-то просачивалось, но это большая редкость. Наиболее частый способ взлома серверов, это всё ещё социальная инженерия, направленная на недобросовестных людей с ssh-доступом на сервер или там к системе доставки кода.

Так что это не серверная проблема. Это по большей части проблема разработчиков на данный момент. И что самое плохое конкретно в данной уязвимости, то что какой-то там rust-analyzer без спросу запускается сразу при открытии проекта и что-то выполняет. Или среда разработки сама выкачивает обновления. Вот это прямо проблема-проблема. Если я лично целенаправленно не дал команды на обновление модуля, ничего не должно запускаться и уж тем более выполняться.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

сначала посмотрят разработчики, потом посмотрят мантейнеры RHEL/Debian/Ubuntu/etc, потом посмотрят админы/DevOps’ы сервера, причём, как глазами, так и в автоматике на этапе CI/CD, а если компания чуть покрупнее, ещё и всякие специально обученные DevSecOps’ы и прочие Sec.

Меня вот это и беспокоит, что одну и ту же работу приходится выполнять на разных уровнях раз за разом. Дублирование работы. А в итоге надежности нету. Всеравно пролазит.

Должна быть какая то более простая и надежная схема.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от vvb333007

Вы знаете, если вы разрабатываете софт на Си, то со временем вы все меньше и меньше делаете таких ошибок. Это называется - набрался опыта. Бывают удивительные ошибки с указателями. Но это одна на миллион. А чаще - malloc() + strcpy() без проверки результата. И прочее. Это н проблема языка, это проблема программиста. И показатель его опытности.

Вон выше, примеры CVE, где опытные разработчики ядра допустили ошибки. Это не проблема языка, и даже не проблема программиста. Это проблема компании, которой нужен продукт. Поэтому если ты компания, то ты набираешь себе исчезающе редких гениальных и супервнимательных прогеров на си, либо меняешь инструмент. Мир пошел по второму пути, крупные корпы потихоньку выкидывают сишку, она останется уделом маргиналов.

Когда я последний раз своими руками устраивал sigsegv - я уже не вспомню. Для меня как-то дико «обратиться по освобожденному уазателю» или «повисший указатель».

Ты или мало кода пишешь (мизерные проекты), или им никто не пользуется. В любом случае твой опыт не гарантирует что в нем нет ошибок. Найдут попозже, вскроют сситему через дыру одну на миллион.

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

Что плохого, когда компилятор тебя подстрахует в этом? Зачем держать это в голове? У тебя бизнес-задача должна занимать основной контекст, а не тряска по поводу забытых ресурсов.

Ах да, программист норм, просто вот ужо был бы нормальный язык, ужо тогда да… А как по мне - гнать программиста надо ссаными тряпками.

Других нет, либо берете этих, либо умираете как продукт.

Gordon
()
Ответ на: комментарий от sena

«несколько многословно»???

Там по ощущениям меньше сотни строк кода. Это много? Покажи аналогичную реализацию на крестах.

Ты серьёзно или шутишь? Это же элементарная задача, базовая. А если действительно что-то сложное понадобится реализовать? Я повидал в своей жизни говнокода, но это нечто. Если ты этого не понимаешь, то не знаю о чём говорить.

Не драматизируй, на фоне сотен тысяч строк бизнесового кода, сотня строк библиотечного, который ляжет в какой-то крейт и не мозолит глаза - это ничто. Опять таки, покажи реализацию на сишке. То что ты не можешь элементарный код прочитать - проблема твоя, но называть все непонятное тебе говнокодом - признак незрелости.

Gordon
()
Ответ на: комментарий от Gordon

Причём тут конкретные CVE? Я писал что палятся авторы этих багов. То есть бери конкретного автора, всю его историю коммитов во всё куда он коммитил, и смотри насколько быстро в его коде нашлось первое (ладно, пусть второе-третье) битьё памяти, особенно среди того, что он допустил до выпуска в релиз.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты же понимаешь что код по CVE выше также проходил ревью? Каждый коммит был просмотрен, и никто ничего не увидел.

Gordon
()
Ответ на: комментарий от MSZX

Да, я им <Neovim — прим. shell-script> не пользуюсь, потому что это хардкорная IDE для ценителей

Хватит уже повторять эту мантру. Оно проще, чем все комбайны типа VSCode, хотя сложнее, чем vim. Говорю, как человек, который на постоянной основе много лет использует vim и VSCode и пробовал работать в Neovim.

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от Gordon

Ну да, коллективная профнепригодность.

Сколько же еще таких быстро обнаруженных? И смотри какие крупные серьезные проекты и компании. Хочешь сказать что там профнепригодные работают?

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

Касательно линукса и glibc - ну да, страдают качеством. Конкретных виновников тоже можно выявить.

firkax ★★★★★
()

у каждой уязвимости есть фамилия, имя, отчество..

dynamic_cast
()
Ответ на: комментарий от LightDiver

Это не дублирование работы. На каждом этапе выполняются разные почти не пересекающиеся проверки разными способами. И надёжнось есть. То, что пролазит, не запускается; то что запускается, не работает; то, что работает, блокируется. Как я и написал, практически единственный способ взлома сервера сейчас - это человек, имеющий к нему доступ, а не код.

А более простая и надёжная схема работает только для хелловордов.

shell-script ★★★★★
()
Ответ на: комментарий от Gordon

Ну, тут вопрос не в библиотеках как таковых, а в увязывании всего этого хозяйства в комплекс.

Простой пример. Используем подход API-first, то есть, сначала публикуем и согласовываем с контрагентами апишку к приложению, например, в популярном формате openapi. Сказано - сделано. Потом пытаемся нагенерировать по этой апишке стабы для сервера. Выясняется, что с генераторами для раста, ну, не голяк, но «есть нюансы». Два в состоянии беты, один, вроде как, стейбл, но с кучей неподдерживаемых фич спецификации OAS. А что с автоматической валидацией параметров запросов? Что с различными типами аутентификации? Что с полиморфизмом в генерируемых модельках? Вопросики, вопросики.

Кароч, без тщательного исследования, что этот генератор даст на конкретной спецификации, я бы не рискнул тащить это в mission critical prod.

Ну и по остальным инструментам современной индустриальной веб-разработки тоже вопросы.

Как там память управляется - вопрос двадцать пятый примерно. Ну, разбухает сервис в памяти до полутерабайта, ну, кому сейчас легко:)

AlexM ★★★★★
()
Ответ на: комментарий от Gordon

компилятор тебя подстрахует в этом?

Подстрахует - ок. Но если мне для этого нужно с компилятором бороться, как в Rust - то такая подстраховка не нужна.

С каких пор, я кстати, что-то упустил, обычный программист, который думает про указатели стал именоваться «редким гениальным исчезающим видом?». Гениальность программиста - в оригинальных или необычных алгоритмах, в решениях красивых и быстрых.

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

Завтра мы скажем - «Ой, что-то столько аллокаций у меня, я даже и не помню, где какие.. Давайте умный сборщик мусора добавим?».

vvb333007
()
Ответ на: комментарий от vvb333007

Завтра мы скажем - «Ой, что-то столько аллокаций у меня, я даже и не помню, где какие.. Давайте умный сборщик мусора добавим?».

Завтра тут не подходит. Так сказали лет цать назад.

bbc69
()
Ответ на: комментарий от vvb333007

Так, а что обсуждать-то? Скорость разработки увеличилась, программы разбухли. Если говорим о Расте, то скорость высокая, безопасно, но требует принятия концепции и перестройки мышления.

bbc69
()
Ответ на: комментарий от Gordon

Пример гипертрофированный, нужен двусвязный список, реализуешь его на unsafe с сырыми указателями, оставляя снаружи безопасный интерфейс,

Это дословно именно то, что я и так сейчас имею, но на Си.

обход списка почти всегда приводит к кеш-промаху.

Ну штош теперт. Для таких , как вы, __prefetch() придумали в GCC, подсасывать в кэш то, что нужно.

В реальном мире списки кругом: ваша сетевая карта, допустим Ethernet, принимает и передает цепочки DMA буферов. Там как раз все обмазано списками, односвязными. Как там ownership модель описывать - немзвестно: там и CPU и DMA одновременно могут по этим буферам лазить. unsafe?

«Сетевые» буфера памяти - списки, тоже с так себе cache-locality (в Linux- sk_buff, в *BSD - mbuf() ). Для всего этого Раст подходит плохо. Но при этом - системный язык нового поколения.

Чудеса.

PS: Мне было бы реально интересно посмотреть на реализацию какого-нибудь более-менее живого TCP/IP стека на Rust. Есть такое? Интересно поглазеть, как у них будет выглядеть работа с памятью.

vvb333007
()
Ответ на: комментарий от shell-script

Во-первых, если я открываю код, значит я уже ему доверяю.

Да? А как просмотреть код для его проверки на закладки?

Иначе, зачем бы мне его открывать не в огороженной песочнице?

– Вот вам песочница.

– Зачем она мне, я доверяю коду, иначе бы я открывал его в огороженной песочнице?

просто решил обновить зависимости

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

unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от firkax

Конкретных виновников тоже можно выявить.

И чо, и чо? Выявишь, что дальше делать будешь? Всех выгнать и не допускать к коду, пускай всё сдохнет без развития?

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

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

firkax ★★★★★
()
Ответ на: комментарий от BruteForce

Я даже как-то теряюсь. Всегда думал, что это общеизвестно.

Знаешь, я когда только начинал писать на Питоне, читал, что хорошо, когда много бизнес-кода и мало обвязки. Я всё не понимал, что это за не бизнес-код такой. Потому ято на Питоне всё - бизнес-код. И понял я только когда столкнулся в другом языке с необходимостью считать входящие соединения и ставить их в очередь. Ну или подсистему работы с памятью, например. Тут-то до меня и дошло.

Банальный вопрос: что быстрее: написать условный эхо сервер или эхо сервер с системой работы с памятью?

bbc69
()
Ответ на: комментарий от firkax

Баги будут всегда. Чем раньше ты примешь это за данность, тем лучше.

Не надо никуда спешить, лучше делать качественно

Сидять пять программистов над проектом, делают качественно каждый какую-то фичу, полгода вылизывает код и внимательно отслеживает все взаимосвязи нового кода с проектом. Через полгода пять веток сливают в мастер бранч и вылезают баги. Придумай механизм избегания такой ситуации, не приводящий к «эту фичу запланируем реализовать через 20 лет».

Я понимаю, что у тебя небольшие успешные проекты, над которыми ты работал в одиночку и нашёл все баги до релиза своего кода, потому что у тебя было много времени. Но не все программы можно написать таким же образом. Подумай над этим.

unC0Rr ★★★★★
()
Ответ на: комментарий от sena

Это же элементарная задача, базовая.

Так и там ничего сложного. Или тебя пугает использование match вместо if? Или тебя пугает «страшная» связка Rc+RefCell? Или что тебя пугает?

WatchCat ★★★★★
()
Ответ на: комментарий от dynamic_cast

В Чернобыле тоже так думали. Но ладно, там не код, а аналоговая кнопка АЗ-5 была, сейчас был бы код.

peregrine ★★★★★
()
Ответ на: комментарий от unC0Rr

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

firkax ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.