Кэрол Хербст (Karol Herbst) из компании Red Hat, принимающий участие в разработке Mesa, драйвера Nouveau и открытого стека OpenCL, рекомендовал пользователям открытых драйверов для видеокарт NVIDIA воздержаться от использования ядра Linux 6.3 из-за выявления специфичной для данной ветки ядра ошибки в коде драйвера Nouveau. Ошибка приводит к аварийному завершению работы из-за повреждения памяти ядра в результате обращения в коде к уже освобождённой области памяти (use-after-free)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59305
LTS релизы используют 5.x ядро, так что обкатыватели новинок, делают своё дело
Учитывая что изменения добавляют одновременно во все ветки - утверждение спорное
>longterm:6.1.34хех
Сейчас программирование, а точнее градация выпуска релизов, ускорилось до скорости спаривания кроликов.
Потом выявляют ближайшие уязвимости, а потом и не ближайшие... потому что в первую очередь кормушке нужны новые фичи.
А тебе не нужны новые фичи?
скорость работы важнее
Если почитать патч, то видно что проблема была всегда, просто стала проявляться чаще на 6.3:This seems to have existed for ever but is now more apparant after
9bff18d13473a9fdf81d5158248472a9d8ecf2bd (drm/ttm: use per BO cleanup workers)
> Если почитать патч, то видно что проблема была всегда, просто стала проявляться
> чаще на 6.3:Тут еще и народ в ветке про файлухи заметил что с блобом от нвидии файлухи разлетаются. Почти наверняка тоже косяки какие-то у блоба в управлении памятью.
А, ну это чьи-то там "открытые дрова". Ну а я пользуюсь официальными и таких проблем не знаю. Держу в курсе.
Не понимаю почему этот коммент заминусован. Nouveau умеет только две вещи: падать, и в редких случаях ускорять 2d-рендеринг. В то время как официальные драйвера мало того что не падают в кернел пикник, так ещё и все фичи поддерживают полноценно.
Чёт ты не в теме просто. На картах, на которых реклогинг работает, всё в порядке с 3д. А вот 2д никогда нормально не работало, сколько я не пробовал использовать. Кстати, паники не чаще чем у блоба были, это же не амд.
>это же не амд...у которой вообще таких проблем нету. Но вы кушайте, Хуанг вам ещё на лопате принесёт. Это майнеры у него кончились, зато такие, как вы, остались.
К слову, на линуксе у amd до сих пор нет восстановления после gpu hang. По-моему. У nvidia есть, но работает не всегда (впрочем, gpu hang вещь не то чтобы частая, это же не amd) и хотя бы не падает в панику, это значит, можно сбросить дисковые кеши и перезагрузить без гарантированных повреждений. Почти всегда. Иксы не поддерживают такое правда.
Как нет, если есть? У меня ещё на прошлой карте 5600XT срабатывало восстановление после зависания. За сейчас даже не скажу, т.к. уже года два не наблюдаю этих gpu hang, но явно никто фичу не отключал.
Спасибо, не знал. У меня всегда только жёсткие паники были на амдшных дровах.
> К слову, на линуксе у amd до сих пор нет восстановления после gpu hang. По-моему.По вашему. А реально это еще аж "Radeon" умел (опенсорсный который) - а уж его респин от амд известный как AMDGPU и подавно. Впрочем оно чаще всего не надо - потому что на большинстве GPU у амд драйверы стали весьма стабильны и ничего для начала и не виснет.
> У nvidia есть, но работает не всегда
Да оно и у амд примерно так же, чудес не бывает.
> Иксы не поддерживают такое правда.
Иксы для начала и не центр вселенной уже давно. Игры и плееры сто лет в обход таковых рендерят, а сами иксы продвинутые фичи вот именно GPU особо и не используют и чему там виснуть фиг его знает.
nVidia для linux GE не стоит покупать, если не хотите торчать на их блобах. Эта компания забила на опенсорс.
Ты пропустил все новости про открытие спек, ядерной части драйвера и её внедрение, и про доработку опенсорсного драйвера инженерами производителя? На данный момент для полноценной поддержки осталось только научить драйвер делать запросы к GSP. Но в то же время карты nvidia берут для работы и большинство пользователей в гробу видело опенсорсный стек, даже если он как-то заработает (это же касается и амд примерно целиком).
Можно открыть ядерные спецификации и выполнять основную работу вне ядра. Что это меняет для поддержки open source со стороны nVidia?
Какую работу? И ты пропустил всю эпопею с libglvnd, этого не достаточно? Любители опенсорса молиться должны на зелёных. А много там амд сделала для поддержки опенсорса, для конкурентов? 2 гигабайта автоматически сгенерированных файлов в дереве ядра не считаются. Разве что в сговор с такими же неудачниками из интела вступила, чтобы подгадить, это да, не мало. А все ценные части по-прежнему в закрытом драйвере.
> Какую работу? И ты пропустил всю эпопею с libglvnd, этого не достаточно?При том нужно оно было только нвидии, по большому счету.
> Любители опенсорса молиться должны на зелёных.
Они и призывают Ктулху чтоб пожрал мерзкую зелень, размахивая факом в камеру - и выписывая еще более эффективный фак GPL_ONLY на уровне кода, запрещая им использовать DRM/KMS/GBM инфраструктуру ядра. Нвидия и кодит альтернативные эрзацы этого, с отставанием на годы, кривое и глючное. Некооперативным вендорам - вот так!
> А много там амд сделала для поддержки опенсорса, для конкурентов?
Представляете, амд и интел это двое ключевых создателей подсистем DRM/KMS/GBM в ядре. Они на пару их пилят с учетом друг друга и там еще всякие etnaviv и проч подыгрывают, даром что конкуренты. А нвидия в этих процессах никто - и звать никак. Ее вообще в рабочих процессах не учитывают, Торвальдс без обиняков назвал их Worst Company Ever. Такая ерунда.
> 2 гигабайта автоматически сгенерированных файлов в дереве ядра не считаются.
Кроме них еще драйвер есть. Нормально интегрированый в майнлайн. И реюзающий сделанную совместными усилиями участников инфраструктуру типа DRM/KMS/GBM подсистем. А невидия в своем закоулке одна альтернативы им пиляет в своем недодрайвере. В результате теперь в топе TOP500 чего-то амд. Так даже нвидии понятно будет имхо :)
> Разве что в сговор с такими же неудачниками из интела вступила, чтобы подгадить,
> это да, не мало. А все ценные части по-прежнему в закрытом драйвере.Закрытый драйвер от амдшников это вообще лол. Его открытые дрова делают в практически всех аспектах. И серьезные игроделы типа Valve комитят в именно открытый драйвер. Им так то тоже оказалось хорошо и удобно. Так что в Steam Deck тоже так то амд. А нвидию отовсюду ссаными тряпками что-то стали. Зажравшаяся мерзкая наглая фирмочка которая всех достала в край.
Ты же понимаешь, что в TOP500 чего-то далеко не игры. А неигры на открытом АМД что-то не очень.
> Ты же понимаешь, что в TOP500 чего-то далеко не игры. А неигры
> на открытом АМД что-то не очень.Вы же понимаете что проприетарных драйверов в ЯДРЕ у AMD вообще не осталось? Их проприетарный юзермод работает поверх открытого ядерного модуля AMDGPU, и вот так модуль может юзать KMS/DRM/GBM подсистемы ядра на ура.
А у фирмы нвидия не хватило вот ума нормальный ядерный опенсорсный драйвер в майнлайн интегрировать. Из-за чего с ними много проблем, переписывать в самопальном виде несколько подсистем ядра это не фунт изюма.
> для полноценной поддержки осталось только научить драйвер делать запросы к GSPДля полноценной - требуется чтобы нвидия стала частью процессов разработки, комитила в майнлайн на общих основаниях и принимала участие в core-подсистемах. Вот тогда всем будет хорошо. Но до нвидии медленно доходят вещи которые стали очевидны почти всем фирмам на планете уже. Но бизнес умеет объяснять. Вон те рейтинги в топ500 прозрачно намекают нвидии где их будущее.
> большинство пользователей в гробу видело опенсорсный стек
А их в гробу видели разработчики линуха со всеми их блобами. Удачи в багрепортах и всем таком. Потом начинаются страшилки что ФС сыпятся и проч - а оказывается нвидияблоб память рушит как черти что. И фиг вы это с блобом зарепортите, так и будете на бочке с порохом курить.
> Не понимаю почему этот коммент заминусован. Nouveau умеет только две вещи: падать, и в редких случаях ускорять 2d-рендеринг. В то время как официальные драйвера мало того что не падают в кернел пикник, так ещё и все фичи поддерживают полноценно.Открытые дрова невидии, исключительно для возможности установки нормальных дров. Как в своё время у винды стоковый "браузер", который был лишь программой для скачивания браузера.
Эти открытые дрова, столь деревянные, что тянут помимо ничего, разве что ничто. Графику в 3д - не тянут, видосы в ютубы качество ниже необходимо ставить, иначе лаги.
Так ещё и мониторить нечем из коробки. Но зато они "ОТКРЫТЫЕ", но бесполезные. Увы.
В этом плане, у амд чуть лучше.
>нормальных дров
>проприетарных, нужна поддержка новых ядер и/или релизов ОС - беги в магаз за новой картой. А ты что хотел - нормальные драйвера денег стоят и фактически по подписке распространяютсяСпасибо, не надо мне такой нормальности.
Заминусован, потому что люди пишут ОТКРЫТЫЙ драйвер, баги исправляют, работают, короче. А тут Вы, опорожниться пришли. Будет и 3д. В своё время. Люди хотят, люди делают, на благо всех. По мере своих возможностей.
А также за то что неправда: в nouveau реализован насколько я помню почти весь GL 4.6 аж. Но отсутствие реклока делает это менее полезным чем могло бы быть.При том вон то упиратеся в основном в отсутствие спеков, нежелание релизить фирмвары для GPU в виде юзабельном для вон тех, а бонусом секурбут-блок их опенсорсных попыток кодить свои фирмвары сервисных процов, раз такая ерунад. В общем инчае чем саботаж и не назовешь. Но это для нвидии явно выходит боком уже. Заслуженно.
Ты не проблем не знаешь, ты не знаешь наличии о таких проблем.
На самом деле зря вы так. Патч уже есть, сейчас его быстро примут и проблему "порешают".
А вот если вспомнить как у Нвидии в дровах обнаружился баг с DMA-BUF из-за которого падал ФФ и Нвидия сказала что в 525-ом драйвере фиксить не будут (поздно мол), впообщелаи исправить в 530, но тоже не смогли и наконец исправили (вроде как) в 535 - вот это дааа, это реально впечатляет.
А виновата точно нв? Точно не могила?
Не Мозилла, они говорят что все по спекам делают, а у Нвидии постоянно "срезанные углы" вылезают тут и там.
Причем до сих пор даже не известно в 535 проблему пофиксили и нет.
Если бы проблема было у всех тогда бы была виновата мозилла, но проблема только у невидии
> к нарушению целостности файловой системы, так как теоретически повреждение памяти ядра может затронуть области, в которых хранятся структуры ФС ext4Вот это мне всегда нравилось в линухах ... Проблема в видеодрайвере, а разваливается FS.
Это в любой немикроядерной ОС возможно, т.к. все части в одном адресном пространстве.
У венды чёт такое было несколько раз. У неё вообще может сыпаться всё, а она будет продолжать делать вид, что всё ок, это намного страшнее. Особенно, учитывая, как часто видеодрайвер падает. А маки ты просто не контролируешь, чёрт его знает, что там падает и рассыпается.
Ну у венды там всё просто (начиная с NT) - глючит видяха, система в панике. Чтоб NTFS разваливался (ну если только от паника) совсем - я не встречал. Ну терялись файлики от неправильного завершения. С маками там всё проще - нет такого зоопарка видях, всё протестировано. Опять же не помню, чтоб из-за видяхи мак падал в панику.
Вот эта штука не всегда отрабатывает идеально, иногда с повреждениями в других частях https://learn.microsoft.com/en-us/windows-hardware/drivers/d... и бсод прилетает по поводу чего-нибудь ещё спустя время (у меня были игрушечки которые вешали видеокарту подозрительно часто, после обновлений проходило). Ну и софт часто остаётся запущенным после сброса видеокарты, это тоже ведёт ко многим непредсказуемым последствиям.
> Чтоб NTFS разваливался (ну если только от паника) совсем - я не встречал.Зато встречал я - вынув файлики с энного количества разваливишихся в хлам нтфс-ов. Самый известный способ это вызвать - глючная RAM.
Вариантов обычно два:
1) Винда начинает лететь в красивый BSOD в ntfs.sys при попытке подцепить диск.
2) Диск не маунтится - и chkdisk не могет это починить.Даже с этим можно справиться. Оно зачастую читается fuse версией NTFS'а или линуксным драйвером. Или же вон там коммерческие "офлайн" читалки есть, которые сами парсят.
У Шинды 98 и FAT32 такое было сколько угодно раз.
У современных виндов видеодрайвер работает в юзер-моде.
Только прилетает бсод с драйвер.sys каждый раз когда ты открываешь веб-браузер и хочешь достать видео из него в отдельное окно. Опять же, там много юзерспейсных дров и они все пострадают, так что одно другому не мешает. Но я подозреваю, что там такая же юзерспейсность, как у линукса с mesa.
Вот не могу понять: с каких помоек вы собираете железо? У меня в последний раз он падал этак во времена 8800GT (но то была проблема известная). А вот так, чтобы рандомно — вообще такого не припомню.
Пространство 64-битное, даже прочитать его всё дохренион времени надо. Вероятность попадание адресов рядом друг с другом при случайной раскладке пренебрижимо мала.
>обращения в коде к уже освобождённой области памятиВидимо у программиста-сишника очки недостаточно тонированные были или хвостик волос жидковат.
Множество хаков на производительность невозможно реализовать на безопасном языке.
А если кому-то нужна была безопасность в этом мире, то уже давно бы отключил спекулятивное исполнение в процах на там же интеле и жил бы с -40% фэпээс и с -90% скорости pcie и nvme.
> Множество хаков на производительность невозможно реализовать на безопасном языке.Use-after-free и "ой, вылез за пределы буфера" - это не хаки на производительность...
Это отсутствие необходимых рантаймовых проверок и оверхеда по памяти на хранение служебной информации.
Вы бы сходили на godbolt хотя бы сначала и посмотрели как асемблер выглядит, прежде чем про рантайм проверки говорить.
Ох уж эти криворукие программисты на С, всем известно что настоящие программисты никогда не совершают ошибок работы с памятью. Это же основная аксиома адептов ненужности раста или языков со сборщиком мусора.
Нормальные програмисты на Си совершают ошибки работы над памятью не чаще чем нормальные электрики совершают ошибки при работе с проводкой
Но у электриков есть естественный отбор, а у программистов нет :-(
Это проблема менеджера программистов.
Не волнуйся, скоро будет. Ты только никуда далеко не уезжа... куда же ты побежал, прихватив чужой трактор?
Кроме тебе никто не считает что существует люди не допускающих ошибок. Но только чтож ты ядро не переписал на раст до сих пор?
Это камень в огород "нинужнистов", которые часто утверждают что если на С программист не может писать безопасный код, то он недопрограммист. И поэтому другие языки безопасные по памяти не нужны, если есть такие мифические программисты.
Безопасные языки это миф.
Гугл топил за джаву на андройде из-за безопасности. В итоге самая дырявая система.
Раст продвигался на безопасности. В итоге элементарные уязвимости даже в базовых вещах вроде пакетного менеджера.
С багами позволяют бороться только мозги и минимальные абстракции (и то и другое не про раст).
Я бы на вашем месте перестал приводить гугл как пример чего-то хорошего. Практически все что они делают - дикий обсёр. Ну кроме продажи твоих данных.
Ну зачем же так категорично. Гугл иногда и правильные решения принимает. Недавно ио-урину на мороз выпнули.
>С багами позволяют бороться только мозги и минимальные абстракцииНу давай тогда на ассемблере все писать по такой логике. Или можно вообще не писать и тогда точно багов не будет
> вообще не писать и тогда точно багов не будетзолотые слова Юрий Венедиктович. Перефразирую: "Не ошибается тот, кто никего не делает".
> Раст продвигался на безопасности. В итоге элементарные уязвимости даже в базовых вещахРаст продвигался на безопасной работе с памятью. Возможно, уважаемый эксперт покажет хоть одну уязвимость с use-after-free на Расте?
А других уязвимостей уже не существует?
> Раст продвигался на безопасной работе с памятью. Возможно, уважаемый эксперт покажет хоть
> одну уязвимость с use-after-free на Расте?Вообще вон там на списке CVE - вулнов софта на расте уже на все вкусы. Даже ошибки работы с памятью, как ни странно :)
Безопасная работа с памятью - это не про отсутствие багов, а сугубо про работу с памятью. Одна из самых распространенных проблем с С.Но все равно полно людей: нашли логический баг, гы, а говорили безопасный.
Какое наглое вранье. Прочтите их декабрьский отчет про ошибки в андроиде. Про то, насколько кардинально там уменьшилось кол-во ошибок, связанных с неправильной работой с памятью, когда они в последние две версии андроида в новом коде интенсивнее пихали по-больше безопасных языков (ява+котлин+раст) в ущерб си/плюсам.Насчет "зверской дырявости". Это как почтальон Печкин говорил: " - Это почему я такой злой был...". Теперь андроид может сказать: " - Это чего я раньше такой дырявый был? Потому что много нативного кода на Си/плюсах было. Не говоря уж о монолитном дырявом ядре на си. А теперь новые нативные подситемы мне пытаются на расте писАть! Говорят, скоро и в линух-ядре на расте начнут что-то пописывать!"
Memory Safe Languages in Android 13
https://security.googleblog.com/2022/12/memory-safe-language...
Вот я и говорю, адепты безопасного кода на С воруют, что "нормально пиши - нормально будет", а все что в таком количестве всплывает - это Васяны программисты недоучки. Гикачады программисты некогда не сделают ошибку при работе с памятью.
Безусловно, лучше быть богатым и здоровым, чем бедным и больным. Проблема в том, что люди неидеальны, не в идеальном мире живут.
Простой пример: когда болгаркой работаете, кожух надеваете? А зачем? Нормальный работник ведь ошибок не совершает.
> Это же основная аксиома адептов ненужности растатак раст и не нужен - касанчик всё нашёл, патч готов, а кукаретики теоретизируют что может быть повреждена фс, а может не может. Тут кстати нет ошибки работы с памятью - в одном из потоков не поставили спинлок, что привело косвенно к UAF.
> так раст и не нужен - касанчик всё нашёл, патч готов,а, так это была самая последняя подобная ошибка в ядре? Всё, больше не будет? Все там научились правильно код писАть? Это наверное ты им показал как надо? Ну, теперь заживем... Спасибо тебе. Ты там поглядывай изредка, чтобы они снова не сбились с пути истинного, что ты им указал - спинлоки не забывали расставлять, за границы буфера не выходили, дважды не освобождали память или не разыменовывали уже освобожденную ну и кучу всего остального непотребного. Лады?
Все ошибаются и будут ошибаться всегда. Почему ты так переживаешь не написав ни одной строчки кода в ядре ?
Наверное потому что хочет пользовать ядро где минимальное колличество багов, а не тыкать что они не комитят в ядро.
Ну возьми и перепиши ядро на расте, делов-то для военов святой безопастности:)
Уж на пути к этому родной.
Заняты в разработке?Можно посмотреть?
А то я как-то не могу найти примеров универасальной работы, с разными структурами на разных архитектурах.
Что бы, как обычно, структуры данных были разными на разных архитектурах, а код, их обрабатывающий, один. Возможно, кое-где обложенный условной компиляцией.
Где бы подсмотреть как в rust нормально поддерживается множество архитектур?
клиповое программирование на всех фронтах
точнее бекендах
Ну что, UNIX-way помогает?
взгляние на top500
и ответь, помогает или нет?
А для простых пользователей дырки это норма.
И что хоть один из этих топ500 использует nouveau? Спойлер никто не использует.
Как он в монолитном ядре может помочь?
> сбой может привести к нарушению целостности файловой системыОго, зашибись бажина.
Обновил дрова - запорол данные.
Ставь BTRFS. Ну или, хотя бы, бекапы делай.
> Ставь BTRFSСтавь... и? Данные начнут запарываться даже без обновления дров?
Бекапы - мимо. Они вещь в себе и нужны by default. И никак не связаны с типом ФС.
Но восстановить бекап это тоже напряг и шанс на факап. А любого факапа хочется избежать.
У нас ошибка в драйвере, поэтому не пользуйтесь ядром где она возникает. Найс логика. Опеннет теперь пропагандирует новояз?
Решение предложено "автором" бага, опеннет просто репостит новости. Предлагаете цензурить исходные новости?)
посмотри в словарях разницу между словами "воздержаться" и "не пользуйтесь", тогда может иногда не будешь глупо выглядеть.
Подскажите, плиз,
kern : err : ... nouveau ... fifo: CACHE_ERROR - ch 6 [chromium[830]] subc 0 mthd 0060 data beef0201
kern : err : ... nouveau ... fifo: CACHE_ERROR - ch 5 [firefox[771]] subc 0 mthd 0060 data beef0201
kern : err : ... nouveau ... fifo: CACHE_ERROR - ch 2 [wayfire[509]] subc 0 mthd 0060 data beef0201
можно как-то исправить без замены драйвера и видеокарты?
по пробовать для начала пройтись аналогом мемтеста для проверки видеопамяти. если куча ошибок то увы в мусорку. если нету ошибок то сочетанием разных версий ядра и драйвера найти рабочий вариант.
Спасибо и на том. Bug report, если отправить, то это же Nouveau Linux DRM Driver виноват или Mesa, может быть?
> Спасибо и на том. Bug report, если отправить, то это же Nouveau
> Linux DRM Driver виноват или Mesa, может быть?Ну если kern и оно же валится в dmesg - тогда это ядерный модуль бухтит, это DRM/KMS часть nouveau которая в ядре так ругается, стало быть. Ну и запостить это в баг. Только вот стоит проверить на максимально свежем ядре сперва, что оно все еще актуально. Лучше на 6.4-rc который вот-вот окончательно релизнется.
>сбой может привести к нарушению целостности файловой системыТаненбаум был прав! Будущее за микроядром!
>Таненбаум был прав! Будущее за микроядром!Будущее только там где не ретранслируют , а делают , вас таких маститых много вот кто то сказал вперед , а смотришь они не делают что бы доказать , а только ретранслируют
Проект будущего GNU/Hurd как раз нуждается в энергичных программистах, готовых это будущее приближать. Присоединяйся. Кодить-то умеешь или только на опеннете комментарии пишешь?
Проект Genode/Sculpt уже реальное настоящее, вполне себе.
> Таненбаум был прав! Будущее за микроядром!"Будущее за микроядром!" так думал Таненбаум 36 лет назад. Но оно почему-то все откладывается.
>MINIX (from mini-Unix) is a Unix-like operating system based on a microkernel architecture.
>Platforms Intel Management EngineПопулярнее всех билдов и портов Unix-подобных ОС, установленных на десктопах, вместе взятых.
Причём, особенно популярна среди вендузятников.
уже всё не так однозначно. Теоретически, если ты будешь писАть монолит на безопасном языке, то ошибки, конечно не исчезнут, но их кол-во кардинально снизится, а производительность пострадает значительно меньше, чем с микроядром. Этакий компромисс - на порядки больше безопасности и надежности (но не абсолютные) при почти той же производительности. Чисто теоретически.
> писАтьТы считаешь, в таком контексте это слово можно прочитать по-другому?
А могли бы использовать пивас-студию и не допускать глупых ошибок.
Это возможно только в том случае, если квас-студия знает семантику и контекст этих операций, в чём я лично сомневаюсь, но всегда можно помечтать о нейросети, обученной на мануалах к АПИ например, ка вариант.
Она, конечно, не панацея. Но количество глупых (а часто и неочевидных) ошибок помогает сократить просто радикально.
Зачем проверять свой код, если можно переписать все на другом языке программирования с CoC-ом?
Народ, а никто не заметил этой строчки в патче:> Кажется, что это существовало всегда, но теперь стало более заметным после того, как 9bff18d13473a9fdf81d5158248472a9d8ecf2bd (drm/ttm: использовать на BO cleanup workers)
Как сами понимаете, всё на самом деле намного хуже, чем нам преподнесли в новости
Все прекрасно кроме одного. Вечером комп включился, прилетело обновление ядра на Lubuntu 6.хх, и после перезагрузки комп фсе, черный экран после груба. Ну и курсор мыши посередине на черном фоне...
ну так выбери в грубе старое ядро, чо ты как маленький
Что-то судя по патчу и описанию проблемы там проблемы с архитектурой. Исправление в виде "обложили спинлоком, авось не упадёт" (значит падать будет, но реже).Ни разу не фанат раста, но вроде там сам язык спроектирован под многопоточность, поэтому такой кошмарный ковбойский код писать должно быть труднее.
>спроектирован подрандомные труднодиагностируемые непонятные баги и непредсказуемое поведение вроде зависаний "ни на чём" ты хотел сказать, нефанат раста ты наш дорогой.
Так пиши, в чем дело? Кто-то запрещает?