LINUX.ORG.RU

Линус Торвальдс пояснил свою позицию в отношении приёма изменений на Rust

 ,


0

7

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

Линус раскритиковал действия Кристофа Хелвига, мэйнтейнера подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC. По мнению Линуса, Кристоф превысил свои полномочия и попытался повлиять на код, который не затрагивал код подсистемы DMA, был реализован в отдельном подкаталоге и не влиял на код, за который отвечает Кристоф. Кристоф попытался контролировать то, для чего используется подсистема DMA, и его действия можно сравнить с попыткой запрета использования DMA в каком-то драйвере, лишь потому, что ему не понравился этот драйвер. Итог: несмотря на то, что сопровождающие отвечают за свой код, они не отвечают за то, кто и как использует результат работы этого кода.

>>> Письмо Линуса

>>> Подробности (OpenNet)

★★★★★

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

Сами апологеты ООП с начала времён критикуют наследование и говорят использовать вместо него композицию. В большинстве свежих языков нет наследования. А dynamic dispatch есть через трейты и dyn.

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

Да нет, это буквально то, как оно работает сейчас.

So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings.

Не вижу про сейчас.

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

И тебе говорили, что Линус вмешивается, когда проблема не решается сама:

А может нужно было просмотреть из чего эта проблема возникла?

Мне лично сложно представить как 300 разработчиков ядра, сишников, в рассылке обсуждают пихать руст в ядро или нет.

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

нет наследования данных которое тотальный антипаттерн

Геттеры и сеттеры для наследования кода во все поля пихать?

Я, в общем-то, понимаю, для чего нужна инкапсуляция, особенно в больших проектах. Но я понимаю и то, что всё можно довести до абсурда. Вот С++ даёт выбор, написать private или protected. Тут, как я понимаю, решили, что выбор зло?

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

Я конечно не настоящий разработчик но вижу ситуацию так:

Есть модуль А от которого зависят множество модулей Б и РустМодуль. Изменение в модуле А могут ломать РустМодуль но никого больше не ломают (причины не важны). Апи модуля А стабильно и не меняется без обратной совместимости.

Выводы: РустМодуль кандидат на выпиливание из ядра т.к. ломается от дуновения ветра. Либо устраните этот недостаток модуля либо на мороз.

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

Изучи раст и проверяй сам, тут я с финским куколдом согласен. Либо повышать квалификацию, либо не трогать, то, чего не понимаешь.

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

Мне лично сложно представить как 300 разработчиков ядра, сишников, в рассылке обсуждают пихать руст в ядро или нет.

Мне тоже, но ведь этого и не происходит. Происходит обсуждение между 5-10 людьми, которые в этом конфликте представляют какие-то свои стороны. Линус в итоге пришел и сказал то, что я говорил с самого начала: мейнтейнер не может блокировать код вне своей подсистемы, даже если ему очень хочется. Вопрос закрыт.

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

Вот С++ даёт выбор, написать private или protected. Тут, как я понимаю, решили, что выбор зло?

Ваще не понимаешь. Это не имеет смысла без наследования.

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

Неплохо, старый хрен попросил немножечко вынуть, но толстый швед сказал что надо терпеть :-D

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

Ну так все kmalloc'и в ядерном расте и так unsafe. А писать действительно сложнее. Как-то в дискуссии на linkedin мы обсуждали с коллегами кусок BPF'a, который реализован на вычисляемом goto (есть такое расширение gcc). Код там действительно «почти write-only», но работает быстро. Кто-то предложил реализацию того же алгоритма на Rust, оно получилось, но с переусложнением синтаксиса. Надо ли оно такое? По-моему, нет.

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

Но затаскиваемый RUST в ядро выглядит именно как понижение квалификации писателей, иначе зачем им это …

это такой путь китайского комсомольца - создать себе трудности и мужественно их преодолеть. Товарищ, дорогой, си элементарно устарел. Прогресс не стоит не месте, у нас больше не PDP-11, мы можем выделить гораздо больше ресурсов компилятору. Мы можем сделать код выразительнее, проще для понимания, поддержки, расширения. Использование помощников - это не понижение квалификации. А отказ от выразительных современных средств разработки, это позерство и мамкино хакерство, а вовсе не показатель какого-то космического профессионализма.

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

Изменение в модуле А могут ломать РустМодуль но никого больше не ломают (причины не важны). Апи модуля А стабильно и не меняется без обратной совместимости.

Так а как РустМодуль сломался-то, если апи стабильно, что случилось?

unC0Rr ★★★★★
()

У меня есть подозрение, что Кристоф выразил мнение большинства разработчиков ядра, пишущих на Си. Возможно даже подавляющего большинства из них. Тут возможно зреет серьезный конфликт между Линусом и программистами, которые годами вносили вклад в ядро. Линус разумеется как руководитель проекта может хотеть (не важно, по каким причинам) Раст в ядро, но в обход сишных разрабов ядра это сделать не получится. По крайней мере не так просто. Ведь если часть из них форкнет ядро, отзовет свой код из текущего ядра (не в курсе, есть ли такая возможность), и уйдет разрабатывать раст-фри форк, ядро развалится. И его не спасет ни Раст, ни корпы, его продвигающие. Линус наверняка всю серьезность ситуации осознает лучше нас всех здесь, и я ему не завидую.

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

Значит не туда смотришь.

That’s kind of the promise here: there’s that «wall of protection» around C developers that don’t want to deal with Rust issues in the promise that they don’t have to deal with Rust.

Это своего рода обещание.. будет «стена защиты».. не придётся иметь дело с растом. Анекдот какой-то.

Откуда у тебя такая искрящаяся уверенность, что это сработает?

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

Геттеры и сеттеры для наследования кода во все поля пихать?

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

Тут, как я понимаю, решили, что выбор зло?

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

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

Это своего рода обещание.. будет «стена защиты».. не придётся иметь дело с растом. Анекдот какой-то.

Не, это нормальная история. В проект с тысячами разработчиков и десятками почти независимых команд нельзя просто взять и притащить что-то кардинально новое.

Откуда у тебя такая искрящаяся уверенность, что это сработает?

Откуда у тебя тревожность, что нет?

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

При чём тут «русский форум»? Хочешь увести дискуссию в русло, в котором, как тебе кажется, ты что-то сможешь доказать? Растофанбоев, как и фанбоев С полно и тут и там.

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

Откуда у тебя тревожность, что нет?

Тревожность от того, что полномасштабное внедрение ещё и не началось, а конфликты уже возникают.

Как бы не получилось, что будем вспоминать ещё наши любимые ub и segv с теплотой и ностальгией. Было ядро с ошибками, которые чинили, а получаем шанс того, что все перессорятся и разбегутся.

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

А можно в двух словах для абсолютного нуба - а нахрена нужен класс без наследования данных? Тогда не проще писать класс без данных в прицнипе?

LightDiver ★★★★★
()
В тот же час зарыли лодки, изнутри песком забили. 
Что не спрятали — взорвали, остальное растащили, 
саксаулы порубили и решили партизанить 

Тут пришел верблюд с посыльным.
С ним письмо от богдыхана: дескать, что за матерь вашу! 
Всё отрыть и жить, как жили!

Махмуд Исполкомов[1], «Песня о лодочниках»

[1] Псевдоним приписывается Игорю Иртеньеву.

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

Тревожность от того, что полномасштабное внедрение ещё и не началось, а конфликты уже возникают.

Если для тебя это удивительно, значит ты очень наивный юноша.

Как бы не получилось, что будем вспоминать ещё наши любимые ub и segv с теплотой и ностальгией. Было ядро с ошибками, которые чинили, а получаем шанс того, что все перессорятся и разбегутся.

Сходи к психотерапевту, он тебе поможет.

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

А чего еще ожидать, если в этом Русте политической мотивации больше чем инженерного смысла?

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

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

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

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

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

А чего еще ожидать, если в этом Русте политической мотивации больше чем инженерного смысла?

Политической мотивации больше в хейтерах, в самом русте только технический смысл и есть.

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

очень наивный юноша

психотерапевт поможет

Услышал ваш крик о помощи, но здесь ничего поделать не могу.

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

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

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

Услышал ваш крик о помощи, но здесь ничего поделать не могу.

Можешь, сходи к доктору, он тебе пропишет таблеточки, и ты перестанешь тревожиться. Потому, что то ты пишешь, имеет название – «катастрофизация». Вот у тебя она. Иди вылечи её, станет легче.

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

Разработчики ядра здесь явно не сидят.

Комитил в ядро за бабло, спрашивайте ваши ответы. Пересекался почти со всеми людьми в треде из топика.

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

Я не доктор и не могу вам ничего выписать. Прекращайте обсуждать свою личность. Это не приветствуется правилами форума.

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

Я не доктор и не могу вам ничего выписать. Прекращайте обсуждать свою личность. Это не приветствуется правилами форума.

Я обсуждаю твою личность, ты же беспричинно тревожишься. Я тебе говорю: нет объективных причин для тревоги, она только у тебя в голове.

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

Мы можем сделать код выразительнее, проще для понимания, поддержки, расширения.

Ты шутишь? Код на Rust и выразительность, простота для понимания - вещи не совместимые.

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

Ты шутишь? Код на Rust и выразительность, простота для понимания - вещи не совместимые.

Смотря как пишешь.

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

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

Эта проблема не нова. То же самое и без раста: если какой-то маинтайнер ломает АБИ своей подсистемы, он и сейчас должен обговорить это со всеми пользователями его подсистемы, убедить их, что такие изменения и правда нужны, и сделать с ними вместе кумулятивный патч, который бы всех пепресаживал на новый АБИ.

То есть, игнорировать собственных «юзеров» можно ровно до тех пор, пока ты не ломаешь АБИ. И не важно, эти юзера на С или на расте сидят.

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

люди с низким знанием архитектуры

люди с низкой социальной ответственностью.

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

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

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

То есть, игнорировать собственных «юзеров» можно ровно до тех пор, пока ты не ломаешь АБИ. И не важно, эти юзера на С или на расте сидят.

В случае с Rust’ом есть договоренность что если мейнтейнер не готов, то крабы сами починят.

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

В том то и вопрос с какого перепугу ломается только раст модуль. Значит апи стабильно, иначе ломались бы все.

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

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

Расценивай ради бога.

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

Осуждаю. Теперь после внесения любых изменений в си-коде подсистемы DMA,

Не любых, а только ломающих АБИ. Огромная разница.

придётся проверять собираемость раст-компонентов, которые от неё зависят.

Это CI проверит автоматически. Ничего нового, при поломке АБИ, отваливается не только раст.

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

Это не так, к сожалению — https://users.rust-lang.org/t/rust-says-tech-will-always-be-political/43627

Вся эта борьба за безопасную память началась с политических заявлений руководства разведовательных и прочих отвечающих за безопасность ведомств Штатов на тему «обеспокоенности, что утечки памяти являются причиной большинства ошибок в программах». Типа придумал генерал себе жупел и понеслось... Я сейчас не могу найти этот меморандум, но в сети он мне попадался.

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

ты пол что-ли сменил? так мы все равно узнаем

То говно, то смена пола. LOR как всегда.

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

Мейнтейнеры Rust их чинят.

А вот и зависимость. А если не чинят? Не хотят, не могут, нет времени и желания? Что это за бред вообще? Это же буквально рычаг давления со стороны фанатиков раста на си-работяг.

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

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

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

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

А где в этом ПОЛИТИЧЕСКИЕ заявления? Это реальная техническая проблема с реальным техническим решением.

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