Rust в Linux: Мощен инструмент – но как да намерим точния баланс?

Разгорещеният дебат относно включването на Rust в ядрото на Linux продължава от доста време в хакерската общност. Повечето от нас разпознават както шума, така и колебанията относно него. Досега повечето от дискусиите бяха фокусирани върху непосредствени въпроси, като ползите за сигурността на Rust и предизвикателствата при интегрирането му в съществуващата C-базирана екосистема. Сега, когато Линус Торвалдс се присъедини към тази идея , Rust вече започна да си проправя път в изходния код на нашата любима операционна система.

Следователно истинският въпрос не е дали да използваме Rust в ядрото на Linux, а как . В края на краищата, Rust не е просто още един език за програмиране; това е и напълно развита философия на дизайна. Това не е надграждане на C с по-малко бъгове, повреждащи паметта, а система за писане на код, която налага строг набор от правила, като по този начин предотвратява много потенциални грешки. Вярвам, че това е ключовият аспект, който трябва да имаме предвид, когато вграждаме Rust в ядрото на Linux.

Останете ефективни и адаптивни

Според изследване на организационната двусмисленост , много мащабни проекти като Linux трябва непрекъснато да участват в два вида дейности, за да останат адаптивни, подходящи и успешни:

1. Експлоатация: Ефективност, усъвършенстване и изпълнение. В Linux това се отнася до дейности като оптимизиране на функции, коригиране на грешки и справяне с проблемите на съществуващите потребители.
2. Проучване: Експериментиране, поемане на риск и иновация. Тези дейности позволяват на проекти като Linux да разработват нови подходи, да се адаптират към разрушителни технологии и да отговарят на променящите се потребителски очаквания.

Изследванията също така показват, че краткосрочно ориентираните експлоатационни дейности са склонни да изместват дългосрочно ориентираните проучвателни дейности . Това е като да искате да научите ново умение или да работите по нетрадиционен проект, но вместо това винаги давате приоритет на ежедневните задачи. Същото важи и за големи проекти като Linux; ако се фокусират твърде много върху краткосрочната ефективност, те рискуват да остареят в дългосрочен план. Светът продължава да се променя, докато проектът остава същият, което прави предложенията му все по-неподходящи за развиващите се нужди на потребителите.

Постигане на точния баланс

От една страна, приемането на Rust е много нетрадиционен експеримент, който може да се разглежда като изследователска дейност за Linux. От тази гледна точка включването на Rust е добре обосновано. От друга страна обаче, за разлика от C, който приема всички видове лудост и недефинирано поведение с отворени обятия, което го прави предпочитан език за хакване на ниско ниво, Rust има вътрешна бюрокрация, която налага определен структуриран начин за писане на код. В известен смисъл Rust функционира и като език за програмиране, и като система за управление на процеси, подобно на методологии като Six Sigma. Специфичен, структуриран начин на писане на код със сигурност може да помогне за рационализиране на процесите и подобряване на краткосрочните резултати, като например уязвимости в сигурността и проблеми с надеждността. Въпреки това, точно както в случаите на други системи за управление на процеси , тази твърдост също така въвежда рискове за дългосрочната гъвкавост и адаптивност.

Следователно заслугите на Rust в рационализирането на процесите и правенето им по-безопасни ще блестят особено в компонентите на ядрото, където дългосрочната адаптивност е по-малко критична. Например драйверите на устройства взаимодействат директно с външни входове и са компоненти с висок риск по отношение на безопасността и надеждността на паметта. Следователно има смисъл да ги напишете с Rust. Те също така имат относително по-кратък живот, тъй като новите устройства често заменят старите. С други думи, загрижеността, че методологията на Rust може да намали проучването или възможността в крайна сметка да искаме да се отдалечим от Rust поради промени във философиите за писане на код, става по-малко уместна. Когато драйвер на устройство е разработен с Rust, той обикновено е по-безопасен и по-надежден и други компоненти не са изградени върху този код. В резултат на това не принуждава никого към определен начин на писане на код след няколко десетилетия.

За разлика от това, основните компоненти на ядрото, като планировчика, трябва да останат адаптивни, за да посрещнат бъдещи предизвикателства и нови парадигми. Използването на Rust в тези области може да доведе до твърдост, която възпрепятства изследването и води до остаряване. Мислете за това по следния начин: Бъдещият код трябва да се основава на компонентите, които се изграждат днес, и когато в крайна сметка една различна философия за писане на софтуер се окаже по-изгодна в бъдеще, изключително гъвкавият C код обикновено може да се променя постепенно, докато не бъде трансформиран в новия подход (постепенно стратегическо обновяване). За разлика от това, Rust настоява за свой собствен начин на писане на код, така че това вероятно ще доведе до дилема дали да продължим да се развиваме със стария подход срещу писането му от нулата. Като се има предвид, че свободният софтуер винаги е имал трудности при намирането на достатъчен брой квалифицирани и редовни доброволци, както и достатъчно редовно финансиране, постепенното подобряване винаги е много по-лесно, отколкото да решите да предприемете голям проект като изхвърляне на компонент и писане от нулата. Следователно всеки език, който настоява за конкретен начин на писане на код, може да се превърне в пасив в бъдеще, принуждавайки Linux да продължи с по-стар начин на писане на код и да загуби своята авангардна позиция.

Накратко, предлагам хибридна стратегия, в която Rust се използва повече за краткосрочни компоненти, където сигурността е от решаващо значение, докато C – най-пъргавият език, който не е специфичен за хардуера – е с приоритет за дългосрочни компоненти, за да се поддържа гъвкавост за бъдещи парадигми и подходи.