LINUX.ORG.RU

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

Leupold_cat ★★★★★
()

Драйверы пишут не макаки, а искусственный интеллект, который так называется, потому что искушен в написании драйверов.

Irma ★★
()

А по ссылке в твой профиль — макака, не умеющая отличать «панику» в программе на расте от kernel panic.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)

В Кубере запускаешь LXE виртуалки на нужной железке, а дрова в виртуалках.

Если одна вязанка дров разваливается, автоматически переключается на другую :)

Добавлять ИИ по вкусу.

sanyo1234
()

что это? какое ядро? это так на 6.7 перешел? у меня void прекрасно работает даже на пне, собственно с пня все и началось это уже потом стал на другие машины его ставить, но я не обновляю ядра пока система сама этого не захочет.

amd_amd ★★★★★
()

Плакай ещё. Подставил кубок для твоих слёз

Ждём драйверов на расте с нетерпением! (:

anonymous-angler ★☆
()

Иногда программы должны паниковать, потому что обрабатывать можно и нужно не все ошибки. Да и странное тут противопоставление, будто код на С свалиться не может. Раст по своему дизайну наоборот снижает вероятность ошибки со стороны разработчика, хоть и не исключает её.

Ghostwolf ★★★★★
()

Вот то что failed to panic - это плохо. Должно было упасть.

Dark_SavanT ★★★★★
()

А что, они хуже C-макак?

[    4.055709] [drm:smu_v11_0_i2c_transmit [amdgpu]] *ERROR* Received I2C_NAK_7B_ADDR_NOACK !!!
[    4.055921] [drm:smu_v11_0_i2c_xfer [amdgpu]] *ERROR* WriteI2CData() - I2C error occurred :1
[    4.056101] [drm:amdgpu_ras_eeprom_init [amdgpu]] *ERROR* Failed to read EEPROM table header, res:-5

gpuhang показывать не буду, не хочу сессию сбрасывать в итоге

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

Только этот пример показывает что ошибки таки обрабатываются, а не валится ядро с page fault

cobold ★★★★★
()

По-моему это не апстрим, а какие-то эксперименты на локалхосте

alex1101
()

Кто бы сомневался…

dimgel ★★★★★
()

ACPI Error

Черт с ним, с растом, когда ACPI перестанет быть проблемой? Мне на домашнем лаптопе пришлось ядро откатывать из-за этого.

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

это нормально, большая удача, что амдгпу хоть как-то работает

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

Не знаю, это не моё. А смысл в том, что в расте этот unwrap на каждый чих. Это типичный стиль обработки ошибок: просто сделай unwrap.

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

Дано: в ядре linux 10 миллионов строк.
Вопрос: на сколько мегабайт оно распухнет (за счёт информации о строках исходников), если его целиком переписать на раст?

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)

Вспомнилось недавнее письмо Линуса с вопросом, как некомпилируемый код попал ему на ревью. Код от интело-макак, если не ошибаюсь, в такой корпорации должен быть отточенный процесс, чтобы не обосраться при посылке патчей на всё сообщество. А вы до раста докопались.

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

в расте этот unwrap на каждый чих. Это типичный стиль обработки ошибок: просто сделай unwrap.

Ну это не проблема, это просто проброс ошибки уровнем выше.

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

В общем я это к тому, что не важно, насколько просто писать плохой код. Важно, насколько сложно писать хороший код.

А это вообще даже не ядерный модуль, насколько я понял. И поведение проги абсолютно нормальное. Ей нужна rw /tmp, т.к. она в неё должна писать. Прога писать не может и завершается с сообщением об ошибке.
Всё, что нужно знать об ошибке тебе сказано. Оформление не очень? Ну всяко лучше чем sigsegv core dumped.

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

Это mount.bcachefs. И вот эта бага в нём.

ТС просто развёл клоунаду на пустом месте.

intelfx ★★★★★
()

Это всё диверсия Микрософта, чтобы сделать так, чтобы дни Ляликса были сочтены.

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

Ну да, а в C практика вообще забывать, что можно в чужую память насрать. А там - дело случая - может упадёт, а может и логины отправить к Пупкину. unwrap упадёт всегда.

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

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

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

Ну это не проблема, это просто проброс ошибки уровнем выше.

Ты путаешь. Unwrap это не проброс ошибки. Это panic в случае ошибки. Разные вещи.

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

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

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

Не видел что-ли код уже написанных драйверов, где половина кода в unsafe блоках?

Пока везло.

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

В интеле может и макаки, но Линус сам читать сообщения компилятора не умеет и решил, что .c включается в .h, потому что он задом наперёд прочитал что куда включается.

unC0Rr ★★★★★
()

А вот написали бы на крестах...

yu-boot ★★★★
()
Ответ на: комментарий от rupert

Ты путаешь. Unwrap это не проброс ошибки. Это panic в случае ошибки.

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

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

Дано: в ядре linux 10 миллионов строк.
Вопрос: на сколько мегабайт оно распухнет (за счёт информации о строках исходников), если его целиком переписать на раст?

Ответ: станет больше примерно на -5 миллионов.

Ты только memset'ы поубирай - уже процентов 5%.

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

А по ссылке в твой профиль — макака, не умеющая отличать «панику» в программе на расте от kernel panic.

В его словах есть вполне разумное зерно. От количества .unwrap() в коде на Rust у меня глаза на лоб лезут. Нахрен все эти Result или Option нужны, если на них болт кладётся? Для сравнения, в хачкелле я вживую fromJust или fromRight (аналоги растового unwrap() для разных типов) вообще не встречал, только в каком-нибудь тестовом коде.

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

Нахрен все эти Result или Option нужны, если на них болт кладётся

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

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

в хачкелле

Ну ты сравнил жопу с пальцем (или палец с жопой, в зависимости от твоих предпочтений). Когда у тебя мир сферических в вакууме структур данных и чистых вычислений, fromJust/Left/Right не нужен, да.

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

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

Как это связано со сраньём в память? Здесь тупо игнорирование ошибок при возврате из функций. Работа с памятью вообще ортогональна.

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

Ну вот на Rust я пока вижу гораздо больше грязного кода. Большинство библиотек из crates.io – лютейший кал, от которого плеваться хочется. Вроде есть библиотечка, даже решает какую-то из твоих проблем, но смотришь внутрь – хочется сразу руки помыть.

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

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

Как это связано со сраньём в память? Здесь

Мы вроде начали говорить про «все эти Result и Option», то есть про общий случай.

Ну вот на Rust я пока вижу гораздо больше грязного кода

Это совершенно ожидаемо, т. к. порог вхождения ниже, а хайпа больше.

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

Ну, всё так. 95% от населения Земли никуда не исчезло, где-то оно будет в любом случае.

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

Как это связано со сраньём в память? Здесь

Мы вроде начали говорить про «все эти Result и Option», то есть про общий случай.

Result и Option как раз используются для передачи кодов ошибок. Память тут просто нигде даже близко не лежала.

Это совершенно ожидаемо, т. к. порог вхождения ниже, а хайпа больше.

Ниже чем куда? Я бы не сказал, что порог вхождения в C или C++ когда-либо был особенно высок.

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

Result и Option как раз используются для передачи кодов ошибок. Память тут просто нигде даже близко не лежала

Result да, а Option используется там, где в сишке был бы NULL (или stale pointer).

Ниже чем куда?

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

Не знаю готов ли я к драйверам, а вот к программам от растомакак я уже с ОСОБЫМ вниманием отношусь. Тот же zellij(tmux на стероидах) со старта может жрать по 150-300 мб и со временем протекать до 2-4 Гб. И даже если не учитывать утечки, то все равно не понятно почему оно так много жрет. На эту память я могу емакс запустить, но в емаксе целая ОС, а не просто терминальный мультиплексор, а если мне понадобится консольный минимализм, то того же tmux-a с его 4-10мб за глаза хватит. Не мне говорить, конечно, но такое чувство, что бОльшинство растософта пишут люди, которые пришли из питона или ЖС, т.е. сотни лефтпадов для маленького проекта - это норма, отсутствие архитектуры - норма, забота о памяти - да кому она нужна? Какие-то альтернативные умы приманиваются к этому языки, чудеса. Могу только helix похвалить, но для него рантайм на 1гб+ нужен для работы всей функциональности из коробки(можно не собирать рантайм, но тогда редактор становится не лучше обычного vi, разве что мультикурсор завезли).

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

Result да, а Option используется там, где в сишке был бы NULL (или stale pointer).

Мммм… я в сишке в основном видел другое: передачу указателя на результат в функцию и код возврата как индикатор успешности. NULL в сишке только для создания указателей. Ну да и похрен.

По хорошему, ничто не мешает в сишке сделать *(void*)0 вполне определённой операцией (не UB), кидающей стектрейс из места, где она произошла. И это даже к потере производительности не приведёт. Просто сишники скорее будут в жопу долбиться огромной оглоблей, чем выкинут чудовищные костыли из 80х.

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

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

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

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

apt_install_lrzsz ★★★
()

И где тут драйвера, ядро, вот это вот все, а не рандомный скрин растохейтера из интернетов?

Так хотелось выебнуться, а вышло вовсе и не так, да? :)

Gonzo ★★★★★
()

растамакаками

Как вижу в трекере эту тему, сразу хочется переслушать ToTo - Растафарай. Хотя казалось бы, какая связь, разве только в названии и там, и там «раста». :)

krasnh ★★★
()

растамакаками

Растомакаками.

Nervous ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)