През целия месец февруари бяхме споделяне на различни новини за случай на проблеми и разногласия които са генерирани в общността на разработчиците на ядрото на Linux за развитие в Rust.
дори Някои от силните играчи в общността обявиха позицията си и още по-лошо, някои са се отказали от длъжностите си като поддържащи в някои от подсистемите на ядрото на Linux.
Предвид тази вълна от дискусии, която изглежда излиза извън контрол, Линус Торвалдс е взел нещата в свои ръце. y се присъедини към дискусията наоколо на съпротивата на някои поддържащи срещу въвеждането на Rust в ядрото на Linux.
Според Линус никой поддържащ не е принуден да учи, използва или дори да разгледа кода, написан в Ръжда, ако не го искаш, тъй като те могат да продължат да работят изключително с C.
В сряда, 19 февруари 2025 г. в 22:42 ч., Кристоф Хелвиг написа:
>
Документът гласи, че не е необходима подсистема за използване на Rust. Това е доказано.
> греши за Линус. И въпреки че може да не сте го знаели кога
> Когато сте написали документа, вие абсолютно сте го направили, като сте го публикували в списъка.Бях обнадежден и го опитах, за да видя дали тази дълга нишка ще даде резултати.
в нещо градивно, но това изглежда се връща назад (или поне
поне не напред).Факт е, че заявката за изтегляне, срещу която възразихте, НЕ ДОкосна DMA
СЛОЯ ИЗОБЩО.Той буквално беше просто друг потребител, в напълно отделна ситуация.
поддиректория, която не е променила кода, който поддържате по никакъв начин,
форма или форма.
Обаче, ако поддържащият реши да не се включва, той или тя също няма да има възможност да влияе в начина, по който е разработен, нито да повлияе на това как външните му връзки са интегрирани в кода на собствената му подсистема.
Торвалдс обясни това тези поддържащи, които се интересуват да продължат напред с Руст ще могат да участват в развитието му, да влияят на строителството на връзки и подпомагане на поддръжката на съответните интерфейси. Обратно, онези, които изберат да не работят с Rust, ще бъдат защитени от проблемите, които могат да възникнат при използването му, но също така ще бъдат изключени от влияние върху неговото развитие. Този подход създава един вид бариера, която, докато защитава онези, които са посветени изключително на C, в същото време им пречи да допринесат за подобряването на интеграцията на Rust.
Така че този имейл не е за никаква „политика за ръжда“. Този имейл е за a
Много по-голям проблем: като поддържащ, вие отговаряте за вашия код,
Разбира се, но вие не отговаряте за това кой и как ще използва крайния резултат.Не е нужно да харесваш Rust. Не е нужно да се тревожите за него. това е…
Още от самото начало стана ясно, че никой не е такъв
принудени внезапно да трябва да научат нов език и че хората, които
Ако искате да работите изключително от страната C, можете да продължите да го правите.
Тази ситуация създава по някакъв начин защитна бариера.за тези, които работят само с C, като ги изолира от сложностите и потенциалните недостатъци, свързани с това към кода Rust. Но в същото време същата тази изолация им пречи да влияят на напредъка на Rust, което означава, че мотото „никой не трябва да се занимава с Rust“ не позволява на всеки поддържащ да блокира всеки код, написан на този език.
La организирано е разпределението на отговорностите така че тези, които се интересуват от Rust, могат да работят върху неговите аспекти, докато тези, които изберат да не се включват, няма да бъдат принудени да променят работния си процес, въпреки че няма да могат да променят разработката на компоненти, написани на Rust.
Противоречието се засили, когато възникна въпросът за одобрението на връзката на Rust чрез подсистемата DMA. В този случай съпротивата на поддържащия, който се опита да блокира приемането на такива връзки, беше игнорирана и Линус открито критикува действията на Кристоф Хелуиг.
Според Торвалдс Хелуиг е превишил правомощията си. като се опитва да повлияе на код, който, тъй като е внедрен в отделна поддиректория, не засяга DMA подсистемата, за която отговаря. По думите на Торвалдс, отношението на Хелуиг е подобно на опит да деактивира DMA в контролер, просто защото не му харесва, което е неприемливо.
В крайна сметка, въпреки че всеки поддържащ е отговорен за собствения си код, от него не може да се изисква да контролира как се използва този код или да вземе решение за интегрирането му в по-големи проекти.