Ядрото на Linux е гръбнакът на операционните системи (OS) на Linux и е основният интерфейс между хардуера на компютъра и неговите процеси.
Преди няколко дни в сайта на „Linux Journal“ беше споделена публикация в която поговори малко за темите, обсъждани на Open Source Summit Europe, в които Джонатан Корбет, разработчик на ядрото на Linux, спомена малко за посоката, която ще поеме развитието в рамките на ядрото на Linux през следващите години.
Публикацията подчертава с голямо значение въпроса за разработването на LTS версиите на Linux, което в момента и в бъдеще може да бъде голям проблем, като се имат предвид характеристиките на тези версии, особено въпросът с времето за поддръжка, което имат. тези.
И в публикацията споменава се, че Разработчици на ядрото на Linux, стрТе възнамеряват да се ограничат до двугодишен цикъл на актуализиране за LTS клонове на ядрото на Linux. Формално времето за поддръжка на LTS версиите остава 2 години, тНо през последните пет години периодът издание на актуализация е удължен на 6 години ако ядрото продължава да бъде търсено и представителите на индустрията са готови да помогнат на разработчиците да осигурят поддръжка.
В бъдеще, Това удължаване е под въпрос, тъй като има спад на интереса относно използването на стари LTS ядра: повечето потребители пренасят своите продукти към по-нови клонове на ядрото рано и 6 години се възприемат като прекомерен период.
Освен това, тъй като броят на LTS версиите се увеличава, увеличава тежестта върху поддържащите, чиято работа става рутинна и се свежда до непрекъсната поддръжка на корекции. Това бреме причинява изтощение на асистента и загуба на интерес към продължаване на работата.
Прегарянето на поддръжката се счита за един от най-сериозните проблеми в общността за разработка на ядрото. Въпреки корпоративната подкрепа, повечето участници в разработката на ядрото действат като доброволци от интерес: само около 200 разработчици от повече от 2.000 активни участници в разработката получават заплащане за работата си. Постоянната монотонност на коригиране на дребни грешки, извършване на размито тестване и преглед на промените изтощава разработчиците и води до загуба на интерес към работата на поддържащия.
Това изгаряне на поддържащия представлява сериозна заплаха, както подчерта Корбет. Поддръжката на Linux до голяма степен е доброволно усилие и само около 200 от повече от 2000 разработчици са платили за своите вноски. Безкрайните изисквания за време на поддържащите, дължащи се на fuzz тестване, коригиране на дребни грешки и преглед на приносите, оказват влияние. Известни поддържащи предупредиха, че се нуждаят от помощ, за да избегнат срив. Компаниите, които зависят от Linux, трябва да осъзнаят, че финансовото връщане е в техен най-добър интерес за поддържане на тази жизненоважна екосистема.
Сред проблемите се подчертава и опасността от появата на клонове на ядрото на Linux, които са отделени от основното ядро и зависят от отделни доставчици. Разклонения като този могат да бъдат резултат от дистрибуции като Red Hat Enterprise Linux, които използват пакети на ядрото, базирани на много стари версии на ядрото с архивирани промени.
Опасността с тези клонове е, че чрез селективно натискане на промени може да пропуснете корекции за уязвимости и сериозни проблеми. Освен това те затрудняват анализирането на възникващите грешки, тъй като не винаги е ясно дали проблемът се проявява в основното ядро или е причинен от специфични за производителя промени.
Споменава се, че по-правилен модел за поддържане на ядрата е да се следва модел, подобен на този на Android, който се основава на прехвърляне на всички промени от основното ядро и разработване на необходимите иновации в основното ядро, вместо поддържане на собствена версия на ядрото, включително промени, специфични за платформата Android.
Моделът за миграция на пълна промяна е полезен предимно от гледна точка на сигурността, тъй като когато кръпките се мигрират селективно, връзката между корекцията и елиминирането на потенциални проблеми със сигурността не винаги е очевидна. Когато промените са напълно мигрирани, проблемът често се разрешава, преди да има информация, че корекцията блокира уязвимостта.
Накрая Ако се интересувате да научите повече за това, можете да проверите подробностите в следваща връзка.